I've been thinking a lot about the scaling factor for game pacing. I was originally thinking that the scaling factor would apply not only to the action pace delays, but also to ship movement and attack delays. So if you scale a game to be 2x pace delays, all actions would be restricted to half the default number of actions per second (250 actions per second down from 500), but the ship movement would also be 2x, meaning 500 ms per sector plus a 40 ms pace delay. The idea behind this is that by uniformly changing the pacing, the relative pace of all actions will be about the same. If ship movement isn't scaled, for example, many scripts would end up running about twice as fast relative to other actions when the pace scale is set to 2x. But the downside of including ship movement in this pace scaling is that it very quickly becomes burdensomely slow. A scale of 8x, which would be reasonable on a slower server as a way to decrease CPU load under heavy scripting, would result in a ship movement delay of about 2 seconds.

So the question I have is, should the ship movement/attack delays be scalable independent of the generic pacing delay? Would a game play reasonably well if, for example, the pace was set to 8x but the ship movement/attack delay was left at 250 ms, resulting in an actual move/attack delay (including pace delay) of 410 ms? Like all actions, the pace of initiating a move or an attack would be slowed by 8x, but the actual time of movement or attack would not be changed (or could be set independently).

FYI, I see Normal ship movement delays as being consistent with a pace factor of about 8x as far as keeping the movement of the fastest ship (Scout Marauder) relatively consistent with the pace of commands in the game. So anyone interested in running a Normal ship delay game would probably want to set pace scaling to 8x (a quarter ship delay game would be consistent with 2x). But I know these slower ship delay games are not very popular, and the need to limit CPU load does not necessarily coincide with a desire to have longer ship delays, or to use ship-defined (TPW) movement/attack delays.

If nothing else, having these as two separate delay scales will give the gameop more freedom to find a balance that works well for him or her. If I treat pace and movement delays together as one scale, gameops will be forced to trade off between load balancing and slow movement.

To tell you the truth John its a waste of time....no one plays ship delay games anymore.

The purpose of that was to let a scout get away from an iss manually.

No one moves manually and no one wants to.

Rob delays are same...Purpose was to slow cashing in an hour long bbs session.

Scripts cash so fast now that the purpose is moot. Guys change the TONE of the game from blue to red via Planet specs...amount of colos and rob/steal%....Rob delays are worthless except to chase players away from games. Same with scalable move delays. Turn them on and you can guarantee yourself zero players in that game

There are a few servers out that are running ship delay and/or rob delay, and they have a few players. Granted, I won't be one of them as that type of game simply frustrates me because of lack of speed. Life is too short to watch a simulated laggy server because of the delays.

Unless a tutorial is provided on the effects of the different settings and how it relates to load balancing, I see most servers being ran "out-of-the-box", or worse in that changes are made without knowing the effect.

While Trade Wars appeals to somewhat of a techie crowd (IMO), I don't think a lot of people, including myself, know a lot about setting up a server or balancing loads. Unless guidance is provided, I can see frustrated gameOps and players. I think it will be like setting up an edit - sounds good to the person doing it, but really hoses things up in regard to balance.

This doesn't mean that it isn't a good idea to have it, just that there will be a learning curve added, and help will need to be provided. I know that a tutorial is way down the road as implementation needs to be accomplished first.

               / Promethius / Enigma / Wolfen /

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

I beg to differ. Personally I don't mind 1/4 ship delay at all, it "feels" good to me. Granted there will be some players who won't want to play a game with delays and that only means more opportunity for manual or near manual players to enjoy a game where they really do not notice any delay at all. I've played both 0 ship delay and 1/4 ship delay and both move approximately the same for the way that I play.

The only current delay that I do notice is the CPC setting, how is that factoring into the game pacing settings?

I do like JP’s suggestion as keeping the overall game pacing settings sysop configurable independent of ship delay settings.

Perhaps if we could meet these manual players.

I don't know any.

I don't personally know anyone from Russia either, but they do exists.

There are plenty of manual or near manual players in the builders games. Log in and take a survey sometime.

T0yman has told me he prefers to move manualy when exploring himself in builders or turn games.

I can understand there not being any manual players in unlimited games, in those you probably don't need any type of delay for playing, but sysops I'm sure would appreciate some sort of pacing to manage the CPU usage.

