new OST implementation for road viaducts#529
Merged
Merged
Conversation
In particular stub-based, T-based or any other form of disconnected OST overrides. Some RUL2 code for alt viaducts and viaduct FTLs is kept unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This replaces the existing FLEX OST piece for the viaducts by a new implementation similar to the RHW implementation, allowing networks to be fully dragged through the onslope transition.
For this purpose, each network (Road, OWR, Avenue) gets its own OST piece (L1 and L2). The previous FLEX piece is deactivated. The RUL2 code is replaced by metarules. The alt-viaducts are left unchanged.
Things that don't work anymore (or only on one side of the OST piece):
The workaround is to use a 1-tile gap or alternatively, in case of the Avenue FTL starter, place it on the other side of the OST.
Conversely, many tight adjacency situations that didn't work before, or weren't stable, are functional now, so I think it's an acceptable compromise (until a DLL-fix for the slope tolerance is found). For example, this works now:
