[Genma Saotome]

I've mentioned on other occasions the desirability of limiting Sprite Text to just what's needed for each activity instead of everything found on the displayed tiles. Here's an example of the problem that should be solved:



And that is a partial listing for one tile... not everything has been added to the tile and there are tiles further on that will have as many.

Thinking about the issues it makes sense to me that Sprite Text be more specialized than what KUJU has provided... Platform and Siding names of course, but beyond that it sure would be nice to have different color Sprite Text (and different keys to invoke their display) for things like car spotting locations (almost everything in the image above is for car spotting), street names, railroad facility names (e.g., Scale, Turntable, Tower, etc.) and perhaps geographic names (for route familiarization purposes).

To get from here to their... the full solution has to be a new route editor... but before then I'll wager some derivation of the *.tit file could be figured out that would enable the feature set I've suggested -- it's only missing the "class" name that would drive the color. I suppose there is a fair bit of work to do in the upcoming Activity Editor phase to define display limiters but I do think on the whole it would be a good feature to develop.

[SVRy_Steve]

I've been fiddling with the sound environments provided by Realtech Hd Audio Manager, things like Quarry, Stone corridor, Auditorium and Concert Hall. Some are pretty heavy echo types, others are open with none of that, etc. By switching on the fly in OR, going through a tunnel, I used the sound environment "Sewer Pipe" and in deep woods, one that's has moderate echo. Out in the open, one that's just that and when viewing at a distance in the mountains, Concert hall makes the whistle sound just right, echoing off the hills. It really adds a nice "real" feel. Is there a way to do this with a type of sound region switching the audio processing to different environments?

Steve

[markus_GE]

I would never have thought of trying to improve sound quality by switching to different modes in Realtek manager... I didn´t even know this was possible. Thanks for bringing this up, this really ads to not only trainsimming, but to general sound experience ;)

Cheers, Markus

[Genma Saotome]

Another thought: Given the fact that a pixel or two at 2000m covers about 16 inches (at 1920 by X resolution) -- and less distance at higher resolutions -- there will eventually be a need for modelers to assign LOD() values > 2000m. Right now we're equating the MSTS default of 2000 as equal to MaxViewingDistance()... perhaps the code should accommodate LOD values in .s files at or above 2000m.

I dunno if explicitly marking faces with "MaxLOD" would be best or just allowing for any numeric value for LOD and giving "max" to whatever's left over, but either way 2000m feels inadequate.

[James Ross]

Genma Saotome, on 26 December 2013 - 11:27 AM, said:

Right now we're equating the MSTS default of 2000 as equal to MaxViewingDistance()... perhaps the code should accommodate LOD values in .s files at or above 2000m.

The current code should have absolutely no problem with LODs >= 2000m - they should work exactly as you'd expect. The experimental option to extend LODs just extends the highest LOD to infinity, no matter what its numerical value is. So I don't think there's any issue here, unless I've missed something.

[Genma Saotome]

James Ross, on 26 December 2013 - 01:55 PM, said:

The current code should have absolutely no problem with LODs >= 2000m - they should work exactly as you'd expect. The experimental option to extend LODs just extends the highest LOD to infinity, no matter what its numerical value is. So I don't think there's any issue here, unless I've missed something.

Cool! Thanks James.

[eric from trainsim]

That sounds correct. I'd manually adjusted some LOD's to ~4000m range when OR first broke the 2000m barrier, and it seemed to have worked then.

[SVRy_Steve]

Forest Object Rendering Options?

I realize that ORTS doesn't have access to the original code for forest objects and in order for no trees to be on the tracks in some older routes, where forest objects were placed across the tracks and tweaked so no trees were on the track, the edges were inset in the new code. Meaning that the trees tend to clump and not go near the boundary box.

For present route builders that use forest objects heavily, this is very awkward! If I place brush and trees close along the tracks in the RE, it is fine in MSTS, but looks like there's been a major clearing project along the tracks on ORTS.

I wonder if it could have a "Compatability Mode" like Internet Explorer? So that if trees are on the track, it could be switched to view forest objects in the way it does now and default to accurate as in the forest object box in the MSTS RE, or the reverse! I realize the trees won't place in the same locations, I just want them to fill in right up to the boundary box!

See this thread for more input on the subject and images to illustrate it.

Thanks for considering whether this is possible,

Steve

[wacampbell]

SVRy_Steve, on 28 December 2013 - 12:00 PM, said:

I wonder if it could have a "Compatability Mode" like Internet Explorer?

And ideally this mode would be set by the route builder, and saved with the route properties, versus having it a global setting, where the end user would have to remember which routes need it and which don't.

[Genma Saotome]

wacampbell, on 28 December 2013 - 12:39 PM, said:

And ideally this mode would be set by the route builder, and saved with the route properties, versus having it a global setting, where the end user would have to remember which routes need it and which don't.

Add it to the *.trk file. That would keep it w/ the route AND that file is being used by OR. Good place for a DisplayUOM( metric | american ) parameter to drive the values displayed in various places (e.g., speed, weight, length). Car data of 13m and 39t tells me and the rest of us archaic UOM users NOTHING.