How long we want the command delays to be?

This is an Internet forum, nobody listens to anyone!

Welcome to the Internet!

Enjoy this complimentary CAPS LOCK!

Mike

you insane

So the issue of forced latency is a complicated one. Certainly we will be injecting as little latency as possible into the process. At a minimum before you see a unit moving it will take round trip time.

my understanding here is not anti micro but allowing the game to proceed in a more predictable manner, in supcom the delay was to allow transmission of the order to all players and acks of receipt so that the sim progressed in the same way for everyone, here it would be more allowing the server enough time to transmit that to everyone, not a matter of no you can't micro cause its not nice, but that if you are microing we want the other player to at least be able to SEE what you did before it impacts them. and realistically i'd like no latency to be forced but at max 300ms, but if it's under 150ms it's going to be invisible for all but the most proficient microers as for most people response under 150ms appears instant

Sup Com was 500ms and that wasn't noticeable, so I wouldn't be concerned.

No, OrangeKnight is right. The lag you are talking about is the net_lag value of the Supreme Commander engine. It was 500ms in Supreme Commander and Forged Alliance and 350ms in Demigod. This enables the peer-to-peer architecture to be played with players that have a (constant, stable) ping up to 500ms to you (and vice versa), or 350ms respectively.

If the travel time between two players is higher than that (may be just momentarily), then there will be pauses in the game, since the game is waiting for the synchronized data packets.

Btw. for comparison, StarCraft also has such a setting, which can even be altered in the options. The highest value is equal to 250ms, if I remember correctly.

Supcom's delay was very noticeable. The sound when selecting a unit (or giving orders) is there to mask the delay, give it a try with that in mind.

Selecting a unit does not cause a delay. Only actual commands are delayed.

He is a site admin, hes in the "Uber employees" group and he seems to know what hes talking about (He links some articles on supcoms networking in the same post).

So im going to assume that his facts are accurate (But any opinion he makes is his own, says so in his signature).

From the articles:

And to my modding knowledge of the engine (which is admittedly rather superficial), unit selection is never synchronized. As the article states, only the input for units or groups of units is synchronized. Which depends on the selection of course, but there is no prior additional data sent and synchronized to each other client, which units the player currently has selected. (Which would create an additional lag on top of the lag of issuing an order.)


Link to bgolus' post garatgh meant: viewtopic.php?p=534013#p534013

You make a very good argument.

Maybe he (and therefore i) was wrong.

I guess we will have to wait for bgolus or Neutrino to post and defend or condemn the statement (to know for sure).

Network lag in the interface is horrible. If it is there you should definitely mask it.

Even unit states should be switched immediately in the UI. I don't care if the unit hasn't actually changed unit state yet in the simulation.
The worst is when you are trying to switch through several unit states by clicking the same button.
Example:
The unit have three move states. "Hold position", "Maneuver" and "Roam".
Your unit is on "Maneuver" and you want to switch to "Hold position".
You click once on the button for move state. The button doesn't change until you get a confirmation from the server. So you click once on the button and wait for the button to switch from Maneuver to Roam and then you can click it once more to go from Roam to Hold position.
Especially with varying latency this is annoying as you don't know how long you have to wait, it brakes your flow, you have to constantly watch the unit state changing and makes it really hard to time it right with just 2 clicks.

Another example from SupCom FA:
You change the firestate from Return fire(Attack move by default when using attack command) to Attack ground. You quickly press Attack because you want to attack the ground. However since the fire state change isn't noticed until the simulation has updated 0.5 seconds later you get the Attack move command instead of the Attack ground command.
In order to get the Attack ground command you have to change the fire state, wait 0.5 seconds and then press Attack to get the Attack ground command.

I would prefer that unit states are always updated locally even though the units haven't actually changed their unit state in the simulation yet.
If you change the unit state and reselect the unit quickly it would be good if the new unit state is shown even though it haven't been changed in the simulation yet.

Indeed, the unit state could be changing while it waits for a real server response. Tanks could turn towards their destination and begin to pack up, making it look as though they're getting ready to perform the command. If it appears that they take half a second to turn around, then they can move immediately when the server gives the OK.

Turrets can have the same appearance, turning around and getting their guns ready for the server's signal to fire.

That would only work if the turning is instant and not simulated. Also what if the tanks are moving? They can't change direction before the server acknowledges it.

There might be ways to make the units seem to respond instantly on your commands but I doubt it can be part of the simulation.

Sure they can. Judicious use of acceleration, turning rates etc. means that a vehicle can not make an immediate action, no matter what the ping is.

They might rubber band if something hiccups, of course.

Before the server has acknowledged the new command the unit will keep its' old course. If the unit is turning but still going straight forward it might look strange.
I think Warcraft 3 did it this way. But units turned instantly and turning wasn't part of the simulation in Warcraft 3.

I don't think that the game can show anything that is part of the simulation beforehand unless it is doing something before it is actually recognized in the server.

While I don't know if it was really on purpose for supcom or a work-around for something, this is something that is not ridiculous to ask IMO.

In the total war games you also have a delay (even in single player) when trying to move your troop formations around. This is a good in the sense that it prohibits close range "kiting" a bit (or instantly rotating your spear men at cavalry in 0 sec) and focuses more on the macro aspect of the warfare. Since PA is going to focus on the macro type of gameplay, it could be a thing to consider. So players can play on multiple battlefields at once, not automatically losing where the opponent is using micro and the player is not.

It was also realistic to so in the total war games, as the commands would need to go through the chain of command (general>captain>sergeants>soldiers). This last point may not be as relevant for PA however.