[Goku]

Genma Saotome, on 04 February 2018 - 10:16 AM, said:

The shape names in the tsection file are meaningless... you can edit the name in a world file so it no longer matches the name in the tsection file and so long as your new shape conforms to the specification of the ShapeIdx() it uses everything will be fine, no matter what name is over in the tsection file. Conversely you can change the shapeinx() value in the world file and again so long as the new value provides size specifications that conform to the shape used, everything works.

For route builder it has meaning!
Example: You have three identical shapes by section definition: 100m length, but one is simple track, one is bridge track, one is tunnel track etc.
You can use one shape definition but it adds so much work to choose proper shape template to each section you place.
Each section placed, you need to choose custom template (and using MSTS RE edit file names in .w files, WTF).
Different shape names in tsection.dat allow you to faster place proper shape template.

You are route builder, so I'm surprised that you don't see the meaning.
Suggesting that you can edit .W file instead of just selecting proper shape from list is just stupid.

With TSRE new procedural tracks selecting templates will be much easier, but still predefined shape names will be useful sometines.

[R H Steele]

Goku, on 04 February 2018 - 10:26 AM, said:

Suggesting that you can edit .W file instead of just selecting proper shape from list is just stupid.

my emphasis

You know, this is none of my business, I'm probably stepping out of line, but...Goku, I've read other posts of yours that use that phrase, you appear to deploy it in arguments when others suggest something that is contrary to what you think is correct. (...and the point is -- it does not matter if you are correct or not )
Obviously, it rankles me. I find it demeaning, insulting, and downright rude.
None of the other members on the development team use this type of language, at least not on the public forums.
Coding sophistication does not obviate the need for simple courtesies.
Try a different tune when offering rebuttal.

My apologies to the board.
Regards, Gerry

[Goku]

I'm sorry. I just forgot again that here are old people that takes everything more seriously.

[ebnertra000]

As I see it, you would need at the very least two versions of, say, a 50m straight piece: a normal one, and a tunnel version that will darken the cab. I'm building a route using USTracks, so every piece placed is initially an Xtracks shape, which is then changed to its USTracks counterpart. When I want a bridge piece, I place a normal shape, and then change it to a bridge piece. For tunnels or tracks inside buildings, I use tunnel pieces, changing them to USTracks tunnel pieces for tunnels, or to an non-tunnel piece in a building, so as to get the night cab to turn on if an engine is driven into said building. Having a shape assigned to each tsection index may be helpful initially, if for no other reason than to have something to start from, but it doesn't mean that that shape must be used in the end.

I suspect all the duplicates in the tsection file were catered more to the MSTS RE era, when it was a bit of a pain to swap a ton of shapes. Now that we have TSRE, it's a snap, and all these duplicates for varying track systems are more or less redundant

[Genma Saotome]

Goku, on 04 February 2018 - 11:05 AM, said:

I'm sorry. I just forgot again that here are old people that takes everything more seriously.

Your inexperience and immaturity shows. When you need a custom shape, say, because you need a different appearance of the rails or ballast, you don not want to create a new tsection entry and submit it as the official shape. Instead you take a copy of the shape you want, you edit the .s file and replace the texture name that is there with the one you want. THIS shape file now goes into the routes \shapes directory and over in the world file you plug in the path and file name. The same is true when you want to customize the switchstand "sign".

This is NECESSARY when you do not own the track library but someone else does. It is wise when you know what you need is so arcane it won't be useful to anyone else.

[Goku]

Quote

Your inexperience and immaturity shows.

No. Your bad understanding abilities shows.

Quote

When you need a custom shape, say, because you need a different appearance of the rails or ballast, you don not want to create a new tsection entry and submit it as the official shape, instead you take a copy of the shape you want, you edit the .s file and replace the texture name that is there with the one you want. THIS shape file now goes into the routes \shapes directory and over in the world file you plug in the path and file name.

Imagine doing this for all tunnel tracks, when in KUJU way you can just choose the shape. Or with Xtracks you can just choose bridge shape instead of editing lots of entries in .W files.

