Has anyone else noticed that the flashing yellows no longer work on the GEML route, they were working before the recent core update, but no more. I initially thought that it might have something to do with the add on route I built, but running to original route it also has no flashing yellows when changing to a different path.
Is there a junction I could try? Not all have Flashing Yellows as it depends on the line speed. Just did a Free Roam Liv St to Stratford on the Down Main crossing to the Down Temple Mills at Bow Jn That is 70 > 40 and I got Flashing YY and Y on approach. Going from Stratford P10 and DM to DE at Maryland there was no Flashing Yellows due to slow speed from P10 Peter
I was using Colchester to Mark's Tey platform 3, this path always used to have the flashing yellow light sequence, but now there are no lights, the signals are black, only the single yellow just before the crossover.
Please name a scenario or exact QD setup where we can verify that (without driving for half an hour). I have both TSC versions installed. Edit: Issue Unconfirmed. Yellow diverging signal flashes normally on latest TSC build. Freeroam Colchester, path set to Marks Tey P3. Do a file verification through Steam.
Hi Torfmeister, thanks for verifying that it is not a "dovetail" issue, I just repeated several tests in different sections of the route where I would expect to see flashing yellows and blank signals every time. I will do the file verification and see what happens..
I don't know the circumstances but some signals can blank out conditionally. I suspect it's the default (error) state of the UK signals (Kuju at least). I came across blacked out flashing yellows on the ECML (pretty common approaching Thirsk from the north) and Edinburgh-Glasgow (most likely the first big wye junction from Glasgow, diverging off the main, utilized mostly by the Freightliner packs). It might also be related to pathing beyond - signaling usually involves sequences. Don Coffey recently explained that diverging signals must have a feather active before it turns permissive, absence of it might also be an indicator. (The red version has non-flashing advance.) In short, setting an untested path (in a free roam, typically) might fail. I don't know how they work exactly, but I smell scripting - sometimes the slowdown procedure is also involved, or the yellow-to-green which might be sort of an intermittent state. Point is, UK signaling has its quirks.
That is not quite correct. A section of line that is permissive allows more than one train in to that section With Mechanical Signalling it is known as Permissive Block with the alternative being Absolute Block. Permissive working will be found at Station Platforms and on Goods Lines It is unlikely to be used at a Junction with Flashing Aspects which are normally used on High Speed Lines or to indicate the route being taken on other routes.
I just created a short 10min scenario to run a light loco Colchester P3 to Marks Tey P3 and I had Flashing Double Yellows and Single Yellows on approach - I was not able to make a screenshot with the Signals blank between each flash. Could it be a problem with the file that makes the signals flash? Maybe try another route and see if they work as they should.
I have ran the steam file checker, this showed a couple of file errors. Got these reloaded, still the same issue. I have now narrowed it down to a class 105 running on the modified route, other locos don't have the same issue. I even dropped the railworks folder and steam reinstalled, still the same issue Seems to be an initialisation issue as you can pass the blank signal, it goes red as expected, then reverse and the lights are flashing double yellow. The next signal is correctly showing a single flashing yellow, yesterday this signal was also blank. Clearing the cache and rebooting does not resolve the issue. I will have another look at this later.
Just an update, I tried to create scenarios on other sections of the route and the flashing yellow sequence works correctly, I even sent the train via the Marks Tey loop and it works correctly, it is only when I turn out to Marks Tey platform 3 that it fails. As a workaround I have found that by running a train eastbound from Marks Tey Platform 2 to Colchester and have it leave shortly before my train crosses over, the lights set correctly and then the sequence runs correctly. The issue seems to be only with a Class 105 and only when the route is set to cross at the start of the scenario, it appears that the lights are not being initialised correctly at the start of the scenario.
I have done a bit of digging and found these entries in logmate 2023/06/06 10:50:21.842 - [Script Manager] - Trace D:\build\CoreRelease\Code\DLLs\ScriptManager\cScriptState.cpp : 229 = error running function: Shared by All.lua:433: stack overflow 2023/06/06 10:50:21.842 - [Script Manager] - Trace D:\build\CoreRelease\Code\DLLs\ScriptManager\cScriptState.cpp : 229 = error running function: Shared by All.lua:433: stack overflow This links to C:\Program Files (x86)\Steam\steamapps\common\RailWorks\Assets\Kuju\RailSimulator\RailNetwork\signals\UK Colour Light\UK 2AspSig Post Entry All.lua -- the first time that this is called, the time since the last update will be large - therefore we should ignore the first update (line 433) if gFirstLightFlash then -- Reset flash state gTimeSinceLastFlash = 0 gFirstLightFlash = false gLightFlashOn = false -- Otherwise increment the timer else gTimeSinceLastFlash = gTimeSinceLastFlash + time Hopefully this will throw some light on the issue.
dolanbaker I would try to cut the scriptblock from line 432 to 455 and paste it into the line 459. See if that helps. If not, you can always reverse the modification to original state.
looks like I was looking a the wrong lua script, repeating the testing I now get the error for a file named "Shared by All.lua" 2023/06/07 22:51:38.223 - [Script Manager] - Trace D:\build\CoreRelease\Code\DLLs\ScriptManager\cScriptState.cpp : 229 = error running function: Shared by All.lua:939: stack overflow 2023/06/07 22:51:38.223 - [Script Manager] - Trace D:\build\CoreRelease\Code\DLLs\ScriptManager\cScriptState.cpp : 229 = error running function: Shared by All.lua:939: stack overflow 2023/06/07 22:51:38.223 - [Script Manager] - Trace D:\build\CoreRelease\Code\DLLs\ScriptManager\cScriptState.cpp : 229 = error running function: Shared by All.lua:939: stack overflow" When I searched for this nothing came back, but a file called "Shared by All.out" which is part of the signalling scripts by AndiS seems to be showing the error. Unfortunately it is not possible to see the source code. I also saw another error with one of the signals I had made, fixing that has cleared the fault (I think), but the stack overflow error still persists.
Yes I got in contact with Andi and he has given me a few pointers, so hopefully I will get to the bottom of it, could be an error in one of my signals. but we'll hopefully find it.
Update, I can confirm that there are no issues with AndiS scripts, the stack overflow issue is to do with a bad signal. But this does not explain the lack of flashing lights, but as part of testing, I decided to try a nighttime scenario. The lights worked as expected! Then I repeated the scenario, they failed again, I then changed the scenario start time and they worked again. Any suggestions as to why lights would be so dependent on scenario start times??
I have now repeated the test several times with different scenarios, edit scenario. first run lights flash second run lights don't flash edit scenario, run, lights flash, clear cache, rerun lights don't flash.
Signal state is different when you load from the editor. In a similar opposite case, there is one signal on Settle-Carlisle, entering Carlisle, showing all aspects at once. But I've also come across many cases when save / reload would either clear or restrict an opposite signal. (Trenton northbound, for example.) Between your explanation and my hunch, it does sound like some scripting issue.
Sorted! compatibility issue! The issue with the flashing lights not working correctly turns out to be caused by a "Pro" signals that I had added between the filters (AndiS signals use a compatibility filter to interface between signal types) and the GEML home signal on the approach to platform3, looks like a comparability issue there. But only going from AndiS signals via the filter to Pro signals, the opposite direction seems to work OK. I replaced them with kuju semaphores and the issue cleared!
