Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New: Implement sprung handle types #755

Merged
merged 6 commits into from
Mar 23, 2022
Merged

New: Implement sprung handle types #755

merged 6 commits into from
Mar 23, 2022

Conversation

leezer3
Copy link
Owner

@leezer3 leezer3 commented Mar 16, 2022

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 --> Notches NOTE: 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:
    1. Unsprung - No spring return
    2. Single - Spring return timer is only reset when this handle is operated
    3. AnyHandle - Spring return timer is reset when any power / brake / reverser handle is operated
    4. 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.

@leezer3 leezer3 added this to the 1.9.0 milestone Mar 17, 2022
@leezer3 leezer3 added the trains label Mar 17, 2022
@leezer3
Copy link
Owner Author

leezer3 commented Mar 18, 2022

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 :/

leezer3 added a commit to leezer3/OpenBVE-Documentation-Hugo that referenced this pull request Mar 19, 2022
@leezer3
Copy link
Owner Author

leezer3 commented Mar 19, 2022

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.

@leezer3 leezer3 merged commit ec70fbe into master Mar 23, 2022
@leezer3 leezer3 deleted the SprungHandle branch March 23, 2022 23:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant