Forged Alliance Forever

Re: test for ui lag

2016-11-13T22:33:49+02:00

ckitching wrote:
SeraphimLeftNut wrote:If this is exactly true, then this thread exactly has no point

That is what we have been trying to tell you.

This is not exactly true however. Three examples:
1. Units coming out of factories. The new unit is finished, and is given a new order as it is rolled off. This order needs to be synchronized between the peers' systems. Depending on the connections, cpu's, unknowns..., etc. the units coming out of factories will linger around for drastically different amounts of time.

2. Engineers assisting factories are repairing units that are being built. Once the unit is built, the engineers need to stop repairing that unit and begin repairing the new unit that is being built. OFten times, again depending on connection, etc. they will continue to repaire the unit that is already built and will even attempt to follow it out of the factory.(This can result in weird patterns of engineers around heavily assisted air factories, something that happens to drastically different degrees game to game) The stop repairing and repair new units commands need to be synchronized between the different systems. Please don't attempt to call this process deterministic.

3. Once a unit is rolled off from a factory a new unit needs to be initiated. This has to be synchronized between systems. This can actually have a significant effect on relative build capacity between players.

Statistics: Posted by SeraphimLeftNut — 13 Nov 2016, 22:33

Re: test for ui lag

2016-07-01T19:34:12+02:00

SeraphimLeftNut wrote:
If this is exactly true, then this thread exactly has no point

That is what we have been trying to tell you.

Statistics: Posted by ckitching — 01 Jul 2016, 19:34

Re: test for ui lag

2016-07-01T17:25:45+02:00

Sheeo wrote:
SeraphimLeftNut wrote:Could you go into more detail about how a patrolling engineer looking for reclaim chooses a piece of reclaim to reclaim and synchronizes this across different games running on different players systems.

Unit AI choices have no need to be synchronized across peers during the game, because they're deterministic and based off of the initial game state.

That is, the engineer is given a patrol order, then until it's given any other order, no further information about that engineer is exchanged between peers.

Imagine it not being this way, and having the game require to exchange commands for every action that every unit performs -- it would be exactly like the FPS model of state synchronization.

If this is exactly true, then this thread exactly has no point

Statistics: Posted by SeraphimLeftNut — 01 Jul 2016, 17:25

Re: test for ui lag

2016-07-01T16:18:34+02:00

SeraphimLeftNut wrote:
Could you go into more detail about how a patrolling engineer looking for reclaim chooses a piece of reclaim to reclaim and synchronizes this across different games running on different players systems.

Unit AI choices have no need to be synchronized across peers during the game, because they're deterministic and based off of the initial game state.

That is, the engineer is given a patrol order, then until it's given any other order, no further information about that engineer is exchanged between peers.

Imagine it not being this way, and having the game require to exchange commands for every action that every unit performs -- it would be exactly like the FPS model of state synchronization.

Statistics: Posted by Sheeo — 01 Jul 2016, 16:18

Re: test for ui lag

2016-07-01T15:28:30+02:00

Thanks Ckitching.