So in this case yes, the player delay needs to be set independantly from the game pacing. If it's not too much trouble I beleive that would be a worthwhile gameop setting. AND to take it just one step further, to have the player delay setting independant for each game. This way gameops can configure many different types of games.

I also agree with T0yman that there needs to be some documentaton about Tedit settings and how they effect the overall game.

Or maybe even one step further - some "out-of-the-box" settings for certain type games to achieve balance, while still allowing gameops to tweak as they see fit.

I think JP was starting on that path with one general game set-up coming with TWGS. Some of the TWA files may well be suited for this application.

If JP makes these puts these new delays in a config file in the beta, then most of the old delay options will be obsolete except to sysops that won't understand how to configure them.

BTW, the old TWA edits that have aliens in them will be worthless. Considering the changes in alien behavior, those edits will be way off track.

I'm a manual player, and have been since the old days. So we do exist.

Not worthless, just not usable with the next release. We'll have to ensure we mark them as TWGS v1.03 in our database download section so those looking to download them will know which version they belong to.

For those who don't think manual players exist and that the setting would be worthless, keep in mind that it's equally relevant to "No delay" ship settings where a 250 ms delay is currently used for ship movement and attacks. If I apply a pace scale factor to every delay uniformly, then a server where the gameop needs to slow the maximum speed of the game down by, say, 1/4th, would also increase the move delay to 1 second. While many script players might not be too bothered by a max 125 actions per second of a 1/4th pace game, they probably would be bothered by a 1 second move delay.

The question I have is, if you slowed down most actions but didn't slow down actual move delay, would that imbalance games too much? It's a complicated question and maybe it won't be obvious until players actually try playing a game with a quarter pace and normal 250 ms move. However that works, it won't be any worse than the CPC pacing system that's been available in the past.

I would really like gameops to be able to slow the pace of games somewhat, if they need to, without alienating players with a slow move rate. With the current pacing, many current machines are going to experience lags during certain actions like moving product. Eventually, as systems continue to get more efficient, these CPU lags will go away. But until that time, there needs to be a way to pace the game without turning off the players. I see the ship movement delay (even for NO SHIP DELAY games) as being much more effected by pace scaling than any other delay. A limit of 250 actions per second compared to 500 is not that noticeable, but half a second move compared to a quarter second is what people are going to notice.

You of course realize that ship delay makes griding impossible and pdrops and foton scripts will destroy any game play right? Thats why you wont see anyone playing in ship delay games. Ship foton scripts are worthless because of the delay so if you make planets on go mobile in 90 days or something then I can grid the whole verse under your nose in a scout with a script in such a game and u cannot do a thing.

If the Planets go mobile quickly then you wont be able to move with the fastest mower....I will kill you.

Bwarp foton scripts would kill all movement.

Ship delay is dead...


This campaign to create a game where scripts can't kill a player might be admirable from a historical perspective but is not going to happen. TW is a computer game and the computer will always put out keystrokes faster than a person.



As far as load balancing you could add a FACTOR to all movement to maintain balance...Adding 100 ms to all actions for example... re-balancing for move delay wont really be possible..any move delay at all turns the game into script wars. Only fast custom scripters would be able to compete. Without move delay the average person has access to all the needed public scripts he needs to compete at a high level. With it I could write a few scripts in a couple days that would make such an edit unplayable.

And I am sure you enjoy yourself on private servers where you can play as you wish. Personally my hands are too crippled to type in 1000's of keystrokes so I wrote my own helper to play.Otherwise I couldnt play at all.

The timings look pretty good for most things. I don't think the
ship delay should be fixed with the pacing multiplier tho, that
may break a few things. People might want to use pacing
to create a unique edit.

I'm not entirely happy with the current move and planet delays.
They're good, but planet gridding seems to take about 100ms
from hit to landing, too fast to ever hit. I've got some work to
do before I can figure out exactly what needs done to balance
that.

Then the landing delay need to go back to the intial landing command and not After passing the shields

or adding slightly to the Place fig or Kill fig commands

Landing, right now, only affects successful landing commands.

So... land burst 10 times, only 1 has a delay. If we add a failed
landing delay of 2ms, or if we change landing to 20ms instead,
we could adjust that. But... that's stuff to test. Making these
kind of changes without fully thinking them thru is a mistake.

We could also add 5ms to pwarp delay by taking 5ms from the
foton delay. That would shift things a bit more towards the torper.