Openrct2: [Bug or improvement?] Block brakes have a different behaviour from RCT2.

[Wirlie]

OS: Windows 10
Version: 0.0.5
Commit/Build: Latest build (6c702fb1a96e2c64a1c749c1cf9054b6ba31afbd)

I've noticed that block brakes have a different behaviour from RCT2, it only affect the block-sectioned mode.

(Introduced by #4017)

• [ ] Reproducible in RCT2 (vanilla)? (N/A)
• [ ] Multiplayer? (N/A)

Screenshots / Video:
OpenRCT2 0.0.4 (stable version): https://vid.me/N6dn
OpenRCT2 0.0.5 (latest build): https://vid.me/Zirv

Note: If this isn't a bug, I think that this should be added to the changelog.

[Generalcamo]

What difference do you mean? I notice no difference at all on latest build from Git.

[Wirlie]

Sorry, I haven't explained the problem in a best way.

If you see the second video that I've attached (OpenRCT2 0.0.5, beetwen -0:48 and -0:43) you can see that the car isn't slowed by the block brakes (it only happen if the brake is opened, otherwise this works fine and the car is stopped), and this doesn't happen on RCT2.

In the first video (OpenRCT2 0.0.4) you can see the correct "behaviour" of the block brakes, I mean that the car is slowed when passing through the block brakes.

Additionally, In the videos, I've included the functionality of the continuos circuit mode, if you compare these two videos then you can see that this not have any difference, this problem only affect the block-sectioned mode (Continuous circuit block sectioned mode).

I hope that you can understand my explanation xP (I'm not very good with English).

[Generalcamo]

I do believe this was intentional, to fix a major issue that a lot of people had with RCT2's (unrealistic) block brake system. If you want to slow down your train, use a brake in addition to the block brake, which will have the same effect as the old system.

[Wirlie]

The major issue that you've mentioned was fixed by #4012 (I think). (okay, I think that I was wrong, it is another issue)
This "problem" was introduced by #4017.

And yes, I can use a brake in addition to the block brake, but, I just want to know if this was intentional or something not expected (not sure if that was caused by a mistake during the refactorization).

Probably @gDanix can solve my doubt.

[duncanspumpkin]

No that's a bug

[gDanix]

In fact, I introduced this behaviour because I understood that, in a block-sectioned ride, when the block brakes are not blocking train (are opened), they don't have to brake at all.

I tested the old behaviour in my refactorized code, but it turned out that, in most roller coasters, the trains weren't able to reach hills after running through a block brake, probably because the brakes were actuating over the whole train, rather than the first car, but this needs to be tested.

[duncanspumpkin]

@gdanix we can't modify behaviour it breaks a lot of hacks that ne uses. I didn't realise that had been changed in the pr

[Generalcamo]

@gDanix This behavior is useful. IntelOrca suggests moving the new behavior to #ifdef NEW_BLOCK_BRAKES for use later. For now, the vanilla RCT2 behavior should be implemented by default however to avoid breaking existing parks and rides.

[gDanix]

Update on this:

• The fix to get back to the old block brake implementation is, AFAIK, as simple as replacing is_block_brake_close (which will always be equal to false) to true here.
• The real bug is here. This check is incomplete and reverting block brakes behaviour will make this bug more evident.

I'm currently fixing this two things