Bve 5 scenario support

Hi, while I was showering this morning, I was remembering how OpenBVE started as an open source clone of BVE 1/2/4 and used the latter's routes but it wanted to be its own thing with its own format. You see, while I understand the idea, Bve 5 has come out and, where's the support for it? BVE support came about six years after the game was initially released, and it has been almost six years Bve 5 has released and no work has been made to support its scenarios.
I really hope that this is because the developers can't read Japanese. That I understand. But what I don't understand is that the community was all adventurous to make routes back in the golden days when there was very little official manual text in English and we wrote up our own manuals based on our experience and now we aren't. But if it's us vs them, and you guys are actively seeking distance from the new version, I'll be disappointed big time.
Bve 5 has an incredible scenario system. It no longer follows the Object - Route - Sound - Train standard, instead, it leaves the choice up to the developer, with files referencing files referencing lists referencing files in an extremely customizable way, you can even reference files outside the personal Bve 5 folder. (!!!) The track geometry no longer follows the incredibly clunky block system. You want to manage your tracks on each 10th meter? You can. You want to start a curve at, say, 1419.75 and the cant transition start at 888? Go ahead! Do you hate the current system of having to change railtypes just to get smoothly curved and cant'ed tracks? Create a super short track object and Bve 5 does the job for you.
Bve 5 is to track geometry and file management what BVE 4 was to safety systems and panels. It's incredible. You may not need to create a super complex XML based format for OpenBVE. The solution may be right under our noses and inside the name, with Bve 5's format. Embrace, Extend, Extinguish. But an XML format, causing format wars and losing a (shy but) loyal member of the community (me) is an option.

Glory! koshikii wrote:Hi, while I was showering this morning, I was remembering how OpenBVE started as an open source clone of BVE 1/2/4 and used the latter's routes but it wanted to be its own thing with its own format. You see, while I understand the idea, Bve 5 has come out and, where's the support for it? BVE support came about six years after the game was initially released, and it has been almost six years Bve 5 has released and no work has been made to support its scenarios.
I really hope that this is because the developers can't read Japanese. That I understand. But what I don't understand is that the community was all adventurous to make routes back in the golden days when there was very little official manual text in English and we wrote up our own manuals based on our experience and now we aren't. But if it's us vs them, and you guys are actively seeking distance from the new version, I'll be disappointed big time.
Bve 5 has an incredible scenario system. It no longer follows the Object - Route - Sound - Train standard, instead, it leaves the choice up to the developer, with files referencing files referencing lists referencing files in an extremely customizable way, you can even reference files outside the personal Bve 5 folder. (!!!) The track geometry no longer follows the incredibly clunky block system. You want to manage your tracks on each 10th meter? You can. You want to start a curve at, say, 1419.75 and the cant transition start at 888? Go ahead! Do you hate the current system of having to change railtypes just to get smoothly curved and cant'ed tracks? Create a super short track object and Bve 5 does the job for you.
Bve 5 is to track geometry and file management what BVE 4 was to safety systems and panels. It's incredible. You may not need to create a super complex XML based format for OpenBVE. The solution may be right under our noses and inside the name, with Bve 5's format. Embrace, Extend, Extinguish. But an XML format, causing format wars and losing a (shy but) loyal member of the community (me) is an option.

You'd be surprised at how much of that is already possible with openBVE

The Options.BlockLength value can be set in a routefile to any value you wish, and will allow you to do most of what you mention with curves.
The only thing that doesn't work quite as well is the cant transistion, as that's currently fixed at the block change. (Although you can just add curve statements with appropriately changing cant values...)

In order to take advantage of this, all you need to do is to create appropriately sized track pieces, and IIRC *everything* else just works.

Similarly, you can refer to any file you wish so long as you know it's relative path.
Once packages are fully stable, I'd like to be able to refer to a file within a package directly, which I think is very similar to what you're after.

BVE5's file format is interesting, but 'better' I'm not sure.
It's taking much the same direction I envisage (Separate stations, signals etc. into separate files), but it's still got a lot of flaws, and because it's plain text, it's not easily extensible.
Take this sample train XML file (Draft, but still...):

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE>
<Car>
<GUID>123456789</GUID>
<Description>XML Test Car</Description>
<Body>
<Object>Object.b3d</Object>
<Length>25</Length>
<Axles>-10,10</Axles>
<Weight>25</Weight>
</Body>
<FrontBogie>
<Axles>-2,2</Axles>
</FrontBogie>
<RearBogie>
<Axles>-2,2</Axles>
</RearBogie>
</Car>
</openBVE>

This is still essentially plain-text, and actually very much resembles the BVE5 equivalent, which uses a plain-text section/ key format to store the same data:
http://bvets.net/en/edit/

