[Genma Saotome]

I posted something about this on the TSRE site but I could not include an image so I'm (basically) repeating the matter here.

KUJU made a strange decision to NOT use the path altitude parameter in the Tsection file but instead to hardcode an offset of 0.325m in the program code to offset the track path from the origin point of the shape. My guess is this decision was made at the last minute when somebody noticed trains were not up on the rails in the last-minute-produced routes that were included in the original cd... essentially a fix could be made more quickly by changing the code than finding and editing the relevant zero in the tsection file.

That clumsy decison then controlled the Tsection specification of all new tracks. Because roads were always flat shapes it was not an issue for roads.

But this is what things look like when you pair road and rail at the same position and Qdirection():
 gap.jpg (123.35K)
Number of downloads: 5

As things stand with TSRE it appears if you use the offset parameter in the Tsection file a sequence of such shapes will not be snapped together as you would expect but instead placed at the offset point creating a stair step result.

There are two possible solutions: Edit the altitude of the track shape and reduce it by 0.325m... OR fix TSRE so we can specify road shapes (at a minimum) so their surface is 0.325m high but their origin point is at zero -- IOW the dimensions of track shapes.

WRT track with a non zero altitude... there are some defined in the tsection and I have to wonder if they really work. At any rate, the problem is if the 0.325 hardcoded offset is removed from OR all the trains would run 0.325m lower. The only solution to that is a massive edit to the tsection file to replace that zero altitude value with 0.325. It is a do-able task but certainly be a non-trivial effort and the revised tsection will would have to be delivered at the same time as the revised OR code. Because road surfaces have always been at the origin point this particular problem would not apply to them.

[StevenMasters]

The roads are at a height of 0.1m (back when I was making them). This was to avoid the "poly" display battle with the terrain.

[eric from trainsim]

StevenMasters, on 12 January 2021 - 03:51 PM, said:

The roads are at a height of 0.1m (back when I was making them). This was to avoid the "poly" display battle with the terrain.

Sounds right. A bunch of my original snappable shapes had offsets built into them.

