Testing v8.005

[davebridges]

Excellent. Thank you so much. I couldn't get the link in that first post to work, I'll try the stable version.

[davebridges]

I got the link for the test version to work. I'll downlolad it to for future needs. Thank you again.

[jugondavidlisto]

Hello, I've noticed that when using Page Up or Page Down to raise or lower an object, the camera acts in the same way. This causes that, at certain times, you end up too high above the object, which makes it difficult to adjust the heights accurately.

I know that in version 0.7.012 this has never happened to me before. In the settings.txt file, I've tried enabling the same options as in the most recent version you uploaded, but I haven't managed to correct this behaviour.

[landnrailroader]

I haven't found any combination of the factors for cuts and fills that will produce a decent cut or fill. Usually the width is the main issue. Could we look into using a method like the old MSTS/RE for cuts and fills. This is why any unfinished routes I put out, will have no terrain adjusting done.

Jerry Sullivan

[eric]

Jerry, I think there may be a relationship to the brush size and intensity when using the F key.... With the brush size and intensity set to 1 / 1, I've seen some better results for cut/fill.

Going to how MSRE did it isn't practical, since nobody knows how that code actually worked.

[eric]

when using Page Up or Page Down to raise or lower an object, the camera acts in the same way.

That shouldn't be happening with an object selected. I'll look into that.

[scottb613]

I haven't found any combination of the factors for cuts and fills that will produce a decent cut or fill. Usually the width is the main issue. Could we look into using a method like the old MSTS/RE for cuts and fills. This is why any unfinished routes I put out, will have no terrain adjusting done.

Jerry Sullivan

Hi Jerry,

Yeah - ANYTHING to improve our terrain sculpting ability - would be GREATLY appreciated.

Regards,
Scott

[eric]

Hello, I've noticed that when using Page Up or Page Down to raise or lower an object, the camera acts in the same way. This causes that, at certain times, you end up too high above the object, which makes it difficult to adjust the heights accurately.

jugondavidlisto this is now fixed in 8.005r (available on the first page). Page Up/Down will only move the camera when an object is not currently selected.

[docmartin]

I have just installed 8.005r and note that the color of the arrows relating to signals have still not been disambiguated. I have posted before on this subject. Is there a problem with this?

[eric]

I've explained how the logic is working. Feel free to provide me with a signal and the related scripts/config files that it's not working for.

[docmartin]

I'm a bit confused here. This is our previous correspondence on this topic:

My initial post: "Eric, this latest version is a very helpful addition to TSRE. Just a couple of suggestions. At the moment the signal pointer shows red if either the signal does not need linking or if it does need linking but the links are not set or not correctly set. Can this be disambiguated? For example, the pointer for a signal not needing links could be orange, say. So the three cases (1) signal no link needed (2) signal link not yet or not correctly set (3) signal link correctly set will each have a different colored pointer - orange, red, green.
Also, although it is unlikely that anyone would mistake the green platform pointer for one of the new green linked signal pointers, for the sake of elegancy it would be good to have the platform markers a different color - maybe gray?"

Martin

Your reply:

"02-10-2025, 18:39
Good point about the platform markers -- I can find a different shade of green for the signals.

I'm already working to see if it's easy to compare the number of heads to the number linked. That should be what triggers green vs. red."

Bear in mind that I am talking about the color of the arrows on the tracks and not the outlining in the "Show List" window.

Martin

[eric]

I've done what I can with the information available in the signal object itself.

What's used to render the buttons on the linking form -isn't- available when the pointers are being rendered.

The Swiss signals you're referencing have what appear to extra heads or subobjects that aren't linkable, but may contribute towards the math (if signal heads enabled = signal heads linked then green else red).

Specifically, they have exit and entrance speed signs and other identifiers, which might be indistinguishable from a junction link in the rendering code.

[docmartin]

Eric,

Forgive my denseness but I don't really understand the technicalities of your reply. At the moment the situation is that (1) signals which need linkage and where the links are set up correctly have a green arrow pointer on the track. If, however, they are (2) signals needing linkage but the links are not set up or not set up correctly then they have a red arrow pointer on the track. But in the case of (3) signals not needing any linkage they also have a red arrow pointer on track. What I am asking is for a distinction to be made between cases (2) and (3). Ideally, this would be by making case (3) also show a green arrow pointer, though as you suggested yourself the green could be a different shade from the green in case (1).

Does you reply above mean that in fact what I would like cannot be done?

Martin

[eric]

Signals that can be detected as fully linked will be green.

Everything else will default to red (which was the case for all signals linked or unlinked prior to the enhancement for linked signals).

Your case #3 can't be determined for all signals. That's why what you're asking for can't be delivered at this time. If more attributes can be detected in the future, I might be able to deliver that.

[docmartin]

Thanks for your quick response. I understand.