Sure, I think there has to be. I was hoping that we could set up some minimum delays and it would allow the game to run at lower CPU levels, but I think 60%-70% CPU for one player is still too much and some gameops will want to slow the game down a bit from the minimum delays. But I think it's good that the op will have the option to do that without changing the relative pace of actions in the games. It may take twice as long to play a game on one server compared to another, but the general balance should be the same. The current CPC pacing system doesn't provide that scalability.

Is this up at the beta site...Do we need to run timing tests now?

Will there be a way to tell the game setting w/o having to log into the game. If the setting is too low or too high for a person's tastes, then they can avoid the game.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

That's the usual plan. I'll include this setting in the usual settings lists.

Ok, I've gone through and added synch points for every action in the game (I may have missed a few). Many of these are the smallest delay possible, which at this point is 2 ms (I'm getting good precision even for such small delays). 2 ms actions can be done up to 500 times per second, so in practice the majority of these delays will not be felt unless a gameop scales up the delays to slow the game down.

This is just a starting point. As we get feedback on these delays, I will tweak them in order to a) keep the game moving fast enough, b) keep the gameplay balanced, and c) keep the CPU load at a reasonable level.

Here is the full list of synch points and their corresponding times. Remember that these times are generally split into 60% pre-synch and 40% post-synch, so the actual delay prior to processing an action is 60% of the listed delay, so 60 ms for 100 ms, or 12 ms for 20 ms, etc, plus the post-synch time of the previous action. The exception is move and attack delay, which are both 20 ms pre-synch and 0 post-synch because the move delay is processed after the synch point. These splits can be changed on a cas-by-case basis if needed, to account for heavier pre-synch (lots of prompts) or post-synch (lots of computations and data processing) operations.

GAMESTATS = 200 ms

PLOTCOURSE = 100 ms

BUILDPORT = 50 ms
READMAIL = 50 ms (per 1000)
CIMSECTORS = 50 ms (per line)

MOVE = 20 ms
ATTACK = 20 ms
CIMPORTS = 20 ms (per port)
CLAIMPLANET = 20 ms
ATTACKPLANET = 20 ms
CORPCREDITXFER = 20 ms
CORPFIGXFER = 20 ms
CORPSHIELDXFER = 20 ms
CORPMINEXFER = 20 ms
CITEVICTTRADERS = 20 ms
LANDPORT = 20 ms
TOWUSER = 20 ms
SETINTERDICTOR = 20 ms
CLEARALLAVOIDS = 20 ms
CLEARAVOID = 20 ms
SETAVOID = 20 ms

PLANETWARP = 10 ms
PORTREPORT = 10 ms
MINESWEEP = 10 ms
PHOTON = 10 ms
GENTORP = 10 ms
CIMWARPS = 10 ms (per sector)
TAKEPROD = 10 ms
TAKEALL = 10 ms
CHANGECOLS = 10 ms
MOVECOLS = 10 ms
ATOMICDET = 10 ms
PLANFIGHTERS = 10 ms
MOVIE = 10 ms
TRANSSHIP = 10 ms
TRANSPLAN = 10 ms
DENSITYSCAN = 10 ms
INFO = 10 ms
UPGRADEPORT = 10 ms
SETNAV = 10 ms

MINEDROP = 5 ms
MINETAKE = 5 ms
ATTACKFIGS = 5 ms
ATTACKCOLS = 5 ms
SHOWROOM = 5 ms
CORPLIST = 5 ms
CORPRANKS = 5 ms
CREATECORP = 5 ms
CORPPASSWORD = 5 ms
CORPPUNT = 5 ms
JOINCORP = 5 ms
QUITCORP = 5 ms
DROPFIGS = 5 ms
TAKEFIGS = 5 ms

