BVE WorldWide
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Limitations of other line implementation methods of OPENBVE and proposals for new methods

3 posters

Go down

Limitations of other line implementation methods of OPENBVE and proposals for new methods Empty Limitations of other line implementation methods of OPENBVE and proposals for new methods

Post by navya01 Mon Aug 15, 2022 11:10 am

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.

navya01

Posts : 10
Join date : 2022-05-01

Rakago likes this post

Back to top Go down

Limitations of other line implementation methods of OPENBVE and proposals for new methods Empty Re: Limitations of other line implementation methods of OPENBVE and proposals for new methods

Post by Quork Tue Aug 16, 2022 8:59 am

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
Quork

Posts : 1438
Join date : 2012-05-05
Age : 32
Location : Hofheim a.T., Hessen (Hesse), European Union

Back to top Go down

Limitations of other line implementation methods of OPENBVE and proposals for new methods Empty Re: Limitations of other line implementation methods of OPENBVE and proposals for new methods

Post by leezer3 Tue Aug 16, 2022 11:11 pm

Working on a 'new' format is somewhat grand Razz

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 Wink

leezer3

Posts : 1960
Join date : 2011-08-23

http://www.bvecornwall.co.uk

Gothpaladinus likes this post

Back to top Go down

Limitations of other line implementation methods of OPENBVE and proposals for new methods Empty Re: Limitations of other line implementation methods of OPENBVE and proposals for new methods

Post by Quork Wed Aug 17, 2022 1:54 pm

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?
Quork
Quork

Posts : 1438
Join date : 2012-05-05
Age : 32
Location : Hofheim a.T., Hessen (Hesse), European Union

Rakago likes this post

Back to top Go down

Limitations of other line implementation methods of OPENBVE and proposals for new methods Empty Re: Limitations of other line implementation methods of OPENBVE and proposals for new methods

Post by Sponsored content


Sponsored content


Back to top Go down

Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum