TSRE Changes / Wish List

[yellowdog]

I noticed that the consist editor on goku's latest version didn't display rolling stock correctly. Just weird pink blocks. I'm on mobile, so no screenshots available atm.

Had a chance to get back into Goku's latest. Here's what I see in the consist editor--red and black geometric shapes. While I didn't scroll through my entire list of rolling stock, it does appear to be the case for every piece I viewed. Just fyi. Not sure what other bugs it may have. Went back in to Eric's fork and everything displays correctly. Untitled.jpg

[steamer_ctn]

The process of adding a hazard or speedpost and changing it to a crossover item should still work.

https://web.archive.org/web/20190820093011/http://msts.steam4me.net/tutorials/make_xover.html

I'll also take a look to see if maybe there could be a hack to combine two speedpost items into a crossing item within TSRE.

Is there any chance of moving this up the priority list, as I am currently working on some code changes that rely on having Xovers in place?

[pwillard]

The BLACK and RED issue stems from a missing library, explained on Goku's Page. Specifically:
OPENAL32.dll

[eric]

Yep, that's why I started including the DLL in the app directory download (which is an old but tried and true way of doing things).

No more problems with someone grabbing the wrong version of the DLL.

[yellowdog]

The BLACK and RED issue stems from a missing library, explained on Goku's Page. Specifically:
OPENAL32.dll

Good to know! I forgot his version didn't come with all the parts.

[eric]

Is there any chance of moving this up the priority list, as I am currently working on some code changes that rely on having Xovers in place?

I've looked, and attributes needed to change in the TDB aren't exposed for editing.

What I have been able to do is get the properties for the Hazard item properly displayed, including the trItemID that's needed for the linking of the crossover item when you do the manual update in the TDB. It still requires a manual update, but having all of the data available does makes a bit of a difference. I've also made an executive decision... "hazzard" is being auto-corrected to "hazard" since it's the only place I can think of where two spellings have the same effect. It's a 20 year old typo that is long overdue for correcting.

Alternatively, if it's any help, I did just create a bunch of new crossover pieces for FastRail (which are really geometric copies of A-Tracks and visually compatible with ScaleRail). 5 degree increments from 15d to 90d, which should cover most situations, and they have the crossover point defined in the shape which is needed for the TDB update.

Download FastRail / FR_Tracks and use the temporary TSection provided.

[eric]

To expand a bit on what I was discussing last night... I've made some changes to how Track Database Items appear (e.g. interactives) to make it a bit easier for making those manual Crossover items:

First off, the Properties pane on the left will now show up when you place or select a Hazard. That wasn't enabled in version 7 apparently....

As you can see, the pink box is gone and replaced with a fuscia arrow pointing down... The numbers in black over the Hazard are the Track Database Item (TrItem) number needed to find the object in the TrackItems portion of the TDB and the TIT. If you enable the Track Database Items option in the View menu, you'll see that those numbers don't change, but they're appended with the TR: indicator. You'll see why in a minute.

capture_5100349.jpg capture_5100350.jpg

Other items which are TrItems include speedposts and mileposts.... Depending on which option you've selected, the black numbers over the grey arrows are the speed or the milepost number you've entered for that object.

capture_5100345.jpg capture_5100346.jpg

One of my biggest frustrations in adding these is I've occasionally dropped the item but forgot to update the actual speed/number before moving on. Now there's a visual reminder of what's set.

If you enable the Track Database items under the view memo, the TrItem reference ID value will replace the speed/number display. Hopefully, that TR prefix makes it clearer as to when the numbers are and aren't referencing the data entered vs. the reference ID's. I may also change the text color when toggling.

These changes will go out with the next testing version later this week.

---

Going back to steamer_ctn 's original request... actually adding the crossover item automatically.

I spent some 16 hours over the last three days trying to make that happen, and kept running into roadblocks with other code (e.g. Autofix) which were erasing the changes as I added them, and then there were a few hard dumps of the editor.

For the few of us that need this functionality, the tried and true "open up the TDB in a text editor" approach is ultimately safer than continuing to put everyone's TDB's at risk if the "change a hazard into a crossover" function were to be used accidentally. I also added a bunch of crossovers for FR_Tracks that mirror some in ATracks, so the need for a custom crossover should be greatly minimized with pre-built diamonds in 5 degree increments. For everything else, there's Jeffrey's "change a hazard" approach we've used for almost 20 years.