I gave up on snapping, and now have a value in WorldFileHacker to make the shift for me (it's the AdjY column if you have the app)...

I'd be fine with a change as long as the TSection and renderer are in synch.

What would the impact be on anyone making track sections? Wouldn't they have to know this when submitting new TSection requests?...

[roeter]

Would it not be possible to leave the offset-value 0 as the default offset 0.325m, and use any value set as offset as delta to this default value?
So, an offset defined as -0.325 would result in 0m offset. This would probably still do the work but would avoid the problem of having to change the tsection.dat.
To keep the program and the tsection.dat file in sync for all routes for all users is a bit of a nightmare.

Regards,
Rob Roeterdink

[Genma Saotome]

To be clear, there is an assumption here underlying what I have described above as a problem and that is this: Road and track shapes should have identical position() and QDirection() values when the shapes are meant to occupy the same location -- rail in the street.

I don't think it is at all practical to fix existing track shapes by removing the hardcoded offset to the train path and then fixing the offset to the train path in the tsection (making zero 0.325m). It's not that it would be hard to do -- convert the tsection to one line per entry, find, cut, and paste elsewhere for restoreation those lines with roadshape() and then change the string " 0 0 0 " to "0.325 0 0 ". The problem, I think, would be the near impossibility of a deducted team to testing the change which would push it on to end users... and the difficulty of getting all end users to replace their old Tsection file with the new one at the same time the OR update is rolled out.

So I think we just have to live with it. If nothing else it does enable the smooth connection of shapes using different rail weights. But living with it doesn't meet the criteria of the basic assumption I've given.

My concern is TSRE first, and OR second. Some time ago I created a road shape with a origin point of zero, same as track, and a path offset (and road surface) of a nominal 0.325m (it is actually 0.315475m so the rail protrudes ~10mm above the pavement but that number is too large to routinely type in a post). TSRE cannot properly place a sequence of these shapes... the result is a "stair" of shapes where with each successive placement is (the Tsection path offset value of) 0.325m higher than the one before. Only Goku can assess the implications of changing that and of course only Goku can make that change.

I've also created a set of road shapes with the traditional idea of the road surface equal to the origin point. This in turn is problematic for me as the road has an arch (as all real roads do) and so all of the slower lanes road surfaces are below zero -- and below the road path. So these don't really work either.

The other problem, a question really, (assuming Goku can and does make the change) is what does using the Tsection path offset mean for roads? The Tsection entry is clearly marked roadshape() so if track and road data needs to be processed differently it can be done. But would it be a simple change? I don't know.

[Genma Saotome]

roeter, on 13 January 2021 - 03:21 AM, said:

Would it not be possible to leave the offset-value 0 as the default offset 0.325m, and use any value set as offset as delta to this default value?
So, an offset defined as -0.325 would result in 0m offset. This would probably still do the work but would avoid the problem of having to change the tsection.dat.
To keep the program and the tsection.dat file in sync for all routes for all users is a bit of a nightmare.

Regards,
Rob Roeterdink

I'm sorry Rob but i do not understand your suggestion.

We agree about the nightmare.

[Goku]

Making changes in tsection file won't help you at all in copying position from track to road shapes, because track shapes have rails at .325m, not 0.

[Genma Saotome]

Goku, on 13 January 2021 - 02:32 PM, said:

Making changes in tsection file won't help you at all in copying position from track to road shapes, because track shapes have rails at .325m, not 0.

Yes. That is what I have been describing here.


A summation:

• KUJU made a crazy descision to ignore the Tsection file and instead hadcoded an offset definiting where the top of the rail is always located (0.325m above the origin of the shape.
  
• It would be far too difficult to try and correct that, we'll have to leave it alone.
  
• Because the offset from origin to path on roads is either 0.0m or 0.1m it should be possible to activate the use of the tsection path offset for new road shapes w/o harming existing routes. The vertical offset for these new shapes would place the road surface about 0.325m above the origin point of the s. file so The Tsection offset value for all existing roads would remain at zero.
  
• When I tried to place road shapes with a defined Tsection offset value I found TSRE would not properly place a sequence of those shapes. The placement was a "stair step of ever ascending shapes, each LOOKING like it was exactly higher than the previous shape by the the offset value in the tsection file. I bel;eive I gave you a copy of those shapes so you could see it for yourself.
  
• If you could fix that I could go forward with the next test and determine whether the OR code recognizes the offset value for these new road shapes.

The road placement bug looks like this:
 TSRE Bug.jpg (126.69K)
Number of downloads: 5

[Goku]

Did you try to use snapable points for your shapes, place roads with add to tdb disabled, and later add them manually using Z?

I'm going to fix it for you later.

[Goku]

Here is a fix for you:
http://www.onrails.e...hp?p=1020#p1020

Seems to work fine.

[eric from trainsim]

Goku, on 14 January 2021 - 02:09 AM, said:

Here is a fix for you

I know this is off-topic, but any chance you could do a fix that perhaps exposes the SDL for signals and eliminates the limits on StaticDetailLevels?... I've already confirmed it works in ORTS with higher values.

[Goku]

Does it solve your issues?

[eric from trainsim]

Goku, on 17 January 2021 - 08:21 AM, said:

Does it solve your issues?

It won't solve *all* the issues I'm coming across, but it would open up a lot of flexibility for how both Dave and I use SDL's.

Being able to edit the SDL on signals would be nice to have, but not essential since I can edit those manually in the W file as needed.

Two other nice to haves:

1) a hack to force reloading of files (W files and shapes only seem to load once) without having to close down the editor and re-open it. That's one thing MSTS did right -- it go back to the source files every time it re-encountered a tile that had already been unloaded from memory (i.e. you'd moved more than three tiles away). The only downside I can think of is changes that weren't saved might be lost, but sometimes isn't a bad thing.

2) a keystroke enabled way for the camera to follow the nearest TDB vectors when using the forward and backward keys (8-2 or the up/down arrows)...

As for other issues... I'll continue to post them in their own thread so that it's not a thread hijack here.

[Goku]

It was question for Dave.

[Genma Saotome]

Goku, on 17 January 2021 - 08:21 AM, said:

Does it solve your issues?

Seems to. I'm seeing a couple of other things but so far they seem to be related to the shapes and not the software.

Thank you for the change!



p.s. removing the limit onthe values of StaticLevelDetails() would be a very nice change too.