Elvas Tower: Forest Enrichment - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Forest Enrichment Rate Topic: -----

#1 User is offline   eric from trainsim 

  • Waste Disposal Engineer
  • Group: Private - Open Rails Developer
  • Posts: 1,572
  • Joined: 30-October 10
  • Gender:Male
  • Simulator:ORTS
  • Country:

Posted 07 November 2022 - 01:32 PM

Another a "how hard would it be" question....

The MSTS definition for a forest object only uses a single texture file, and then randomizes the size & placement of the cruciforms that get rendered.

How hard would it be to replace the value within the texture field to refer to a list or array containing multiple textures, each with a min/max size for each texture, and randomly add these into a single forest object?

There's already a structure for the forests.dat file that's recognized (not sure if ORTS uses it), which could easily be extended into a multi-select list:
Forest ( "SilverMapleM" "SilverMaple.ace" 25f 15f 0.5f 1.2f)
Forest ( "SilverMapleL" "SilverMaple.ace" 30f 19f 0.5f 1.2f)
Forest ( "weeds5" "weeds5.ace" 4.5f 4.5f 0.5f 1.3f )
Forest ( "weeds7" "weeds7.ace" 4.5f 4.5f 0.5f 1.3f )
Forest ( "weeds9" "weeds9.ace" 8.5f 8.5f 0.5f 1.3f )
Forest ( "Trackline-46" "MSTracklineVeg46-DG.ace" 2.50f 3.5f 0.9f 1.1f )
Forest ( "Trackline-48" "MSTracklineVeg48-LG.ace" 2.50f 3.5f 0.9f 1.1f )


My thought would be to re-use that structure as a separately named .DAT or JSON file which could be referred to in the .W object declaration for a forest:

	Forest (
		UiD ( 1 )
                TreeList ( MixedTrees.dat )
		TreeTexture ( silvermaple.ace )
		ScaleRange ( 0.5 1.2 )
		Area ( 200 450 )
		Population ( 360 )
		TreeSize ( 25 15 )
		StaticFlags ( 00000000 )
		Position ( -969.622 188.433 -443.505 )
		QDirection ( 0 -0.702966 0 0.711187 )
		VDbId ( 4294967295 )
	)


For backward compatibility... leave all the attributes in place for the current logic so that there's a default to render...

however...

If TreeList() is present with valid properties and can be read, randomly use the values from the DAT or JSON to seed what's being rendered.

Yes, I know TSRE doesn't support this. Those of us who create routes would need to manually hack their W files for this to be useful, but I think it's worth a little bit of extra hacking to avoid needing to overlay duplicate forest objects that often wind up planting multiple cruciforms in a similar seeding pattern that start to overlap each other.

Hope the idea is somewhat clear... happy to hear other options for creating dense, diverse forests.
Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users