Block Brakes

[Version1]

So, here come some questions/ideas from a block brake enthusiast.

First of all, in this issue on Github it is mentioned that block brakes used to not brake the train for a while. What happened to that? I think it was a move in the right direction to make them more viable in game again.

Also, I saw that there is an option now to override the block brakes manually using the tile inspector. Would it be technically viable to allow us to use the tile inspector to put a block on any piece of track? Right now we only have block brakes (which brake the train way too much) and the endpiece of lifts (which does allow us some ways to trick the system) but being able to declare any piece a block would be a nice addition for realistic coaster building (especially multiple launch coasters)

[X7123M3-256]

9 hours ago, Version1 said:

What happened to that? I think it was a move in the right direction to make them more viable in game again.

 

From reading that thread it looks like it was reverted because it's different to vanilla behaviour and therefore might break existing saves. There is a pending PR that implements similar functionality, but it's been there for more than a year and does not look like it's going to be merged anytime soon.

[Ruedii]

On the note of block breaks, and breaks in general, being able to have them on sloped pieces would be really nice, permitting them on any piece with a cheat would also be great.

[NightHawk]

*cue the "requires new save format" comments*

[X7123M3-256]

On 06/12/2019 at 05:59, Ruedii said:

permitting them on any piece with a cheat would also be great.

This can't really be done.

[Ruedii]

12 hours ago, X7123M3-256 said:

This can't really be done.

Yeah, I just thought that might be an issue because of missing image files.

I suspect the appropriate image file segments could be warped to handle sloped pieces for breaks and block breaks, but that won't work for curves. We could also use original image overlays if we wanted to.

Added physics functions would be needed.  This isn't a big deal.

As of save format, I'd have to check if there are still unused designation codes for track pieces types.

Still it clearly is more work than it sounds. 

As of the issue of block breaks always slowing the train to a near stop, we could in theory treat them as regular breaks for this function (having a speed) and set a default identical to what the original RCT series uses if the value it puts there is found.  I'd have to inspect the save file format to see if the appropriate field is free for that tile, but I suspect it is.   This would cause minor problems porting the file back to the original RCT series and RCT Classic, but nothing a little informative note won't address, as if standard programming technique is used, the field is simply ignored and treated as default.

Edited December 8, 2019 by Ruedii
Info on the other issues of block breaks.

[X7123M3-256]

21 hours ago, Ruedii said:

Yeah, I just thought that might be an issue because of missing image files.

I wasn't talking about the images. Unlike lift hills, brakes are considered distinct track pieces, so if you wanted to allow brakes on every track piece you'd have to create a braked version of every track piece. That can't be done until we have a new save format (although if we did have a new save format, we could make it so that brakes are handled the same way as lift hills rather than creating two versions of every single track piece).

21 hours ago, Ruedii said:

As of save format, I'd have to check if there are still unused designation codes for track pieces types.

I already checked, there aren't. We have a few slots for new track types, but none for new elements.

 

21 hours ago, Ruedii said:

As of the issue of block breaks always slowing the train to a near stop, we could in theory treat them as regular breaks for this function (having a speed) and set a default identical to what the original RCT series uses if the value it puts there is found.  I'd have to inspect the save file format to see if the appropriate field is free for that tile, but I suspect it is. 

This is possible and has already been implemented, but the PR was never merged.

Edited December 8, 2019 by X7123M3-256

[Ruedii]

13 hours ago, X7123M3-256 said:

This is possible and has already been implemented, but the PR was never merged.

Yeah, while it is likely possible on the current save format (the variable slot in question is probably free) it involves adding more code to make it import original RTC2 saves properly.  It also would be subject to the same limitations as the current brakes.

Moving to the new save format would fix both of these issues, and also require changes in  the code for other things.  It might be better to wait considering the low priority of the issue.

[X7123M3-256]

11 hours ago, Ruedii said:

Yeah, while it is likely possible on the current save format

It's definitely possible because it has already been done. I don't know why the devs rejected it, I think it's a nice feature.

[NightHawk]

+1

Edited December 15, 2019 by NightHawk

[Ruedii]

On 09/12/2019 at 18:10, X7123M3-256 said:

It's definitely possible because it has already been done. I don't know why the devs rejected it, I think it's a nice feature.

The current problem is that the code provided interfered with the multiplayer code, and needs to be adjusted to address that issue.

The feature wasn't rejected, it was put in triage because it is not as simple as it sounds and the volunteer who wrote a patch hasn't written an acceptable patch.  

If you want to build a version with this feature, and forgo multiplayer, you can.   The code IS available on github.

As of people wanting to fix this patch.
It needs the following:
1. It needs to apply multiplayer code from the brakes to the block brakes in order to fix any syncing issues.
2. Debugging is needed to insure it isn't exposing any previously unknown desync bugs in the braking code.
3. Because the code executes on a block brake (a severely desync prone part), strong desync protection may need to be added.

While others may debate this position, my caution against desync bugs over performance states that strong desync protection should be added to all brakes considering it is a key point in a roller coaster that can cause minor desync bugs.  They are often put in roller coasters to make sure the roller coasters behave the same between runs.  They are literally desync protection for roller coasters.  Having your desync protection desync is bad on every level.

Edited December 27, 2019 by Ruedii
More Info.