MENU = 2 ms
TREASURY = 2 ms
CITSHIELDS = 2 ms
CITINTERDICTOR = 2 ms
CITMILITARY = 2 ms
CITQUASARATMOS = 2 ms
QUASARSECTOR = 2 ms
CITUPGRADE = 2 ms
EXCHANGESHIPS = 2 ms
CITDISPLAYUSERS = 2 ms (per user)
CITREMAIN = 2 ms
MESSAGELINE = 2 ms (per line)
READMESSAGE = 2 ms
LISTAVOIDS = 2 ms (per line)
DISPLAYSHIPLINE = 2 ms (per line)
SHIPSTATS = 2 ms
SHOWPLANET = 2 ms
PLANETSCANLINE = 2 ms (per planet)
SELFDESTRUCT = 2 ms
ANNOUNCEMENT = 2 ms
RANKINGS = 2 ms
ALIENRANKINGS = 2 ms
SHIPPASSWORD = 2 ms
PRINTLOG = 2 ms
SHOWWARPS = 2 ms
SHOWUNIVERSELINE = 2 ms (per line)
TRANSWARPPREF = 2 ms
PERSONALSETTINGS = 2 ms
EVILCLASSES = 2 ms
GOODCLASSES = 2 ms
TIME = 2 ms
LAUNCHBEACON = 2 ms
USERSTATS = 2 ms
LISTGLOBALS = 2 ms
WHOSPLAYING = 2 ms (per player)
MEMSTATS = 2 ms
SETMESSAGES = 2 ms
SETPAUSING = 2 ms
SETAUTOFLEE = 2 ms
PAUSE = 2 ms
KILLBEACON = 2 ms
SCANROOM = 2 ms
GAMESETTINGS = 2 ms
SETTINGSLIST = 2 ms
JETTISON = 2 ms
PLANETDISPLAY = 2 ms
LANDING = 2 ms
MOSTWANTED = 2 ms
CLAIMREWARD = 2 ms
POSTREWARD = 2 ms
GETCOMMISSION = 2 ms
DEPOSITBANK = 2 ms
WITHDRAWBANK = 2 ms
TRANSFERBANK = 2 ms
BALANCEBANK = 2 ms
CINEMA = 2 ms
PORTSD = 2 ms
BUYHOLDS = 2 ms
BUYFIGS = 2 ms
BUYSHIELDS = 2 ms
BUYSHIP = 2 ms
SHIPNAME = 2 ms
SELLSHIP = 2 ms
BUYGENTORP = 2 ms
BUYAMINE = 2 ms
BUYLMINE = 2 ms
BUYHOLOSCANNER = 2 ms
BUYDENSITYSCANNER = 2 ms
BUYTWARP1 = 2 ms
BUYTWARP2 = 2 ms
BUYTWARPUP = 2 ms
BUYPSIPROBE = 2 ms
BUYPSCANNER = 2 ms
BUYBEACON = 2 ms
BUYATOMICDET = 2 ms
BUYCORBOMITE = 2 ms
BUYCLOAK = 2 ms
BUYEPROBE = 2 ms
BUYPHOTON = 2 ms
BUYMINEDISRUPTOR = 2 ms
LIBRARY = 2 ms
BROTHEL = 2 ms
TAVERNANNOUNCEMENT = 2 ms
BUYDRINK = 2 ms
EAVESDROP = 2 ms
BUYFOOD = 2 ms
TRICRON = 2 ms
GRIMY = 2 ms
GRIMYSPY = 2 ms (per port)
WRITEWALL = 2 ms
PORTWAND = 2 ms
TAKEOFF = 2 ms
ANNOUNCE = 2 ms
CLOAK = 2 ms
FIGSCANLINE = 2 ms (per line)
MINESCANLINE = 2 ms (per line)
CORPPLANETSCANLINE = 2 ms (per line)
CONTRACTS = 2 ms
CHANGENAME = 2 ms
COLLECTCONTRACT = 2 ms
PLACECONTRACT = 2 ms
LEAVEPORT = 2 ms
TRADE = 2 ms
PLANETQUASAR = 2 ms
PLANETFIGHTERS = 2 ms
PLANETRETREAT = 2 ms
PLANETCHANGEMILITARY = 2 ms
CORPMEMBERS = 2 ms (per member)

I'll post this to classictw.com so we can get some live testing going.

CIM sectors needs cut down. That would take 25 minutes for
a 30k, which is just way too much. Plus, it doesn't generate
a great deal of load on the server so there's not much reason
for it. Probably should reduce cim ports, too.

What's the difference between CIMWARPS and CIMSECTORS?

I don't see lift from planet there either. Is that delay free,
or just missed?

What about leaving prod, too?

Cimwarps is Plotting a course in Inter Mode I believe

I'm open to the possibility of speeding up CIM reports, but the timings on CIM reports are actually slightly faster here than they have been. Looking at the Warps display (I), the current pacing delays 1 second per 100 sectors. Not including the processing time for the sector displays (which I assumed was basically negligible), that's 300 seconds, or 5 minutes for a 30K warps display. I defined the new per-sector delay by dividing 1 second by 100 sectors for 10 ms. While the current pacing will be somewhat longer than 300 seconds, this approach will be no longer than 300 ms. I approached the other delays the same way. The delays I proposed are close to the ideal pacing of the current CIM displays.

