[landnrailroader]

Colleagues,

In readying the Milwaukee Road, Coast Division, 2nd Sub. for distribution, my helpers and I have
come across a problem as follows.

when a forest object, in this case pine trees, is set up to produce trees sufficiently far off the
right of way in MSTS, those same objects are rendered much larger and too close to the track in
ORTS. The route, because of it's complexity is going to be a ORTS only route, so is this a known
issue, is it going to be fixed, or-----??

J. H. Sullivan
(landnrailroader)

[ebnertra000]

I'm a long way from home right now, but there should be a line that can be entered into the route's .trk file that forces forest objects to keep a certain distance from the tracks. For specifics you'll have to check the OR manual

[landnrailroader]

Ebner,

I'm sorry, but I do not see any mention in the manual about the .trk file
although it seems reasonable that something might be there. There is a
terrain error which is set to "1" but I believe that is the default value.

There are two issues. One is that the forest object nearest to the track
is out about 10 meters in RE, or MSTS but renders right on the right of way
and twice as large in physical size in ORTS. I would suspect that some
factor in ORTS affects this and the value in effect magnifys size by at
least 2, and also makes the physical dimensions of the forest object,
i.e. the red bordered block, abouit 2x in size also.

Jerry Sullivan

[R H Steele]

Chapter 15 - OR-Specific Route Features

Quote

15.1 Modifications to .trk Files
Many of the features described in this chapter require additional parameters to be added in the route’s
.trk file. The additional parameters can be directly added at the end (just above the last parenthesis) of the
route’s .trk file residing in the route’s root folder. Don’t add such parameters in other positions of the file,
because this would create problems if you want to use the MSTS editors with the related route. However,
to avoid modifying the original file, the Include method described here is also applicable to the .trk file,
creating a new .trk file inserted into an OpenRails folder in the root folder of the route. As an example, in
case of the parameter needed to avoid forest trees on tracks ( see here), this additional .trk file will contain:
include ( ../Surfliner2.trk )
ORTSUserPreferenceForestClearDistance ( 2 )
Only OR will look in the Openrails folder.

here's the trk file for the WP3

include ( "..\\wp3.trk" )

	ORTSUserPreferenceForestClearDistance ( 2 )
	ORTSSwitchSMSNumber ( 10 )
	ORTSCurveSMSNumber ( 11 )
 	ORTSCurveSwitchSMSNumber ( 12 )

Important...first line in the include file is always a blank space line, preceding the include name path string

[landnrailroader]

Thanks for the information. Having been a CAD system manager for 21 year
while working for CSX, these things bug me a lot, so I could not sleep last
night until I went back, found the reference, and piddled with it. One
thing that was not mentioned is that the file in question must be a unicode
text file and once I realized that, I got it things working easily and
retired to almost instant sleep.

Now one other thing remains that is of less importance and that is that
forest objects are still rendered about twice the size of when they are
rendered in MSTS.

My experience in the real railroad world was that usually trees and such
were not closer than 15' to the near rail on main tracks, so I used a
factor of 5 for the adjustment assuming that ORTS measurement was from
the center line.

J. H. Sullivan

[James Ross]

landnrailroader, on 15 September 2018 - 02:51 PM, said:

when a forest object, in this case pine trees, is set up to produce trees sufficiently far off the
right of way in MSTS, those same objects are rendered much larger and too close to the track in
ORTS. The route, because of it's complexity is going to be a ORTS only route, so is this a known
issue, is it going to be fixed, or-----??

Hmm, there should not be any doubling of size for the forest area itself or items within it, and I don't think anyone else has noticed such a thing, which is curious.

The forest item scaling is very simple (just multiplying the width/height from the world file with a number between the minimum and maximum scale ranges in the world file), so perhaps you could drop us one of the world files containing a misbehaving forest so someone can take a look? Screenshots in OR and MSTS would be helpful as well.

An additional problem may be that we place items (their centre points) right up to the ehde of the forest area, where as IIRC MSTS keeps them a little way from the edge.

If we can identify a concrete error in the way forests work compared to MSTS, we'll fix it, but sometimes it takes many hours of experimenting in MSTS to figure out why it isn't working the same.