Limitations of other line implementation methods of OPENBVE and proposals for new methods
3 posters
Page 1 of 1
Limitations of other line implementation methods of OPENBVE and proposals for new methods
This document explains the limitations of BVE's other line implementation method.
BVE supports relative coordinate systems. That is, the coordinates of the main line as the origin (0,0), and the X,Y position of the other line is defined at each KM station.
Existing Syntax Examples
Main line "gtx-b"
Other Line "Jongno Line"
,;"Jongno Line 1"
42250,.Rail 15;-39.866;56.29;0
42275,.Rail 15;-39.606;55.69;
42300,.Rail 15;-39.347;55.105;
42325,. Rail 15;-39.087;54.565;
42350,.Rail 15;-38.828;54.069;
42375,.Rail 15;-38.568;53.618;
42400,.Rail 15;-38.309;53.211;
42425,.Rail 15;-37.651;52.849;
42450,.Rail 15;-36.209;52.532;
42475,.Rail 15;-33.979;52.259;
42500,.Rail 15;-30.955;52.031;
42525,.Rail 15;-27.128;51.848;
42550,.Rail 15;-22.485;51.709;
42575,.Rail 15;-17.199;51.615;
42600,.Rail 15;-11.867;51.565;
42625,.Rail 15;-6.632;51.551;
42650,.Rail 15;-1.879;51.325;
42675,.Rail 15;2.328;50.769;
42700,.Rail 15;5.994;49.988;
42725,.Rail 15;9.125;49.206;
42750,.Rail 15;11.725;48.427;
As above, it is implemented as X,Y values at the current km station.
The problem with this method is that the track is not the actual location, and when the route is changed to another track, the coordinates at the corresponding km station are different.
In the example above, if the location of "Jongno Line" at 42km250 of "GTX-B" is x=-39.866,y=56.29
After changing the "Jongno Line" to the main operating line, it will be in a different location.
This section corresponds to 0km007.98 of the "Jongno Line" and cannot be expressed because it is out of the 25m block unit range of bve.
The station of the "GTX-B" line at the 0km point of the "Jongno Line" is 42km241.6 and the distance corresponds to x=-39.948.
As above, when the main line is "GTX-B" and "Jongno Line", the coordinates are different, and you can see that this is an unrealistic and cumbersome method.
Therefore, it is suggested to change the implementation method of the bve coordinate system to the absolute coordinate system.
If the example coordinates are expressed in the absolute coordinate system (example origin is "GTX-B" 39km370 X=0,Y=0)
The coordinates of "GTX-B" 42km250 are x=1101.6685,y-2451.9398
The coordinates of "Jongno Line" 0km007.98 are x=1076.481,y=2455.891
Since this coordinate is an absolute coordinate, it is a fixed value and points to the same position on any line.
Therefore, if you change the existing ".rail" syntax,
example phrase
.rail [index or name];order number;x-coordinate;y-coordinate;z-coordinate;object index
It can be expressed like this
The reason for determining the sequence number here is to set the direction of the line.
If you don't specify a sequence number, you won't know where it's going.
By specifying the sequence number, you can tell whether it is going down or going up.
If we write the sentence again
rail ["Jongno Line"];0;1076.481;2455.891;156;0;
You can override the "25m block unit limit" and this limit will no longer make sense.
Using the proposed method, you can change the driving route at any time (eg, once you have implemented the “GTX-B” and “Jongno Line”, you can select the driving route while taking turns at any time)
You no longer need to implement the same station track layout over and over again.
In the past, if you wanted to change the branch position once determined in a complex section like Seoul Station, you had to re-create all Track Layout in Stations based on the main line. (Example: If you want to depart from Seoul Station Line 5 on Line 11)
In the proposed method, since the track coordinates are fixed values, there is no need to change them, just change the desired route.
In addition
The curve and slope of the track are automatically calculated as each coordinate is moved, and there is no need to manually set the curve radius and slope.
It is a method that has never been done before, so if it can be realized, it will be a revolution in BVE.
BVE supports relative coordinate systems. That is, the coordinates of the main line as the origin (0,0), and the X,Y position of the other line is defined at each KM station.
Existing Syntax Examples
Main line "gtx-b"
Other Line "Jongno Line"
,;"Jongno Line 1"
42250,.Rail 15;-39.866;56.29;0
42275,.Rail 15;-39.606;55.69;
42300,.Rail 15;-39.347;55.105;
42325,. Rail 15;-39.087;54.565;
42350,.Rail 15;-38.828;54.069;
42375,.Rail 15;-38.568;53.618;
42400,.Rail 15;-38.309;53.211;
42425,.Rail 15;-37.651;52.849;
42450,.Rail 15;-36.209;52.532;
42475,.Rail 15;-33.979;52.259;
42500,.Rail 15;-30.955;52.031;
42525,.Rail 15;-27.128;51.848;
42550,.Rail 15;-22.485;51.709;
42575,.Rail 15;-17.199;51.615;
42600,.Rail 15;-11.867;51.565;
42625,.Rail 15;-6.632;51.551;
42650,.Rail 15;-1.879;51.325;
42675,.Rail 15;2.328;50.769;
42700,.Rail 15;5.994;49.988;
42725,.Rail 15;9.125;49.206;
42750,.Rail 15;11.725;48.427;
As above, it is implemented as X,Y values at the current km station.
The problem with this method is that the track is not the actual location, and when the route is changed to another track, the coordinates at the corresponding km station are different.
In the example above, if the location of "Jongno Line" at 42km250 of "GTX-B" is x=-39.866,y=56.29
After changing the "Jongno Line" to the main operating line, it will be in a different location.
This section corresponds to 0km007.98 of the "Jongno Line" and cannot be expressed because it is out of the 25m block unit range of bve.
The station of the "GTX-B" line at the 0km point of the "Jongno Line" is 42km241.6 and the distance corresponds to x=-39.948.
As above, when the main line is "GTX-B" and "Jongno Line", the coordinates are different, and you can see that this is an unrealistic and cumbersome method.
Therefore, it is suggested to change the implementation method of the bve coordinate system to the absolute coordinate system.
If the example coordinates are expressed in the absolute coordinate system (example origin is "GTX-B" 39km370 X=0,Y=0)
The coordinates of "GTX-B" 42km250 are x=1101.6685,y-2451.9398
The coordinates of "Jongno Line" 0km007.98 are x=1076.481,y=2455.891
Since this coordinate is an absolute coordinate, it is a fixed value and points to the same position on any line.
Therefore, if you change the existing ".rail" syntax,
example phrase
.rail [index or name];order number;x-coordinate;y-coordinate;z-coordinate;object index
It can be expressed like this
The reason for determining the sequence number here is to set the direction of the line.
If you don't specify a sequence number, you won't know where it's going.
By specifying the sequence number, you can tell whether it is going down or going up.
If we write the sentence again
rail ["Jongno Line"];0;1076.481;2455.891;156;0;
You can override the "25m block unit limit" and this limit will no longer make sense.
Using the proposed method, you can change the driving route at any time (eg, once you have implemented the “GTX-B” and “Jongno Line”, you can select the driving route while taking turns at any time)
You no longer need to implement the same station track layout over and over again.
In the past, if you wanted to change the branch position once determined in a complex section like Seoul Station, you had to re-create all Track Layout in Stations based on the main line. (Example: If you want to depart from Seoul Station Line 5 on Line 11)
In the proposed method, since the track coordinates are fixed values, there is no need to change them, just change the desired route.
In addition
The curve and slope of the track are automatically calculated as each coordinate is moved, and there is no need to manually set the curve radius and slope.
It is a method that has never been done before, so if it can be realized, it will be a revolution in BVE.
navya01- Posts : 10
Join date : 2022-05-01
Rakago likes this post
Re: Limitations of other line implementation methods of OPENBVE and proposals for new methods
I might be overlooking something, but from my limited knowledge and understanding that would be a total respecification of the route format, absolutely incompatible to BVE of any version. Therefore I highly doubt this would be realised, especially since, to my understanding, Chris is working on an independent route format which would be free of the limitations of the whole BVE system.
Quork- Posts : 1438
Join date : 2012-05-05
Age : 33
Location : Hofheim a.T., Hessen (Hesse), European Union
Re: Limitations of other line implementation methods of OPENBVE and proposals for new methods
Working on a 'new' format is somewhat grand
Basically, I'm implementing any major new features / reworks in XML (slowly....)
Simply put, the existing formats are a mess, and are far too reliant on magic numbers etc.
Much of the existing code was for that matter written to directly emulate BVE2, as opposed to being general purpose, which makes the job harder.
I made the XML choice years ago, as it was the dominant format, and provided a clean break when implementing major stuff, as opposed to trying to shoehorn it into something existing.
It also has the massive advantage of being an existing fixed specification.
Your proposals are (essentially) a tile based system.
This is the general direction things need to take, but your basic design is naieve and will cause no end of troubles; Doing this in an actually functional manner would likely require ~1km square tiles.
Essentially, at the end of the day, grand proposals are all well and good.
Please come back when you've got a working code example
Basically, I'm implementing any major new features / reworks in XML (slowly....)
Simply put, the existing formats are a mess, and are far too reliant on magic numbers etc.
Much of the existing code was for that matter written to directly emulate BVE2, as opposed to being general purpose, which makes the job harder.
I made the XML choice years ago, as it was the dominant format, and provided a clean break when implementing major stuff, as opposed to trying to shoehorn it into something existing.
It also has the massive advantage of being an existing fixed specification.
Your proposals are (essentially) a tile based system.
This is the general direction things need to take, but your basic design is naieve and will cause no end of troubles; Doing this in an actually functional manner would likely require ~1km square tiles.
Essentially, at the end of the day, grand proposals are all well and good.
Please come back when you've got a working code example
Gothpaladinus likes this post
Re: Limitations of other line implementation methods of OPENBVE and proposals for new methods
Not saying that this is necessarily the way to go, just as a peek to other places: The LokSim3D formats are XML based (with some "historically grown" quirks). There objects are relative to tracks, which isn't unlike BVE, but there is no main "track 0", all tracks are equal and objects can be defined relative to any track, meaning you can freely use all tracks the same way and go in all directions. The downside is big loops don't work, because the program doesn't recognise the fact that some objects are actually pretty close when a track intersects itself after some longer distance; though I guess this could be caught via some pre-calculations.
The interesting question for me is - how do savegame formats of e.g. Transport Fever 2 work? Maybe there's some chance of using some of those approaches?
The interesting question for me is - how do savegame formats of e.g. Transport Fever 2 work? Maybe there's some chance of using some of those approaches?
Quork- Posts : 1438
Join date : 2012-05-05
Age : 33
Location : Hofheim a.T., Hessen (Hesse), European Union
Rakago likes this post
Similar topics
» OpenBVE Metropolitan Line
» Jubilee Line for OpenBve
» OpenBVE Jubilee line?
» Victoria LIne v4 for Openbve
» OpenBVE Metropolitan Line (For Real)
» Jubilee Line for OpenBve
» OpenBVE Jubilee line?
» Victoria LIne v4 for Openbve
» OpenBVE Metropolitan Line (For Real)
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum