The Cim goes great!

Fig refresh is painfull.


Lift and Land messages and/ot IG messages preclude ANY play while that is going on.

I couldnt get the game to take a keystroke even thru burst

Ok, let's talk about that a bit. Can you describe exactly what's happening and what should be happening?

@Sing, I added a "quit" delay that's minimum for now, 2 ms, so let me know if you want that higher. Since you get a 2 ms delay for any pause you hit in the game, you will have a 2 ms delay on start as well (unless there's some way to avoid getting a pause on startup).

The latest version with the fixed movement delay is on classictw.com.

Something to keep in mind when doing timing tests is that the first action in a burst of actions will not actually be delayed because the idle time prior to starting the command will absorb the initial delay. So, for example, if you issue 5 move commands, the first move will only have the 250 ms delay, without the 20 ms synch delay. So the total expected time for 5 moves would be 250+270*4. Also note that latency does have an effect. On a local connection, I get 1330 ms for 5 moves, but doing the same macro on a remote connect to twgs.21-6.com I get 1338 ms and on twgs.classictw.com I get 1350 ms. Something that seems to be a quirk of windows telnet is the fact that if I send "@mNNN^M mNNN^M etc", the initial @ gets sent right away, but then the rest of the commands all get sent in one burst, so there ends up being a relatively large delay between the first @ and the move command, and that delay gets measured in my @ time measurement. If I precede the @ with a ".", which does nothing, I can force the @ to be included with the other commands in one burst, without this delay. This just illustrates what happens if, for whatever reason, the command buffer is split. All commands processed in a single buffer will run at full speed, but any split in the buffer will introduce additional delay. I'm not sure if I can do anything to change that.

Happy thanksgiving!

Just putting info out there John...

Could have been a client side issue.

Well, I'd just like to know about any little thing that's changed. I did change the way CIM load balancing is handled, and it might effect other things as well. For example, could you break out of a CIM report using SPACE? Or was there any way to halt a CIM report once it started? I just want to make sure all of the functionality is still supported.

You can't break out of cim reports such as figs, ports or warps. I haven't tested the fig refresh cim, but I see no use for delays in that area because I haven't noticed that hogging resources in the past. Port cim has always be slow, I'm not sure if speeding that up will effect server resources or not. From PH's statement you may have already changed port cim delay to make it faster. Also I wouldn't speed it up too much because as I said earlier in a post, that would make cim hunter quite a bit more powerful.

As far as I know it's the same speed.

Would it be useful to be able to break out of CIM reports?

I suppose there would be times it might be useful, but I haven't run into a lot of situations where I needed to. Now the fig display would be nice because I have hit "g" by accident a few times with a 15k grid and it takes a while. lol That's only because the "g" key is easily pressed by mistake.

D, you've always been able to abort the "G" figlist with
a space provided you don't hit any other keys after G
except the space.

As for CIM, it doesn't really matter. Its rarely ran by
mistake.

Interesting on the Abort Fig Display, that has gotten me in trouble a few times. Thanks

kk, I didn't realize that. That will be helpfull information.

"Command [TL=00:00:00]:[8012] (?=Help)? : G


_"




Apparently "g " as a macro leaves u hanging gamewise at a non prompt and/or it aborts display but you still are stuck for same time as reading it.

Yeh, that doesn't happen on the old version, but does seem to
happen on the beta. I couldn't even relog until it had finished.

Would be good to get that functionality back, if someone aborts
the fig list there's no reason to delay for the rest of it.

That's a common situation. The "abort" is handled at a lower level than the function that's being processed, and in order to make all commands abort without having to code in special logic to break out of the command on abort, all the game does is stop sending output. All the normal processing continues. Obviously there are places where this processing isn't necessary, and a simple break on abort would allow the game to drop right out and save a lot of unnecessary processing. I did this the other day with the transport list. Instead of looking at each ship even if the list was aborted, it drops out. I could do this with the fighter list as well, and any processes where a) the processing could take awhile and b) there aren't any necessary side-effects of the processing. So make a list of commands that it would help to completely abort rather than just hiding the output and I'll look into optimizing them.

Fig list
Mine list
Sector display
Navpoint display
Planet (land) list
Planet info (enter from the planet prompt)

Think that's about it.

Cool. Just keep this in mind and let me know if you want any other aborts optimized. There are so many places where I could do this, but I only want to do it where it really makes a difference.