I'm a bit confused.

I've got TWGS local and nothing seems to matter regarding it's response speed. Faster CPU doesn't seem to really help the response, ramdisk, no change (no noticeable changes, anyway).

I have to ask....

Why doesn't TWGS just *BLAZE* when you remove all the bottlenecks (ram disk access, run it locally, etc.)?

Seems as if the program itself pauses at certain intervals, for no reason I can see. I had thought that one could find the bottleneck of performance, but, it seems reliant on how TWGS is programmed, not on the system or environment it runs. Or, to be more precise, it depends on the latter factors much, much, less.

That's exactly what it does do. Bottlenecks certainly slow it down, but you can only get it so fast. There are reasons for the pauses, mostly a matter of timing events, and there are a handful of CPU intensive functions that'll eat up as much CPU as you can give it, regardless of what CPU that is.

For example, I did a CIM sector report and capped the CPU usage (for the core it's running). It's below. The peaks are when TWGS stops to 'figure out' the next 99 to display. These seem to be prevalent in the program regardless of what you do on the CPU/network it's running.



And that really sucks.

The TWGS is designed to pause. You can turn the delay down to 1/4 a second I believe, but it is not meant to go as fast as your CPU can handle it.

This is designed to give defensive moves more precendent over offensive moves. It's a built-in latency. Otherwise, the player with the fastest internet connection would dominate.

There was once a TWGS with no delays, and it blazed. It was popular with the more experienced players but new players found it impossible to compete.

A TWGS with no delays would be like playing a First Person Shooter that allowed you to run around the game like Flash Gordon.

I hope you didn't toss a ton of time or money at this. The TWGS works just fine on an old Celeron 466.

I didn't toss a ton of time or money at it. It was a side project on testing script speed and execution. To do it, I localized TWGS and then got curious about the bottlenecks it might have. I removed them as I could (installing and running it from a RAM disk, highest network capability I had available, etc) and looked at profiling the process to discover more. When I was satisfied that it wasn't the system that caused any delays, I had to conclude that it was the program.

It sucks that TWGS can't have an option for 'No internal delays'. IMHO, it's a lame statement to say it runs fine on....X. It isn't about minimum capabilities, it's about fastest possible. And, we've progressed to the point where you have to cause a delay in the program so it's usable? No one reads 99% of the text anyway, so I would have voted for the 'Allow delays if the sysop chooses them but don't enforce it across the board' option.

I say the TWGS "runs fine" on a 466 because by design it just isn't going to run faster, just like the clock and calendar are going to run the same regardless of CPU.

Unfortunately for you, this "no delay" argument was had and ended 6-8 years ago. Back then I was on the same side of the argument you are, but as a Sysop I had an uptick in players that I couldn't deny. It was good for the game.

My only suggestion would be to download a VMWare Player and attempt to trick the virtual machine into running faster than it should. There are CPU settings in VMware config files that can be added, possibly tricking the VM into running double, triple speed. The problem would be that you would also have extra Externs every day.

I believe the setting is 'host.cpukHz'.

Good luck.

PS Ram drives don't help. We figured that out in 2000.
http://www.thestardock.com/?p=1113

There are a couple different delays.

Ship delay, which can be set as low as "none" which really means 1/4th for all ships regardless of TPW. This was added to prevent a person from bursting a huge macro and mowing down everything. It's this element that makes torping possible.

Then there's max CPC, which breaks down long command lines into separate queues. That'll add a delay too. There's a "process interval" that if changed can have some crazy consequences. There's a rob/steal delay, that's obvious, death delay too. But there's some additional built in delays that aren't obvious or easily changed. One of which is the CF plot delay, that's there to prevent overloading by sector plots. There's also a delay built into the xport list, which is related to the plot delay somehow.

There's also a delay on text output too, the server breaks up blocks of text output and only sends certain amounts per window. This causes stuff like CIM and large sector or planet lists to take a while. That's what you're experiencing with the CIM. That's why it's important to abort as much text as possible when doing stuff, since you can remove some of that delay. I say some, because apparently some of it still occurs... which is why even if you abort displays, a sector full of ships takes a bit.



Nod, ship delay. Even w/ a slow connection all you need is to burst a large macro. Even w/ a really good connection, it'd be hard to get your torper set right to stop it in time.



Still is in a lot of ways, on both of those issues. Better, but experienced players still wipe out newer ones. There's so many scripts and concepts that just don't make sense until you've got games under your belt.



Nod. Depends on the number of nodes tho. Alien manager sucks up a lot of CPU. The tw node processes also suck up a lot of memory if it's available. And there are definitely things in the game that can bring a modern multi-core system to it's knees. When you start talking about the more load-intensive elements of the game, a faster system will definitely run faster. Not that the game internally will seem faster for most, but add a few more players and it's the difference between lag and none.

All of these delays are added for various purposes. Some are inherent to the way the time sharing system works, others are invented to send the game another direction. Pwarp and landing delays have been discussed before too, don't know if they'll ever happen tho.

It got me thinking about spreading out the load from a programatic perspective. A server component could do the heavy lifting of text input/output and network I/O with several independent modules optimized for keeping track of timings and events (Ore/Org/Equ/Fig production, Alien Movement/commands) and of course a clustered database to keep it all organized as a single cohesive unit (a single game).

But, John would have to release the source code before anything like that could be done. But, I can dream.

I'm sure JP isn't going to release the code except to the person that purchases it, and from past experience I can tell you it won't be as cheap as you think it might be.

Also, without delays, the game would be unplayable as you know it now. A player could hit 20 fighters before you'd get the message of the first one. Also, 2 or 3 people running scripts without delays and a lot of processing would max out the CPU even on the best of machines if the bandwidth allowed it. If it was a small machine on a T1, you'ld see it smoking within a matter of hours.

That is exactly right, Big D. Remember folks, this game played fast on 14.4 baud modem. It's ridiculous on a T1 or God forbid, a T3 or larger.

If you log your playing session, then look at the file size after, you'll realize it wouldn't take any time to download that entire hour of turns over today's connections. It's JUST text, afterall.

Hehe. My log is huge for dialup, like 30mb. And ping would totally blow, packets would get fragmented, game would be unplayable from my perspective on a dialup... or at least not worth playing.

For one hour of playing time you have 30mb?

BTW when I stated the game ran fine on a 14.4, I was refering to the old BBS days, when there wasn't a TCP/IP stack, routers etc between you and the game. We are refering to bandwidth, are we not? Latency is another issue.

Might get a little improvement if the game was simply recompiled with a modern Compiler. JP mentioned that the vesion we all enjoy and love was Compiled for Windows 95, iirc.

If the pauses are indeed internal and intentional, the compiler is irrelevant as it will only run so fast.....by design.