Now, that said, let's explore speeding these up. These reports draw 0% CPU on a reasonable system, so there's some room to give a bit back to players in terms of speed here. Looking at debug output, a 10 ms synch delay is actually delaying between 9 and 10 ms, meaning the processing time is very low compared to the delay time here. I don't want to push this too much, but we could speed this up.

The naming for CIMSECTORS was pretty poor. Should be CIMPLOT, probably. That's finding a course between two sectors. CIMWARPS is showing warps out of a sector.

The plot timing of 50 ms is actually worse than current timing. Currently, 30K takes 20 minutes plus some additional time, while the new timing would be 25 minutes. That's because I stuck with a set of standard delays of 5, 10, 20, 50, 100, etc, as you proposed, and current timing would be 40 ms per sector, so I rounded up to 50 ms rather than down to 20 ms. I have no problem dropping that down to a smaller delay. Again, we have plenty of CPU here. Relative to something like the product mover script that pegs the CPU at 100%, these operations are over-paced.

Sorry if some of the constants are non-obvious. planet liftoff is TAKEOFF at 2 ms. Leave Prod is the same delay as Take Prod, since they're handled in the same code block. Should be TAKELEAVEPROD, I guess. But hopefully the general placement of these delays is relatively clear and we can discuss ways to improve on these timings.

I need to modify something I said above. The CIM SECTORS pace is for showing explored and unexplored sectors, not plotting courses. There is no bulk course plotting function in CIM. Doh!

Ok, so displaying a full map of 30K sectors is not quite as bad as we were both suggesting, 20 minutes and 25 minutes. That's because they output is 7 sectors per line. So it's actually about 3 and a half minutes for the new timing and less for the old timing. But, again, we can speed that up.

Ok, I dropped these CIM display delays down to 5 ms each. There's still plenty of CPU to go around here, but the other issue is data transmission rates. The port display is sending about 8K per second, and that's 4x as much as is currently being transmitted per second. Known/unknown sectors report hits about 14K per second. Let's make sure we balance this in terms of speed, CPU load, and data rates. No sense in having too much speed but overtaxing bandwidth. Some people have less bandwidth than CPU speed to go around.

The CI warps display isn't what I'm talking about.

If I do ^IQ

(which might be what you're refering to).

"You have explored 95.38% of the known Universe."

30k uni. That's 28614 sectors, right?

Started at:
05:17:10 PM Thu Nov 24, 2022 (CT time)

Ended at:
05:22:14 PM Thu Nov 24, 2022

That's 5 minutes, 4 seconds. That would be 318.72 sec for
30k, or 5 minutes and about 20 seconds.

I'm not sure if what you're proposing would change that,
as I'm not sure what you mean by CIMWARPS versus CIMSECTORS,
But please don't do anything to lengthen the CIM. It's
already painfully long.

Ok, on the land lift...

Landing 2ms
Takeprod 10ms
Dropprod 10ms
Lifting 2ms

So, landing, grabbing, lifting, landing, dropping, lifting would
take 28ms per cycle? Alrighty. 5m ore at 250 per, 20000
rounds. (20000 * 28ms)/1000 = 560 seconds = 9 minutes,
20 seconds? That should be fine.

I would use caution if you are planning on speeding the port reports (cim) more than it was before, as it will make cim hunter quicker and more powerful.

Seems like you didn't really read my post on CIM timings. I said it's already less than you are used to and I'm willing to go faster. No need to debate that any more.

If there's a desire to keep it set at the current rates, I'd be happy to do that. That was my goal to begin with. I just wanted to offer to speed it up if that was beneficial.

On the prod moving cycle, what I have in place now is slightly faster than the 30 ms I had proposed before which pulled about 60% to 70% CPU. So this will be slightly heavier load on CPU. There's definitely a tough trade-off here. I hate to have that much CPU load per player, but I don't want to slow the game down too much either.

I noticed during this transition that the computer Known/Unexplored universe display (K) has no delays, while the CIM versions are paced. I'd like the two reports to be consistent since they're the same thing. Should the CIM version be as fast as the computer display (2 ms per 7 sectors, total 30K sector display time in about 8.5 seconds), or should the computer display be slowed down to match that of the CIM display, about 2.8 minutes? Or both somewhere in between?

Also, on this same subject, I went ahead and set the computer Port Report (R) delay to match that of the CIM port report so you can't grab that data faster one way than the other.

Yes maybe I misunderstood what you were saying. I'm still not sure I'm on the same page. I guess the question I'm asking is: "will the port report (^r) be faster than it was before the beta changes started?"