[eric]

The last chapter of the TrItem updates... something along the lines of the Milepost/Speedpost that I wanted.... Station and Siding names.

capture_5100359.jpg

What's fun about this is that the text will scale based on the size of the station/platform or siding name:

capture_5100361.jpg capture_5100362.jpg capture_5100360.jpg
The longest I was able to get was 64 characters before it started truncating the display, but there are three variable display scales at play here, so you're not really limited by what you want to put in for a station and/or platform name.

And yes, I did go back and change the Speed / Milepost coloring a bit...

capture_5100364.jpg capture_5100363.jpg

Hopefully this makes things a little easier to navigate and know what they've missed when adding interactives.

[eric]

Testing version 8.005s is up and available with these changes.

Sent from my SM-S911U using Tapatalk

[scottb613]

Hi Folks,

Just a suggestion - would it be possible to adjust the cut and embankment tool [F] - to have a [1.5] width setting? [1] often is too narrow leaving many artifacts - [2] is often way too wide.

Along with the geo topic - has anyone ever tried making stamps to better handle cuts and embankments? Using the [F] as you would to modify the mesh? I'm assuming the [F] only works on a bounding box footprint - not that we could carve smooth shapes into the terrain. If stamps would work better - I'd have to figure out how to snap it to the tracks for ease of placement. Anyway - just a thought.

Thanks.

Regards,
Scott

[eric]

Bounding box is only relevant if it's not a track or road section, where it follows the geometry from the TSection.

I'll see if the cut/fill values can be a double vs an integer.

[scottb613]

Bounding box is only relevant if it's not a track or road section, where it follows the geometry from the TSection.

I'll see if the cut/fill values can be a double vs an integer.

Hi Eric,

Thanks for all you do - much appreciated.


Yep - we're on the same page - the bounding box was in regard to the "terrain stamps" idea. I'd love to improve our manipulation of mesh - when using high-res GEOtiff - we can see what our ORTS mesh is truly capable of - yet sadly - we can't leverage that with the available TSRE toolset for manual manipulation. I'm always plagued by jagged edges or undefined cuts and fills.

Regards,
Scott

[longiron]

Eric,
First I would like to say a BIG "Thank You" for carrying on with TSRE. Making it better and more usable software

I have only one ask, that the images from Google maps for developing terrain textures were more like Solution for Real Terrain. SRT created 34 Terrtex per tile (512 x 512) using Google maps. It was easy to use them as a template for creating custom Terrtex or using them directly for distant mountains.

[eric]

TSRE does save the individual 512x512 textures when you do terrain painting... It's not intuitive, but you can then load those ACE files and save them as something else if you want to have them as a template.

[eric]

Not really a new feature, as much as it is fixing a bug or unsupported condition from the original TSRE code.

Attempting to load a route without a TDB has always caused the app to fail to open.

I've now got some exception handling in place so a clobbered route -can- be opened without a TDB, and it will create a new one on exit assuming you've added track to the TDB either via a Z key action or placing new track. The downside... you can't recover what was previously there without doing a TDB rebuild by hand (i.e. clicking on each piece). That may or may not be helpful when recovering an older route. It's also some incentive for me to work on rebuild logic...

There was an unhandled exception I found with that process -- if you clicked on a piece of dynamic track not already in the TDB, and it had a value outside the bounds of the local TSection or if the local TSection is missing/empty, it would hang briefly, give the blue spinning wheel and abort to the desktop without saving any changes....

There's now some logic in place to detect where the Dynamic Track is out of range, and it will create a new local TSection entry.

There is some minimal risk with this fix... If you edit a route without a TDB or local TSection, and create the new files, there's a fair chance you'll eventually come across a piece of dynamic track that falls within the range of the new TSection, and renders differently from what's expected. That should be fixable if you double Z the track. If not, then you'd have to delete that DT and place a new piece in its place. The other possibility is that it will abort to the desktop... I'm trying to figure out a way to test for that, but haven't just yet. It's getting late so it'll have to wait for tomorrow.

Once I get past vetting that last condition, it should be available in the next testing release. I might also hold this back for v8.006, as 8.005s seems fairly stable.