[Genma Saotome]

TSRE 7.002

Near end of a 250m road shape, not connected to anything at all.
 00-near.jpg (112.54K)
Number of downloads: 1

Far end
 00-far.jpg (157.66K)
Number of downloads: 1

Here is the tsection entry:
TrackShape ( 25534 FileName ( MR_All_n1B_21x250m.s )
NumPaths ( 2 )
Sectionidx ( 1 -1.6764 0 0 0.314 3 )
Sectionidx ( 1 1.6764 0 0 0.314 3 )
RoadShape ( )
)

What the above states is there are two paths, each 1.67m on either side of the center line with a defined car path 0.314m above the zero altitude level, 250m long. No squirlly angles in there. What is different is the value of 0.314. All other shapes int eh tsection value have 0 in that location. This a bit higher so the road shape can have an arch, including a lower altitude in adjacent lanes, with room for a gutter quite near to 0 altitude..

Copy POS as well as copy Pos/Rot for pasting upon another similarly defined shape does not work at all.

I've put several months of work into this library of road shapes and to see what the program is doing is a real shock.

[ebnertra000]

TSRE has had an issue like this for a long time, where they would end up slightly off-kilter. It's always happened with longer pieces, but is very inconsistent; because of that, I've never found the cause. I can place 250s until the cows come home, and then one will suddenly do it. I will usually end up rotating the piece back manually, since (I think) the shape is crooked, but not the .rdb lines

[StevenMasters]

Going from memory (at work right now), but the 0.314 is in the angle position.

[Genma Saotome]

StevenMasters, on 22 September 2021 - 05:16 AM, said:

Going from memory (at work right now), but the 0.314 is in the angle position.

Yeah, I think you are right. I went looking for exceptions to " 0 0 0 " and found slip switches.

Ok... I misunderstood the purpose here. That leaves me with a major problem, specifically, how do you define a path offset above the the origin point? KUJU appears to have hard coded a value for railheads and either did the same or assumed zero for roads. I have built a road shape library that depends on the path being above the origin point. How to I define the path for that?

Here is an example of the goal:

 streets.jpg (192.09K)
Number of downloads: 0

There are 4 shape files shown there -- the #1, #2, and #3 lanes, plus the centerline. Not shown are shapes for parking lanes or shapes for gutter/curb/parkway shapes, both in multiple "flavors"... even the cernterline comes in flavors: Yellow lines, white lines, black lines and no lines. Also not shown are identical shapes textured for asphalt, cobblestone, and street cars, as well as the track for the streetcars. All of this is based on the various shapes using an identical xyz origin point to make placement of the several shapes very easy -- you set down the #1 lanes and everything else that follows uses the same Position() and Qdirection() values. And the roadway is arched.

This means the roadway for the #1 lanes has to match the altitude of the railhead shape (for streetcars). And because the roadway is arched the altitude of the carspawner path in the #2 and #3 lanes is lower. All of this depends on defining the carspawner path above the origin point -- exactly as-if it was a track shape. Except KUJU didn't provide for this in the Tsection file, they hard coded the offset in the program.

What can I do??

[dajones]

Try

TrackShape ( 25534 FileName ( MR_All_n1B_21x250m.s )
NumPaths ( 2 )
Sectionidx ( 1 -1.6764 0.314 0 0 3 )
Sectionidx ( 1 1.6764 0.314 0 0 3 )
RoadShape ( )
)

The third number in SectionIdx is supposed to be the Y offset, but I don't know if anyone has ever used it.

Doug

[Genma Saotome]

Doug, that IS the answer, thank you.

However there is still a problem, this time in TSRE: The program seems to be using the XYZ position from the tsection data as the origin point of the object, instead of the objects own 0,0,0 origin point. In practice this means the road shape I'm describing in this thread will use 0, 0.314, 0 to located the object on the ground which means the object itself is invisible underground. The option to "snap-to-object" when placing does not prevent this... and of course if you turn off the display of the terrtex you are most likely to see the next placement drop to -infinity altitude.

So as I feared, it appears there are only two solutions: code changes in TSRE or placing other road shapes and then hand editing both the .tdb and world files to subsitute in the shapes I want to use. I have, on occasion, done the later; it's no fun, especially after making an error.

FWIW, Goku has not logged into his own board (or this one) in over three months. The tree sap might be solidifying into amber.

[Goku]

I did solve this problem for you 10 months ago (road Y offset). And everything worked well.
https://github.com/G...8/TDB.cpp#L1608
For perfect results, this solution requires that all your shape paths have the same Y height.

Don't know why did you forget this and are back with the same issue.
Forget about fixing it second time.

[Goku]

Here is the old topic on tsre forum: http://www.onrails.e...c.php?f=7&t=190
I made TSRE version for you, did test all your shapes. Everything worked great, but you just ignored it.

[Goku]

As you can see, everything worked great in the version I gave you:

https://i.imgur.com/uy3so88.png

But, you ignored it, and meanwhile I did make a fix for this bug: http://www.onrails.e...c.php?f=7&t=247
This caused the solution to your problem to stop working.

Try TSRE version .7.007

[Genma Saotome]

You might have asked if this is still a problem.

Checking this morning, yes, the generic roads are placed correctly. Offhand I don't recall what I saw before, it was 3.5 months ago. It had something to do with replacing shapes, specifically when the path was at a different height. I changed my approach sometime after writing the above posts and IIRC it works now. I would like to verify t hat again today.

FWIW I'm working with 465 different models, all of which have gone thru multiple versions and all of which must be identical in several points.

A request, if you have time: when changing the name of a shape AFAICT you have to know the correct .s file to type. Is there a place in TSRE where you can select a shape and copy it's .s file name? If not, could that function be added to the right mouse click menu? I could then copy/paste that name from the selected shape into the edit window and then there would not be any errors and I would not have to pull up windows explorer to find the name.

[Genma Saotome]

Weter, on 09 January 2022 - 02:39 PM, said:

Someone wrote about shape names substitution.
Me personally have changed the names of gantry shapes successfully.
This makes wider gantry to appear at exactly the same position, as previous narrow one.

Yes, I have done this myself. What I'm asking about is whether there is already a way to copy the .s file name from a shape placed in the route so it can be applied as an update to the name of something else. For example, this name: MR_CA_As_11b_21x025m.S is what I want to use to replace this name: MR_All_n1B_21x025m.s; Being able to copy/paste the name is better than trying to remember which part of the first name can be kept and which part needs to be changed.