I actually think the vast majority of actions should be considered "instantaneous", and should therefore have the same small delay. This delay should be large enough that we have room to make some actions occur more quickly if needed. I think a pre-synch of 10 ms and a post-synch of 10 ms would be a good baseline value.

I would go through the menus and apply this baseline synch to every action. Then I would go through on a case-by-case basis and tweak these as needed. So rather than build a list of actions to be synched, let's work on a list of actions that need special timings.

That's a good list.

I see your point about a default "instantaneous" delay. Suppose we set that at 2 ms pre and 3 ms post. We're not going to get much faster than that. It's 200 CPC, but I simply don't have the precision to do 1 ms pre and 1 ms post (2 ms minimum). I could do it, but it'll be 2 ms plus or minus 1 ms which is a big error.

I just realized that your point about "sending multiple Ls but only the last one actually lands" isn't going to be a problem. You won't reach the synch point for an action until it's guaranteed that you're actually going to take that action. The game will still eat invalid entries with zero delay. This is another way this is superior to the current CPC system, I think.

So we don't have to worry about the overhead of throw-away input. There won't be any pacing of that. We only need to worry about the pacing of the fastest "instantaneous" actions. Is 5 ms fast enough for something like drop-take figs?

Ok, first thought on delays... this would be total delay per.

0ms - Landing
0ms - Changing to the computer prompt
0ms - Changing to the corp prompt
0ms - Laying beacon
0ms - Attacking beacon
0ms - Z Instructions
0ms - Getting / info
0ms - Jetting cargo
5ms - Killing fig (or firing at figs)
5ms - Laying fig
5ms - Displaying sector
5ms - Laying armind
5ms - Laying limp
5ms - misc computer prompt info things
5ms - Misc corp prompt stuff
10ms - Firing photon
10ms - Density Scanning
10ms - Holoscanning
10ms - Getting I info
10ms - Firing a gtorp
10ms - Detting a planet
10ms - Upgrading a port
10ms - Setting navpoint
10ms - Pwarp
10ms - Xporting
20ms - Attacking (plus ship delay)
20ms - Moving (plus ship delay)
20ms - Killing planet shields
20ms - Killing planet figs
20ms - Claiming planets
20ms - Evicting traders
20ms - Porting
20ms - Locking tow
20ms - Turning on interdictor
20ms - Eprobing
20ms - Transferring cash via corp menu
20ms - Transferring shields via corp meun
20ms - Transferring figs via corp menu
20ms - Setting avoid
20ms - Showing avoids
20ms - Send corp msg
50ms - Displaying all figs
50ms - Showing mine list
50ms - Building a port
50ms - Personal planet list
50ms - Corp planet list
100ms - Plotting course
100ms - CZ ship list

Now if 0 isn't possible (it's zero currently, so not sure why
it wouldn't be) then go with as small as possible. 2 ms/0ms,
or, at most, 2ms/2ms. Altho most of the 0 delay stuff does not
stress the server.

Ok, so the method you're talking about wouldn't put any delays
at all until the landing actually goes thru?



This needs to take zero delay.



This can take a few MS if needed.

If that's the case, then give it the smallest delay 2ms/2ms you
can. That shouldn't be a problem. Would there be a way to add a
separate 10ms delay to the defense check? I'm still concerned
about the landing process lag bug.

In the same way landing needs 0 (or close) delay, either the Z
or the J (Z instructions or J jet cargo) needs 0 too. They're
used to buffer. Now if the delay only happens if you say yes
(yes jet, or yes to instructions) then that's not a problem. But
if the act of getting to the question costs time, then we need
to look at that too.

Did you use the high precision timer (queryPerformance*), or did you use one of the other windows timing functions like getTimerTick? Anything other than the performance counter functions won't give you better than 15 ms accuracy, but the performance counter can give you less than a ms accuracy depending on the system (you can query the actual accuracy). I'm getting anywhere from 15,000 to 100,000 ticks per second on my test systems, so that's pretty good accuracy. I'm curious because it would be nice to know what the actual delay is for those 0 ms actions. I'm sure they're within measurable range of the performance counter.

On the landing with Gen Torp option, you'd only have a delay if you decided to fire GenTorp. In general, you won't have any delay until the action is actually taking place, so if there's ever a way to abort an action, you won't have hit the delay.

Those aren't measured, those are recommended initial values.
Normally what I do is run 1000 or 10,000 of a particular thing
and check the timing in between to get an average per iteration.

That being said, twxproxy has a ticks function w/ crazy precision.



Hrm. Here's what I see happening, and you can tell me what you
think would work to fix it.

I have 5 planets in a sector. They've got max cols in ore. I bring
in a mobile planet, I want to strip the produced ore and excess
cols of the 5 planets onto the mobile so I can so that ore to defend
an area later. So I pwarp, then run a product mover like my vacuum
or mombot's move, or swath's macro loop function.

