How long we want the command delays to be?

i think to make the game more fair between players with differnet connection a "forced" latency would be nice. everybody has an minimum ping of like 100 and only players with realy crappy internet will suffer.

No. Lag compensation is a bad idea.

Why? 100 milliseconds isn't much. SupCom had 500.
It is easier to adapt to a set delay rather than one that is changing all the game.
How does Starcraft do it? Micro is highly proficient in Starcraft and if 1 player have much higher latency to the server than it can really be considered a disadvantage.
That said, PA isn't going to focus as much on tight micromanagement so I doubt that high latency is going to be a big disadvantage.

Just have acceleration rates for units.

Problem solved.

That should already be part of the simulation aspect, but I'm don't see how it solves anything?

Mike

:lol: Exactly!

There are better ways to do away with micro than delaying responsiveness to a command. ZK implements a few.

igncom got a point in that low acceleration makes high intensity micro like stutterstep and projectile dodging harder to perform.
Even though SupCom have 500 ms delay you still see intense bombermicro and projectile dodging at times. You just have to give the commands earlier.
If you want to decrease the viability of projectile dodging it would be good if you added turn rate acceleration as well. You can't jinx as fast back and forth then.

Although I'd still say that parts of Zero-K are micro intensive. Like raiders vs raiders.

Low acceleration can be a brilliant idea, but the Supremilated mod (gosh, that's getting old now) tried it and it broke the path finder when you had blobs of tanks. It broke doubly hard when you wanted to formation move them too.

How so (I never had a chance to play it) as I am curious?

Haha! Don't get me started on how much more complex pathfinding have to be with low turn rate acceleration. But... Impossible is nothing!

The path finder wants to keep units close to each other (kind of important when you want a formation). Units in the front edge of the blob could freely drive off, while those behind are blocked momentarily by the front. Since units have a slow acceleration, those blocked take too long to move, then the front units stop and come back because they're straying too far from the formation.

Now the front units are back in the blob, and blocking the units again. Derp.


I suppose this could be fixed by increasing the distance that units were allowed to stray before returning. But at the time, I don't think anyone knew if that was possible.


Also, this was without flow-field pathing. Whether or not the same thing would happen with FF is purely speculation.

The problem in SupCom was that a unit driving into another unit from behind would lose all its' speed. This doesn't happen with flow-field pathing so I doubt it would be an issue.

He was suggesting forced latency. Would you like the game to raise your ping just because? I certainly would not. I'm not arguing over whether I like micro or not, I don't really care. I do care about a forced latency though.

I would prefer no latency at all but that is most likely not technically possible.
SupCom had half a second forced latency. If the host could set the latency to a tenth of a second to keep everyone on equal terms while the orders are executed on my computer one tenth of a second after I give the commands, I would prefer it that way.

The argument that PA isn't going to be microintensive could go both ways:
"It doesn't matter that your orders are executed with latency delay because micro isn't that important"
"It doesn't matter that your orders are executed with 100 ms delay because micro isn't that important"

I understand that SupCom had a forced latency, I'm just saying that I don't want it to return in PA. There is no reason for there to be a forced minimum latency. However quickly you can send information to the server should be your ping, not some predetermined amount. Whether it makes micro hard or not, really does not bother me. I honestly do not care about micro's presence. Besides, I imagine that it's one less line of code to not include forced latency. Uber could better focus their attention elsewhere.

Forced latency is only needed for peer-to-peer models, since in that system all the clients must be sync'd to each other (so you'd get crazy lag spurts without some limit). However, not including it in PA in some way would give people with lower pings an unfair advantage. I'd imagine some middle ground is needed (say an enforced latency, but reducing it from the 500ms it was in SupCom).

an option for a short forced latency for sake of fairness might not be a bad idea.

Besides, the client server model might have a say in it, independent from your ping the server's effort to keep things synchronized might add some delay anyhow.

We should consider ourselves lucky, that they probably don't implement the bureaucracy communication model: write, sign, fax, end of work day, copy, stack,weekend, send response

Im realy starting to hate how everyone just ignores my posts now days. Maybe i should start borderline trolling just to get some attention. :roll:

Anyway, time to repeat myself: Its been confirmed (well somewhat confirmed atleast) that a delay will be present, it will be shorter then supcom's but still longer then TA's.