OpenBVE
OpenBVE copied to clipboard
New: BVE5 route parser plugin
This is the route parser from https://github.com/leezer3/OpenBVE/pull/154 separated into a plugin now that we support the plugin interface for loading routes too.
This will currently load routes converted with the BVETS Scenario Convertor nicely, but native BVE5 routes vary from poor to completely broken.
TODO:
- Optimise- See the object creation etc. of the CSV / RW route parser.
- Make visible in the main game menu.
- Fix curved repeater generation.
Some progress on curves:
This now generates curved objects for the repeaters and adds them to the route. Can definitely be optimised (this now just creates a cloned / transformed object for each block), but one step at a time; Let's get the maths right before doing more.
Curved secondary tracks are a little broken at the minute however- This is because a curve inside (or outside) the primary curve actually has a different radius, and at present all use the radius for the primary track.
That's better. For the moment, this has just performed a standard railtype transform on the newly generated curved object. No correction for the secondary track radii at the minute, which should be added as an alternative (although this pushes up the unique object count somewhat)
There's still a bunch of misplaced stuff on Keisei at the minute (level crossings are a good example) which needs investigating, and the visibility is wrong for some stuff, which again needs investigating.
Misplaced objects aren't present in the old branch https://github.com/leezer3/OpenBVE/pull/154
Must have made a typo somewhere.....
Misplaced objects was an easy fix, forgot to normalise a vector.
Keisei now looks largely correct, but this is incredibly simplistic. Large complex routes range from semi-OK to completely broken.
Not yet implemented at all from Keisei:
- Passing trains (can probably pull into a TFO)
- ~~Sound events (easy)~~
- Beacons (easy)
- Most height / curve interpolations.
- Inaccuracy. This will require the entire innacuracy framework re-building, as it allows to define the max sway at any given point. (Currently just converting the first parameter to the equivilant BVE4 variable and ignoring the rest totally)
- New-style gradient / interpolation. (Middling, can probably handle most in the parser)
- Signal speed limits
- Signals
Need work:
- ~~Fog breaks if a second fog is added.~~
- Variable length repeaters / blocks.
Future:
- Add some error messages and validation, not much of this at the minute.
- Test....
Working on trying to add some of the missing commands at the minute.
Another interesting change in BVE5-
A sound list file allows the developer to specifiy the maximum number of playing copies of a sound. I'm presuming that the quietest copy of said sound is ignored. Whilst in and of itself this is low priority to implement it might be interesting for announcements or something (on the basis that a modern train with per-car announcements etc. will likely only trigger n announcements at once), so will probably make its way into the main tree before too long....
Other thoughts: A lot of stuff wants converting into lists. Can almost certainly use the object key as a list key too, but I'm sure there was a reason I deliberately didn't do this when the thing was first done :/ (check handling of non-existant objects?)
Something broken in the sections somewhere- Not reverting to red when the train enters, but at least we can see some signal objects now.
Trivial to convert to a plugin: https://github.com/leezer3/OpenBVE/tree/BVE5_S520
There's an issue with object disposal not working quite right which I haven't got time to chase tonight, but that branch works and loads.
FWIW, after a quick bit of testing, this definitely seems less glitchy than mine. I'd prefer a full source solution, as opposed to the secondary DLL import doing most of the work, but we'll see :)
I haven't really looked at this branch lately, as the GL3 menu took up rather a lot of time. It's on my list to revisit, along with some stuff necessary for BVE5 train loading (you've seen the motor sounds WIP pull), but it keeps on coming back to needing to rework many of the framework pieces before we can actually implement things properly, as opposed to hackily.