[Lindsayts]

jjtang has put the following message up on Trainsim.com...........

"I have just committed a code which avoids placing trees on tracks. It involves testing every tree to see if it is close to a track

To use this feature, one has to turn it on in Menu->Option->Simulation.

I tested it on Bernina pass, a route heavy with forest, without noticeable impact on performance. It did successfully avoid the big tree placed on the track in front of the St. Moritz tunnel."


This is great news, I may say. I am a heavy user of the Adelaide hills route, which is plagued by this problem. I was wondering if simply testing each tree to see if was near a line would work.

[cjakeman]

Lindsayts, on 11 March 2013 - 12:54 PM, said:

I tested it on Bernina pass, a route heavy with forest, without noticeable impact on performance. It did successfully avoid the big tree placed on the track in front of the St. Moritz tunnel."

I don't know anything about placing trees, but can't help wondering if this procedure could be packaged as an independent utility to produce modified content rather than being employed at run time. It would avoid complicating the core code.

Maybe that's Jijun's intention in the long run?

Just a thought,

[thegrindre]

My thoughts are that it does need to be placed in the code just as MSTS does it.

:sign_oops:

:oldstry:

[cjakeman]

cjakeman, on 11 March 2013 - 01:19 PM, said:

I don't know anything about placing trees, but can't help wondering if this procedure could be packaged as an independent utility to produce modified content rather than being employed at run time. It would avoid complicating the core code.

Was a bit hasty there.

I've looked at the code now and see that trees are positioned at random within an area. If the area specified spills over onto the track then Jijun's run-time solution is a perfectly reasonable approach. Could perhaps add a (single) warning message for the log file, so the model builder knows that the area spilled onto the track.

[eric from trainsim]

Copying over my response and part of someone else's from the TS thread... happy to hear some comments from the guys here...

Someone else said

Quote

If so, don't push them too far back from the edge of the ballast because it may also affect shrubbery. Nothing looks more un-lifelike than a pristine, straight-edged run of track through a forested or wooded area, particularly if it is an industrial shortline.

I agree with that, especially where weeds or grass are deliberately used to span tracks in a yard or along an lightly used or abandoned branch.

It would be ideal if there were the ability to add an object level permission/setting for this, and set a buffer distance from the track, but MSTS has been known to blow up when it encounters properties it can't process, and the RE happily deletes out any extended properties it doesn't know about.

That said, there may still be a way to not blow up MSTS and still allow OR to apply some different processing:

1) use of a texture naming convention (e.g. nnnnnnnnn_nospill.ace would trigger "no trees on track"
2) checking the static detail level (i.e. zero and all even-numbered = ignore track, odd-numbered = avoid track so that there's an equal number of levels available?)

JJ, will this be in an experimental release anytime soon? I'm happy to do some testing on it.

[Lindsayts]

cjakeman, on 11 March 2013 - 01:19 PM, said:

I don't know anything about placing trees, but can't help wondering if this procedure could be packaged as an independent utility to produce modified content rather than being employed at run time. It would avoid complicating the core code.

Maybe that's Jijun's intention in the long run?

Just a thought,

The problem in tree placement is the vast number of trees in some routes or some cases the route is so large that a forest tool is the only way one can complete the item. A single person simply cannot individual place hundreds of thousands of objects. Its likely a random placement tool in a prescribed area would have more uses than just a forest (shrubs, grass's, rocks). In reality in my opinion anyway this is a function of the route editor, the sim itself should not generate positions of fixed objects under most circumstances.

The current situation is likely just a response to fix the immediate problem of trees on the track. As you say though the forest tool to randomly place trees would be better to be an intependent utility to generate the number of positions of trees required to be used in the route as required. This would remove some code from the sim and make a more managable situation in regards to tree placement.

Lindsay

[James Ross]

Lindsayts, on 11 March 2013 - 12:54 PM, said:

This is great news, I may say. I am a heavy user of the Adelaide hills route, which is plagued by this problem. I was wondering if simply testing each tree to see if was near a line would work.

I'm against this feature, not least because we have no evidence MSTS does it nor any control over the distances it "keeps clear".

We're also supposed to be in a bug-fixing phase and jtang is repeatedly adding new features without any consent. :sign_oops:

[Lindsayts]

eolesen, on 11 March 2013 - 01:56 PM, said:

Copying over my response and part of someone else's from the TS thread... happy to hear some comments from the guys here...

Someone else said

I agree with that, especially where weeds or grass are deliberately used to span tracks in a yard or along an lightly used or abandoned branch.

It would be ideal if there were the ability to add an object level permission/setting for this, and set a buffer distance from the track, but MSTS has been known to blow up when it encounters properties it can't process, and the RE happily deletes out any extended properties it doesn't know about.

In the long run with an OR route editor one end solution of a random tool placing objects on the track is to adopt the realife approach, ie use the random tool in the editor to place all objects over an area, and simply remove any on or near the track as appropriate. This would make the task far simpler while allowing a good amount of user control, such user coontrol in the end being critcal to a route that looks real world.

Lindsay

[Lindsayts]

James Ross, on 11 March 2013 - 02:07 PM, said:

I'm against this feature, not least because we have no evidence MSTS does it nor any control over the distances it "keeps clear".

We're also supposed to be in a bug-fixing phase and jtang is repeatedly adding new features without any consent. :sign_oops:

In any open development projects (or infact any thing using volunteers) in the end one must take the good with the bad UNLESS the the interfernce is distructive. If one blows up everytime a volunteers does something wrong one will soon have no volunteers. If one openly attacks the volunteers the attack WILL be remembered no matter what one latter does.

An example of this in a large volunteer group I worked in with members numbering in the hundreds a single thoughtless memo from one of the managerment resulted in the loss of over a third of the active membership most of whom never returned. In this episode I am the only member out of the 250 that asked the management for an explanation. It was one of the directors of this organisation that told me they lost 80 members they could ill afford to lose.

My own take on this situation is the solution lies in the long run. While trees on the track in the current versions is the result of a differnt approach in the random generator and therefore not really a bug. To a user its a __REAL__ glaring bug that sticks out miles.

Lindsay

[eric from trainsim]

I get the frustration with scope creep, but there are some very real, tangible benefits that this "what if" attempt by Jinan can provide.

The only problem with avoiding addressing this now and just waiting for an editor is that it does nothing for the body of work that already exists.

Just guessing, but MSTS's logic seems to take into account the width of the cruciform when plotting the objects. I couldn't figure out from forests.cs if the width is figured in when looking at the plot area, or if it's just looking at the axis' coordinates.

I know I've been somewhat outspoken on trying to improve forest logic both here and over on TS, and it's because I've got 200+ miles of mainline in northern Wisconsin and Michigan which will require on average of 60 forest objects per tile. Trying to get the same effect with individual clumps and tree lines would add literally a year of work. I suspect it's also why there are so many desert Southwest routes...


If I could ignore leaving a path for the track, that would reduce it down to probably 20 or 30 objects per tile, a huge decrease in loading and increase in performance. It would also reduce my workload by a couple of man-months, and more or less force users of my routes into using MSTS.

I'm ready to cut the strings as quick as I can, and I know some other route builders and modelers are as well.