Openrct2: Synchronize with adjacent stations has effect when adjacent station's rides are unfinished or removed

Created on 27 Jul 2016  Â·  6Comments  Â·  Source: OpenRCT2/OpenRCT2

OS: MacOS 10.11.6
Version: 0.0.5
Commit/Build: build 17c5178

When an unfinished or recently removed ride (Ride B) is adjacent to a ride that is openend/testmode AND has _Synchronize with adjacent stations_ enabled (Ride A), no vehicle from Ride A can leave the station.

  • [ ] Reproducible in RCT2 (vanilla)? (To be tested)
  • [ ] Multiplayer? (Not tested)

Steps to reproduce:

Bug for unfinished rides (= not suitable for testing/opening)

  1. Construct Ride A in such a way it's suitable for testmode and opening.
  2. Enable _Synchronize with adjacent stations_ on Ride A.
  3. Open/Test Ride A.
  4. Construct Ride B such that its station is adjacent to that of Ride A.
  5. Vehicles from Ride A will no longer depart from the station until Ride B is suitable for testing/opening.

Bug for removed rides

  1. Have Ride A and B adjacent to each other. At least Ride A should have _Synchronize with adjacent stations_ enabled.
  2. Remove Ride B.
  3. Peeps located in the front most vehicle of Ride A die of old age.

Screenshots / Video:
schermafbeelding 2016-07-27 om 22 47 58
_The station on Ride A even has green signal lights, but the vehicle refuses to leave because Ride B's presence. Even though Ride B, isn't open, doesn't have any vehicles and has never been openend before._
schermafbeelding 2016-07-27 om 22 52 20
_Before removing Ride B_

schermafbeelding 2016-07-27 om 22 52 54
_After removing Ride B_

Save game:
Diamond Heights.sv6.txt

bug

Most helpful comment

Oh… of course. Still I think it would be better the _Synchronize with adjacent stations_ gets ignored when no other stations are present. Or alternatively, a vehicle could have a status message with "Waiting for adjacent train to depart" to display in the bottom of the ride window. This could make it a lot more clear what's actually going on.

All 6 comments

While I'm not that familiar with the codebase, I've attempted to do some breakpoint debugging on vehicle.c to get a sense of where this problem could originate from. Can't say I've found the sticking point, but there are some things I think where notable to require further investigation:

  • The _synchronisedVehicles list never gets items removed, only added. This could explain why rides that are in actuality removed are still considered for the synchronisation. Perhaps this list should updated to check if all rides mentioned in the list still exist in the park (gRideList?).
  • This codeblock never seems to get reached, even in perfectly normally working synchronised rides. Usually a value is returned at either this or this point
  • My guess is that the solution for the first problem lies somewhere in counting the amount of vehicles on the other station. If the count == 0, don't consider it for synchronisation. This way you can account for a whole lot of different scenarios: adjacent ride is unfinished, adjacent ride doesn't have any vehicles but is open/testing (due to some hack, mod, error).
  • This loop is repeated twice in vehicle.c. Removing the duplicate doesn't seem to fix anything, but it should be removed nonetheless.
while (_lastSynchronisedVehicle < MaxSynchronisedVehicle) {
    x += TileDirectionDelta[direction].x;
    y += TileDirectionDelta[direction].y;
    if (!try_add_synchronised_station(x, y, z)) {
        break;
    }
}

The code needs to be looked into anyways because of #4178, so whoever does that can fix two bugs in one go.

Rides with synchronise with adjacent stations turned on never leave the station if there's no other ride to sync with. So if you don't build ride B at all, ride A still won't depart.

Oh… of course. Still I think it would be better the _Synchronize with adjacent stations_ gets ignored when no other stations are present. Or alternatively, a vehicle could have a status message with "Waiting for adjacent train to depart" to display in the bottom of the ride window. This could make it a lot more clear what's actually going on.

I think this is an original bug as well if the desynchronization crash bug was not triggered.

@Niels-NTG could you check if 5a046ece6078bc7629250b3ee45acb683b785f53 fixed this?

@IntelOrca Yes, it did. I tested the following cases:

  • Closing Ride B.
  • Removing the entrance and exit of Ride B.
  • Removing Ride B entirely.
    In all cases vehicles of Ride A still manages to depart from its station. And it still syncs properly when both rides are operating (opened or test mode).
Was this page helpful?
0 / 5 - 0 ratings