[R H Steele]

Goku, on 04 February 2018 - 11:05 AM, said:

I'm sorry. I just forgot again that here are old people that takes everything more seriously.

Dude, for a bright guy, you sure don't know when to put down the shovel and quit diggin' the hole deeper.
You don't personally know me, you know me only from my written posts, so you made two HUGE assumptions,
1. That I'm old ( correct - at least the biological shell I'm occupying looks old to the casual observer )
2. and that being old "I take everything more seriously"....seriously, you got that from asking for civil discourse?? Very illogical.
Okay, I'm finished. Apologies for taking up thread time with off-topic peccadilloes.

Here's my team of advisors that supervise everything I post. They let me out periodically to bother the other two legged critters...

Attached thumbnail(s)

• 
• 
• 
• 

[copperpen]

Once again I see we have a minor spat about how the application of shapes and textures in a route can or "should" be done. Using the "flexibility of the Kuju tsection.dat is excellent for the singular purpose of its design, to place track sections of plain, tunnel or bridge type, but they must all use the same ballast texture that is defined in the texture sets placed in the route textures folder.

If you want some track sections to use a different type of ballast you must use the alternative method of editing the shape to use the different textures, place the shape/s and textures into the respective route folders and then edit the world files to point to the revised shapes, cannot be done in any other way at present, and could be open to error.

It is however possible to build the required flexibility into Goku's editor so that it can use track sections from any user specified location without having to use the tsection.dat.

[DRelyea]

Hi,

Ummm. partly correct on the different ballasts. The Global folder TSection.dat that shipped with MSTS was only capable of 20,000 track, road and other shapes that utilized a track vector for placement. Using it, yes there can only be one ballast.

Through the provenance of MSTSBin, this was elevated to 40,000 shapes. This creates a conflict with a route Tsection.dat where the Dynamic track entries start at 20,000,and what the Horace Utility was coded to fix. Horace changes the entries not only in the Route's TSection.dat, it adjusts the numbers in the affected w files as well.

Xtracks and other track and road packages are built around the original 253 track and road sections that shipped with the disks. At some point the A(X)t ...... conc.s shape system was introduced, now allowing 2 different textures to coexist side by side.



The stone ballast track the train is riding on was laid in the MSTS RE at the same time as the cinder ballast track. The Stone ballast is a swap of the base texture for the 'conc' shape's default texture.

To add the other two ballasts needed, Chats, and Rock, I will have to either

1. Create a custom TSection.dat for the route where I clone shapes, modify the texture call on the clones and add Tsection shape entries, or

2. Use the shape swap method in the w file If and only if I am posulutely, absocertainly sure I will never, ever click on one of those shapes. Clicking on a track shape that does not have a corresponding Global Tsection shape entry crashes the MSTS RE hard, and I suspect TSRE as well.

Doug Relyea

[Genma Saotome]

Goku, on 04 February 2018 - 11:41 AM, said:

No. Your bad understanding abilities shows.


Imagine doing this for all tunnel tracks, when in KUJU way you can just choose the shape. Or with Xtracks you can just choose bridge shape instead of editing lots of entries in .W files.

Look in the mirror.

I gave you two examples, both of which involve placing arcane shapes NOT REGISTERED in the tsection file, never to-be registered, never to be placed in \global\shapes -- because they are arcane -- yet needing a well established specification for their paths.

OF COURSE one would not hand edit a global shape name to another global shape name in ordinary cicumstances... but I'll give you one that isn't ordinary: If you want to convert a route using xtraks to ScaleRail, UKFineScale, or DBTracks you are not going to do that by removing the original and placing the replacement. Instead you are going to pull up your superior text editor, the one that does edits on filesets, and methodically replace the xtracs name with the subsitution (e.g., a2t100m to SR_2tStr_c_100m) across the file set of *.w in that route. You do not need to do the same with the ShapeIdx() values because you are not changing the paths, only the shapes.

