Forest Enrichment Enhancing Forest Region Definition
#1
Posted 16 November 2015 - 05:47 PM
Forest ( "MSMajesticOak36A_01" "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f )
What would be great is to define a Forest region as follows:
Forest ( "Diversified NE Forest" "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f 60; "usdecidtree1.ace" 16.0f 18.0f 0.9f 1.1f 30; "US2autofir1.ace" 12.0f 22.0f 0.9f 1.1f 10 )
so the forest would be populated with 60% Oak; 30% USdecid and 10% fir trees
Comments?
chris
#2
Posted 17 November 2015 - 01:15 AM
One way to do this is to follow the same path as for the signal definition files. The program could search for a 'forest.dat' file in the OpenRails subdirectory in the route's main directory, and use this more extended definition if it finds it. This would allow the route still to be opened in MSTS, which is required for using the route editor.
Regards,
Rob Roeterdink
#3
Posted 17 November 2015 - 02:01 AM
roeter, on 17 November 2015 - 01:15 AM, said:
Or an UV mapping support, so a single texture can contain multiple tree textures, to save draw calls.
But the best would be a full 3D shape forest support, with viewer facing materials. But i didn't see svn commits about the graphics, since long time.
#4
Posted 17 November 2015 - 07:13 AM
longiron, on 16 November 2015 - 05:47 PM, said:
Forest ( "Diversified NE Forest" "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f 60; "usdecidtree1.ace" 16.0f 18.0f 0.9f 1.1f 30; "US2autofir1.ace" 12.0f 22.0f 0.9f 1.1f 10 )
so the forest would be populated with 60% Oak; 30% USdecid and 10% fir trees
This is a unique syntax (the semicolons) so I'd like to avoid that, but the idea is principally sound - and has come up a few times before, IIRC. Same goes for the suggestion from disc to use shape files.
If adding new parameters after the existing ones works in MSTS, we don't need to support forests.dat in an OpenRails subdirectory, but I would support doing so as a means of separating content. I'd start with the above example but without the semicolons.
#5
Posted 17 November 2015 - 07:41 AM
Quote
What about using 'proper' stf rules?
The above example would then become :
Forest ( "Diversified NE Forest" ( 3 Forest ( "MSMajesticOak36A.ace" 41.0f 30.0f 0.9f 1.1f 60) Forest ( "usdecidtree1.ace" 16.0f 18.0f 0.9f 1.1f 30) Forest ( "US2autofir1.ace" 12.0f 22.0f 0.9f 1.1f 10 ) ) )
MSTS would not be able to read that, but that's no problem if we use the OpenRail subdirectory.
Regards,
Rob Roeterdink
#6
Posted 17 November 2015 - 08:02 AM
#7
Posted 17 November 2015 - 09:47 AM
Can we also try the same named set idea for car spawners, with an override to use a named set (vs the default) so that my side streets can have small cars, my country roads can have tractors, and my highways can have cars, trucks and buses?...
#8
Posted 17 November 2015 - 10:51 AM
{ "Diversified NE Forest" : { { Shape : "Oak.s", Textures : ["MSMajesticOak36A.ace"], ScaleRange : [0.9, 1.1], Probability : 60, }, { Textures : ["usdecidtree1.ace", "usdecidtree2.ace", "usdecidtree3.ace"], Size : [16, 18], ScaleRange : [0.9, 1.1], Probability : 30, }, { Textures : ["US2autofir1.ace"], Size : [12, 22], ScaleRange : [0.9, 1.1], Probability : 10, }, }, "etc..." : { { ... ... }, }, }
;) This format can be extended by any number of additional keywords to fulfill all ideas.
#9
Posted 17 November 2015 - 12:18 PM
I think the most straight forward solution is simply have a side-by-side file in the \world directory that has a different suffix. For discussion purposes lets call it .ORW (or .WOR, it doesn't matter). Put the new forest definition there. Change the loader so it looks for both file types and read the second one when found, appending it's data content to what the other paired file contained. For OR itself it would appear as it all came from one file.
As other ideas for object placement get approved, add those to the .ORW/.WOR file. When there is an Open Rails editor, flip the responsibility for which file is primary (IOW the .w file is left over to hold whatever the OR editor cannot yet handle). This effective makes the .ORW file the go-forward file so an initial decision on json/kuju/xml/anything else format is required.
Once again I'll express my opinion that people need (at least) two directory trees: One that is pure MSTS (and will always stay that way) and a copy of that for OR (e.g., it uses include files, it has OR specific parameters in the .eng and .wag files, etc.) that allows file content to be altered in ways that would be incompatible with MSTS.
FWIW, I used to think the best answer was to add OR specific stuff to the existing .w file but to place it after the final MSTS paranthesis. I'm no long enthused about that idea for fear that when RE writes to a .w it will ignore/drop the OR appended specifications.
#10
Posted 17 November 2015 - 01:36 PM
Genma Saotome, on 17 November 2015 - 12:18 PM, said:
Yes and no... I think it reads in what it can, and then over-writes the bad entry with something the RE can handle.