[Genma Saotome]

Making a list for future reference... we were talking about the need -- or lack thereof -- for an Open Rails equivalent to Kuju's .w file. I figure it's time to ask the community.... So... is there anything the OR team needs to change about KUJU's \world\*.w files that will allow more/better/different features? I mean the data, not what an editor lets you do -- that's a different problem.

See, when you look at a .w file it seems pretty robust... it records the location of everything and so at first glance it seems good enough. But is it really? That's what I'd like to find out.

This is just brainstorming ideas so I'm open to hearing just about anything... stuff like have them cover one square km each instead of four, put each object's data on one line, break 'em up into many files with one file per entry type (e.g., one file for track another for roads, etc.), to use JSON format instead of SIMIS... or anything else.

IOW, is there anything you can think of that cannot be done using KUJU's specification for that file? If you could change anything about what they already do, what would that be?


For myself, I'm concerned there isn't enough data being recorded in the world files to indicate this track is linked to that interactive (the other way around had the data but there's nothing in the track entry). I could support this track is linked to that track (and vise versa).

I'd like to see shapes that have night textures get a line to specify when the "lights" go on and off.

And I think if roads could have the equivalent of turnouts (at ordinary street intersections) I suspect more data would be needed in their .w file entries.

[DRelyea]

Hi,

The need for 1km tiles would depend on if there will (or has) to be an object tile limit in ORTS as there was in MSTS. Without diving into all the interactions, the ability to split the "Atomic" MSTS tile into 4 quarks (Nyuk, Nyuk, Nyuk) would be very useful for high density areas. I expect the majority of these high density areas would end up in Urban settings, where the 'long' view would be blocked by taller buildings (4 story and more) so this might not impact on the tile loading scheme.

I agree with the data recording for the interactives. MSTS has to chase the information across 3 files. As well as us trying to fix a problem. If it's a grade crossing, that's even worse, as it now reaches the RDB and RIT.

Putting modified SD data into the world file makes sense, in that the stock "SD" file could have one set of values, while an entry in the W file for the same shape would override for that instance the stock SD file. That could be accessed the same way MSTS does, with a right click context menu. Same building in different locations could have its lights go on and off differently and maybe cycle again when the start up crew arrives at 0430.

Ability to modify the stop distance or stop place on roads at Grade crossings for the angled crossings would be very useful, without having to place more tracks outside the working one(s)

Ability to modify easily how many tracks a single "base" controls. MSTS will only max 4. I think the trick someone else came up with will reach 10 tracks.

Doug Relyea

[Jeffrey Kraus-Yao]

Erased.

[strawberryfield]

I have already told my idea: remove all tracks and roads data from the .w files and recreate the shapes "on the fly" using the .tdb data and profiles (also stored in the .tdb)

This way we can have easily multiple tracks types, diffrent gauges, textures... in the same route without troubles.

Another advantage is that without having data sparse in various tables we don't need the data relashonship integrity.

[roeter]

Quote

For myself, I'm concerned there isn't enough data being recorded in the world files to indicate this track is linked to that interactive (the other way around had the data but there's nothing in the track entry). I could support this track is linked to that track (and vise versa).

There are lots of links I can imagine between signals, tracks, interactives, level crossings etc. - but I do not think the .w file is the proper place to put these.
For one thing, these links are obviously not restricted to the area covered by a .w file. So to recover the info, one would have to read all .w files, shift through all information to extract what is required and try to get the proper links.
It's all a lot more easy if all such information would be stored in separate file(s).
In fact, there is some information I would like to take out of a .w file. At present, info for signals and level crossings is split between the .tdb and the .w files. That is troublesome, needs a lot of extra work to collect all info and can lead to serious problems (e.g. the problems with spurious .w files). I would very much prefer to have all that info in a single location.

As for storing link information with both interactive and the track : don't do that. Storing link information with both items always carries the risk of data becoming inconsistent. The only way to keep two-way link data consistent is simply to store it only once.

Regards,
Rob Roeterdink

[Genma Saotome]

Rob, those are some interesting comments you've made!

If I understand you then what you are saying is let the new .w file describe only those things that have one origin point that have been placed within one specified area (e.g., a tile) and create other new files that describe features that could (or do) span multiple .w files and have a start and end point. Is that correct?

That sounds like the .w file hold only static objects and all the stuff that has start and end points (and the things that tie into them) one or more newly designed files. That would be better for the OR code?



Roberto, I agree with your goal.

[Lindsayts]

I have touched on this in another thread but if possible sort the objects in the W file into size ranges so that when its loaded into memory its simple for OR to work out the objects it needs to display at what ever distance, example a tile loaded at say 10 kilometre viewing distance only needs to display large objects (like Forth bridge size). This will signifacntly reduce OR's memory use and probably also its work load allowing it to better display almost any modern route.

If one sets the experimental option"object viewing distance set to Max" (or something like that) (Note 1) on high object density routes it really pushes up the memory usage. The above is some thoughts to improve the situation.

Note 1: This option is a real life saver on routes with a low object count such as routes in semi arid and arid areas, ie most of Australia.

Lindsay

[roeter]

Genma Saotome, on 14 February 2015 - 11:49 AM, said:

Rob, those are some interesting comments you've made!

If I understand you then what you are saying is let the new .w file describe only those things that have one origin point that have been placed within one specified area (e.g., a tile) and create other new files that describe features that could (or do) span multiple .w files and have a start and end point. Is that correct?

That sounds like the .w file hold only static objects and all the stuff that has start and end points (and the things that tie into them) one or more newly designed files. That would be better for the OR code?

Basically, that is right. Clearly, it would require some changes to the present code, but it would be more easy, and make it a lot more easy to add all kinds of links and interactions, some of which (like that between signalling and level crossings) are a real hiatus at present.

Regards,
Rob Roeterdink

[DRelyea]

Hi,

Sorry, that was not the stop distance I meant. I was referring to how close or how far the vehicles stop from the tracks, not each other. The current solution at high angle of incidence (or shallow) is to eat 6 tracknodes by placing a piece of track on each side outside the active ones.

Doug Relyea