The primary difference here is that my preference is to use an existing, well-documented and extensible format, rather than creating another proprietary format. (Simply switching to reading BVE5 train files also creates problems as soon as I add a feature BVE5 doesn't have- We need a distinction between the 2 formats)

In short, I'm not seeking to create distance, but rather evolving along a rather similar path
No plans to try and get a parser working at the minute, but I'm not saying 'no' either....

Cheers

I've been aware of Options.BlockLength, and how OpenBVE changes the cant at the block preceding the curve, but it's just so much more convenient to indicate where to start the transition and where to start the curve and super-elevation. And have the rails modified by the program to fit the curve as well. Using a small BlockLength and a small rail object can cause some issues, like 25m long platform not aligning correctly to curved tracks or having to calculate by hand the distances when a track approaches or furthers from rail 0 more often than just a couple of times.
50, Track.Rail 1;3.8, 150, Track.Rail 1;11.4 creates an abrupt change at 125 ~ 150 with default blockLength. On Bve 5, it's a straight line between 3.8;50 and 11.4;150, but if you want to create a curve, you can add a relative radius to the rail you want to modify, thus making a curve outside rail 0. I ask for that convenience.

The problem with the current file system is that when loading structures, the main folder is the Railway\Object folder, or when loading trains, Train. Your object folder is crowded and your scenario's object folder is just one step away from the noise. On Bve 5, the reference point is the file itself, allowing for a much more package-like file organization and letting the developer organize the files how it best suits him/her, rather than our system, where the files are spread in a fixed manner.

The files itself, I think you're looking at it the wrong way. Plain text files can be easily augmented. Taking Mc's 701 series' Vehicle_F2-28(2B).txt as an example:

Code:

Bvets Vehicle 1.00
PerformanceCurve = ..\..\Notch\Notch_IGBT.txt
Parameters = ParametersF2-28_IGBT_1M1T.txt
Panel = Panel2_F2-28.cfg
Sound = Sound_F2-28_IGBT.cfg
Ats = ..\..\ATS\ats.dll
MotorNoise = ..\..\MotorNoise\IGBT\MotorNoise.txt

Notice that it has the version of the game and what type of file it is. We can add a simple version check and add to our version of the file, like what we've done to train.dat to be able to tell "This train is compatible with OpenBVE only." That is a very simple way to differentiate between Bve 5 stuff and OpenBVE stuff.

Code:

OpenBVE Vehicle 1.00
PerformanceCurve = ..\..\Notch\Notch_IGBT.txt
Parameters = ParametersF2-28_IGBT_1M1T.txt
Panel = Panel2_F2-28.cfg
Sound = Sound_F2-28_IGBT.cfg
Ats = ..\..\ATS\ats.dll
MotorNoise = ..\..\MotorNoise\IGBT\MotorNoise.txt
Exterior = ..\..\ExtView\701-1000.cfg
Cameras = Cameras_2_Car.txt

leezer3 wrote:The primary difference here is that my preference is to use an existing, well-documented and extensible format, rather than creating another proprietary format. (Simply switching to reading BVE5 train files also creates problems as soon as I add a feature BVE5 doesn't have- We need a distinction between the 2 formats)

Do you realize the XML format is proprietary relative to Bve 5? Again, you can simply add a version check and and add to it like we've done in the past.
And regarding the XML format, is OpenBVE going a TS20XX way rather than Bve's way? Bve has split up its files. Condensing motor sounds, extensions, ATS, into one single train.xml while claiming to promoting evolving to a path similar to Bve's is... SJW-ish at best.

I humbly ask you to try doing some extensive coding in Bve 5. Its scenario system is much more dynamic that the old, clunky, block-based BVE 1/2/4 one.

Whilst I haven't done extensive coding in BVE5, I'm well aware of how the files work
Whilst I completely agree that I'm 'proprietary' relative to BVE5, XML is a commonly used file format with a complete set of documented external standards.
This is actually really important-For example, BVE2/4 used the semi-colon as both the comment deliminator, and an argument separator. This caused all sorts of problems when openBVE came along and started interpreting comments in unintended ways
Same deal with character sets- They're handled natively with XML, but Mackoy's file formats require a plain-text identifier if you're using something unexpected.....


The path I'm intending to take (Although this very much depends on feedback to a certain extent) is IMHO the 'best' way of doing things.
Some thoughts on your example file:

Code:

OpenBVE Vehicle 1.00

Whilst this appears innocuous enough, plain text identifiers are nasty. In order to parse this, we'd need to read the string (Catering for case variations which inevitably come up), split at the appropriate place and finally parse the version number at the end into a double.
We then need to specifically parse each line and ignore what we don't understand. With XML on the other hand, we can just select what interests us with a simple XPath query

Code:

PerformanceCurve = ..\..\Notch\Notch_IGBT.txt

Haven't decided how the performance curves should be stored, but I agree that it should be in a separate file to the main train data.

Code:

Parameters = ParametersF2-28_IGBT_1M1T.txt
Panel = Panel2_F2-28.cfg
Sound = Sound_F2-28_IGBT.cfg
Ats = ..\..\ATS\ats.dll
MotorNoise = ..\..\MotorNoise\IGBT\MotorNoise.txt
Exterior = ..\..\ExtView\701-1000.cfg
Cameras = Cameras_2_Car.txt

These are the rest of the bits from the train configuration. Mackoy has chosen to retain the train as a 'whole' unit philosophy, and so each of these is relative to the complete train.

This is fine, but in my eyes, it's really not the best method of doing things.
A train is made up of individual cars, each of which has it's own individual set of properties. For example, adding a node to a car could be used to define an induvidual interior views for each car in the train. This is currently nowhere near possible with either openBVE or BVE5.

This means that the route should refer to a 'consist' file, which in turn refers to the individual car files.

leezer3 wrote:This is fine, but in my eyes, it's really not the best method of doing things.
A train is made up of individual cars, each of which has it's own individual set of properties. For example, adding a node to a car could be used to define an induvidual interior views for each car in the train. This is currently nowhere near possible with either openBVE or BVE5.

This means that the route should refer to a 'consist' file, which in turn refers to the individual car files.

I understand your point of view, considering steam locomotives, freight trans, and whatever else, but you've forgotten that for interiors we can use extensions.cfg, and use different models for each car. I agree that, for a freight train, we should take care of each car individually. Bve 5 was made primarily for passenger trains and EMUs, that's why there are no car specific stuff for it.

I just hope that Bve 5 support comes some time in the future. OpenBVE is just that, an open source clone of Bve. And I hope it stays like that.