[scottb613]

Hi Folks,

Yeah - I've definitely wanted all those improvements that Darwin listed (I know I've created some Trello Cards on them myself) - but - without anyone getting into TSRE code as well as needed ORTS resources - it seems unlikely. Irregular Forest Polygons (perhaps based off the TSRE ruler) - just think of the possibilities - OMG. This Mixed Forest aspect - discussed here - seems like "low hanging fruit" from a development perspective - the process to seed texture files is already in place - without minimizing the effort - all we need to do is try to feed it a new source.
;)

Honestly - I don't think any environmental aspect of ORTS has been touched for a very long time. I see the "public domain" release of my 100,000,000 pixel "skydome" is in wide use - yet seeing the distortions from the ORTS shape kill me every time I see it.

Regards,
Scott

[Genma Saotome]

In a nutshell, OR programmers do whatever they want to do and there are very, very few of them. A number of them had no significant programming experience before joining the project and several of those toughed it out and made contributions. So it is possible... but obviously it is also beyond the ability of the vast majority of people interested in advancing OR. However slowly, it still rolls forward.

[darwins]

I like to think that OR is still in a long slow "initiation" phase. I have this wild dream that at some point it will reach a "chain reaction" stage where we will see a large increase in the number of developers and the topics that interest them. Okay perhaps it is a dream. Maybe we are in some incredibly slow decline and fall instead. http://www.elvastower.com/forums/public/style_emoticons/default/shock6.png

[Weter]

Who knows, mr.Smith... who knows.
Philosophists thought us, that quantity always turns to quality, some day...
I observ total railroad-sims rejection in my country now. ET only gives some hope.
Though, too few young hobbyists. It seems, many of us turned to watching gadgets, instead of at least virtually tweak things.
Build cubes in maincraft(in better outcome), instead tuning trains/building routes and models. Usually - following empty bloggers.
Sorry once again.

[scottb613]

darwins, on 19 November 2022 - 01:08 PM, said:

I like to think that OR is still in a long slow "initiation" phase. I have this wild dream that at some point it will reach a "chain reaction" stage where we will see a large increase in the number of developers and the topics that interest them. Okay perhaps it is a dream. Maybe we are in some incredibly slow decline and fall instead. http://www.elvastower.com/forums/public/style_emoticons/default/shock6.png

Hi Darwin,

Yeah - I’ve had the same dream. I realized early on what an opportunity ORTS offered to the train sim community - one that surely doesn’t come along very often. Removing all commercial obligations - could and should make all the difference. I’ve tried to champion the ORTS cause pretty early on - contribute where I could - but the numbers don’t look very good - at least from a North American perspective. There are so few of us producing any content and even the actual downloads have slowed to an absolute trickle. My very first - pretty crappy - steam locomotive was downloaded over 2000 times. My latest works - of a much higher caliber - are seeing maybe 150 to 200 total. While obviously not definitive - it’s certainly an indication of what we’re seeing in ORTS as a whole.

While most of us are more geared towards physics and operation - flash and visuals are what bring in new blood. You need to get them through the door. I’ve tried to push for improvements in both environment and visual aspects - along with anything that makes route building easier. Without a fairly consistent supply of new routes - we’re destined to die on the vine. As most are aware route building is not something to be undertaken lightly. I’ve watched how easy the Trainz guys have it and I’m certainly envious.

I’m still here - so obviously I have hope.
:)

Regards,
Scott

[Weter]

It's a quite significant 20-years long part of our lifes too.

[Csantucci]

Returning to forest enhancements: at the moment improvemens that require changes in TSRE5 can't be considered, because unfortunately the development of TSRE5 has stopped.
So, what can be considered are only improvements that require not too complex editing of text-like files (.w, .dat or json files).
I see two alternatives:
1) extending .w files only: in the Forest () blocks within the .w file there could be a reference to more than one .ace file with related parameters (population, size, scalerange). These additions could be inserted in an extension .w file to be located in the Openrails subfolder of the WORLD folder. This is a way of doing which is already used, and has the advantage that TSRE5 (or the MSTS RE) would see the original file and so there wouldn't be incompatibilities.
2) generating a new file type, which could be named something like ForestTypes, which would include a list of Forest types, each one listing .ace file present in that forest type and their related parameters. In this case the .w file would be modified (always with the method of the extension .w file) only by adding a reference to the forest type. This would be useful if there are more forests of the same type within a route.
I have two questions: would an addition like this be considered useful by route builders? Which of the above options is preferred ("I would like to have both options" is not an accepted sentence ;) ).

