You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A relatively common feature of prototype power / brake handles is a spring feature.
This gradually returns the handle to a 'default' position after a set period of time.
This PR implements this, along with some missing XML plumbing for setting the number of power / brake notches.
Significant Changes:
Allows the driver car to be set via the train.xml
Allows the number of brake notches to be set via XML using the Train --> Car --> Brake --> Handle --> NotchesNOTE: The number of brake notches is only set via the driver car (values set on other cars will be ignored)
A brake handle spring delay in seconds may be set in XML via Train --> Car --> Brake --> Handle --> SpringTime - Each time the timer elapses, the brake will be increased by one notch. Interacting with the handle resets the timer.
The maximum notch a sprung brake handle returns to may be set in XML via Train --> Car --> Brake --> Handle --> MaxSprungNotch
Spring type may be set via XML Train --> Car --> Brake --> Handle --> SpringType with available values as follows:
Unsprung - No spring return
Single - Spring return timer is only reset when this handle is operated
AnyHandle - Spring return timer is reset when any power / brake / reverser handle is operated
AnyKey - Spring return timer is reset when any key is pressed. (think about whether to limit this to security keys etc, or whether it should be global??)
TODO:
Sprung reverser handles???
Future Design Issues to Consider:
Really, we ought to have a per-car handle. If in the future, decoupling or changing the physical driving cab is implemented, this would allow the 'new' driving cab to have correct handle types etc.
This could possibly be done relatively easily via changing the current handle location to be a reference to the actual handle within the current driver car.
However, this could equally create a total and utter mess with existing content, and anything not specifically designed for this.
Possibly could do something like aliasing DriverCar to the inital driver car, and using CurrentDriverCar as the reccomended variable going forward, but that's just got a different set of messes to contend with.
Still a WIP, and not added to the documentation yet.
Loosely related to #684 as MSTS allows this handle type.
Largely complete other than implementing the AnyKey reset method.
NOTE:
This makes a small change to the XML format-
The Acceleration node containing the acceleration curves is now moved to be a child node of a new Power node, so that we can control the power handle notches / spring identically to the brake handle.
The original position for the acceleration node is still supported, but once this is merged, the preferred location should be updated in the documentation.
I don't believe many (if any) released trains use this format yet, and it's not complete, so possibly consider dropping this, but it made it into a release build :/
Documented, and probably reasonably ready to merge....
Sit back and think for a little bit first though in case something has been broken I've not noticed.
Edit:
Probably want to put out 1.8.3 first (ought to do shortly, especially with new language done), and then think about merging this, that we we don't immediately stuff a new feature into stable.
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
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.
A relatively common feature of prototype power / brake handles is a spring feature.
This gradually returns the handle to a 'default' position after a set period of time.
This PR implements this, along with some missing XML plumbing for setting the number of power / brake notches.
Significant Changes:
TODO:
Future Design Issues to Consider:
Really, we ought to have a per-car handle. If in the future, decoupling or changing the physical driving cab is implemented, this would allow the 'new' driving cab to have correct handle types etc.
This could possibly be done relatively easily via changing the current handle location to be a reference to the actual handle within the current driver car.
However, this could equally create a total and utter mess with existing content, and anything not specifically designed for this.
Possibly could do something like aliasing DriverCar to the inital driver car, and using CurrentDriverCar as the reccomended variable going forward, but that's just got a different set of messes to contend with.
Still a WIP, and not added to the documentation yet.
Loosely related to #684 as MSTS allows this handle type.