I've posted a new update on twgs.classictw.com. The main changes here are diagnostic code to track down this disconnect issue, and changes to Bigbang to guarantee all course plots are within maximum course length.

I banged a new game under JP Test Game. If someone could go in there and do some analysis of the map and let me know if it looks normal, nothing crazy, that would help alot.

Sing, have you had a chance to do some timing tests so I can work on locking in the current timings? I'd like to get some baseline readings to compare when I put the delays back in. That'll help me avoid disrupting the gameplay with these delays.

The old timings work well enough, and the current ver seems
to be using those. Start w/ that as your baseline?

Yeah, I thought you said you'd go through some typical actions and detail those timings.

Just to make sure this is understood, I need some delays here, and the current zero delays for some actions aren't acceptable because those actions will continue to get faster as they have done for years now, while those already using delays will not change. And if I can't add delays without slowing some actions, I need to make sure that other actions are slowed as well in order to maintain balance. I want to do this in a way that has a very minor effect on current gameplay, but by doing this, the current relative timings will be locked in forever, regardless of future changes in hardware.

In the older version, when the delay is set to 0, there was 0 planet delay plus user ping and ship delay was a flat 250 ms delay plus user ping right?

If this is true, I would think that if you made the planet move at 250 ms, then ships should have a flat 500 ms delay to balance it out like it was previously.

My reasoning for this is due to the fact that the person doing the planet drop has to recieve the message and process the information before taking action.

We run into a similar problem with the robots at work... Certain people in production like to adjust timers in a robot to speed the line up... Unfortunately, they will take 1/2 a second off of 1 robot, and not the other one sitting next to it, "because it looked like it was going fast enough"... What happens is usually a crunch... (Yes, we run these robots that close...)

The solution we use in maintenance to increase line speeds is to reduce all the involved timers by the same amount... You could do the opposite... Add x number of mS to every delay... This would ensure a linear result across the entire game... Then if that works out, you can "tweak" the individual timers as needed...

Again, just my $0.03 worth...

I'd just like to make sure it's as simple as that. I'll try what you suggest first, but I'd like to have some hard numbers to verify that it's going to work out as intended.

I can make the "zero delay" something as low as 30 ms, then up the 250 ms delay to 280 ms, which should have a minor effect on pacing in the game, but which would lock in these delays.

The thing to do to test it would be to throw up an unlimited turn game and advertise when it's going to be banged. I'm sure there are 4 or 5 players that would get into it if it were to be an actual game and not just a test game. If things seem screwy I'm sure they'll let you know cause you know how us TW players like to whine.
If you don't want the hassle of advertising it, I can even throw whatever version you want tested up on Silver Wings and I can get 4 or 5 players into the game

I have been testing certain combonations of actions at Toyland but he is having issues with the isp.

Ill have some data shortly

I did. Is there anything specific to test?

Seems we have...

Move delay
Pwarp delay
Bwarp delay
Xport delay
Land delay
Attack delay
Game entry delay

I would be very reluctant to add a photon-specific delay,
simply because it makes balancing the rest of these very
difficult.

Right now it's...

Move delay = 250
Pwarp delay = 0
Bwarp delay = 0
Xport delay = 0
Land delay = 0
Attack delay = 250
Game entry delay = 0

But if we did...

Move delay = 300
Pwarp delay = 50
Bwarp delay = 50
Xport delay = 50
Land delay = 50
Attack delay = 300
Game entry delay = 50

It would still work pretty well. The problem comes
when the delays reach larger than the average ping.
If, for instance, you have a 200ms up front land delay,
then an adj photon will hit too easily. If you slow down
torps, then the balance is off again.

As for landing delay, I wouldn't make it at the landing
itself, but rather at the point where the defenses stand
down message occurs. That would mean that the player
is on the planet already when the delay hits, but would
eliminate the landing lag bug. You could make that up to
100ms and it wouldn't be a problem, then. If that's not
quite good enough, maybe a small 30ms delay on the
landing (after the command is successful, but right before
the landing occurs) and another 50ms after.

Right now the game also lags a bit when someone enters
the game. Adding a small entry delay might help that.
But that needs to be less than the typical lag too, otherwise
someone can sit w/ an attack script and kill decloaking
players.

Some of these things will be used together. An example would be:

