Jump to content

DazT

Member
  • Posts

    332
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by DazT

  1. 1 hour ago, JachyHm said:

    Probably no, it would be way too hard for such function.

    I don't quite see why would you want to draw trains without any updates about them.

    As of the print function, that would be probably quite easy to implement as the screen is bitmap already, but I assume you primarly wanted it to print "offline" timetable, so it won't make much sense anyways (and you can always use PrtScr).

    Also keep in mind that the app mainly tries to imitate the real world one, although some functions had to be alter for use with SimRail.

    The train geek in me wants to look at the current in-game timetable clashes for the planned timetable. Ironically it worked as such earlier when EN1 went down for 5 hours, so TPV still worked minus any train updates, so I've found one timetable clash alone (to be fair I already knew about the one I spotted)

    I'm thinking more of when we get a new timetable so I can go back to the devs and say, this doesn't work, that doesn't work in the timetable.

  2. Something I've noticed but never really paid attention until the other day is cancelling a route on a workstation (any workstation), the two initial starting options (ZD or ZW) are greyed out so to a newbie it doesn't indicate which of the two they should be clicking on, it just makes it appear like they don't do anything (even though they do)

    I'd expect them to be white (or red, whatever the design standard is on real Polish workstations)

    image.png.9aae32bb0de27677a204cc95b8a9ddf2.png

    Also, if you select option "ZW" and wait for the initialisation of it, the option you then need to click (ZWP) is also greyed out

    image.png.0286e707c2a4f0bece48b61960b9a70d.png

    Server: N/A
    Build: EAB 21/04/2024 14:12

    • I agree 2
  3. This actually seems to be a more common occurrence at many boxes where a left track train automatically gets priority over trains running right track

    This fault also occurs when Zw (either player or AI) left tracks trains to Myszków over Track 1. The AI at Myszków will hold trains on Track 2 at My_C until all left tracked trains have cleared Track 1. Not only is this unrealistic, it also causes carnage at Myszków where several trains get held for no reason at all. This also then stops trains that have just spawned in for actually getting a clear signal until the nonsense of left track resolves.

  4. When setting the route from Track 1 to Track 3 at Olszamowice, the interlocking draws onto more track than the route requires, the headshunt/neck that actually isn't part of the route.

    image.thumb.png.2f81da233295c9ce5f7f355d0454d176.png

    When a train enters using this route, this also causes track flooding/bleeding

    image.png.a4b2bf7420350b1021d03cc5f40a4c07.png

    Server: N/A (All)
    Build: EAB 24/04/2024 - 14:12

  5. Now I know certain trains had to be removed from the timetable from spawning due to issues at signalling issues at Radzice, but I'm under the assumption that this fault has been fixed now that the 412xxx services have been reintroduced.

    There are still some trains that still don't enter the simulation and haven't for months, I'm not sure if this is an oversight since the last update, or is there a legitimate reason as to why the following trains still don't enter?

    Trains concerned at MHE services: 45270, 45272, 45274 and 45276

    Server: N/A (All)
    Build: EAB 24/04/2024 - 14:12

    • I agree 2
  6. If any of the boxes (Będzin - Sosnowiec Główny - Katowice Zawodzie) are AI controlled and 406xx is bang on time at any of these, the AI will hold 406xx for 141xx to pass, even though according to the timetable the 406xx is booked ahead of the 141xx EC all the way to Katowice main.

    It's very annoying if you're driving the 406xx and you're doing your best to keep good time, only for the AI signalling to think it knows better and shove the EC ahead. All that happens in this instance is the 141xx EC arrives at Katowice early and delays the 406xx for 5 minutes for absolutely no reason at all.

    Expected behaviour is that if the 406xx is running within +/- 1 minute of time then it should go ahead of the EC and stay ahead of it.

    Server: All N/A
    Build: EAB 24/04/2024 - 14:12

    • I agree 1
  7. If you ask the AI at Sprowa for left track running over Line 2, if you happen to have a train also on Track 1 (correct line) the AI will hold whatever that train is at Signal Sp_B regardless of how far away the train sent on Line 2 (Left track) is away.

    The AI at Sprowa needs tweaking so that it clears Sp_B (T1) or Sp_A (T2) based on the priority/timetable order of the train.

    Server: N/A
    Build: EAB 24/04/2024 - 14:12

  8. Whilst working Kozłów, Tunel AI requested to run a train on Track 1 towards Kozłów.

    The AI at Tunel released the line lock and the arrow was flashing in the right direction (towards Tunel) but it never then sent WBL. The only way to resolve was to leave and rejoin after which point the left line running had been accepted by the Kozłów (as AI)

    Also noted that once track 1 was in left line running, there is no way to press the "Allow left track running" button to clear signal Y

    Server: EN1 ~0020hrs-0030hrs (UTC+1)
    Build: EAB 21/04/2024 14:12

  9. 2 hours ago, Fightdrug said:

    my words when i would drive that train at this point i would notice that something is wrong when i pass the last switch and then you have a emergency brake 🤕 because the signal make you clear that the area till the next signal is free from trains so i dont would check the switches

    interesting fact here when you do that in real life you can say goodbye to your job as dispatcher and when someone inside the train gets harmed you even can go to prison 😄 alteast in germany

    Same here in the UK if in the rare possibility that signalling system let you actually do it. (the majority of installations won't without a timeout of either 2 or 3 minutes) 

    • I agree 2
  10. If that was how they did it then that's a bit naughty, especially had the second train been player controlled as you drive to the condition of signals displayed (speed, braking point, location to stop at etc etc), a clear signal indication tells the driver the signal section is clear of any other trains and by someone fooling the system like that is just sh*t signalling.... Rather than just waiting a few minutes and giving the correct signal indication. 

    • I agree 2
  11. Assuming you were on DE1, this is what the TDRS logs show, possibly just a glitch, I guess the only ones who could tell were the devs by looking at the actual server logs.

    Looking at TDRS looks like it never saw the Zw_C to Zw_H3 bit (possibly too quick for the API to even see it). Interestingly though what the logs do show is when train 73123 passed Zw_C and then saw Zw_G1 the signal speed shows 32767 (ie, vmax) (14:47:07 UTC) and then the next log entry shows "0" for red (14:48:11 UTC). So the only thing I can think of is 73123 was Sz'd into the platform on top of 40131 (hence the signal reversion as 40131 departed which according to the logs for 40131 was at ~14:47:27 UTC when it started moving). Zw_C also shows a signal speed of 40 for 73123, also suggesting the use of Sz or other shenanigans.

    The only reasoning for it not seeing the H3 bit is, Zw_C, Sz set with Ponts 11 and 13 set towards Line 3 (in reverse/ '-' position) and then whoever was on there realising it'd go the wrong way and quickly setting the points to normal (+) position and then it seeing Zw_G1. Again, probably happened so fast the API never saw it (Between 14:46:54 and 14:47:07 UTC), that's 13 seconds (where it's more than enough time for points to be swung)

    If it was indeed Sz'd, it'd be interesting to know why the train list never showed Sz at Zw_C??!!

    Log for 73123
    image.thumb.png.ca9c4a9f193eacdf265de52d2d7b2152.png

     

×
×
  • Create New...

Important Information

Terms of Use Privacy Policy