TA , would digging into even more details would lead to any kind of measurable improvement though ?
It works well enough for a nearly ten years old game. I'm quite fascinated by your resilience in your quest, not sure many of the rest of us will want to plug a USB voodoo doll to our computer in hope it might do something though.
( even if it's all a rational pursuit, I still don't want FAF to meddle with Windows registry because it might help solve a problem I don't have :p ).

Statistics: Posted by Zoram — 01 Jul 2016, 15:28

Re: test for ui lag

2016-07-01T14:56:51+02:00

ckitching wrote:
When you give an order, the game always schedules it a certain amount in the future, not right now. (I think it's either half a second or 1 second right now, can't remember, it's tunable).

The reason for this is that for each simulation timestep to be displayed, your computer has to have received all the orders that everyone wants to make in that timestep. If you scheduled the order for right now, then the simulation would have to stop for everyone until your order has been sent to everybody. By scheduling your order a little bit in the future, the game has some time to synchronise before that order has to happen, so your simulation doesn't freeze.
When you see a game freeze and someone is "behind", that's basically what has happened: the simulation has caught up with the command stream and we're now stuck waiting for someone to tell us their orders (even if it's nothing) for this step so we can carry on.
The tradeoff is there is a delay between giving an order and anything happening (but units that were already carrying out orders don't freeze in place).

This isn't something to be "fixed", that's just how it is. Almost everything that comes out of your threads to do with "reducing UI lag by avoiding memory fragmentation" and suchlike has little to no technical merit. Would you like a tinfoil hat?

Yes. What you have stated here I have already stated in other threads in greater detail, but thank you.viewtopic.php?p=125377

Could you go into more detail about how a patrolling engineer looking for reclaim chooses a piece of reclaim to reclaim and synchronizes this across different games running on different playerss systems.

Also, it is not just a tinfoil hat, it is a Faraday Cage.

Statistics: Posted by SeraphimLeftNut — 01 Jul 2016, 14:56

Re: test for ui lag

2016-07-01T05:54:55+02:00

Astrofoo wrote:
I'm imagining what FA games would be like if we used the FPS update system....

It simply wouldn't work with a peer to peer communication style. As with an FPS the simulation is being run on a server. It might however be interesting if strategy games could recover from de-syncs. The only way I could see this happening would be by having a voting system to determine the majority checksum state. Those players who have a divergent simulation, upon having re-established connections, would then need to download the majority game state - and then have the simulation continue from that point.

Just thinking about it. If this could work it would theoretically be possible for players to join a game mid-game. Either by introducing another army (such as another ACU gating in) or by assuming control of an existing army (perhaps belonging to a previous player). It was suggested that this would be a neat way of running the Galactic War. Where battles on world maps would be persistent, and reinforcing players could join the battle in real time.

Statistics: Posted by Hawkei — 01 Jul 2016, 05:54

Re: test for ui lag

2016-07-01T04:38:59+02:00

I'm imagining what FA games would be like if we used the FPS update system....

Statistics: Posted by Astrofoo — 01 Jul 2016, 04:38

Re: test for ui lag

2016-07-01T03:50:34+02:00

Zoram wrote:
out of curiosity, how do they manage in multiplayer fps where split seconds matter ?

FPS games work a completely different way.

So, FA basically works by running a simulation on everyone's computer, in a synchronised way. Everyone starts in the same state, and has rules for how to advance the simulation. You synchronise the orders everyone gives, and there are rules for how to apply these to the simulation so things evolve in the same way for everyone.
If there's a bug that causes this in-sync property of the simulation to be violated, that's a desync error. The game periodically calculates a checksum of the entire sim state and compares it with everyone else to make sure you all still have exactly the same view of the game world. If you've diverged, you're fucked. It's a really neat way to do strategy games on a large scale, because you send very little data (you basically only send a description of what buttons people press and nothing else).

Shooter games work very differently. Firstly, they don't care if messages get dropped: they use a different way of sending messages that is faster than what FA does, but has a risk of messages not making it to the destination (or arriving in the wrong order!). They then proceed to spew little updates at rapid intervals and hope for the best. The software extrapolates from the last update to fill in the blanks (so it'll keep everyone moving in the direction their last update said they were moving in, for example. Ever seen someone in a shooter game just randomly running with their face against a wall? Their connection had probably dropped and the program didn't work it out yet).
They're normally a bit clever, and do things like send updates less often (or even not at all) if you're just going in a straight line. Shooting normally just gets sent as a position, direction, type of weapon, and timestamp ("I shot this, there, then"). Ever seen a laggy player in an FPS game mysteriously seem to spawn a rocket slightly behind themselves? That's how this happens: their shoot message got delayed relative to their walking.
If a move message gets lost or something, it doesn't matter too much. The person will lag a bit and then jump to whatever their next update says. (a move update will probably contain both your position and velocity, so the game has something to extrapolate from so you don't notice the fact that everyone is actually only updating their position every 50ms or so. This positional uncertainty is also how you can get that thing in shooters where you totally hit that guy but it didn't work: his real position was actually somewhere else, and you were shooting at your computer's extrapolation of where he probably is.)

It handles the split-second thing, but it does it by sacrificing the ability for everyone to always see exactly the same view of the world. That's why laggy FPS games start getting all weird and glitchy, and laggy FAF games just get slow.

Statistics: Posted by ckitching — 01 Jul 2016, 03:50

Re: test for ui lag

2016-07-01T03:08:37+02:00

ckitching wrote:
When you give an order, the game always schedules it a certain amount in the future, not right now. (I think it's either half a second or 1 second right now, can't remember, it's tunable).

The reason for this is that for each simulation timestep to be displayed, your computer has to have received all the orders that everyone wants to make in that timestep. If you scheduled the order for right now, then the simulation would have to stop for everyone until your order has been sent to everybody. By scheduling your order a little bit in the future, the game has some time to synchronise before that order has to happen, so your simulation doesn't freeze.
When you see a game freeze and someone is "behind", that's basically what has happened: the simulation has caught up with the command stream and we're now stuck waiting for someone to tell us their orders (even if it's nothing) for this step so we can carry on.
The tradeoff is there is a delay between giving an order and anything happening (but units that were already carrying out orders don't freeze in place).

This isn't something to be "fixed", that's just how it is. Almost everything that comes out of your threads to do with "reducing UI lag by avoiding memory fragmentation" and suchlike has little to no technical merit. Would you like a tinfoil hat?

out of curiosity, how do they manage in multiplayer fps where split seconds matter ?

Statistics: Posted by Zoram — 01 Jul 2016, 03:08

Re: test for ui lag

2016-07-01T02:19:52+02:00

For God's sake TA, just accept that the game isn't perfect and try to just naturally enjoy the game and its little imperfections. Shit happens and that's just all there is to it. You of all people know how old this game is. There is only so much doctoring that can be done to it to better optimize performance without making an entirely new game. I get on the forums only occasionally, yet the only new threads I ever see are from you about ui lag. Come on man...

Statistics: Posted by Rapier31 — 01 Jul 2016, 02:19

Re: test for ui lag

2016-07-01T00:32:32+02:00

Useful technical information:

ckitching wrote:
When you give an order, the game always schedules it a certain amount in the future, not right now. (I think it's either half a second or 1 second right now, can't remember, it's tunable).

The reason for this is that for each simulation timestep to be displayed, your computer has to have received all the orders that everyone wants to make in that timestep. If you scheduled the order for right now, then the simulation would have to stop for everyone until your order has been sent to everybody. By scheduling your order a little bit in the future, the game has some time to synchronise before that order has to happen, so your simulation doesn't freeze.
When you see a game freeze and someone is "behind", that's basically what has happened: the simulation has caught up with the command stream and we're now stuck waiting for someone to tell us their orders (even if it's nothing) for this step so we can carry on.
The tradeoff is there is a delay between giving an order and anything happening (but units that were already carrying out orders don't freeze in place).

This isn't something to be "fixed", that's just how it is.

Kick in the balls on the way out:

ckitching wrote:
Almost everything that comes out of your threads to do with "reducing UI lag by avoiding memory fragmentation" and suchlike has little to no technical merit. Would you like a tinfoil hat?

Statistics: Posted by nine2 — 01 Jul 2016, 00:32

Re: test for ui lag

2016-06-30T22:18:54+02:00

When you give an order, the game always schedules it a certain amount in the future, not right now. (I think it's either half a second or 1 second right now, can't remember, it's tunable).

The reason for this is that for each simulation timestep to be displayed, your computer has to have received all the orders that everyone wants to make in that timestep. If you scheduled the order for right now, then the simulation would have to stop for everyone until your order has been sent to everybody. By scheduling your order a little bit in the future, the game has some time to synchronise before that order has to happen, so your simulation doesn't freeze.
When you see a game freeze and someone is "behind", that's basically what has happened: the simulation has caught up with the command stream and we're now stuck waiting for someone to tell us their orders (even if it's nothing) for this step so we can carry on.
The tradeoff is there is a delay between giving an order and anything happening (but units that were already carrying out orders don't freeze in place).

This isn't something to be "fixed", that's just how it is. Almost everything that comes out of your threads to do with "reducing UI lag by avoiding memory fragmentation" and suchlike has little to no technical merit. Would you like a tinfoil hat?

Statistics: Posted by ckitching — 30 Jun 2016, 22:18

Re: test for ui lag

2016-06-30T21:17:03+02:00

Legion Darrath wrote:
Can you stop making new threads about UI lag for literally every thing that you think of? Make one thread and use that to report your findings.

It took you this god damned long to get annoyed?

Statistics: Posted by briang — 30 Jun 2016, 21:17

Re: test for ui lag

2016-06-30T11:03:25+02:00

Can you stop making new threads about UI lag for literally every thing that you think of? Make one thread and use that to report your findings.

Statistics: Posted by Legion Darrath — 30 Jun 2016, 11:03