In addition to the above, I'm asking whether there is interest in having the possibility to define a forest composition not by .ace files, but by .s files.

[Weter]

Hello, Carlo.
What for me:
1.Yes
2.Second
3.Not clear

[scottb613]

Csantucci, on 20 November 2022 - 10:02 AM, said:

Returning to forest enhancements: at the moment improvemens that require changes in TSRE5 can't be considered, because unfortunately the development of TSRE5 has stopped.
So, what can be considered are only improvements that require not too complex editing of text-like files (.w, .dat or json files).
I see two alternatives:
1) extending .w files only: in the Forest () blocks within the .w file there could be a reference to more than one .ace file with related parameters (population, size, scalerange). These additions could be inserted in an extension .w file to be located in the Openrails subfolder of the WORLD folder. This is a way of doing which is already used, and has the advantage that TSRE5 (or the MSTS RE) would see the original file and so there wouldn't be incompatibilities.
2) generating a new file type, which could be named something like ForestTypes, which would include a list of Forest types, each one listing .ace file present in that forest type and their related parameters. In this case the .w file would be modified (always with the method of the extension .w file) only by adding a reference to the forest type. This would be useful if there are more forests of the same type within a route.
I have two questions: would an addition like this be considered useful by route builders? Which of the above options is preferred ("I would like to have both options" is not an accepted sentence ;) ).

In addition to the above, I'm asking whether there is interest in having the possibility to define a forest composition not by .ace files, but by .s files.

Hi Carlos,

Thanks for taking the time and interest.

Concur - what we are talking about here excludes any changes to TSRE.

My thoughts - we use a predefined naming syntax in TSRE to define the Forest Region and place Forest Regions as we always do - even if we need to use some place holder texture to work with TSRE. Then - using that named syntax - ORTS at runtime looks up another "ORTS Forest Region" file that defines the makeup of each Forest Region for a given route defining "Forest Reference Number", "Texture", "Size", "Density". The "Forest Reference Number" correlates to the named syntax used in TSRE. If we use the placement of the existing "Forest.dat" into the standard ORTS Directory within a route - we could even use the existing Forest.dat and just add to it making it ORTS specific.

For Example:

ORTS Forest Lookup

Forest 1 | Birch.dds | 10 to 20 Meters | 100 per whatever unit of measure
Forest 1 | Oak.dds | 15 to 23 Meters | 10 per whatever unit of measure
Forest 1 | Maple.dds | 12 to 19 Meters | 20 per whatever unit of measure

Forest 2 | Hemlock.dds | 9 to 12 Meters | 250 per whatever unit of measure
Forest 2 | Pine.dds | 15 to 23 Meters | 100 per whatever unit of measure
Forest 2 | Maple.dds | 12 to 17 Meters | 25 per whatever unit of measure 
Forest 2 | Ash.dds | 10 to 12 Meters | 35 per whatever unit of measure 

etc etc etc...

I've experimented - and - even slightly changing the coloration of the same texture file to a couple different variants - greatly enhances Forest Regions - making them seem less like exact clones.

I missed any conversation or reasoning - on why we left Cruciform Trees in Forest Regions to start with - as MSTS used Cruciform. In my humble opinion - Cruciform Trees are MUCH BETTER than Turn to Face the User Texture Only Trees. Was the issue performance related? I much prefer shapes to just textures.

Regards,
Scott

[eric from trainsim]

Are you suggesting with Option 1 that reading TreeTexture (ThisTree.ace) would be able to reference an array in a file defined in the OpenRails subdirectory and headed ThisTree.ace? If so, I'm good with that.

We do need to consider what TSRE will do with any extra attributes.... I did do some testing against my original idea, and TSRE definitely stripped out extra attributes. I'll keep looking to see what it might allow that's not normally part of a forest. I was able to add StaticDetailLevel and have it remain even if I moved the object. So... that may be another way to trigger using a list.


That has me leaning towards Option 1 -- which presumably would leave the existing Forest() structure and then ORTS seeing the OpenRails directory would have to swap out the processing (again that's I'm reading correctly).

To your last question, Carlos... I could see an argument for having shape files instead of textures. Shapes can throw shadows. I'm not sure cruciforms or rotating panes can do that. It would also be an easy way to populate city streets, parks, platforms with things like flat people or cars.