Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Faulty signal detection on Baltimore-Washington with MP36PH #21

Open
stefandd opened this issue Oct 8, 2024 · 1 comment
Open

Faulty signal detection on Baltimore-Washington with MP36PH #21

stefandd opened this issue Oct 8, 2024 · 1 comment

Comments

@stefandd
Copy link

stefandd commented Oct 8, 2024

When running a quickdrive on that route with the MP36PH with you script (release) from '01. Washington Union' to '09. Baltimore Penn Station', a ghost signal is detected shortly before 'Landover Track 2'.

The track there permits 100mp/h according to your script (even though it should be 125mp/h according to TS [release/non-beta]!), and suddenly a 45mp/h signal is detected that is not existing for miles out. There is no signal post showing any such aspect and TS does not show anything either. Also the ghost signal seems very close since I am immediately, despite acknowledging the signal, in suppression likely for being below a brake curve. After some driving, the 45mp/h signal disappears again, and I can continue to go at 100mp/h.

https://www.youtube.com/watch?v=49Ck2UaHOXk

@stefandd
Copy link
Author

stefandd commented Oct 8, 2024

@YoRyan

I debugged this for a while and realized the cause of the bad behavior of both your script and the orginal DTG script. There is a single! sig4speed45 signal fired with a distance of 645m (read out with Call("GetNextRestrictiveSignal")) at the point captured by the video above which is of course immediately above the brake curve. However, all really restrictive signals send hundreds or thousands of messages via OnCustomSignalMessage. I believe such single signal messages are the result of a race condition between the train entering a signal block and a signal lua script firing a last restriction signal from the block ahead before being cleared by TS (dispatcher).
When I filter the signal messages with a Lua script like this and only accept those that are sent at least 5 times in a row:

require ("Assets/DTG/WashingtonBaltimore/RailVehicles/CommonScripts/orig_MP36PH_Engine_Script.out") -- Require the original renamed script
orig_oncsig = OnCustomSignalMessage

function myMessage(txt, duration)
    SysCall("ScenarioManager:ShowAlertMessageExt", "MP36PH Debugscript", txt, duration, 1)
end

last_sigmsg = ""
sig_counter = 0
function OnCustomSignalMessage(arg)
    if arg ~= last_sigmsg then
        myMessage("OCSM: ".. arg .. ", (last signal sent " .. sig_counter .. " times)", 5)
        last_sigmsg = arg
        sig_counter = 1
    else
        sig_counter = sig_counter + 1
        if sig_counter == 5 then -- buffer the signal messages; only when one is sent 5 times --> send it to the DTG script
            orig_oncsig(arg)
        end
    end    
end

then the problem goes away with the DTG script. I did not test this filtering with your script, but I would recommend to consider implementing this kind of filtering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant