Openrct2: Guests stop and watch ride preview "ghost pieces", causing desyncs in multiplayer

[andreas-haratzis]

OS: Windows, Linux, Mac (Assumed)
Version: 0.0.6
Commit/Build: 171d973e55ff93565cb238799322bed4fd2cd816 (latest on develop at time of writing)

While building together in multiplayer, we (@tallow-cro and I) noticed that desyncs would often occur moments after we started building in a busy park. Eventually we figured out that guests were stopping and watching the white ghost-like pieces of roller-coasters and rides, as if they had been placed (but not opened yet). We figured that because the ghost pieces aren't synchronized, this was causing desyncs.

• [x] Reproducible in RCT2 (vanilla) (confirmed on the very first park)
• [x] Multiplayer? (this issue occurs across all game-play, but is only an issue in MP)

We further verified this was the case by removing the behavior in peeps that move their state into 'watching' - no further desyncs were reproducible using the method outlined below (though clearly not an actual fix).

I'm guessing that this could be fixed if the sprite sweep used for enabling the watching state ignored ghost pieces. This would deviate from the original RCT2 behavior, but we figure it's very minor.

Steps to reproduce:

1. Start a fresh park with a few guests
2. Begin constructing a thrill ride (e.g Twist) and hover it near a busy path. Also works with roller coasters.
3. A guest will eventually watch the ride being constructed

Screenshots / Video:

Oh and lastly, it would be greatly appreciated if Tallow and I were able to fix this bug for the project, if it is actually confirmed etc. Would be a nice programming exercise :D

[IntelOrca]

Nice find

[duncanspumpkin]

We will probably just have to disable the feature in multiplayer much like the being watched thought

[IntelOrca]

Don't we just need to check whether the track element is a ghost? - it seems strange for peeps to look at something which is for your eyes only.

[YoloSweggLord]

That's quite the bug catch. And yes, anyone can contribute to OpenRCT2. Just make sure no-one else is working on it at the same time as you.

[janisozaur]

@andreas-haratzis see https://github.com/OpenRCT2/OpenRCT2/pull/4712

[duncanspumpkin]

@IntelOrca there are two separate watching events one for built rides and one for ghost rides. I think. Will need to check

[IntelOrca]

Fair enough then, we can just do what you suggested then

[Gymnasiast]

I believe the 'Wow! A new ride being built!" thought is coupled with ghost rides.

[duncanspumpkin]

https://github.com/OpenRCT2/OpenRCT2/blob/4f61cae8a80145880e6db11e56a518eb10e4b63b/src/openrct2/peep/peep.c#L11538

It doesnt actually check for the map element ghost flag it just checks to see if the ride has no rating. This will require a rethought on the whole peep_find_ride_to_look_at as there will also be a desync caused by ghost scenery.

[Nubbie]

Well I presume A) Check for multiplayer flag and disable thought _viewing_ (easy) or B) Re-write parts of the command peep_find_ride_to_look_at | to fix it :U

Edit: _@duncanspumpkin yeah ment watching for it as the thought is just the next command together with animation, wasn't careful with the wording xc_
Still, just adding a simple quick flag would be maybe just a way of ignoring the problem instead of fixing it

[duncanspumpkin]

@Nubbie its not the thought that is the issue its the actual viewing. The easy way is to disable watching for everything when in multiplayer.

[IntelOrca]

The easy way is to disable watching for everything when in multiplayer.

That's extreme though, you only want to disable watching ghosts

[duncanspumpkin]

That means modifying the function to look for ghosts then. Its not a simple fix there are a few places that will need to be changed.

[Tallow-Cro]

@Nubbie brings up a good point though, even though we disabled the 'looking at un-built rides' behaviour, which stopped network desyncs being detected, having a guest think about a new ride being built is actually a theoretical desync that just isn't being checked for.
The only checks for network desync are:
1.) srand0 does not match between client and server
2.) Sprite Hash does not match between client and server

I know it seems like a small thing for a guest to be thinking about a different thing, but this could create a case where on one client they are thinking about a ride being built (But not watching, to fix the current desync issue), whereas on the server the guest is thinking about "This park is filthy" Which could be the 1 person that leads you to getting the "Guests are complaining about your path".
Or alternatively, they are thinking on the server-side "This park is really clean and tidy" which leads to you getting the reward for a clean park on the server, but not on the client.

Something similar happened when myself and @andreas-haratzis were playing actually. He received an award for the "Park with the best roller-coasters" at the same time I (The server side) received a reward for having "The tidiest park in the country"

Essentially, it's just a bit of the butterfly effect.

In the end, either 1 of 2 things will have to happen: Ghost rides will have to be seen on both clients (Which is not suggested at all, because a slight ping drop means that this will most likely cause MORE desync issues) or ghost rides would have to be ignored by Guests altogether, which out of the two is the easier issue to solve.

