-
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.
Description: With the old (openGL 1.2) renderer, a polygon with both a daytime and a nighttime texture defined was rendered without ambient lighting- e.g.
[MeshBuilder]
Vertex -1,0,0
Vertex -1,1,0
Vertex 1,1,0
Vertex 1,0,0
Face 0,1,1,2
[Texture]
Load texture.png, texture.png
Coordinates 0,0,0
Coordinates 1,1,0
Coordinates 2,1,1
Coordinates 3,0,1
With the new renderer active, ambient lighting will be applied.
NOTE: If BVETSHacks are active, this behaviour will be preserved. If you wish to produce approximately the same effect, please set the material to emit pure white, e.g:
[MeshBuilder]
Vertex -1,0,0
Vertex -1,1,0
Vertex 1,1,0
Vertex 1,0,0
Face 0,1,1,2
EmissiveColor 255,255,255
[Texture]
Load texture.png
Coordinates 0,0,0
Coordinates 1,1,0
Coordinates 2,1,1
Coordinates 3,0,1
A third-party tool is also available to batch apply this 'fix' to all existing objects: https://www.zbx1425.cn/nautilus/daynightfix.html
See also the commments in the following issue: https://github.com/leezer3/OpenBVE/issues/480#issuecomment-626623040
OpenBVE prior to 1.8.2.3 did not implement the ElectricBrake delay variables. Unfortunately, the corresponding variable positions in train.dat were subsequently used to implement the delay for the LocoBrake feature.
Care should therefore be taken when manually editing the train.dat file, which now functions as follows, dependant on the version string:
- BVE1220 and BVE2000 versions - Parameters 5 and 6 in the #DELAY section control the ElectricBrake delay settings.
- OPENBVE17250 and below versions - Parameters 5 and 6 in the #DELAY section control the LocoBrake delay settings.
- OPENBVE18230 and above versions - Parameters 5 and 6 in the #DELAY section control the ElectricBrake delay settings. Parameters 7 and 8 in the #DELAY section control the LocoBrake delay settings.
Previously, a stop set to AllCars would override a stop containing the specific number of cars in a train. If no matching stop was found, the first stop with a greater number of cars was used, no matter if there was a better (closer) candidate further on.
Changes in behaviour:
- If the number of cars is found, this should now be used wherever the stop point is located.
- If the number of cars is not found:
- When an all-car stop is present, this will be used unconditionally, wherever it is located.
- If an all-car stop is not present, the stop list will be searched to find the closest number of cars above that of the player train. This stop point will be used,
Notes: In a small number of cases, this could possibly cause developer placed stop point hint objects (signs, marks on the track etc.) to be inconsistant with the on-screen stop point overlay. The on-screen overlay should be used in this case.
Previously, when the flange or run sounds changed, the original sound was stopped. When the sound was next called, playback restarted from the beginning. With longer sound samples, this may produce unwanted behaviour.
Changes in behaviour: The loop for run and flange sounds is now paused when the sound changes. When the sound restarts, it does so from the previous playback position.
Notes: This now matches the behaviour of BVE4 / BVE5.