Once again one works in the world file with an editor because it is the most efficient tool for the specific task at hand.

[Genma Saotome]

copperpen, on 05 February 2018 - 01:43 AM, said:

Once again I see we have a minor spat about how the application of shapes and textures in a route can or "should" be done.

It occurs because both MSTS and OR are data driven applications -- they provide no assets of their own. The data is not binary (or when it is its easy to convert back to readable strings). And so the environment is fundamentally fully open. There are a few exceptions where stuff has slipped into the code that should not be... the calculation of the Davis parameters is one such example (the .eng or .wag should include the choice of which version of Davis to use and the small number of parametric values to compute A, B, and C).

A few data transactions do apply to multiple files; for those one must proceed very carefully no mater how the task is accomplished. For the rest it is (and should remain) anything goes. The occasional pain that creates to support staff is vastly outweighed by the ease and gains in creativity of the mass of end users.

IMO it would be a major mistake to lock everything up.

Needless to say I am not a fan of Apple application software.

[Goku]

Genma Saotome, on 05 February 2018 - 11:01 AM, said:

OF COURSE one would not hand edit a global shape name to another global shape name in ordinary cicumstances... but I'll give you one that isn't ordinary: If you want to convert a route using xtraks to ScaleRail, UKFineScale, or DBTracks you are not going to do that by removing the original and placing the replacement. Instead you are going to pull up your superior text editor, the one that does edits on filesets, and methodically replace the xtracs name with the subsitution (e.g., a2t100m to SR_2tStr_c_100m) across the file set of *.w in that route.

But what if you want custom shape for standard a2t100m tracks and other for tunnel 100m track? Or for buffer tracks? If Kuju didn't provide separate shape definitions (as you wish), then you have to edit all shapes by hand, not by "superior text editor".
I think you don't understand the problem at all and we are talking about totally different things. Your examples are not even close to this problem.
If there will be no shape file names in tsection.dat then how the heck Route Editor will know what shape to put in .W file? You need procedural tracks to solve this issue.

Genma Saotome, on 05 February 2018 - 11:01 AM, said:

Once again one works in the world file with an editor because it is the most efficient tool for the specific task at hand.

No, it's not good way of doing things. Yes, with MSTS bad design it's sometimes necessary to get good result, but suggesting it as superior solution to be used in the future is insane.

[Genma Saotome]

I had not thought about the initial lookup seeking the path information... yeah... that does need the file name. However, once placed, there is no further use for the name except for the world file conveying to the display software what shape file to display.

There are VERY rare circumstances when you do hand-edit the whole Uid() construct to place roads and tracks and that's the difficult-to-solve matter of deliberately introducing bad joints to skew the track slightly. You have to compute the qdirection() and position() values outside of the editor and plug those values into the UiD() block. NOT recommended for noobs.

> No, it's not good way of doing things. Yes, with MSTS bad design it's sometimes necessary to get good result, but suggesting it as superior solution to be used in the future is insane.

Sez you. You will never build TSRE up to do everything that is needed by the route builder. Some of that is due to ignorance, some of that is simply a proper consideration of where to put your time, some of that is what you are interested in that week, and the rest is a cost:benefit judgement that says don't bother doing some things. All understandable and predictable. But on the route builder side, we will still encounter issues and we will still work the problem to a solution with the implementation often requiring a text editor.

[Goku]

Quote

I had not thought about the initial lookup seeking the path information... yeah... that does need the file name. However, once placed, there is no further use for the name except for the world file conveying to the display software what shape file to display.

Yes. Good we finally agree.

Quote

Sez you. You will never build TSRE up to do everything that is needed by the route builder. Some of that is due to ignorance, some of that is simply a proper consideration of where to put your time, some of that is what you are interested in that week, and the rest is a cost:benefit judgement that says don't bother doing some things.

TSRE isn't perfect of course. As I said, using text editor to edit advanced data is sometimes unpleasant necessity. But it's not a thing you can recommend for future solutions.