Clearing Trees from tracks in OR - new_needs testing

[Don6218]

Ok, completed the trip back and NO TREES!! on the tracks!!

This works exactly as it should, it took two trips but it was worth it! No more trees blocking the train path.

Kudos to the people responsible for this, it is a great advance with OR and very simple to use. On the FRC Route it worked exactly as described and extremely simple to install.

Thank You.

[poochwilly]

I do as well like this route.Is it possible to show us fellow simmer's an example of how this gets placed in order to work,not sure if I did right as I yet to have to go from one end of it to the other to see if tree's are still in the way. Any help would be greatly appreciated.

Thanks again Poochwilly

[hminky]

This explains how:

http://msts-roundhouse.vnxglobal.com...-in-open-rails

Is easy and it works.

Harold

[poochwilly]

Edit the new (blank) file to add the following:

include ( ../<Route_Name>.trk )

ORTSUserPreferenceForestClearDistance ( 2 )

Where exactly does this go? Thanks
A picture for an example for the not super computer smart people

[R. Steele]

Where exactly does this go? Thanks
A picture for an example for the not super computer smart people

Into an OpenRails folder placed within the desired route folder -- see pictures

bandicam 2016-01-15 00-54-28-118.jpg bandicam 2016-01-15 00-54-32-782.jpg bandicam 2016-01-15 00-58-50-678.jpg

[OTTODAD]

Hi Peter !

Please check my post #16, reporting that I have added Carlo's fix to the actual *.TRK file of the route and it worked, moving all but a few trees, leaving other assets untouched !

Where did your way of doing it come from ?

[R. Steele]

Hi Peter !

Please check my post #16, reporting that I have added Carlo's fix to the actual *.TRK file of the route and it worked, moving all but a few trees, leaving other assets untouched !

Where did your way of doing it come from ?

Otto, the OR developers started the process by using the routes trk file, then later they decided it was preferable to use the "include" function in Open Rails.

See post #38 by Baldwin, user preference. Ignore following - that's the way it was finally coded, and the proper way to implement the tree clearing algorithm.

It would be a good idea for OR users to become familiar with the "include" function in OR, it will expand the possibilities of OR and can be used in many other ways.
All explained in the thread at Elvas. Erics Website "The MSTS Roundhouse" is one of the places these instructions have been posted.

http://msts-roundhouse.vnxglobal.com/tutorials/clearing-trees-on-tracks-in-open-rails

[baldwin]

It works using either method. User preference rules. However, having an OpenRails sub folder in the route folder structure does make things easy to include as they get developed. It matters not to MSTS either as what it is not coded to read, it skips over.

[EricF]

What the OR developers discovered with editing the route's own .TRK file is that if you ever open the route in the MSTS RE and make changes, the .TRK will be updated by the RE upon saving, and in the process the Open Rails includes will be erased from the file.

The separate file method safeguards the OR includes from being affected by the MSTS editor.

Both methods work, but using the separate OR-specific directory and file helps to make sure your changes will "stick."

[hminky]

Lot faster with the separate folder, just copy it into another route and change the nomenclature.

Harold

[R. Steele]

What the OR developers discovered with editing the route's own .TRK file is that if you ever open the route in the MSTS RE and make changes, the .TRK will be updated by the RE upon saving, and in the process the Open Rails includes will be erased from the file.

The separate file method safeguards the OR includes from being affected by the MSTS editor.

Both methods work, but using the separate OR-specific directory and file helps to make sure your changes will "stick."

Thanks Eric, I knew there was a good reason the OR developers coded it to use the include function. Thanks for bringing that point up.

[OTTODAD]

What the OR developers discovered with editing the route's own .TRK file is that if you ever open the route in the MSTS RE and make changes, the .TRK will be updated by the RE upon saving, and in the process the Open Rails includes will be erased from the file.

That puzzled me !

Why should changes made in the MSTS Route Editor affect the contents of the route's *.TRK file, not storing any data affected by changes made in the Route Editor ?

So I put it to the test and moved a building in the Dorset route and saved it.

No changes were saved into its *.TRK file and the ORTS Trees Fix is still there.

[EricF]

The RE's ways can be mysterious...

I suspect the problem may not be with minor changes. But at some point, if the .TRK file is validated or "normalized", the RE may be clearing out anything "extraneous." Apparently, using the "Properties" menu in the RE tends to do this.

Putting "includes" in a separate folder for Open Rails use might seem like an extra complication, but it does have the advantage of creating a structure for OR improvements that is de-coupled from MSTS. Fewer restrictions pushed down from the MSTS order of things. Open Rails will either load the route according to the MSTS format in the presence of nothing else, or it will recognize its own discrete extensions and overlay them. The goal, I believe, is less co-mingling with MSTS' own established files and instead adding a clean structure for OR-specific features.

[poochwilly]

Thanks all in this wonderful sim community, I'll give it a go with WP3 on the weekend.

Thanks Poochwilly

[R. Steele]

The RE's ways can be mysterious...

I suspect the problem may not be with minor changes. But at some point, if the .TRK file is validated or "normalized", the RE may be clearing out anything "extraneous." Apparently, using the "Properties" menu in the RE tends to do this.

Putting "includes" in a separate folder for Open Rails use might seem like an extra complication, but it does have the advantage of creating a structure for OR improvements that is de-coupled from MSTS. Fewer restrictions pushed down from the MSTS order of things. Open Rails will either load the route according to the MSTS format in the presence of nothing else, or it will recognize its own discrete extensions and overlay them. The goal, I believe, is less co-mingling with MSTS' own established files and instead adding a clean structure for OR-specific features.

Concur. Same wiping out of OR Data happens with the CabView when the Cab Editor erases all traces of the ORTSfont line, maybe there is a way to use that in the include file.