The problem with this ATM is that ghost rides are bundled into the same check as non-ghost rides when guests are watching, so it's going to be a bit of a task, as there are quite a few areas that will have to be changed. We haven't looked into how people "Think" about things yet, but we'll look into that and see what we find.

[Tallow-Cro]

There is actually a second desync issue that we will try exploring today, and that is 2 people trying to build rides when they lack funding.

We've found that sometimes when two people try to build a ride piece at the same time when there is only enough cash for one of them will sometimes result in BOTH clients seeing they have built the piece, whereas on the server-side, only ONE had actually succeeded in building the track, which leads to a gap in one of the rollercoasters. which is an immediate desync, and if it goes un-noticed, can lead to a HUGE desync where the server side has an incomplete ride closed that is open and running for one of the clients.

This is a much bigger issue, and TBH, there isn't much of a way to solve this one, except if the server side occasionally sent out the entire map t be re-downloaded or something. There may be a more elegant solution, but this one will be hard to nail down.

[Tallow-Cro]

@IntelOrca While disabling watching while in multiplayer is an 'extreme' fix to the solution, up front it is the best way to fix the current issue (which is persistent Network desyncs) until a better solution is crafted.

We found that while the watching was active, we would get the desync every few minutes, and sometimes within SECONDS of joining (People want to build stuff, you know?) but without it we could play for ages undisturbed.

Again, it's not the best possible fix, but as a temporary bandaid solution it would serve it's purpose extremely well.

[IntelOrca]

We've found that sometimes when two people try to build a ride piece at the same time when there is only enough cash for one of them will sometimes result in BOTH clients seeing they have built the piece, whereas on the server-side, only ONE had actually succeeded in building the track, which leads to a gap in one of the rollercoasters. which is an immediate desync, and if it goes un-noticed, can lead to a HUGE desync where the server side has an incomplete ride closed that is open and running for one of the clients.

That's interesting, any command should only be applied once the server has given the client an OK (in other words all actions have a round trip, client -> server -> client). This might not be too difficult to fix once the right place that is wrong has been found. #4924 may be related to this.

[Tallow-Cro]

After further discussion, this may be caused by a previous desync, as one
client may end up with more money than another.
We're going to have to look into this.

On Fri, Jan 13, 2017 at 11:29 AM, Ted John [e-mail] wrote:

We've found that sometimes when two people try to build a ride piece at
the same time when there is only enough cash for one of them will sometimes
result in BOTH clients seeing they have built the piece, whereas on the
server-side, only ONE had actually succeeded in building the track, which
leads to a gap in one of the rollercoasters. which is an immediate desync,
and if it goes un-noticed, can lead to a HUGE desync where the server side
has an incomplete ride closed that is open and running for one of the
clients.

That's interesting, any command should only be applied once the server
has given back the client an OK. This might not be too difficult to fix
once the right place that is wrong has been found.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenRCT2/OpenRCT2/issues/5058#issuecomment-272327080,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX6sMvViKhK3oCLgp51cIzD9yqEFDRIzks5rRsV3gaJpZM4LhwUN
.

[andreas-haratzis]

@janisozaur I did notice the good work @zsilencer did with the desyncs :D though where he mainly changed ride construction behavior, this would more require changes to peep behavior.

@Nubbie I'd much prefer to have a look at the B solution, since this behavior doesn't seem all that hard to rectify (though I'm not too well versed in the codebase haha) and personally I really like the feature.

I'll take a look into fixing peep_find_ride_to_look_at, and the surrounding code to its call to see if we can fix this

[duncanspumpkin]

Just remember it's not just rides peeps look at while under construction. It can also be scenery. Both will cause desyncs.

[andreas-haratzis]

Not sure if the email reply came through so apologies if this is duplicated:

peep_find_ride_to_look_at makes a lot more sense now, especially all those duplicate loops. Whatever I write for the ride I'll duplicate for all those other checks. Though as far as I'm aware everything that I need to change is still contained in that function.

[duncanspumpkin]

@andreas-haratzis yeah everything is in that function. What the function does is try work out if scenery would block your view of a ride. So each loop is checking another tile further out to see if the view is blocked.

[zsilencer]

With the other constructions we are using map_remove/restore_provisional_elements because there can be other side effects of the ghost, also so there's no need to change peep.

[andreas-haratzis]

@zsilencer Aaah that makes more sense, as @duncanspumpkin brought up there are checks if rides block views, there could be all kinds of these ride checks in peep behavior, ride behavior etc. that will need similar ghost checks...

So @zsilencer would this require similar changes to what you made in https://github.com/OpenRCT2/OpenRCT2/pull/4712 ? If so then I should probably leave it to you, I'd be way in over my head with that haha

[janisozaur]

Closing this as #5578 seems to have fixed it. Feel free to leave a comment/reopen, if you find it still affecting you.