Ok, so this new instant message queue changes a lot
of game timings. I mean a lot. A 100ms pwarp delay
is suddenly not off the charts here, considering.

So here's my thoughts...

On a pgrid, the hit and land is about 100ms at most
(usually closer to 80). That needs brought up. So how
about bringing the pwarp delay up to 60ms. That would
plug that problem.

On the pwarp photon, we now have a window of about
260ms. That's about 100ms too big for a pwarp foton,
but if we increase pwarp to 60ms, then the timing is
only about 40ms off.

Now I'm not sure how to balance that further. If we
move up the pwarp delay too high, it'll make pgridding
impossible. If we bring it up down, it makes pwarp
torp too easy. A photon delay works against the pgrid
balance.

So here's a thought, I don't know if it'd be feasible
or not. How about adding an extra 2ms (in addition to
the 60ms) per pwarp hop? That way if you're far away,
it takes longer to shoot (makes sense, actually), but
if you're adjacent, then you've got a better chance.

That would give people a way to combat pgridding while
still giving regular gridders a chance to move around a
bit. From there, we can test those new baselines.

The test server has the up to date timings?

I'd like to test for myself. I don't want to see direct torp get to powerful.
That would stalemate every game.
I think you put too much on pgridding personally.
It is expensive to pgrid compared to other methods and this limits its use.
You will never stop a 2 ship planet gridder with a standard direct torp but that is expensive with both turns and fuel so is self limiting in use.

I believe it does.

You might be right, I do put a lot of emphasis on
pgridding. I do that because it costs more ore,
and thus is more balanced than regular gridding.

A good 2 ship pgridder is very difficult to stop,
but then again it's also very costly to run, too.

This is one of the reasons why I'd like to see the
distance-based delay. Wouldn't it be cool if the
placement of the torper actually sped it up? That
would bring about some cool techniques to direct
torping.

Once we get these timings in, we can work on the
direct torping thing. I suspect we might need to cut
back on the move delay some.

I think your idea is Great actually. Maybe more than 2 ms would be ideal.
Id like to test some timing on combonation moves to see the balance for myself.

The planet does an ore check vs distance before it moves so i doubt the added feature would be an issue.

Low end timing is 2 ms. Most delays are only 2 ms and that allows 500 such actions per second. I believe that's fast enough that nobody will notice that it's paced, yet it will not change from this point on.

Ok, I had a bug in the event system that was causing messages to be ignored now and then. I tracked it down and it's fixed, and my testing shows that the new approach to events is stable, efficient, and fast. With 30 players moving around in the same few sectors, generating a ton of output and events, both of which use the windows message system to function, I was reading 0 ms delay on the event turn-around time. So I'm pretty confident of it.

I will now implement the timing changes you requested. I intend to hold off on release until we get these timings right and players don't notice any difference in gameplay.

Keep in mind that the time for an event to be processed is no faster than it could be received before, it's just that it's consistent now. Before, you could receive an event notification anywhere from 0 to 250 ms from the time of that event. Now you're consistently receiving the notification immediately. Of course, if that's too fast, there's no reason we need to provide the player with the event notification immediately, even if it is received immediately. Or we could provide the notification, but not allow the player to respond with an action immediately. The point is, we have control over the timing and we can make it consistent. But the timing of the event notification could pretty much be whatever we need it to be.

I already have a delay that's imposed between receiving an event and acting on that event, and that delay could offset this change. If we need a 100 ms delay in reacting to an event, we can do that. We could even have a random range to emulate the randomness of the 0 to 250 ms delay that people are used to.

I like the idea of having a variable delay for pwarp based on distance. But this might be too big of a change. What I'd like to do is work out ways to reproduce the current balance with the new timings, without changing gameplay. However, if there are no objections from players on this forum, I would be willing to give it a try.

If we add back a 50ms message delay, then that slows down
the response for both. That's fine for defense against a
normal gridder, but now that makes hitting a pgridder
almost impossible (unless you can find a way to slow them
down exclusively, I'm not sure how that could be done).

What I am looking for is a way to balance the pgrid against
the regular gridder. Give pgrid a slight edge because of
the resources spent, but not so much of an edge its impossible
to hit.

This reason this particular thing changed is because the
better pacing has reduced the server-side lag spikes that
used to get us hit. IMO, that's a good thing.

When pgridding, most people pgrid in a line. This makes it
easy predict the next hit, so you can go adjacent and torp
w/o having to pwarp around. That makes pwarp a useful item
for balancing stuff like this.

A distance-based delay would allow people to have fast pwarps
when they need them, and slow them down for other situations.
It wouldn't change play too much tho, people would pick more
centrally located places to torp from and would use pgridders
that hop around a little bit, but both are already done for
other purposes.

I'll test the current timings and let you know how they go.

You're preaching to the choir on this. I think it's a great idea. But I did promise that I wouldn't change gameplay if I can avoid it, so the question is whether there are some here who would consider this a major change (Kewlbreeze?).

Keep in mind that the delays in the game right now are the same I put in several days ago. I have not yet implemented the new timings you requested.

Actually I suggested the distance based pwarp delay months ago. I don't see this as a major game change. However, it will justify some upgrades in grid and torp scripts if you want top efficiency.

I seem to recall some resistance to the idea, but I may be mistaken.

Sing, if you make a list of several important delays, I would be willing to create an editing screen so you can experiment with various times on your own. That might go a lot more smoothly than trying to work together on it.

I can't recall exactly what was said then. Keep in mind that was before many of the of current changes were made, so the circumstances a different now.

Pwarp
Land
Xport
Fig kill
Fig lay
Move
Photon

And maybe add an event queue delay jIc.

Under this condition Pwarp foton not only gets more expensive gas wise but slower the farther away u get. Faster and less expensive the closer u get to someones base or central protective grid. Grid is intended to protect you. I dont see this as a major game change especially if it helps balance other things. It makes sense and adds complexity. Both are good things.