Developer Fails of the day

[AndiS]

There is rule 39 stating that if the next signal in the same box is closed, then the train must come to a near halt before the signal is cleared.

And there is rule 5 (warning arrangement) stating that if the overlap beyond the home signal at the next box is not cleared, then the train must come to a full stop at the box in rear (or the starter there) and the driver be informed about the fact. For RW purposes, I left it at the full stop at the starter since you cannot trigger messages boxes in signal scripts.

Now if the overlap beyond the starter is not clear (which is a rare case) and a train approaches the home signal of that box, should we demand a full or a near stop? I opted for the full halt, but later forgot that I did.

Then during testing, I piped a bunch of AI trains through the station like I always do. And of course, these test layouts are always condensed to reduce travel time in order to reduce testing time. So a train ended up within the 400 m mark beyond a starter and another was brought to a near halt at the starter, but that one would not clear. I searched my scripts far and wide to find that bug, until I found it was a feature. My bad not to bring that train to a full stop.

Lesson learnt was to remove the feature and perform rule 39 even if the overlap beyond the next signal is occupied. If I don't read my own documentation often enough to remember all the tiny bits, who will?


Two fun facts about RW that are not exactly my fault but caused their share of wasted time nonetheless.

1) I knew that AI 'jerks' when passing signal links, that means that speed is reduced for split seconds in a insane way. I did not know that reverse movements occur as part of such episodes. Until I tested signals that clear automatically for unexpected trains (but not for trains in the reverse direction, like Kuju did). Only when you do that on a single line and on a dense layout, you will find single time slices (i.e., single calls to OnConstistPassed) where a train that is supposed to do 20 mph moves up to 35 mm into the opposite direction.

It resulted in randomly clearing signals for no apparent reason, which only happened if the insane jerking occurred in the monitoring zone of 200 m or so, near the signal. However, the jerking is nearly as fixed as all AI movements, so once it happens, it will happen in the majority of test runs, leaving you to wander what the hell of a bug you introduced into this specific signal that clears with absolutely no reason.


2) I knew that the AI dispatcher changes the switch for the next train as soon as the numbered link is cleared by the first train. I was not aware of the fact that the JUNCTION_STATE_CHANGE message is sometimes sent out to signals (by calling their OnSignalMessage function) before the OnConsistPass functions of all signals are called for the same time step.

So what happens is that for time step X, the dispatcher sees that the link is clear and starts changing the switch. This causes messages sent out to the signals concerned. After these messages are digested by these signals, the game calls OnConsistPass for all signals near, still at the same internal time X.

The naive view of the signal is first that the switches are changed while the train is still on them and then (some milliseconds later in real time, at the same time step in simulation time) that a disconnected link was cleared (which is more or less ignored in the normal case).

The funny thing is that this issue does not occur in many cases as the dispatcher waits five seconds before setting the path for another train, for the same direction. But for the return of the same train via the other track it did not wait in my case. Again I have seen it before that the dispatcher changes switches insanely early. But changing it before giving notice that the link is cleared was a first for me.


In both cases, yet another state variable to monitor what the game is about to do overcomes the problem.

[DominusEdwardius]

Oh dear, absolute facepalm. Was testing out a driver anim fix for my current animated wheels, originally the problem being that at low FPS the anim jerks occasionally and isn't smooth. So I try several fixes by driving an austerity forward a few 100m up Mardy incline and a low FPS ( around 15 ) and observe any jerkiness. I finally come up with a promising solution which seemed to completely removed the Jerkiness going forward, but to test it more thoroughly I decided to switch austerities to another one in a empty siding to allow me to get some speed up going downhill. Promptly get into it and take off and... the anim was still jerky, completely stumped as to why it wasn't working I questioned Chris. It then suddenly dawned on me, the austerity I had used to do the high speed test was the standard one.... I had done the scripting on the advanced one both having separate scripts Go back into the game and swap the austerity around and wouldn't you know worked almost flawlessly.... Silly me!

regards
Edward

[BigVern]

Hitting the terrain smooth button in MSTS but accidentally having the value set at 4 degrees not 40. Ooops, where did my hills go..?

The ¬ key to undo last terrain change only works about 50% of the time these days and this was sadly one of the really needed occasions when it didn't. Retreat into Demex after identifying the affected tiles and re-apply terrain, with note to self - pay more attention in future!

[TrabantDeLuxe]

Here's a thread that I feel at home in.

• Make a low poly, make a high poly.
• Set up a cage.
• Bake a texture.
• Said texture looks silly, change things and render again.
• Texture still looks silly, change more things and render again.
• Texture still looks silly, change even more things and render again.
• ...
• So wait, where does it save the texture?
• Conclude that you've been looking at the wrong texture all along.

[JamesLit]

It must be a stupid reason. It must be a stupid reason.

My own asset constantly crashing TS.

LogMate and RW_Tools say nothing.

Everything seems correct in BE2, 3DS and Photoshop.

Everything exports correctly.

It must be a stupid reason. It must be a stupid reason.

Let's try Xform resets. Let's try pivot resets. Let's try exporting only parts of the object rather than all of it. Let's try remaking the materials. Let's try merging it into a new scene. Let's try this. Let's try that. Let's try everything all over again.

Let's do all this for about a week.

Let's finally have the idea that perhaps TS doesn't like full stops in folder names. Let's remove the full stops from the folder names. Let's try. Let's laugh and cry at the same time as the asset now works faultlessly.

[VictoryWorks]

Useful to know, but brave (or foolish ) to try to start with. I don't even use spaces in folder names, just Camel Case with letters and numbers only to be safe.

[JamesLit]

Oh I'm sure, but I insist on using folder and file names that revolve around properly constructed English - a trend whose responsibility I think is probably shared between my autism and my defiance.

[AndiS]

Properly constructed English is a thing of the past. It is best used in hand-written letters to yourself. Otherwise, lowercase letters and numbers will do. Punctuation is a thing of the past, too. If you are really cool, you leave out 1/3 of the letters and make the reader guess.

I remember one problem with Windows and a dot in a folder name, being interpreted as filename extension or so. Cannot remember what exactly the problem was. Or it was a dot in the filename of a saved web page that prompted the browser to omit the default .html extension. Anyway, I stopped using dots in filenames long ago.

[VictoryWorks]

Saw this tweet recently which fits nicely here where lua is a major topic...

The software development process:
I can’t fix this
*crisis of confidence*
*questions career*
*questions life*
...
Oh it was a typo, cool!

[malkymackay]

Yep, I spent a a good hour or so the other day wondering why the script I was working on didn't want to play ball. One typo in a function name was the culprit