[Jovet]

I may be a bit late to suggest these, as I know a new release of OR is looming, but I'd like to see if these suggestions/fixes can be agreed upon and incorporated into the new version. Two of them are cosmetic and presumably simple, and the other two are more than just cosmetic.

The cosmetic suggestions have to do with the Track Monitor.

1. Since the Track Monitor shows all signals in range, the nearer signals are occluded by the further ones (at least in the forward direction, I don't know about reverse):

http://msts.jovet.net/files/images/ORSignalOrder.png

There are 4 signals shown here, and they're very close together. The first one is Clear, the second one is Caution, and the other two are Stop. Note that the balls/icons for the further signals cover the nearer ones. Since OR does not show the actual name of the nearest signal indication, it's not possible to tell what it is on the Track Monitor if signals are close together and its icon is partially obscured. The nearer ones should cover the further ones. Can this be corrected?

2. With the helpful addition of mileposts showing in the Track Monitor, a few complications have arisen. One is that OR goes out of its way to display all mileposts and speed posts, even when they are redundant:

http://msts.jovet.net/files/images/ORMilesDupe.png

This route has mileposts on each side of the double track mainline, which causes double TDB entries to record them. The MSTS Track Monitor shows both mileposts at each location also, but it overlays the digits on top of one another so you can't even tell there are two mileposts there. OR makes the great improvement of ensuring that mileposts and speedposts close together remain legible on the Track Monitor. But here, with the mile values the same, the extra ones become redundant. The same thing happens with speedposts, too. I think these extra mileposts/speedposts of identical value should simply be hidden, only the first one encountered being visible on the Track Monitor. All duplicate values should be hidden until the next value is encountered as you "look" down the track.

3. This is just an idea I'd like to hear some feedback on: MSTS shows mileposts on the Track Monitor with white text and speedposts with yellow text. This makes it easy to tell them apart at a glance. I would not mind seeing this in OR, despite the fact that they are shown in different places on the Track Monitor. This could even be expanded to color increase in speed limits one color (e.g. green) and decreases in speed limit another color (e.g. yellow). Thoughts?

And now a few deeper problems/suggestions...

4. This bug. It'd be nice to get it sorted out. It's strange and persistent for me, but the manual alteration of the Time field text also always fixes it, such as adding a 0 and backspacing it out. It seems something somewhere gets updated when the time field text is changed, and for some reason that is being wiped out under the hood when I change the Route selection.

5. I've observed a signaling/pathing bug which causes a signal to constantly oscillate indications, even when the game is Paused. I will start a new thread for this and post a test route to demonstrate the problem soon. Edit: A thread for this is here.

[thegrindre]

I see no reason not to make these 'balls' smaller as well.

http://www.elvastower.com/forums/public/style_emoticons/default/oldstry.gif

[Genma Saotome]

IMO, as Rick suggested the icon for the aspect can be made smallest and that brings an issue to mind: Many signals, especially older signals, used position as the aspect. One such example was the PRR who, IIRC, used a circular array of lights which allowed for three possible rotational positions -- 0d, 45d, and 90d. Waaaay back in time it was a ball, raised or lowered.

Q: Is there a legitimate need to accommodate any of those (arcane) methods of presenting the aspect?

[Jovet]

thegrindre, on 08 January 2017 - 12:33 PM, said:

I see no reason not to make these 'balls' smaller as well.

I hadn't really thought about that, I've never had cause to complain about their size.... just the order they're drawn in. But it's a thought.

Genma Saotome, on 08 January 2017 - 02:57 PM, said:

Q: Is there a legitimate need to accommodate any of those (arcane) methods of presenting the aspect?

I do not believe so. The "balls" are intended to reflect American cab signal aspects, so no matter the signals used out in the field, aspects like shown on the Track Monitor would be seen in the cab. (Though, as pointed out by others, usually it would be the indication you had just passed that would be shown, not the indication of the next signal to be encountered.)

[conductorchris]

Yes. The coming Conn River line has ball signals which were in service in 1956. They've been modeled static.
Christopher

[roeter]

Jovet, on 08 January 2017 - 04:17 PM, said:

(Though, as pointed out by others, usually it would be the indication you had just passed that would be shown, not the indication of the next signal to be encountered.)

And, as even more usual, that "usually" as mentioned above is restricted to where one lives. Here in Europe, many cab-signallig systems do show the aspect of the signal one is approaching, not the signal just passed. In locations where signals are close together, the aspect shown even changes to the aspect of the signal beyond the one which is being approached, which is indicated by special lineside indicators "cabiew code change". A more complicated difference between cabview systems is whether they work continously (as the Dutch "Automatic Train Control") or based on specific transpoders in fixed locations (as the British AWS and German Indusi). Using the latter systems, the cabview shows the state of the signal when the transponder is passed, but the aspect shown in the cab does not change if the signal changes. So, to correctly implement cabviews, we're looking at at least three or four different systems.

Regards,
Rob Roeterdink

[James Ross]

Jovet, on 08 January 2017 - 07:57 AM, said:

1. Since the Track Monitor shows all signals in range, the nearer signals are occluded by the further ones (at least in the forward direction, I don't know about reverse):

Yeah, we should at least flip the rendering order. They could also be stacked, so further-away signals are pushed upwards until they're clear of the closer ones, like we do for the text objects.

Jovet, on 08 January 2017 - 07:57 AM, said:

2. With the helpful addition of mileposts showing in the Track Monitor, a few complications have arisen. One is that OR goes out of its way to display all mileposts and speed posts, even when they are redundant:

That seems like a slightly unusual case, but pretty easy to fix for mileposts. Speed posts I am not sure if we should just compare number or also distance, i.e. two of the same speed post 1km apart - should the second one be supressed until you've passed the first?

Jovet, on 08 January 2017 - 07:57 AM, said:

3. This is just an idea I'd like to hear some feedback on: MSTS shows mileposts on the Track Monitor with white text and speedposts with yellow text. This makes it easy to tell them apart at a glance. I would not mind seeing this in OR, despite the fact that they are shown in different places on the Track Monitor. This could even be expanded to color increase in speed limits one color (e.g. green) and decreases in speed limit another color (e.g. yellow). Thoughts?

Possibly. I believe temporary speed restrictions do already use red & green for their speed posts, so maybe make all the fixed speed posts yellow.

Jovet, on 08 January 2017 - 07:57 AM, said:

4. This bug. It'd be nice to get it sorted out. It's strange and persistent for me, but the manual alteration of the Time field text also always fixes it, such as adding a 0 and backspacing it out. It seems something somewhere gets updated when the time field text is changed, and for some reason that is being wiped out under the hood when I change the Route selection.

I haven't yet reproduced the issue. :(

Jovet, on 08 January 2017 - 07:57 AM, said:

5. I've observed a signaling/pathing bug which causes a signal to constantly oscillate indications, even when the game is Paused. I will start a new thread for this and post a test route to demonstrate the problem soon.

The signalling code runs in steps, updating only some items each time, so although weird, changing when paused is not completely unexpected. Oscillating indications, though, is indicative of a more serious problem though. :)

[Jovet]

roeter, on 09 January 2017 - 01:20 AM, said:

And, as even more usual, that "usually" as mentioned above is restricted to where one lives. Here in Europe, many cab-signallig systems do show the aspect of the signal one is approaching, not the signal just passed.

The word "many" isn't any better, Rob. I agree it is a complicated issue but it isn't something I was suggesting be changed at this time...it was more a cheeky remark about how some are never happy. I do think the MSTS implementation of knowing the next signal indication is best for laymen driving virtual trains around, though. I will not pretend to know all of the permutations of cab signaling implementations since I am only strongly familiar with about a dozen signaling systems/practices worldwide, which is hardly exhaustive.

James Ross, on 09 January 2017 - 12:28 PM, said:

Yeah, we should at least flip the rendering order. They could also be stacked, so further-away signals are pushed upwards until they're clear of the closer ones, like we do for the text objects.

Thanks. I actually do not mind them overlapping, because the subsequent signals don't really matter until the imminent signal is accepted, and once it's accepted then the next "ball" becomes fully visible. Though if a signal is the cause of the speed limit, probably its ball should stick with the speed digits (and maybe a different color for them?) But it's up to you.

James Ross, on 09 January 2017 - 12:28 PM, said:

That seems like a slightly unusual case, but pretty easy to fix for mileposts. Speed posts I am not sure if we should just compare number or also distance, i.e. two of the same speed post 1km apart - should the second one be supressed until you've passed the first?

If the speed limit doesn't change from the one before it, I don't see why it should be indicated at all on the Track Monitor. (Same for mileposts.) Or maybe no change in speed limit should be white and a change in speed limit be yellow... but then you go right back 'round to the yellow/green idea I had above...

James Ross, on 09 January 2017 - 12:28 PM, said:

Possibly. I believe temporary speed restrictions do already use red & green for their speed posts, so maybe make all the fixed speed posts yellow.

Thanks. That does ring a bell, now that you mention it.
None of the Track Monitor window is scriptable like MSTS's is, correct?

James Ross, on 09 January 2017 - 12:28 PM, said:

I haven't yet reproduced the issue.

Having looked at the code a while back, it doesn't seem terribly complicated, and I didn't spot evidence of some mystery secondary time-value variable that gets updated upon change to the Time text, but I do not speak C# fluently so I may be ignorant. I am open to suggestions and superior experience on trying to figure out what is going on. So if there's anything I can do or check or test, let me know. I even wondered if it's some locale setting that would make my system different to the CLR but I don't see any unusual settings.

James Ross, on 09 January 2017 - 12:28 PM, said:

The signalling code runs in steps, updating only some items each time, so although weird, changing when paused is not completely unexpected. Oscillating indications, though, is indicative of a more serious problem though.

Hah! In my world, Pause means paused! e.g. All activity stops. Maybe the text should be changed from "Pause Menu" to "Mostly-Paused Menu" :lol2:
(On a serious note, I have accidentally tried to click "Quit Open Rails" in the middle of an activity, caught myself, and tried to drag the mouse off of the "button" to get it to ignore my click... but unfortunately that just drags the Pause Menu around with the mouse, though adding the right button threw it off enough, luckily.)

The oscillation problem I've observed rarely for some time but I seem to be seeing it more and more of late.

[Jovet]

A thread to discuss the signal oscillation problem and provide a test route to easily reproduce it is here.

[SP 0-6-0]

Oscillating indications, though, is indicative of a more serious problem though.

Like Crossed Wires. :ermm:

Reminds me of what caused the Clapham Junction accident of 1988.

Robert