pgrid/saveme --- move delay (300) + land delay (50) = 350 ms + ping
pgrid/export ---- move delay (300) + xport delay (50) = 350 ms + ping
pgrid/retreat --- move delay (300) + move delay (300) = 700 ms + ping

While pwarp/ptorp and bwarp/ptorp scripts would have less delay
Pwarp/torp ----- pwarp delay (50) + ptorp delay (0) = 50 ms + ping
Bwarp/torp ----- bwarp delay (50) + ptorp delay (0) = 50 ms + ping

300 ms difference vs. a 250 ms difference from before = 50 ms greater delay than before.

I'd think a 275 ms move delay would be better reducing the difference to 25 ms instead of 50 ms. Either that or add a 50 ms ptorp delay also.

No, no, and no. Move delay happens before the move, not after. So your
math is wrong. Also, pgridding doesn't involve ping if you do it right.



You're wrong.



Dumbest suggestion to date. If you do that, you make it near impossible
to pwarp torp gridders.

Yeah, that's what I'm concerned about, having these delays compounded.

I think I can get away with a 15 ms delay for the short delays. The literature consensus is that 15 ms is the minimum timer resolution I can expect from a general system. So let's try that.

Since it appears that I have to explain this...

Pgrid:
Call saveme, wait for response, move, hitfig, layfig, burst of lands

Callsaveme and waiting for response = 2, maybe 3 ping cycles. But
you're still on the planet.

Move = Move delay, but you're still in the original sector. While
someone can sit adj and run a dtorper, the 250ms move delay
is plenty enough for that. When people worry about getting torped,
it's in the hitsec. This move delay doesn't happen in the hitsec.

Hitfig = This takes about 20ms, depending on the server

Layfig = Another 20ms, depending on the server

Burst of lands = Varies, but about 50ms or so.

Total? Under 100ms.

If you add a planet move delay, and a landing delay AFTER the
landing like I suggested, then you bring it up to 150ms or so.

So, what happens? Well, against a fast adj torper, you get hit
pgridding if you grid in a line. That's no different than it is now,
however. So the timing balance hasn't changed. You can solve
this with an xport, or by fixing your macros. Good macros can
reduce the time it takes to lay and kill figs.

But lets say you xport:
1. Call, wait for response, move, killfig, layfig, xport
2. Wait for successful pgrid msg, xport back, land

Calling save and waiting for response, along with move, happens
in the original sector. Killfig, layfig, xport, that's 40ms plus an
xport delay. A 50 ms export delay takes this to under 100 ms
again, while reducing the amount of strain an xport puts on the
server (the path calculations between a dozen ships can cause
the server CPU to spike).

Waiting for the response, eh, 2 ping cycles maybe. Then an
xport and land macro. If xport delay happens before the xport,
and the landing happens after the landing, then you get no extra
delays here but it does add stability to the server.

So against a slow torper, or a pwarp torper, you can straight pgrid.
Against an adj torper, you have to xport pgrid. Meanwhile, fix up
your macros and reduce the delay.

If you're worried about 50ms being too much, which I doubt but
you can test, a 25ms delay would be perfectly fine.

There should not be a ptorp delay. Why? Because of the difference
between adj, dtorp, ptorp, and btorp. You cannot keep the balance
across all of those.

About photon delay, there already is an intrinsic delay there. It's just that at this time it's not controlled. Isn't it better to have a very small (15 ms) controlled delay that won't change? If it has a negative effect on other timings, then it may be necessary to adjust other timings so that this small delay is negligible. But not having a delay in there doesn't mean there's no delay, it just means that it's an uncontrolled delay.

Well, except if it's greater than 15 because the CPU is slow, then
it's still going to be over 15ms. You can't guarantee performance
on a slow CPU. On the other hand, with the fastest of CPUs, it could
be close to 0. So the real question isn't about an uncontrolled delay,
it's about how a 0 delay affects play. And a 0 delay photon helps,
rather than hurts, it. There will always be some aspect of uncontrolled
delay due to ping, that cannot be helped.

What I'm getting at about the timings here is that you can't adjust
the timings for all situations. There exists no combination of settings,
with a ptorp delay, that can be as balanced as no delay. Just think of
the permutations a bit, you'll see what I mean.