It lifts, lands, grabs ore, lifts, drops ore, repeats. Over and over.
Now if there's 100k ore on each planet, that's 500k ore. That's 2000
rounds per sector, 400 per planet. What happens on the server,
most of the time, is that the CPU load for that core will spike up to
100% (or close to it). Anyone else with a tw2002 process on that
core is now lagging crazy.

Now, if the guy running this ore xfer has a bubble of 100 sectors,
think about how long that lag will be. It can make the server very
slow for very long periods of time.

So we need something to fix this. It can happen with xport too, but
that's only in special cases. We'll deal with that later.

Well, obviously the trade off here is load balancing against speed. It's definitely possible to pace that out so that it doesn't peg the server, but the cost will be a smaller number of cycles per second. Let's project what it might be using your proposed numbers.

If I understand the process correctly, it's moving product from one planet to the other? So you land, take product, lift off, land, drop product, lift off, cycle.

After the initial cycle, the timing would be

Landing = 5ms
Take Product = 5ms
Lift off = 5ms
Landing = 5ms
Drop Product = 5ms
Lift off = 5ms

total time per cycle = 30 ms
total cycles per second = 33
at 250 units per cycle, 2000 cycles to move 500K units, that's about 60 seconds.

That seems reasonable to me. If it's still pegging CPU, we'd have to consider increasing these delays and find the right balance of keeping the game moving while maintaining a reasonable CPU load.

We could actually test this right away, since I have 5 ms baseline delays in place for all of these actions. Let me get a clean update on classictw.com and I'll give you the greenlight to run some tests while I watch CPU. Just let me know when you'll be able to get in there.

What's nice about this is, once we get the minimal delays in place, we'll be able to scale these up to slow the game down. This will serve the same basic function of the CPC setting, but will be better because the actual timing will be scaled uniformly. A gameop could edit a game to run at half the speed, but all timings will be the same relative to one another.

Ok, the current version at classictw.com has 5 ms delays for many (not all) actions. Movement is 250 ms + minimum 3 ms (post-synch delay for the previous action). The land/take/leave/land/drop/leave cycle can be tested. I'll see if I can do some tests, but I'd like to observe the server while you're using one of your scripts. Let me know when you would have some time to test this and I'll try to check in on you.

30ms would probably do it. Might even be able to remove
the lifting delay to cut it down to 20.

When I get a chance I'll setup some planets for test and
you can monitor the load.

I did some simple tests with macros to move product. Using the 5 ms synch delay, 30 ms per cycle, I was able to run an ore mover at about 65% CPU. That's not as bad as it would be without any delays, but probably not optimal in terms of load balancing. Just to get an idea of the range, I upped it to 50 ms synch delay and ran the macro at about 16% CPU. Moving 500K ore at this delay would take about 8 minutes.

Something to consider here is that we could make this scalable as a sysop setting. This test was a 2.4 ghz celeron. At this absolute minimum delay of 5 ms, the CPU load will continue to drop as machines continue to get faster. Those who want to throttle back the pace can scale these delays up so that a high load script like this is only taking 5%, 10% to 20% per user, depending what they consider reasonable.

Aside from this approach, it may be possible to look at individual tasks like this and try to optimize them to get the CPU load down even with faster delays. But the reality is that there are some very CPU intensive actions in the game and the only way to keep from overloading CPU is to slow things down.

Can make it scale, but I don't think it matters much. It
probably goes as fast as it possibly can given the CPU,
which means it also peaks at/near 100% CPU. 16% CPU
is fine tho, and it'll get better on faster CPUs. What delays
did you change for that?

Also, check xporting. Get 10 ships, xport between them
over and over while aborting displays.

A user running a twx script locally is going to tax the cpu considerably more than someone logged in via the net and running the same script on a different machine. However, you also have to consider multiple users running the same script or similar scripts at the same time. With the old 0 delay setting I never had a lot of cpu problem with users scripts unless there were several players running high velocity scripts like movers, wsst, and tsst.

BigD, the test I ran was a remote connection to twgs.classictw.com.

Sing, the 16% result was with a 50 ms synch delay, or about 300 ms per cycle, which would put a 500K ore move operation at about 10 minutes. But I think the way to go is to define the baseline at 5 ms synch delay, and anyone with a powerful enough computer can run it at this pace. Others might need to run it at a scaled pace, like this 10x scale I tested on classictw.com. But ultimately it'll be up to the gameop to decide the appropriate balance of speed and CPU load given their system power, common player load and activity level. And of course a true zero delay option could be included. I just want gameops to have the ability to control the load on their server.

I'm going to switch it back to 5 ms delay and leave that up on classictw.com for now. I'll add in the delays you recommended over the next day or two.

So there's going to be a scaling option then and people can change it?