I banged a SubZero edit on twgs.classictw.com. It's game L. Gold aliens are disabled. It has maximum bandwidth and 150 ms ping. All configurable pacing parameters are minimum (2 ms).

I need it to be put through some paces. Make sure it doesn't choke on any activities. Test multiplayer interactions as well, since the event system was optimized. The changes I made effect the game at a very low level, so if there are problems, they should show up pretty quickly.

Merchant Cruiser holds 2500 figs... When startup in the game you get 8000

This is normal behavior. Is there an issue with how this is handled? It's been like this for years.

Edit: I see what happened here. Without Gold enabled, you can't set initial fighters to greater than the Merc's max fighters. This edit had Gold enabled and set initial fighters to greater than standard Merc's fighters. I turned Gold off in bigbang, but that didn't reset the initial fighters value. It remained greater than the standard Merc's max fig count. I've fixed it so, when Gold is disabled, Bigbang will reset initial figs and initial holds to remain within the standard Merc's range.

Now that a few of you have been running some scripts, let me know if you find that anything runs slower or faster than before (compared with TWGS v1). At some point, I need to work on pacing to make sure some actions aren't too fast or too slow, throwing off the balance.

What kind of TW ping times are you used to getting?

Are there scripts that are taking significantly longer to complete? Shorter?

Can a ship attack too quickly relative to an enemy's ability to escape, so that the attacker always hits, or too slowly so that the attacker always misses?

These are the sorts of things that I need to bring back into balance for this new version to be ready for prime time.

Yes, grid defense scripts like pdrop and ptorp are entirely
ping dependent. And it's not a linear change, either. You
go from being able to defend your grid to being unable to
stop anything in about 10ms.



Attacks aren't an issue. You can macro out before anyone
can attack you, and if you're stuck in an IG you can xport
out or callsaveme. The real issue is pwarp photon torps.

Ok, so about grid defense scripts, what range of pings are needed in order for these to function as expected? Also, what was the situation before where every player has a different ping? Would some have a fast enough ping while others would not?

I assume there are other timings that balance with ping in order to effect grid defense. If it is desirable to have a higher ping (100 to 150 ms) so that most players would have the same ping, then it would be necessary to change other timings so that grid defense will work with higher pings.

But to start, let's just talk about what ping is expected in TWGS v1 in order for grid defense to work.

It depends server to server, the load of the server, and other
aspects. It also depends on the techniques of the gridders.

A straight hit-twarp requires a 150 or so on most servers. A
lawnmow can require more or less, depending on how the
packets come in. In some cases you need much faster, in
other cases you can pdrop adj and catch them. When I say
150, I mean the comms-based script I use, not ICMP. I
basically use prome's ping, which is available in .ts format
on here somewhere.

In a pgrid, it's much harder. You have to fire a torp within a
very tight window, or manage to end up in their sector w/
cannons on. Depending on patterns, that can be very hard.

Today, corps are usually put together around super pings.
A server has a set of players, the bad ping people don't
play there much, the really good ping people develop corps
around the best pingers. You get 1 or 2 great ping players
on torp defense as the anchor of the corp. This results in
corps that play exclusively on one or two servers, and all
sorts of other rather disturbing trends (favoritism tends to
develop over time).




The biggest two factors for balancing this will be move
related delays, and landing related delays.

If everyone has the same ping or pings that are very close, the trick would be to arranging it to where the gridding and grid defense balance out on a random basis. So if a gridder is gridding that he might get hit by a torp 1 out of 50 grid attempts or so. So the timings would have to be very close to balance game play.

The point about randomness is important, I think. In the current public release, randomness is part of the system. The ping time is a combination of the ICMP ping plus a random delay from 0-100 ms, and for event response, throw in a random delay from 0-250 ms to receive any event. These random delays are gone now, but if the randomness is necessary to gameplay, I can re-introduce it in a controlled manner.

Sing, you made the point that a lot of this depends on the server and load, etc. A big point of what I'm doing is trying to set the pacing so that the game is less dependent on network and system specs. So if we can balance the game with ping and other delays that are above the common delays expected from ICMP ping and system load, then most systems will provide a consistent gameplay experience.

At some point we just need to dive in here and do real-world tests, determine if something works or doesn't work, then tweak timings and see if we can fix whatever is broken.

The reason I'm a fan of some random features is because static formulas are very easy to script and obtain a perfect solution. With random formulas it's harder to achieve an exact outcome, so the player is somewhat at the mercy of the game itself.

I completely agree. The original randomness was not by design, but I think it was a positive factor. The changes I'm making right now won't force me to remove the delays or the randomness. The benefit of these changes is that the delays will tend to absorb things like network latency and CPU load, rather than add to them. Anything that eliminates those variable delays and replaces them with consistent delays is a good thing, I think.

A random delay of up to 100ms is a very bad idea. Random is
not really random, it never is. There's always a mean. A 100ms
would have a mean of 50ms, which is a huge HUGE delay to
add. You would basically have to get lucky to hit anything. Think
about it, the mean would be 50, the stdevs would be like 20 and
80, the 2nd devs would be like 5 and 95. So you're looking at a
15% chance of hitting in the first stdev and 1% in the 2nd.

Now do the math from there. A 20ms delay is huge for this given
how tight timings are. You'd have to shoot 10 shots just to get
lucky enough to hit someone even on a straight twarp grid. Add
in pgridding... and you might as well not waste your time trying
to defend your grid at all. Basically you can kiss you nacient
bases goodbye, I'm going to stop trying to defend my grid and
just go after yours instead.

The current version is no where near this bad. I know it looks
like it should have random values, but in actual play you don't
see them. Ping is fairly consistent, and hit rates are fairly
consistent too. If you do add anything random, it needs to be
very small. 50ms at the most, 30ms is probably better.



Right, I know. There will still be issues on systems that are
slower than the reference, tho.

A random delay of up to 100ms is a very bad idea. Random is
not really random, it never is. There's always a mean. A 100ms
would have a mean of 50ms, which is a huge HUGE delay to
add. You would basically have to get lucky to hit anything. Think
about it, the mean would be 50, the stdevs would be like 20 and
80, the 2nd devs would be like 5 and 95. So you're looking at a
15% chance of hitting in the first stdev and 1% in the 2nd.

Now do the math from there. A 20ms delay is huge for this given
how tight timings are. You'd have to shoot 10 shots just to get
lucky enough to hit someone even on a straight twarp grid. Add
in pgridding... and you might as well not waste your time trying
to defend your grid at all. Basically you can kiss you nacient
bases goodbye, I'm going to stop trying to defend my grid and
just go after yours instead.

The current version is no where near this bad. I know it looks
like it should have random values, but in actual play you don't
see them. Ping is fairly consistent, and hit rates are fairly
consistent too. If you do add anything random, it needs to be
very small. 50ms at the most, 30ms is probably better.



this sounds too much like random 'lag' ... ?

I believe JP was using examples from the old version delays. With the new timings, a random factor wouldn't have to be as drastic to accomplish the same goal. If pings are balanced or identical, then a 2 to 10 ms random delay would at least add the factor of luck into the equation.

Yes, I'm aware of that. There's more to it than that, tho.