TSRE Changes / Wish List

[yellowdog]

Wow, thanks for the effort! I wonder if Erick_Cantu has any ideas?

[eric]

It'll wind up being a one or two line statement somewhere. It's figuring out which statement will work that's been the trouble, and I really do want to crack the JSON nut here as it is a more flexible structure than STF is.

[Erick_Cantu]

Wow, thanks for the effort! I wonder if Erick_Cantu has any ideas?

Not a clue, sorry. The only idea I have is to see if maybe whoever wrote the OR code (I think it might have been Carlo?) has any insight.

[eric]

It's not a problem with how they're structured or written... it seems to be an issue with QT's string handling, so I'll have to figure out something else that doesn't use the built-in functions. Wouldn't be the first time I've had to read a file byte by byte...

[eric]

The hard part of the container view is finally working... After two days of trying to do it the correct way via JSON, I went back to the old fashioned way... splitting apart strings and looking for the applicable fragments. It's an ugly way to code and totally unsupportable in the long run if the files change slightly. But it works for now, which is what mattered.



Most freight animations live in the same directory, and the shape renderer expects textures to be in the same directory as the shape.

Both of those conditions aren't true with the NAVS version of ORTS loads... the FA's are in their own directory and referenced via an intermediate file, and the textures live in the directory above where the shapes themselves are located....

There's still some work to do to calculate the positioning (center, front, rear, above) but that's relatively easy considering the logic pasted a few posts earlier can be ported from c# to c++ relatively easily.

[yellowdog]

That's great news, Eric! Thanks so much!

In regards to this-- "the shape renderer expects textures to be in the same directory as the shape"

I'm not sure if this is related or will help, but Tyler Bundy does some things with aliasing textures that I haven't seen before, with his cab.s files. The file structure for his locomotive models contain a 3DCabview folder, which has the shapefiles for his cabviews. These cabview.s files are only seen from the cab, as you look out over the nose of the loco and then rotate the view to look backwards onto the longhood/walkway. Those cabview.s files utilize the same textures the .s files use to render the whole model. But the external .s files and cabview.s files point to the textures very differently. For the external .s file (which is in the same folder as the textures), the language is typical:

images ( 8
image ( XXXXa.ace )
image ( XXXXb.ace )
image ( Truck2.ace )
image ( Alpha.ace )
image ( GP38c.ace )
image ( cpler1.ace )
image ( Plow1.ace )
image ( Truck2.ace )

but for the cabview.s (which is in a folder below the textures) the language looks like this:

images ( 6
image ( "..\\\\\\\\XXXXa.ace" )
image ( "..\\\\\\\\XXXXb.ace" )
image ( "..\\\\\\\\Truck2.ace" )
image ( "..\\\\\\\\Alpha.ace" )
image ( "..\\\\\\\\GP38c.ace" )
image ( "..\\\\\\\\GP38d.ace" )

I've not seen that aliasing format before (i.e. "..\\\\\\\"), although it could exist elsewhere and I just haven't run into it. At any rate, the format successfully points back up to the root loco folder to render the textures. The Consist Editor wouldn't display this cabview.s file when loading the locomotive, because it's only seen from the cab when you're actually in-game (ORTS only). But the shapeviewer.bat is able to correctly display the cabview.s file with textures (as does SView.exe). Not sure if that helps at all.

[eric]

Yep, there are certainly ways to reference textures elsewhere, and fortunately Goku had already built in support to pass the texture location as an override. It just wasn't set up to declare and invoke the override in the way that the load-or files were applying it.

In the end, it was actually about 20 lines of code to make this work and 10 of those were copied from other statements already present and simply modified a bit.

[yellowdog]

Nice!

[eric]

Did some cleanup of the code tonight to make it a little more supportable long-term, and it seems to be working pretty good.

What's still missing is positioning for CenterFront, CenterRear, Front, and Rear -- that's not part of this NAVS pack, and it doesn't do much good to try and code for it without a way to test it.

If someone's aware of a set (US or otherwise) that has those other positions used for positioning within an Load-OR structure, let me know what it is and I can do that last bit.

For gits and shiggles, this is what's being extracted out of the JSON file as well as the WAG file:

[I] Load-OR Attributes: "e:/dropbox/msts/TRAINS/TRAINSET/navs_container_base/container_48ft_5.load-or"
[I] loadarealength : 14.6304
[I] loaddoublestacker : true
[I] loadshape : "navs_container_base/container_48ft/navs_container_48ft_5.s"
[I] loadcontainertype : "c48ft"
[I] loadcontainerlen : 14.6
[I] loadpos : "center"
[I] loadbase : 2.9
[I] loadoffset : 0 - 0 - 0
[I] loadoroffset : 0 - 0.3429 - 0

[I] Load-OR Attributes: "e:/dropbox/msts/TRAINS/TRAINSET/navs_container_base/container_48ft_6.load-or"
[I] loadarealength : 14.6304
[I] loaddoublestacker : true
[I] loadshape : "navs_container_base/container_48ft/navs_container_48ft_6.s"
[I] loadcontainertype : "c48ft"
[I] loadcontainerlen : 14.6
[I] loadpos : "above"
[I] loadbase : 2.9
[I] loadoffset : 0 - 2.9 - 0
[I] loadoroffset : 0 - 0.3429 - 0​

[yellowdog]

Latest testing version seems to display the load-or files correctly for me! Thanks, man! I'll look around and see if I have anything with those other parameters.

dttx 456701 4.jpg

[eric]

Another day, another tweak.

Dynamic track in TSRE was built to match Kuju and XTracks:

capture_500504.png

Now, it's in the Settings file to be able to define the rail width and location:

 railProfile = 0.7175, 0.7895

capture_500503.png


That should help those who model in gauges other than 1435mm.

And before anyone asks to make this read the TrProfile or something else.... no, I'm not going to invest more time in this feature anytime soon. This was a small tweak I could make so that the editing experience could be just a little closer to what would the game engine would show.

This will be released with the final 8.003 version, planned for later this week.

[conductorchris]

The request was made to use different terrain file formats besides .hta.

I recall an extensive discussion on this question at Elvas Tower when Goku was working on the issue.

[eric]

The request was made to use different terrain file formats besides .hta.

Noted, if someone can provide the details around the other file format...

[eric]

Something I've been wanting for a while is a way for the camera to snap to the TDB line and follow the track so I could easily "fly over" or check scenery along a route while placing it..

I dialed that idea back a bit last night, and came up with this...

capture_500524.png

If you select an object, this menu option resets the camera's rotation to that of the selected object. It's set about 10m higher, and using the forward arrow or scroll key, you can follow the track, road, or other object.

capture_500525.png

Since the rotation of an object could be 180 degrees opposite of what you'd expect, there's also this option to flip the camera 180 degrees...

capture_500516.png

The flip option will be available on the context menu regardless if there's an object selected.

I may still get snap to TDB working for the camera, but until then, this will suffice.

[eric]

Sometimes you get lost and need to reset your perspective....

capture_500527.png

When you use any of the new camera reset/repositioning functions, any objects selected will be de-selected intentionally, just in case you accidentally got used to using the scroll wheel to move the camera.

If there are other suggestions on camera functions, let me know.