I have a morsel I've been sitting on awhile. But instead of just coming right out and telling it to everyone, I wanted to see if I could encourage my fellow scripters to think outside the box a bit.

I've thought up a technique that completely queues a desired macro on the server before any of said macro begins executing. This completely eliminates the risk of a macro being divided up into separate packets, and so there is no longer a risk of the macro stalling due to latency.

Any takers? How can one accomplish this? I'll give a hint tomorrow if no one guesses it.

+EP+

Ok here's my guess.
I would say you are sending a <break> to the server that stops execution for a short period of time and then sends all commands at once just as if it were in 1 single packet.  Spaces or CN9 would still need to be used to bypass loading screen displays I would think.

Actually the game isn't important enough for me or anyone on my corp to be in the game at extern every night to prevent you from getting in.   Persistance is a good quality in a tradewars player.  Then there are some cases were it's bad.  I hate pushy salesmen. lol
 

Well sending stuff within the same packet and caching stuff on the server are 2 different things. You can get stuff sent within the same packet by holding execution for a small bit or by enlarging your own packet size and then sending everything within the same send. But that doesn't guarantee that execution won't start half-way thru the burst, I'm not convinced that twgs runs directly from the packet anyway... I believe there's a command buffer of some sort.

Caching stuff before execution is a different task completely. In that case you could have commands fragmented over multiple packets but the burst would still be processed into the command buffer at the same time. This won't bypass move delay, it won't bypass xport lag, it won't bypass any kind of game lag or max cpc issue (atleast I don't think it will), but I guess if you're having a lot of trouble with your packets getting split and that is causing problems for you, then I guess it might help.

I do something similar to the first by just using waitFor...



Then send the burst. That ensures that no other commands are waiting in the buffer before I send my stuff. I do something similar in my pgridder.

The 2nd, I have no clue how to do. I know of no way to get TWGS to hold my commands until exection, but that's not saying there isn't a way. I have no idea how that would impact CPC or if we'd just forcing it all into the buffer, not actual execution. If there's a way to say "start buffer" and then "end buffer" ... The telnet protocol provides a number commands. Whether TWGS can handle them or not is a story all to itself... TWGS doesn't always behave as a complete telnet server. TWGS doesn't respond to ansi codes so an escape wouldn't do it...

 Neat...
 
  How much more balante do i have to be:
 
~14 and counting~

Okay, hint time.

There are a few delays built into twgs that can't be circumvented. One of these has proved to be something of a nemesis of mine, and i'm convinced that there is no way to avoid it. And like my dear old Dad used to say, "Get yer head out yer arse." Wait, not it was GrandPa... "If you can't beat 'em, join 'em". And so, you can put a few of these delays at the beginning of a macro, giving laggy packets time to cache up.

+EP+

Well this is where you are throwing me.  You are saying macro, and a macro to me is text and spaces sent to the comand line.  To use delays or waits, would then make it a script.  I'm still not quite understanding what you mean.  Delaying execution at the beginning of the script shouldn't allow seperate packets to be sent as one packet.

Hehe, I had the same question... so let me explain it the way he did.

If you have a string of commands... say...



Normally all of this gets executed together. But what if the packet is split between z a 99999 * and the warp to terra? What if the 2nd packet isn't received by the server for another, say, 100ms?

Well in that case you're vulnerable to getting torped, right?

So what if there was a way to pause execution of the first block of commands until the 2nd block was sure to be received? That way both blocks have been received and the entire string has been reconstructed together and is ready to be executed by the server...

They might still be sent as seperate packets, but the server will have received both by the time it starts executing the first set.

In reality I'm not sure how useful this would be. The MTU of your typical ethernet is like 1500, dialup is like 576. That's the max number of bytes in a packet. This means that dialup packets are more likely to be split up than, say, cable, but if you're doing a lot of gridding on dialup then maybe something like this could help a little bit.

Ah ok, that makes more sense.  I was reading that he was going to send seperate packes as one, when he was actually saying that this will avoid sending 1 packet as seperate packets.

Well it won't neccessarily do that, what it will do is allow the server enough time to catch up and reconstruct any split packets. You can't control if a packet is going to be split or not, but you can control how the packets are processed on the other end.

As i recall there is also a limit to the number of commands per cycle. (Not sure if that still exist or if everybody just sets to 255 these days.
Thinking through what EP said. If you could buffer everything so that is always parsed in one chunk by the server would be great. Some stuff I'm not sure you can overcome:
Windows Thread Switching - 10 MS time slices. You may or may not be able to get into that with a long macro.
Multi Thread vs Hyper thread vs Dual Cored. These will all handle data switching differently, and I don't believe this can really be overcome by the scripter.
As to the MTU discussion, keep in mind the 1500 MTU also includes overhead. At the same time, if you are sending 1500 bytes as a string WTF! That is a ton of data for a burst to accomplish. As to fitting it in one packet, u always want Nagel (sp) turned off by your system, as that will packet buffer.
I'd be curious to know what EP has in mind.

Thinking about that more. Actually, if the theory is that you are "waiting" on the server to get the whole macro, any macro could begin with something that does nothing, except burn clock cycles (any key stroke that does not cause a reaction from the server, I would suggest a string of commands, followed by backspace characters) so that the "initial macro" which does nothing is executing and wasting CPU cycles while the rest of the important data arrives and is processed immediately.
It has been too long for me to recall what would be some good keystrokes to do that. Sorry, too busy playing wow to dig out my old TW scripts to read over them.

Yea, CPC exists. Talked about that w/ EP and it's something we'll need to test at some point, but I doubt this would bypass the CPC limit. The goal is just to get everything at the server together, so your packets don't get processed seperately.

Basically you're just doing something that burns clock cycles. Some are more effective at this, and his is unique to him... so he made me promise not to say anything till he does. You'll smack yourself when he says it tho... hehe.

There's a bunch of stuff you can't really overcome as a scripter, sadly.

Maybe

Cool, I even got Jhereg thinking about this one

My trick is to preceed the macro with a couple of course plots. TWGS will process the first plot immediately, but each subsequent plot delays everything else in your macro by .5 secs each. Absolutely no way to circumvent it. So sending 2 plots = .5 sec delay, 3 plots = 1 sec, etc. So if you prepend 5 plots to your move macro, it will delay execution of the move 2 seconds. That should be more than enough time for even the laggiest dial-up packets to have been received by the server, ensuring zero delay mid-macro due to transmission lag.

I'm also guessing that this gives your macro maximum efficiency during it's first CPU timeslice. I'm not sure I can explain that further, but it seems logical.

Understand that none of this helps a dialup user react to a fig hit, or perform buydowns faster. But it does help ensure that a macro completes as quickly as possible ONCE IT BEGINS PROCESSING. I believe this will prove true for broadband users as well.

This also proves to be a handy trick anytime you need to add a small or random delay mid-macro. Just remember that the first plot introduces no delay so long as it was > .5 secs since your last plot.

+EP+