-
Notifications
You must be signed in to change notification settings - Fork 52
Errata
This page describes fixed bugs, which may effect the functionality of existing routes and trains.
Description: A station name containing brackets would cause the station to be ignored.
Notes: This was added to fix several BVE 2 era routes.
Description: If collisions were set to enabled, and the initial position for a train (As set via Station.Stop) placed it in collision with a set of buffers (Placed via the Buffer command), this train would be stuck.
Notes: This has been fixed by checking for collision with buffers at the initial station, and moving the Station.Stop so that the train is 1m clear if this is detected.
Description: Setting a horizontal clip region of 15 pixels on a texture which was only 10 pixels wide caused the legacy BVE2 panel.cfg parser to crash. This has been changed to return the width of the texture (i.e. 10 pixels) and to generate an error message.
Description: Setting a time value with precision in the milliseconds would fail to parse, as the engine does not support times with a precision greater than 1 second. This has been changed to discard any precision greater than one second.
Description: openBVE uses a track follower to calculate when to introduce objects to the renderer. When in free camera mode, animated objects where being introduced incorrectly based solely upon the position of this track follower, as opposed to adding the appropriate offset for the free-camera position.
Notes: This changes the behavior of the free camera to be consistent with that of the other camera modes.
Rotation damping should not be applied when changing between external and the cabview, or on first load
Description: Animated objects and panel configuration files allow rotation to be 'damped'. This was incorrectly being applied when switching between the cab and an external view, and on the first frame of the simulation, and producing visual anomalies such as clock hands spinning into place upon start.
Description: Prior builds of BVE4 and openBVE have somewhat inconsistent behavior when holding down a horn key.
- When holding down a horn key in BVE2, BVE4 and prior versions of openBVE, the sound triggers repeatedly and overlaps.
- The original openBVE developer documentation states that the Primary and Secondary horns should play once, and the music horn should loop whilst the key is held down.
- Depending on the timing of when the music horn key was released, the sound would either stop or loop until the key was pressed again.
Changes in behaviour:
- Three-part sounds have been introduced for all horns (Start, loop and end) If either a start or end and a loop sound is defined, all horns will loop.
- Primary and secondary horns without three part sounds defined (legacy) will play once
- The music horn loop will start on the first keypress, and stop upon the second keypress.
Description: As it is not possible to build routes with negative track position values, it should be assumed that any fog starting at position zero should be that applied initially, rather than any interpolation being applied from position 0 onwards.
Changes in Behavior: Any fog set at an absolute position of 0 is now assumed to be present before the start of the route, rather than the interpolation effects starting at position 0.
Description: Using the default (no) plugin always overwrote any sound paths defined in the [ATS] section of the sound.cfg file with the default ats.wav etc.
Changes in Behavior: The default ATS sounds are loaded first, and then may be overwritten by sound.cfg entries.
Description: When a Wall or Dike was set to be present on both sides of the track (e.g. a Direction value of 0 ), this would be ignored if either of the Left or Right objects were not present. This behaviour is confusing and inconsistent with BVE.
Changes in Behavior: When an Wall or Dike is declared in this manner, a specific error message highlighting the missing Left / Right object will be generated. The other, present object will now be displayed.
In a small number of cases, this could potentially cause unexpected objects to appear in routes coded solely using openBVE as a reference. If this is the case, and the route author is no-longer contactable, please open a bug so that this can be special-cased.
Description: It was possible to call the .Rail and .RailEnd commands with a index of zero. As the position of Rail0 is used as a fixed reference for the game-word to be built around, neither of these should be possible to call.
Changes in Behavior: Using either of these commands with an index of zero will now produce an error message. If you have been using the .Rail command to change the RailType for Rail0, this should be changed to the .RailType command.
Description: openBVE previously rejected L and R as invalid directions for Walls and Dikes. These commands were valid in BVE1 & BVE2 only, and BVE4 ignored any command using them. As openBVE maps an invalid wall / dike direction to 0 (e.g. both sides of the track), this led to the objects appearing on both sides of the track.
Changes in Behaviour: L and R are now accepted as (undocumented) available directions. On affected routes, walls should now appear on the correct sides, as opposed to on both sides of the track.
Description: It was previously possible to do the following:
2000, .freeobj
This placed FreeObject 0 on Rail 0 at track position 2000. Similarly, the following also worked:
2000, .freeobj 1
This placed Freeobject 0 on the rail specified by the first argument at track position 2000.
Changes in Behaviour: FreeObjects must be placed with both the desired Rail and the ObjectIndex you wish to place declared. This matches the behaviour of BVE2 / BVE4, and is considerably more logical.