|
Post by bigjacko on Jan 9, 2020 1:07:21 GMT
OK, so two more things to try now. Right click on TS in the Steam library, select properties and then on the box that opens select the Tools tab. From the drop down list select File Integrity Check. This may take quite a while to run to 100%. When it finishes it will tell you if any files failed to validate. I'd bet money you have over a 1,000 files corrupted. TS will re-acquire the correct files. So now you should have a clean TS installation. Now reinstall the District Line 2.02 version, use the complete installer, and disable any anti-virus programs before doing this, Norton in particular WILL remove critical files. If you have Windows 10 up to date, you do not need any antivirus, Windows Defender is perfectly capable of protecting your PC from all known threats. Uninstall, and then reinstall all the JT stuff. I have a feeling crashing out of the Editor with Task Manager killed the scenario. Stay well out of the Editor in future. Now once you have installed VDL Phase 2 ( over the top of your existing install ) delete the SDBCache.bin file again and then restart TS. Before you try again, now go into settings/tools and clear the cache. Ts will restart clean and try again. If that doesn't work, I'm outta ideas.................. good luck. Saw your post above, the S7+1 won't affect this one , the signals from JT's Met line are very important though, so reinstall that at least. Thanks Eddie - I will work through that in a sec. I figured you'd probably be in the land of nod by now, so was busy prepping a video for the morning for you to see... it's here: I'll go and do those bits you've mentioned - but I will just comment on a couple before I do... 1 - Norton? Please! What do you take me for? I wouldn't touch Norton with yours! I've probably made more money out of fixing people's Norton problems in the past, than I have out of 'normal' development I happily use Defender on Windows 10 these days - it's plenty good enough for 99% of situations, and about as good as Avast/AVG/Avira/et al (and without the nags or bloats). 2 - I'll do the FIC, but I can't remember whether it'll wipe my AP soundpacks and delete my other 'non-standard' (i.e. JT/community) fixes and tweaks. Do you happen to know? I don't mind reinstalling them (if I can find them - I have several thousand hours on TS... in fact, I started with 'Rail Simulator' over a decade ago, so I have quite a lot installed! ) 3 - I promise you that ditching out of the World Editor (even in scenario edit mode) is safe, if done via Task Manager (or, if in windowed mode, by using the Close Window/F4 method). I've spent many hours in the editor making my own route-tweaks and private scenarios, and even though I've not published anything to the world-at-large, I'm confident enough that providing you don't return to 'Drive', and/or don't affirm any filechanges, it won't touch your route or your scenarios that were 'under edit'. The TS editor is not smart enough to 'buffer on disk' or autosave (or if it does, I have that turned off). And this is evidenced by the file last-mod timestamps - if the files are ever altered, they'll show up differently there. You'll see that yours are still 'straight from the zip', I promise you I will reinstall them again, though, just because... well, like you, I'm running out of ideas at this point! LOL I'll report back in however many hours it takes - i.e. tomorrow, most likely! Thanks again!
|
|
|
Post by bigjacko on Jan 9, 2020 1:51:41 GMT
hah! Good guess, Eddie...
|
|
|
Post by bigjacko on Jan 9, 2020 3:21:30 GMT
OK, progress report. Not good, alas.
Let Steam reacquire those 1266 files, then ran Validate Steam Files (FIC) once more, just to be sure that it came back with zero this time. It did.
I then deleted SDBCache.bin, ran TS2020, went to Tools and told it to wipe cache. Restarted (as 32-bit), so killed that, and relaunched 64-bit instead (I wish DTG would sort that... if I issue a restart from the 64-bit app, it's pretty obvious I'd want the 64-bit to relaunch, not the 32!)
At this point, I wanted to see if the cache and verification steps had made any difference, so I played the scenario but alas same outcome. No disc rotation at depot-exit.
I quit and followed the remaining steps:
Uninstalled JT Metropolitan then JT S7+1 using their normal uninstallers via Windows 10 Settings/Apps.
Reinstalled same, Met first, then S7+1.
Re-ran the VDL installer (VDL Phase 2 2019_09_26.exe) and installed all its files again.
Didn't bother with the audio patch or the corporate liveries this time.
Double-checked that the S7 Destinations files are all still correctly in-place in the JT S7+1 District-related subfolders.
Deleted the SDB cache again. Didn't issue the second in-game 'Tools Cache' clear, but figured (afterwards) it probably wouldn't have made any difference. I will try this again though tomorrow - just in case.
Ran the 64-bit app, ran the scenario - same outcome.
I might see if running with LogMate sheds any light - if I can remember how to use that! Been a while.
|
|
|
Post by Jimi on Jan 9, 2020 15:06:20 GMT
Hi Jacko, I wrote that scenario, and as Ed showed it should work. I did find that sometimes the shunt clearing was a matter of timing. We design a scenario to work in a certain way, and then if the player is early or late for a "meet" it can have far reaching ripple effects. Just as in real life. The dispatch and signal system SHOULD take care of these situations, but sometimes falls short - especially the dispatcher. As you prepare the train and start leaving the depot, make sure you are keeping to speed limits. You will be held at the exit shunt, and as messages inform, you will be given the GO after a specific train has passed westbound (73TS IIRC). After that, you have time to exit before an EB D78 pulls into ECM. My gut instinct from your descriptions makes me feel you are a touch late and not at the exit ready for the gap that was built in. I've seen some weird TS behavior over the many years we have all messed with it, but I can't see how this won't work if you have all the right bits installed (as you seem to have). I don't think its a files/content related issue. Sometimes, as we have discovered, clearing/rebuilding the scenario cache can cure warts. If you still have issues, I'd bet it's a scenario timing issue. I really wouldn't try to chase it with Logmate. Take a loot back at Ed's slideshow, and note the clock times shown in the lower left of the HUD at each step. And there are videos on YT of others successfully running this scenario. I meant it to be somewhat simple as it's the players first training on the stock, and not give the player grief simply exiting the depot! Make sure you are at the exit early enough and watch the other trains go by and watch for the "you're next" message and teh clock time it happens. And let us know what happens next...
EDIT: To save you looking back at Ed's screenies (although it is worth it to check other details), here's the events and clock times from them so you know what to expect and when: At W Outlet road shunt 8:01:08 You're next message 8:02:44 Shunt clears 8:03:43 At ECM berthed red starter 8:04:33 ECM starter clears 8:04:50
I notice in one of your screenies, you are not at the outlet until 8:06:59. 5 minutes late. And another shows 8:03:17 with teh 73 about to berth ahead of you - so you are still waiting correctly for the clear in that one.
Get the train setup quicker and then 15mph down to the shunt. I would bet this is the problem. 5 minutes late so other services have got clear signals blocking your exit.
|
|
|
Post by bigjacko on Jan 9, 2020 15:53:43 GMT
Afternoon! I did a LogMate run, and it came back with some interesting (but equally confusing) possibilities, maybe. Obviously the LogMate file is huge (250,000+ lines) so I won't post it here (not least of which in case it contains any sensitive info). But if any of the devs would like it, just let me know and I'll send it to you somehow. Delving through it with, I must admit, fairly limited knowledge of TS's inner workings, but a good knowledge of general coding and scripting, a few things immediately stick out as odd. I'll skip all the preamble stuff where the game is going through its menus and complaining about missing box-art and other guff, and focus on the activity only once the 01 Training Scenario is chosen and physically started. During its loading phase (I think), this turns up twice, but I don't think it's massively important (you might know different, though!) 2020/01/09 13:10:30.852 - [RunTimeError] - Verify failed:
2020/01/09 13:10:30.852 - [RunTimeError] -
2020/01/09 13:10:30.852 - [RunTimeError] - cBlueprintSet.cpp : 345
2020/01/09 13:10:30.852 - [RunTimeError] -
2020/01/09 13:10:30.852 - [RunTimeError] - Expression: success
2020/01/09 13:10:30.852 - [RunTimeError] -
2020/01/09 13:10:30.852 - [RunTimeError] - Assets\Mundo\Scenery\pylonl12.bin appears to contain invalid data
I do appear to have that file in that location, plus a GeoPcDx to go with it, but (here is the odd bit) they are both ZERO bytes in size. Empty files. No idea why. Remember this is all post-cache wipes and verify-file-integrity, so I've no idea how significant this is, but have a gut feeling 'not very'. Moving on, we have a few hundred of these: 2020/01/09 13:10:30.852 - [Content] - Trace cBlueprintLibrary.cpp : 266 = Blueprint set not found : SAD, Foliage_Pack1
and a: 2020/01/09 13:10:31.352 - [RunTimeError] - Verify failed:
2020/01/09 13:10:31.352 - [RunTimeError] -
2020/01/09 13:10:31.352 - [RunTimeError] - cBlueprintSet.cpp : 345
2020/01/09 13:10:31.352 - [RunTimeError] -
2020/01/09 13:10:31.352 - [RunTimeError] - Expression: success
2020/01/09 13:10:31.352 - [RunTimeError] -
2020/01/09 13:10:31.352 - [RunTimeError] - Assets\Wilburton\Stockton\Scenery\Buildings\PF_fettleShop.bin appears to contain invalid dataAgain, I do have a PF_fettleshop.bin file, and a PF_fettleshop.geoPcDx in that location, both zero bytes again. A few more thousand of the SAD, Foliage_Pack1 missing blueprint warning, interspersed later with: 2020/01/09 13:10:31.859 - [Content] - Trace cBlueprintLibrary.cpp : 266 = Blueprint set not found : UKTS_FP, Blocks_and_Lofts
2020/01/09 13:10:31.859 - [Content] - Trace cBlueprintLibrary.cpp : 266 = Blueprint set not found : UKTS_FP, FoliageNot convinced these are a big deal, but again, I may be wrong. We're about 15 thousand lines in, now, and I see a few more 'invalid data' warnings for the following items: 2020/01/09 13:10:33.396 - [RunTimeError] - Assets\JustTrains\ChilternMainline\NL\Scenery\Platform\filler_block_3.bin appears to contain invalid dataThis one is unlike the others, because I do appear to have this file and it's non-zero (1KB big). Plus a .geoPcDx and an .xml to go with it, both of 4KB. Lastmod timestamps show 12th Nov 2019, 21:25 for all. I don't actually own this specific DLC, and going by the file creation timestamps, they look like they were installed by my reinstallation of the Metropolitan earlier this morning at 02:39 after the verify-files operations Eddie advised. Nearby, we have: 2020/01/09 13:10:33.396 - [RunTimeError] - Assets\JustTrains\ChilternMainline\NL\Scenery\Buildings\Shelter02.bin appears to contain invalid dataSame deal - this exists, complete with an .xml and a .geoPcDx, all non-zero, healthy-looking files, Lastmod timestamped 12th Nov 2019, 21:25, and evidently re-created on my system last night during the Metro reinstall. Then we have: 2020/01/09 13:10:33.897 - [RunTimeError] - Assets\JustTrains\ChilternMainline\NL\RailNetwork\Tunnels\Sieg_Hage_DoubleTrackTun.bin appears to contain invalid data
And again, same deal - exactly as per the last two errors. Extant files, non-zero, lastmod and creation timestamps as previously. I have a hunch here that JT may have included these because they are required by the Met, but somehow they have been broken in the repackaging. I guess it's possible that anyone with the full Chiltern DLC may not experience these glitches, but that may depend entirely on the order they were installed in, maybe? And indeed, I cannot say what, other than these log lines, is experienced in-game as a result of these errors... maybe something is missing, maybe it just defaults to something else, maybe it's not even slightly obvious or important. Can't tell! But I'll report them here anyway, in case it's a sign of a dependency on the Chiltern DLC that you were unaware of, and which might need to be put into the Requirements section of your website in the future. Moving on...about 16700 lines in, I think the basic loading-of-parts is done, and the engine moves on to the construction phase. I see these: 2020/01/09 13:10:34.902 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:34.902 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Content/Routes/df59cee1-b6b9-4fd5-966a-1f3437f08a15//Route.xml.bin
2020/01/09 13:10:34.902 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:34.902 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Content/Routes/df59cee1-b6b9-4fd5-966a-1f3437f08a15//Route.xml.xml
and 2020/01/09 13:10:34.902 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Content/Routes/df59cee1-b6b9-4fd5-966a-1f3437f08a15/Terrain/DistantPatches.bin
2020/01/09 13:10:34.902 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Content/Routes/df59cee1-b6b9-4fd5-966a-1f3437f08a15/Terrain/DistantPatches.xml
Not at all sure what this represents, but none of the referred-to files exist in those locations. Could be nothing, might be important. The ones that reference files within the Routes/df59cee1-b6b9-4fd5-966a-1f3437f08a15/ are obviously more concerning, possibly - because those are within the VDL's main DLC area, and presumably being specifically called by the scenario itself? OTOH, maybe they're just default locations that Railworks looks to find video-streams and funky camera work on scenario load, and them not existing might be totally normal. No idea. Next we have a couple of hundred lines of: 2020/01/09 13:10:34.902 - [Content] - Trace cNetworkRibbon.cpp : 1984 = Ribbon not found while loading curves, are all network files in synch? Ribbon ID :{a7a6aca6-74d6-4359-87cd2c031d2b756a}
2020/01/09 13:10:34.902 - [Content] - Trace cNetworkRibbon.cpp : 1984 = Ribbon not found while loading curves, are all network files in synch? Ribbon ID :{5414b212-385c-4d60-a67552bfd8921eb3}
but with different Ribbon ID numbers at the ends of each line. No clue what this is, but have a hunch it's not major (or we'd see no curves, if it was, and clearly that isn't the case). Then I start to see a lot of these: 2020/01/09 13:10:34.908 - [Script Manager] - Trace cScriptState.cpp : 229 = error running function: (none):0: attempt to call global `SwitchFeatherLights' (a nil value)
2020/01/09 13:10:34.908 - [Content] - Trace cScriptComponent.cpp : 225 = ID: RailNetwork\Signals\Signals\JTLU_Repeater_B2AYG_Fog_F1.xml long: -0.276827, lat: 51.498728 Error calling Initialise function
interspersed with a lot of these: 2020/01/09 13:10:34.908 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "RailNetwork\TriggerPoints\jt_triggerpoint_s8_stop_0_3.xml"
2020/01/09 13:10:34.908 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "RailNetwork\TriggerPoints\jt_triggerpoint_s8_stop_0_3.xml"
2020/01/09 13:10:34.908 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "RailNetwork\TriggerPoints\jt_triggerpoint_s8_stop_3_3.xml"
2020/01/09 13:10:34.908 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "RailNetwork\TriggerPoints\jt_triggerpoint_s8_stop_0_3.xml"
2020/01/09 13:10:34.908 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "RailNetwork\TriggerPoints\jt_triggerpoint_s8_stop_0_4.xml"
in various combinations and orders. Other signals causing the same error and similar references to the triggerpoints are: 2020/01/09 13:10:34.908 - [Content] - Trace cScriptComponent.cpp : 225 = ID: RailNetwork\Signals\Signals\JTLU_Repeater_B2AYG_Fog_F14_Tall.xml long: -0.293322, lat: 51.515588 Error calling Initialise function
and 2020/01/09 13:10:36.411 - [Content] - Trace cScriptComponent.cpp : 225 = ID: RailNetwork\Signals\Signals\JTLU_Repeater_B2AYG_Fog_F1_Tall.xml long: -0.287791, lat: 51.513853 Error calling Initialise function
Various different latitudes and longitudes - presumably every instance on the map fires off an error such as these. Checking for the existence of those files, I can find (in my E:\Steam\SteamApps\common\railworks\Assets\JustTrains\CommonLibrary\RailNetwork\Signals\Signals folder) the JTLU_Repeater_B2AYG_Fog_F1.xml file and a .bin with it (all non-zero and apparently readable, dated 2nd Aug 2017 18:39, all installed in March 2018 as part of some other JT DLC presumably - I know not which one), but I can't find any of the others there: JTLU_Repeater_B2AYG_Fog_F14_Tall.xml or JTLU_Repeater_B2AYG_Fog_F1_Tall.xml. I do have lots of other JTLU signals here in this folder, including disc signals, it seems - but everything seems to have come from my other JT DLCs, judging by their lastmod ages and creation dates. Widening the search, though, I find all of these JTLU_Repeater_B2AYG files in my E:\Steam\SteamApps\common\railworks\Assets\JustTrains\LULibrary\RailNetwork\Signals\Signals folder - every one, with a .bin to match the .xml. The odd thing is that although they are all lastmod-stamped 8th Nov 2019 15:38, they are created-stamped at 31st Dec 2019, which is when I first installed Met. They do not appear to have been uninstalled and then replaced by the reinstallation of Met that I did early this morning - similarly, the Met reinstall doesn't appear to have over-written them, and must have skipped them. That raises the question that if one or more of those files was borked/corrupted, maybe it's not safe to rely on the 'JT Met uninstall-reinstall' approach, if the installer is conditioned to ignore stuff it believes is 'shared common'. Not sure whether I should rip these out manually and run the Met install yet again... Continuing on, we're well into 'effect creation mode' now, and there are handful of these: 2020/01/09 13:10:41.418 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "Scenery\Buildings\PF_fettleShop.xml"
2020/01/09 13:10:41.418 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "Scenery\Buildings\PF_fettleShop.xml"
2020/01/09 13:10:41.418 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "Scenery\Buildings\PF_fettleShop.xml"
2020/01/09 13:10:41.418 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "scenery\Vehicles\fastlinevan.xml"
2020/01/09 13:10:41.418 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "scenery\Vehicles\fastlinevan.xml"
2020/01/09 13:10:41.418 - [Content] - Trace cEntity.cpp : 1272 = Missing blueprint "scenery\Vehicles\NRISvan.xml"
but I doubt these are majorly important. These are the last few errors before the Dispatcher V1 is called for and effect creation phase ends: 2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/procedural/textures/invisible.TgPcDx
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/structures/textures/vb_wp31_01.TgPcDx
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/buildings/textures/stencilshadow.TgPcDx
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/structures/textures/vb_wp31-04.TgPcDx
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/buildings/textures/york_newc_wp16_10.TgPcDx
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/buildings/textures/york_newc_wp16_04.TgPcDx
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:41.418 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/buildings/textures/oxfo_padd_wp15-01.TgPcDx
2020/01/09 13:10:42.920 - [Streaming] - Trace Core\cFxFileMapped.cpp : 52 = cFxFileMapped failed to open, no physical file system: @os:e/Steam/steamapps/common/RailWorks
2020/01/09 13:10:42.920 - [Streaming] - Trace Core\cFxStreamFile.cpp : 244 = cFxStreamFile failed to load: @os:e/Steam/steamapps/common/RailWorks/Assets//scenery/buildings/textures/york_newc_wp22_05_01.TgPcDx
Not sure about these. References to Assets//scenery are a thing of the past, I thought. Maybe these are in the scenario-file, or maybe they're just vestigial Railworks behaviour. Not sure. I doubt they are the cause of our disc-signal problem though, in any case. Dispatcher then seems to run and set up physical train units and paths, and for the most part seems ok. There are a couple of oblique references to: 2020/01/09 13:10:42.920 - [Script Manager] - Trace cScriptState.cpp : 165 = Unable to execute non-function: Initialise
but I don't think these are crucial. There are many successes and apparent goodness, with one oddity just before the point where it seems to start from the initialsave... 2020/01/09 13:10:43.924 - [Script Manager] - Trace cScriptState.cpp : 389 = Lua Error: cannot read E:\Steam\steamapps\common\RailWorks\Content\Routes\df59cee1-b6b9-4fd5-966a-1f3437f08a15\Scenarios\5f3c47e0-df71-49ed-9f20-5921539fe6bf\ScenarioScript.lua: No such file or directory
I've checked, and that file doesn't exist in the scenario folder (which is the 01.Training one) - again, maybe this is default behaviour of the Railworks core, and is standard if this file doesn't exist - or maybe it's a sign something it missing, so I report it here for completeness' sake, just in case. Then we get into the initial run, and right off the bat, I see: 2020/01/09 13:10:43.924 - [Data Management] - Trace Scenario.cpp : 619 = vvvvvvvvvvvvvvvvvvvvvvv
2020/01/09 13:10:43.924 - [Data Management] - Trace Scenario.cpp : 620 = LoadGame ( InitialSave )
2020/01/09 13:10:43.924 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 0 + 4)
2020/01/09 13:10:43.924 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnSignalMessage onto stack: JT - Trigger Point (S8 Stop Board 0 + 4)
2020/01/09 13:10:43.924 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 0 + 4)
2020/01/09 13:10:43.924 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnSignalMessage onto stack: JT - Trigger Point (S8 Stop Board 0 + 4)
2020/01/09 13:10:43.924 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 0 + 4)
2020/01/09 13:10:43.924 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnSignalMessage onto stack: JT - Trigger Point (S8 Stop Board 0 + 4)
and those last few failure lines are repeated about 150 times. Are we looking at a dependency on the S8 that the S7+1 cannot fulfil, perhaps? And is it crucial to the operation of certain signals, triggers or paths? Just guessing... Then we move to the next phase: 2020/01/09 13:10:43.925 - [Script Manager] - Trace cScriptState.cpp : 389 = Lua Error: cannot read E:\Steam\steamapps\common\RailWorks\Content\Routes\df59cee1-b6b9-4fd5-966a-1f3437f08a15\Scenarios\5f3c47e0-df71-49ed-9f20-5921539fe6bf\ScenarioScript.lua: No such file or directory
2020/01/09 13:10:43.925 - [Scenario Manager] - Trace cScenarioManager.cpp : 3637 = On Game Starting... (modeDrive)
2020/01/09 13:10:43.925 - [Scenario Manager] - Trace cConsistManager.cpp : 2540 = InitialiseSignalScriptSystem
2020/01/09 13:10:43.925 - [Script Manager] - Trace cConsistManager.cpp : 2545 = INIT ResetAllSignalStates
2020/01/09 13:10:43.925 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 3 + 3)
2020/01/09 13:10:43.925 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnSignalMessage onto stack: JT - Trigger Point (S8 Stop Board 3 + 3)
2020/01/09 13:10:43.925 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 0 + 3)
2020/01/09 13:10:43.925 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnSignalMessage onto stack: JT - Trigger Point (S8 Stop Board 0 + 3)
and then the same story again, but more - this time 300 or so more of these repeated fails about S8 Stop Boards, in a burst, then another couple of hundred more after that. (Notice also the errant call for ScenarioScript.lua at the beginning of that chunk, but again I think that is vestigial or default Railworks behaviour maybe.) Then things start to form a pattern of repeating failures (none of which is obvious from the driving seat, of course). It begins with: 2020/01/09 13:10:44.430 - [Script Manager] - Trace cAnimObjectRender.cpp : 644 = Anim id Clear01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F1
2020/01/09 13:10:44.430 - [Script Manager] - Trace cAnimObjectRender.cpp : 488 = Anim id Stop01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F1
2020/01/09 13:10:44.430 - [Script Manager] - Trace cAnimObjectRender.cpp : 644 = Anim id Clear01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F4_Tall
2020/01/09 13:10:44.430 - [Script Manager] - Trace cAnimObjectRender.cpp : 488 = Anim id Stop01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F4_Tall
2020/01/09 13:10:44.430 - [Script Manager] - Trace cAnimObjectRender.cpp : 644 = Anim id Clear01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F4
2020/01/09 13:10:44.430 - [Script Manager] - Trace cAnimObjectRender.cpp : 488 = Anim id Stop01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F4
and some more of the same referencing similar signals, and then goes into a regular loop for the rest of the scenario (until I stopped it after waiting for the disc signal again, at about 5 minutes in, with the D78 ACTS23 trying to pull away doors-closed but failing). But the cycle goes like this, pretty much: 2020/01/09 13:10:44.430 - [Pathing] - Trace cPlatformController.cpp : 2757 = Cannot move between adjacent points!
2020/01/09 13:10:44.430 - [Engine] - Trace DxCommon\cHcEffectDx.cpp : 135 = Creating effect myprojected.fx
2020/01/09 13:10:44.430 - [Rail Vehicle Manager] - Trace cEngineSimLocoBase.cpp : 349 = Was Dead now powering up
2020/01/09 13:10:44.430 - [RunTimeError] - Shoes not implemented
2020/01/09 13:10:44.430 - [RunTimeError] -
2020/01/09 13:10:44.430 - [RunTimeError] - cEngineSimSubSystem::setShoeState()
2020/01/09 13:10:44.430 - [RunTimeError] -
2020/01/09 13:10:44.430 - [RunTimeError] - d:\build\corerelease\code\dlls\railvehiclemanager\cEngineSimSubSystem.d.h : 152repeat the last ShoeState block three times or so. This is odd - particularly because it refers to an explicit filepath that does not exist on my machine - I have no d:\build\ folder at all, so I don't know whether this is a VDL-related reference to a developer's own build system, or something errant in the guts of Railworks itself. This following (non failure) set of lines would seem to indicate we are right at the beginning of the scenario still - in case that helps pinpoint timing: 2020/01/09 13:10:44.430 - [Camera] - Trace cPhysicalConsist.cpp : 923 = cPhysicalConsist::CreateInteriorCamera 5
2020/01/09 13:10:44.430 - [Pathing] - Trace cPathFollower.cpp : 1096 = junction changing state: [440] 68a453c0 at locn: (lat, long): 51.515190, -0.288745 for requester: D78 ECM1 - EBY9 - ACTS21 at time: 8:0.0
2020/01/09 13:10:44.430 - [Pathing] - Trace cPathFollower.cpp : 1096 = junction changing state: [450] 686a4dc0 at locn: (lat, long): 51.515202, -0.298888 for requester: D78 ECM1 - EBY9 - ACTS21 at time: 8:0.0
But the 'loop of fail' continues with: 2020/01/09 13:10:44.430 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnConsistPass onto stack: JT - Trigger Point (S8 Stop Board 3 + 0)
2020/01/09 13:10:44.430 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 3 + 0)
2020/01/09 13:10:44.430 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnConsistPass onto stack: JT - Trigger Point (S8 Stop Board 3 + 0)
2020/01/09 13:10:44.430 - [Signals] - Trace cSignalComponent.cpp : 736 = GetSignalState function not implemented in signal script
then 2020/01/09 13:10:45.431 - [Script Manager] - Trace cAnimObjectRender.cpp : 644 = Anim id Clear01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F1
2020/01/09 13:10:45.431 - [Script Manager] - Trace cAnimObjectRender.cpp : 488 = Anim id Stop01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F1
2020/01/09 13:10:45.431 - [Script Manager] - Trace cAnimObjectRender.cpp : 644 = Anim id Clear01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F4_Tall
2020/01/09 13:10:45.431 - [Script Manager] - Trace cAnimObjectRender.cpp : 488 = Anim id Stop01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F4_Tall
2020/01/09 13:10:45.431 - [Script Manager] - Trace cAnimObjectRender.cpp : 644 = Anim id Clear01 not found in 2 Aspect Signal Head in JTLU_Repeater_B2AYG_Fog_F4
then 2020/01/09 13:10:45.431 - [RunTimeError] - Shoes not implemented
2020/01/09 13:10:45.431 - [RunTimeError] -
2020/01/09 13:10:45.431 - [RunTimeError] - cEngineSimSubSystem::setShoeState()
2020/01/09 13:10:45.431 - [RunTimeError] -
2020/01/09 13:10:45.431 - [RunTimeError] - d:\build\corerelease\code\dlls\railvehiclemanager\cEngineSimSubSystem.d.h : 152
and back to 2020/01/09 13:10:45.431 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 0 + 3)
2020/01/09 13:10:45.431 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnConsistPass onto stack: JT - Trigger Point (S8 Stop Board 0 + 3)
2020/01/09 13:10:45.431 - [Script Manager] - Trace cScriptComponent.cpp : 365 = Push Function failed due to missing script instance in JT - Trigger Point (S8 Stop Board 3 + 0)
2020/01/09 13:10:45.431 - [Script Manager] - Trace cScriptComponent.cpp : 464 = Failed to push function OnConsistPass onto stack: JT - Trigger Point (S8 Stop Board 3 + 0)
for the entire rest of the scenario (until I killed it 5 mins in having had no disc signal rotation). This loops starts about 18,500 lines in and the scenario ends and moves back to menus at about line 254,500 - so there is a LOT of this stuff repeating endlessly - more than a couple of hundred thousand! Oddly, there is not much else reported as 'positive successes' which surprises me (things are clearly moving in the sim, and 'life goes on', as you've seen in the video) - but it's possible I'm missing it because single lines of 'goodness' don't stand out much in the pattern of repeated bad behaviour, when viewed on the document-map or even in my text-editor main-window itself. Conclusions? Hard to draw any just yet, from my position of little-knowledge about the scenarios actual needs, but my hunch tells me that this 'shoestate' has some bearing on things, quite likely, and almost certainly, there is some kind of dependency on the S8 stock which is, after all, a major requirement for running VDL, and the S7+1 probably doesn't cut it. There's also something 'funny' about those B2AYG fog and repeater signals, which may shine a light (pardon the pun) on a DLC dependency issue perhaps? Maybe the JT Chiltern Extension does something different with those signals than the JT Met pack does? Maybe something's got screwed at their end in the parcelling up of items? Maybe this is only showing up because I don't have that DLC, and the developer team does? Given the various overlaps between Chiltern-London-Birmingham, Chiltern-London-Aylesbury, London-Aylesbury, and Metropolitan, I would not be at all surprised if 'stuff was up the creek'. It's a lot of confusion just to know which would be the cheapest route to even test this theory, let alone what stuff would be being paid-for twice. I do hate JT's pricing strategy sometimes - it sometimes leaves me feeling that I've not just bought old rope, I've bought the same bit of old rope twice! My dilemma now is, do I test out the Chiltern signal theory (and risk wasting another £24.99 + £16.99 on C-L-B and C-L-A to do so and find out I could've fixed it with just the L-A at £24.99)... or do I shell out another £21.99 for the S8 Advanced, knowing full well that - apart from the trigger stops and a passenger view - I've basically bought everything already as part of the S7+1 Advanced. Hmmm, choices choices. I think for now I'll sit tight, and wait to see what you guys think, and whether this is all going to be a moot point anyway with your forthcoming S7-centred update. I'm sure I can wring a bit more fun out of vanilla Metropolitan, and am happy to wait a bit longer for Virtual District Line - especially given its wonderful price point! And if you need any help/beta-testing/compatability-checking, do let me know. I am probably not the only potential VDL user that doesn't have JT's Chiltern or Aylesbury stuff, nor the S8, so if that combination is useful to you to test stuff on, just let me know! Thanks for the experience so far - despite the issues, I'm not daunted, and still think you have done something quite wonderful, which I will eventually get to fully enjoy. And I know I might seem tight, not simply dumping another seventy quid in JT's hands to be able to fix the problem... but really, that seems so wrong to me, especially as I have ALREADY dumped about 80 quid into JT's hands for the Met bundle and Western Expressways and other DLC in the last week! I'd much rather dump that amount into YOUR hands, for the efforts you've gone to, seeking nothing in return, than pay a commercial company twice under what could be construed as false pretences... Happy days, eh? Keep up the fab work, anyhow - it's something to be very proud of.
|
|
|
Post by Eddie on Jan 9, 2020 15:57:00 GMT
The other thing worth pointing out is we released this route back in September 2019, and there have been hundreds of downloads, and yet this is the first time anyone has reported an issue with any of these training scenarios. You are the only person so far. The clue that something has changed in your scenario is that the D78 appears to arrive as the 73TS departs when in fact it should be a bit later than in your video. Check my screen when the shunt clears the D78 is only halfway down the platform, so as Jimi says timing is critical. Ditch the Track IR and other distractions and do the job as your instructor tells you. You are not supposed to be sightseeing. :-)
EDIT I posted the above before I had seen your previous highly detailed look at logmate. The crucial fact as you may have hinted is that on here everyone has the L-A route and now the Met too. We also have both the S8 and S7+1. It could just be that the shunt disc that is part of the Met may be different in some way to the L-A version which is where ours come from. Most of our downloaders have bought the L-A as part of the requirements. As you are a late boarder with only the Met, that could be a possible issue.
I really don't want to tell you to buy the L-A route to find out though, because in theory the shunts should be the same from the LUL common library, but you might have a point. If other start reporting the same issue , then it looks like the Met AND L-A might need to made a requirement.
|
|
|
Post by Jimi on Jan 9, 2020 16:22:58 GMT
I don't see anything in the log fragments above that I'd worry about. There are thousands of what appear to be errors every time any scenario starts. The vast majority are non-errors and the rest are more like warnings or info. You can drive yourself nuts with that stuff unless you are looking for specific things (e.g. debugging signals or in my case a ton of new C69 LUA code).
Please go back and read my post above re timing and then run again and compare your clock times to Ed's. You appear to have everything installed correctly, else you'd get hard errors (like 'failed to load') at scenario start. We are all running the Met, so the Chiltern/Aylesbury stuff is a red herring. The Met LUL signal set is common, not specific to route. That only leaves the scenario itself (and maybe the scenario cache but we've addressed that one).
Ed - can you put a fresh copy of just the released Phase II scenarios folder up on Dropbox, so Jacko can grab and start from a clean copy? Might want to pass the location via PM and not here in public :-)
|
|
|
Post by bigjacko on Jan 9, 2020 16:51:57 GMT
The other thing worth pointing out is we released this route back in September 2019, and there have been hundreds of downloads, and yet this is the first time anyone has reported an issue with any of these training scenarios. You are the only person so far. The clue that something has changed in your scenario is that the D78 appears to arrive as the 73TS departs when in fact it should be a bit later than in your video. Check my screen when the shunt clears the D78 is only halfway down the platform, so as Jimi says timing is critical. Ditch the Track IR and other distractions and do the job as your instructor tells you. You are not supposed to be sightseeing. :-) Fair points, but my defence is (from experience) that just because a thousand people bought (or downloaded) something and never reported a fail, doesn't mean that there isn't something wrong in the shipped product that affects a subset of users. "Absence of evidence is not evidence of absence", so the legal-beagles love to say. In practice, very few people bother to report things, and even fewer are prepared to go deep to try and help find the cause - though I do agree that there is often a much better ratio where niche things are involved, especially high-quality, free, niche things, like this. But (confession time) I've been in the invidious position of having to ship a major licensed arcade game product for Activision in the 1980s, knowing full well that half the levels were not even implemented... and yet we got no complaints from the massive sub-set of users in a certain very popular UK 'book club scheme' that it was shipped it to. Not one, from several tens of thousands of customers. Can't say much more than that in open public (and we did re-ship a working version to that user-group in due course, once the final, final gold master was, er, final). But my point is, silence doesn't de facto mean success. It just means silence. Of course, it could well still be something particular and peculiar to me, I fully concur - but at this point, I'm trying to rule out all likelihood that it is a 'simple purchased or missing DLC combination issue' - something that might legitimately hit a bunch of your other users (silent or not!) at some stage, as your reach broadens. If it's not that, then it's something much, much deeper at my end, and wouldn't pretend it isn't - but I start with the obvious or easy items first and dig down. For example, I might be the first user in your customer-base who doesn't have the S8 AND doesn't have any of the Chiltern (L-B nor L-A) stuff prior to the Met? Unless you've surveyed your users, how would we know? I'm not suggesting you should, of course - but hopefully you get my point. We become more reliant on intersecting sub-sets of users and the hope that one of them may raise a flag. I might just be the first, because I, well, raise flags, because I know developers sometimes want and need them raising! Equally, I might just have something spannered in my decade old set of TS junk. Though I have tried to keep it reasonably well-ordered and fettled over the years, and this is the first time I've had something quite like this outcome. In regards to your other points, I have also run the scenario many times, without the TrackIR, I promise - I deliberately attempted to rule that out quite early on. I've also run the scenario under 64-bit and 32-bit versions of TS2020, and I've run it in Windowed and Fullscreen mode, and I've run it in various levels of graphics settings (always remembering to bring back up the scenary details and density back to max, as per your manual). I've probably played it in excess of 20 times now, in different forms. Testing software is something I have done as part of my living, and luckily, I actually enjoy it! Sometimes, more than the writing it! Also, I agree, the arriving Acton-bound D78 is 'flexible' in its timing, and I think I said as much earlier on in one of my other posts. That's per normal Railworks defaults, I think. Even today, I had a situation where the 73TS was well on its way off out before the D78 even arrived, but the exit-road disc still didn't clear, and (eventually) the D78 went through its usual arrival, doors-open, dwell, doors-closed, pull forward slightly and stop at the greens, after which, it's a guarantee that the exit disc will never clear. The video I posted this morning has the D78 arrive a bit earlier than at other times I've seen it; but it's made no difference whether it's early or late, in my experience with it. My heart always goes up a beat when the 73TS leaves early, hoping "this is the one?" but sadly, no. I have yet to establish the exact moment when the INBOUND disc signal clears from the wrong-line platform at ECM, and it definitely appears to be doing so - that is what is presumably stopping that Acton-bound D78 from leaving the platform, despite its greens. I might have to do a tiny bit of sightseeing to pinpoint the timing of all that. It is presumably set at caution when the first ECM-bound D78 and then the 73TS is incoming, because the points must surely be locked straight then. I'm guessing that when the points get set to exit the depot, the platform disc-end clears, but the exit-road disc doesn't... for reasons I have yet to establish. I might have to get my scalpel out. Heyho. My money's on JT though. Literally. It'll be either the S8 missing, or their bundling of parts. I expect the only way to fix this is to fork out another 70 quid and pray. But we'll see. Thanks as ever, for your patience and advice.
|
|
|
Post by bigjacko on Jan 9, 2020 16:57:28 GMT
Aha, we've been playing 'forum-tag!' - LOL - I do love it when that happens. Jimi - just found your timing post now - investigating. Will report back. Eddie - I didn't realise your post was technically before my logmate post - thanks for the glint of hope, and the epithet of 'late boarder' - I love that! Film at eleven, no doubt. I am (through gritting teeth) seriously considering just stumping up the cash for the S8, though it sticks in my craw and then some. At least it'll rule out one possibility. I will just have to stick pins into my JT voodoo-doll afterwards, to get redress.
|
|
|
Post by Eddie on Jan 9, 2020 17:06:01 GMT
Jacko, I can get you a clean set of the master scenarios folder that shipped with 2.02. I'll send you a pm with a dropbox link. Worth trying just in case anything has happened to the files on the server. Long shot. Your call. Yay or Nay. perhaps try some of the other training scenarios ?
|
|
|
Post by bigjacko on Jan 9, 2020 18:23:40 GMT
Eddie, I'm happy to try that new download - many thanks for going to the trouble. I really don't mind how much twiddling I have to do at this end though. I'm into this now, and actually rather enjoying the Sherlockian bughunt aspect of it all. And, I almost bite my lip here, and say... I did try scenario 02 - the Lillie Bridge equivalent. And, er, I found the 2nd dwarf signal after leaving Lillie for OLY, never cleared, and on the way back (I think into Earls Court), the signal at the entry to the platform didn't clear either. However, I have only played that one+and-a-half times, so it's entirely possible I've done something wrong. I wasn't going to mention that just yet, for fear of confusing matters, until I had a solid set of reproduceable results I could give you. Watch this space (if you can bear it! LOL Sorry!) On to Jimi's timings though.... My usual timings are pretty tight and rapid (I've got used to the drill long since now, though I may have dawdled the first time I played it through, not anymore. I could do this blindfold now, just by audio cues!) These are my timings from the video I posted. They're pretty normal for me, and pretty in-line with what you've outlined in your timings post. 08:00:05: First message, dismiss manually, CTRL-SHIFT-S to set the reverser to FORWARD2 08:00:20: Second message, dismiss manually, SHIFT-F for saloon lights, H for headlamps. Then off I trot, about 10 sec later, usually aiming at about 10mph (as per the advice in the message), probably straight into parallel to get me up quick. Coast into the exit road slot to be there by... 08:01:14: At shunt disc, just as first WB D78 is stopping, and first EB D78 is departing. I definitely see the red 'stop progress' bar in the HUD. Next target shows as "Ealing Common 1". (Jimi says 08:01:08, so 6 secs late)08:01:35: Third message "Good. Now we wait for manline traffic". The red stop-progress bar is gone now. The WB 73TS is approaching and stops at signal waiting for WB D78 to clear ECM at about 08:01:50. 08:02:00-ish: The WB D78 leaves ECM platform. 08:02:16-ish: WB 73TS moves past signal to enter ECM platform. 08:02:35-ish: EB shunt disc (ECMDT wrong-line entry, WM6) confirmed at CAUTION in map view. 08:02:50-ish: 73TS stationary at WB ECM platform. 08:02:55: Fourth message "You'll be following that 73TS..eye on shunt disc" appears. Tried dismissing it manually, and leaving it to time itself out. No difference. (Think this tallies with Jimi's 'you're next' message at 08:02:44, so about 11 secs late here). 08:03:20: 73TS departs ECM WB. 08:03:36-ish: First glint of 2nd EB D78 arriving into ECM. Jimi indicates 08:03:43 as likely time for shunt disc to clear - but obviously not seeing this (at least not at the WM19 end - WM6 may well have cleared by now - I will try and check this on my next go!)08:03:50-ish: EB D78 stationary at ECM platform. 08:04:22-ish: Doors closing on EB D78. 08:04:25-ish: EB D78 starts to leave ECM platform. 08:04:29-ish: EB D78 stops at green signals. End of the line! Nothing ever changes again from here. Jimi has very slightly later timings (4 or 5 seconds) for the EB D78 being held at a RED starter, whereas in my case it's GREEN, despite WM6 being cleared for depot entry, wrong-line (i.e depot exit right-line): Regarding my screenies: - That one was taken after waiting at the shunt for most of that five minutes! It wasn't the same run as in my video, but it was similarly timed. I just decided to take a screenshot at the point where I knew we weren't ever going to get a clear. It's not the point at which I'd arrived at the shunt - not by a long shot! - That's a similarly late photo, just to use as the frontispiece of my video, I think. I wanted to capture the presence of the 'blocking' D78 as well as the stuck shunt signal, that's all. Again, I'd been at that location for at least two minutes by then. Do check out the video if you haven't already, Jimi - it might shed more light. I've tried to highlight where I am located with respect to other things, positions, timing, and reverse views (though I still need to check a few more, evidently). I think my timing isn't too shabby, and certainly ought to be within expected bounds. I'd say we're roughly similar, and certainly I'm not dawdling to the point where the D78 should ordinarily have grabbed the route. Whilst there is a tight zone between the departure of the WB 73TS and the arrival of the EB D78, and in practice (on mine), the D78 does believe it's getting the road (hence two greens - see video), it actually isn't fully, because the WM6 wrong-line depot entry shunt has already cleared - presumably just as the 73TS was leaving the platform, or had cleared the platform starter (I will try and pinpoint that shortly). But because the WM19 depot-exit shunt hasn't cleared, or because the points have shifted, the D78 is held by the dispatcher, even though its signals are (imho WRONGLY) cleared. Something's definitely gone potty with that interlocking, by the looks of it? IRL, there's no way that a cleared WM6 or the points being set for depot should allow the two platform signals (WM5 & WM7) to clear, surely? I'm also not entirely sure whether the points being set for the depot-out road should even clear WM6, should they? I mean, the train is coming OUT, not going IN? But then again, being a manually controlled signal, who knows? Seems iffy, from an interlocking POV but this is the LU, after all. Their practices are sometimes a tad 'tighter' than BR, and this may be perfectly normal. Either way, not sure. There's something odd going on there, the more I think about it. IMHO the sequence should be... 73TS clears ECM WB starter and frees up that TC, WM5, WM6, WM7 all should be at danger, and the WB signal approaching ECM, and WM19 depot exit. Then - and only then - can the points change to set road out of depot. And then, ONLY WM19 should clear, to signal direction, to a clear ECM WB platform. WM6 shunt should stay at danger, surely? Having played with TS's dispatcher and interlocking (such as it is) shenanigins myself over the years, I know this isn't going to be easy to fathom... but I think maybe this has something to do with it. Possibly due to the components involved - possibly not... but I am back to suspecting the JT kit in its various DLC forms and packagings. If it's not breaking any EULA terms, am I ok to have a poke around in the route and scenario editors a bit more deeply? At my own risk. of course? Just to see how it's wired up, in case something obvious is adrift, or a component has gone bad?
|
|
|
Post by bigjacko on Jan 9, 2020 19:41:03 GMT
An updated video for your perusal and entertainment, chaps. Voiceover on this one (but a little quiet - sorry - I was rushing a bit). And no TrackIR. TL;DR - there is something wonky with WM6, for sure! Enjoy.
|
|
|
Post by Jimi on Jan 9, 2020 21:08:38 GMT
What is hard to fathom is why it works for us and other users and not you. And BTW you don't know our user base too well if you think they don't report what they think are bugs. But it's usually multiple people reporting the same thing. Once in a while we get a "solo" report and we have to try and diagnose - as is the case here.
The outlet shunt should clear once the 73's rear end has passed the ECM WB stater, as the platform block is now empty. You are next in sequence, before the D78 that is about to enter ECM EB. As you are getting the sequence of messages we can conclude you are stopped in the right place and the dispatcher is aware you're waiting. That WM9 clears is simply that it seems a path between itself (it's Link0) and the section of track it relates to - the path into the depot which happens also to be the outlet path you're on. Check the 9 view while you are waiting. it will let you see ALL signal states and which paths are currently set (mainline WB/EB, depot entry/exit, etc.). That may reveal some more.
I'd be inclined to re-install the scenario from the "kit" Eddie PM'd you about. That would allow us to eliminate one simple variable. I just re-ran the scenario and it works exactly as designed. Something is clearly not right, and I doubt we need to look too deeply. Occam's Razor applies.
|
|
|
Post by Jimi on Jan 9, 2020 21:25:23 GMT
Just checked your video. There's almost certainly something wrong with your signals. The 73 started up against a red home signal. Someone else a while back reported a slew of signals issues and I'm trying to recall the cause. The scenario is trying to run correctly. It's actually the signals that are NOT displaying the correct view of the world.
Instead of moving the camera all over the world, just bring up the 9 view and watch the signal aspects and track paths that are set. I'm close to betting they all show correctly. So I'm leaning towards tour JT signals not being right (we use JT shunt discs too, in addition to the LU signals). The rest of us likely started with the L-A JT route to get the signal stuff, then added the Met. Both use a common set of LU signals, and the Met provided a superset of LU signals, which we have not YET taken advantage of - added tunnel sigs etc.
Make sure you are running the scenario from the "drive" option, and not route or scenario editor option. The latter do not fully initialize the route and signals.
We will figure this out. Please check the 9 view and tell us what you see.
|
|
|
Post by bigjacko on Jan 10, 2020 0:56:33 GMT
Sorry for the delay, Jimi - been cross-checking the wife's PPI compensation settlement (needless to say, they've stiffed her for several hundred quid, but we've done the math, and will be on to them tomorrow! LOL) Anyway - couple of points to respond to, before I set off and remake that video from the map view perspective... 1 - didn't mean to imply anything ill of your user-base, or your awareness of them (and did say that in niche products the responsiveness is usually way better than in 'mainstream' stuff where people don't seem to care). Was just trying to make the point that although I'm 'first reporter', doesn't automatically mean it's all fat-fingery stuff at my end. 2 - You mention you're not yet using the LU common signals that Met provides - yet, as per my Logmate report, it's evident that the only place that some of these signals exist is in my MET-provided LUL folder, and not in my other JT common folder (see above for the specifics, in the logmate report). Because it appears full absolute pathnames are not being invoked in the log (and maybe the script), I wonder if somehow Railworks is searching and finding alternatives (possibly unsuitable ones) in a different relative path instead? I'll try and document exactly what I've got, in case that'll help. It is beginning to look like some variance in JT's packaging arrangements between Met and Chiltern/L-A versions, maybe? 3 - the 73TS starting against the red - my voiceover was a bit quiet there, but I cracked the gag about "the instantaneous green that only AI drivers can see." That wasn't an entirely fatuous comment - it's been an issue of old, that (for reasons I can only put down to Railworks) sometimes AI drivers get their right-away before the signals have even responded visually. But in code terms, it's a 'safe release' - the train is actually given the clear, albeit only by the code, and the signal is immediately reverted back to red by the passing train, before it's caught up visibly. I have seen that so often over the years that I thought it was an accepted 'thing' in Railworks. If you're telling me that never happens for anyone else, then... gulp! That's been with me on Railworks since, well, the very first ever install of it back in 2003 (as Rail Simulator), and every version of Railworks/TSxxxx since then! It has moved from HDD to HDD a few times since then, and possibly been entirely reinstalled from scratch maybe once or twice in that period, but always with whatever the latest offering Steam has had to give, rather than by going back to my aged CDs or anything daft like that! And I've never intentionally messed with any inner signal-workings - though I might've installed one of the old UK signal packs many, many moons ago. Auditing this all is going to be a fun job - might take me all summer! LOL But I'm game... 4 - FWIW, I have only ever accessed the scenario/world editor once, right at the beginning of all this, just to check exactly where the intended stop point was (because it's a little tight on the HUD, and I wanted to see exactly where it was, and whether it was part of the route core, or the scenario). In all my other proper testing, I've never launched this from the editors - just from the standard TS starting menus (choose Standard, choose VDL route, choose D78, choose Scenario, choose Start, choose life, choose Trainspotting, etc, etc). I'm aware that starting scenarios mid edit from the editor is an unreliable thing at the best of times, and a bloody nightmare the rest of the time! Like I said, I've built a few scenarios over the years, and probably thrown more than my fair share of shoes and coffee-cups at the dispatcher and the AI's inability to touch a consist after the player has. It's partly this experience which makes me take my hat off to you guys, for the excellent work you have done. That's some serious commitment right there, and it shows. Anyway - enough blather. I'll get on and make that map 9-view video and audit the various JT signals. Probably have something for you by the morning. Thanks again for all your help and patience.
|
|
|
Post by Jimi on Jan 10, 2020 1:15:08 GMT
Responses: 1. If a load of folks report something, we have to initially assume it's a problem with our stuff. If one person reports it, we have to initially assume its a local issue. The preponderance of evidence in each case guides the investigation, and history of investigating these supports the approach. 2. No I did not say we weren't using the common signals that Met provides. Met ADDED to the common set by adding some new tunnel signals and a few others. We are still using the JT LU Common set that L-A initially provided. The Met uses those too, but others specific to the Met route were added to the common set. We have not yet leveraged those but plan to as the tunnel signals now available are better than the post signal we are currently using for parts of the VDL. TS does not search around for signals. Each is hard coded into the tracks.bin file for any instance of the signal. Logmate has never displayed full paths, only sufficient to identify things. Pathnames in TS tend to be very verbose. And FWIW the signal set JT has provided I feel strongly is the best I have ever seen in terms of appearance and functionality. It just works exactly as it should. Same for the UKpro set we use for the NR sections. And we have spent countless hours carefully positioning wiring and testing them. They are a key and totally visible part of any route and must be believable and function correctly.
3. There was no green shown to the 73, and this has to be a signal fault. The proof will be the 9 display which accurately shows signal aspects. Signals do not always get messages from other signals telling them to re-assess their state. E.g. when the D78 left and passed the ECM WB starter, a message should be sent in rear to the Home to reassess the situation. It should find the block ahead now clear and then change to green. This is purely visual, and totally separate from the dispatcher telling the 73 train its OK to go now.
I wrote a post elsewhere before release to set folks expectations about the signals and how good they are and that users should believe what they see. Some of us are certainly used to poorly written signal code and signals that fail and we EXPECTED to have to TAB past a broken red one - rather than believing it's reading correctly that the track section ahead is busy.
I'm left thinking there has to be something in your TS installation that is corrupt or is interfering with the JT signals. We know they are all installed, located and wired correctly in the route; and work correctly for a very large install base (thousands of downloads). If the signals were faulty we would be buried in bug reports. We have had a few bugs reported by multiple people; notably the issue with the JT S8 SPADding past a red shunt disc. JT has since fixed that by implementing a gadget (that we have deployed on VDT and will include as part of the next update) that suppresses such a SPAD. You have also noted signal issues in a number of locations, not just at ECM Dpt. Again, this is unique to our user base; but multiple signal issues suggests a generic signal problem and not an issue with a specific signal or location.
The one thing where you MAY be unique (I don't have the data) is you are starting with the Met as a JT common signals base and not L-A. Both routes ship with an "LU Common" set of signals, but with the exception of the ones added for the Met specifically, they SHOULD be the same. Note emphasis :-)
Would you please also enumerate any other locations you see unexpected signal behavior?
Please use the 9 view to see what's happening with both the signals and the track paths. At this point I don't trust the signal aspects.
|
|
|
Post by bigjacko on Jan 10, 2020 3:32:35 GMT
OK - video with map view here:
I hope I've framed it well enough. It's clear that the 73TS is off and away before that signal into ECM WB platform has shown green on the map view. Why, I have no idea though!
I did have a poke around in a clone copy of the route, to see what signal object names I could glean for our suspects. Alas, it's not clear from the editor, because they all refer to RailNetwork\Signals\Signals\JTLU-name-of-signal-here relative filepaths, rather than showing the complete path to the object which is actually in use. Editor limitation, evidently, as you indicate. Not sure where to look to find the full monty, if it's even possible to find.
I appear to have two repositories where JT LU signals are found:
E:\Steam\SteamApps\common\railworks\Assets\JustTrains\LULibrary\RailNetwork\Signals\Signals
and
E:\Steam\SteamApps\common\railworks\Assets\JustTrains\CommonLibrary\RailNetwork\Signals\Signals
The LULibrary ones (552 files) all seem to have been last-modded on 18th Nov 2019 15:38, and created on my HDD on 31st Dec 2019 19:30 (this despite the fact that I have uninstalled Met since then, and re-installed it yesterday - see earlier comment about my hunches on JT's handling of what it may regard as 'DLC-shared' folders)
The CommonLibrary ones (2,964 files) fall into two distinct batches:
2,892 of them are all prefixed JTMS_ and are last-modded 08th Nov 2019 19:13, and created on-disk 31st Dec 2019, 19:24. Pretty sure that's when I installed JT's South Western Expressways that I bought over Christmas hols.
The remainder (72 of them) are all prefixed JTLU_ and these match (but are a subset of) the filenames in the LULibrary set. Importantly, these files are different to the LULibrary ones - they have different content in the .bin and .xml, in terms of internal relative filepaths, names, Blueprint IDs, parents, etc. Not vast differences, but (without seeing the actual scripts), potentially enough to throw a spanner in the works maybe, if they were getting invoked somehow? These files are all last-modded on 02 August 2017, 18:39 and created on my disk at 12 March 2018, 11:38.
By deduction, I think I've worked out that these CommonLibrary JTLU files are NOT installed by JT Met, and instead come from JT's Western Mainlines v1.13 era, because I have kept the installer for that (despite having a couple of newer ones and some hotfixes - I'm a bit OCD about keeping old installers) - and the creation timestamp for that WM installer is 12th March 2018, 11:30 - a mere 8 minutes before. Presumably they were used for the Paddington/Royal Oak/Westbourne Park area H&C signalling.
I could try pulling these CommonLibrary LU signals out temporarily - but given what you've said about TS not going hunting for files in other places, I'm guessing they're not even being called-for, and they're a red herring? CommonLibrary does contain versions of the JTLU_Sem_1T_Disc and JTLU_Sem_2T_Disc signals that are different from the ones in the LULibrary repository and are the ones under scrutiny (WM19 depot exit is a 2T_Disc, WM6 depot entry is a 1T_Disc).
I suppose if the CommonLibrary ones are being ignored, then the acid test will come down to whether your London-Aylesbury LULibrary repo objects match the last-mod dates of my Met-sourced ones? 18th Nov 2019 15:38 - if they're all the same last-mod, we can reasonably safely assume they are all byte-identical, if not, well... further investigation may be in order, and we can pick a few to compare more closely, if you're up for it.
Many thanks again for your continued help, in any case. I'm really sorry if this is a pain for you guys.
EDIT: Oh - you asked for other instances of odd signalling. So far, I've only played this 01. Training and 02. Training (twice). The only other oddity I've encountered, I already mentioned previously - the 2nd depot-exit 2-aspect dwarf on the way out of Lillie to OLY didn't clear, and the (I think) 4 aspect immediately before Earls Court platform didn't either (but that may have been a dodgy approach handling on my part - will test later - need some sleep now!)
|
|
|
Post by Eddie on Jan 10, 2020 14:33:28 GMT
The dodgy colour shunt at Lillie Bridge exit to OLY, we know about. That has been playing up, but hasn't broken any scenarios. So, it's a known issue at the moment.
Check your PM.
|
|
|
Post by bigjacko on Jan 10, 2020 18:32:14 GMT
Hi guys,
Thanks Eddie for the download pack. Less than wonderful news to report, sadly.
I've run everything though my file comparison tool (UltraCompare) and it seems that my LU signal repo is a perfect match for Eddie's. The only difference in the entire batch is the lastmod date on his Blueprint.pak (mine is a few days newer) - but the files are otherwise identical. So - that rules out any difference between JT's Met and their L-A packaging. But at least it eliminates one line of enquiry at last, so thanks Eddie for that.
On the Scenarios front, yes, many file changes, so I dumped my existing Scenario folder into a backup zip and deleted the lot, before replacing them entirely with Eddie's versions.
I also took the opportunity to remove all of my JT Western Mainlines CommonLibrary JTLU signal files - just in case. Absolutely no chance of them being invoked now (not that there probably really was before, but I feel better doing it, LOL).
Anticipation was palpable... but alas, no difference in behaviour. The 73TS SPADs that signal prior to ECM, and WM19 never clears.
I'm at a loss.
I'm going to do some experimenting and see if I can cook up a short testbed route and see how these signals behave and whether AI trains follow correct aspects in a less complex situation - just to rule out something utterly, utterly weird going on with my install. Whatever it might be, it clearly survived a 'Verify Files' op the other day, so goodness knows what it might be. The last possible 'obvious' difference I can think of is something between the bundled S7+1 Advanced, and the missing S8 Advanced. If I get nowhere in my signal testing, that'll be next, I think.
Cheers for now, and thanks again.
|
|
|
Post by Eddie on Jan 10, 2020 19:08:54 GMT
Well, it was worth a try. I'm presuming you did a SDBCache.bin delete as well ? There are plenty of other good scenarios worth running in the pack. Might be better to leave 01 alone for a while. Let it ferment.
|
|
|
Post by bigjacko on Jan 10, 2020 21:46:55 GMT
Well, it was worth a try. I'm presuming you did a SDBCache.bin delete as well ? There are plenty of other good scenarios worth running in the pack. Might be better to leave 01 alone for a while. Let it ferment. I'll be totally honest, Eddie, no - I forgot that step. But I have just done it again now, and retried the scenario, with the same result, alas. Another thing I tried before dinner was another Verify Files Integrity - just for shizzles. Very unexpectedly, it came back with 1261 files failing (it was 1266 a couple of days ago, and I got that down to zero for absolute certain, because I re-ran it immediately afterwards, that time). No idea how that can have gotten so altered in that short space of time - even if it noticed I'd taken out the Western Mainlines JTLU files (which I doubt, because they are JT's, not DTG's), that would only account for about 74 files, not over a thousand. Ah well. I'll give it some thought and I'm sure something will come to mind (aside from the S8!). I gave Scenario 3 a go just now, and everything worked fine. No problems at all, and much fun in the C69. My kids were particularly impressed with Putney Bridge station - we stayed at the Premier Inn there in November when we saw the Tutankhamun exhibition, and we used that station a lot, so it's sort of become 'their home station' a bit. Happy to say we recognised much, the approach roads, the buses and their stops, the Premier Inn building itself (sort of) - even the little newsagents on Putney Bridge itself. Top notch work, guys. Really good show.
|
|
|
Post by Jimi on Jan 11, 2020 1:58:47 GMT
Your comments on Training 3 are good to hear, and that it was recognizable and stirred memories fr you is great. Also very pleased you're finding some workable scenarios to try. It seems the issue is around that shunt disc, which has given us various issues before. We will keep poking at it from our end, and hope you find much more enjoyment in the other scenarios, and in the not too distant future, with the new ones we are going to release in V2.03. Our best to you and yours.
|
|
|
Post by Eddie on Jan 11, 2020 9:55:04 GMT
I've found that if you get a dump in TS, just once, you will lose about 1200 files in one hit. Whether these are critical or not is a mystery. It does seem that version 68 2c, the current build is prone to dumping with out of memory crashes. Just search the UKTS forums for reports about that issue. It seems to be that people who have really powerful game rigs are suffering the most from these sorts of issues right now, 32Gb RAM and big graphics cards, so trouble is afoot in the TS game itself. Just run as many scenarios as you can and enjoy those that do work.
Nothing new with TS falling over, we've been here before many times over the last few years, but one rule seems to be worth noting . Use 64 bit to run scenarios and 32 bit to edit.
|
|
|
Post by bigjacko on Jan 11, 2020 12:57:15 GMT
I've found that if you get a dump in TS, just once, you will lose about 1200 files in one hit. Whether these are critical or not is a mystery. It does seem that version 68 2c, the current build is prone to dumping with out of memory crashes. Just search the UKTS forums for reports about that issue. It seems to be that people who have really powerful game rigs are suffering the most from these sorts of issues right now, 32Gb RAM and big graphics cards, so trouble is afoot in the TS game itself. Just run as many scenarios as you can and enjoy those that do work. Nothing new with TS falling over, we've been here before many times over the last few years, but one rule seems to be worth noting . Use 64 bit to run scenarios and 32 bit to edit. Useful insights, those, Eddie - thanks. I'm racking my brains to remember if I had any OOM crashes between the time of the previous FIC and the one yesterday. I believe maybe I did (I tried running Training 02 in 32-bit app and it OOMed //EDIT - scrub that... timestamp of that OOM crashlog is 8-Jan-20 18:00, and I did my first FIC on your advice, on 9th Jan 1:50AM, so it's not that!//), so that might be the reason. Wasn't aware of the "1200 files die every crash" rule-of-thumb. I shall religiously FIC after every OOM hereafter, knowing that now! LOL. Thanks for that gem! Also didn't know about the play64 vs edit32 rule either, so that's handy too. Oh, and FWIW, my rig is by no means 'super-fast' by today's standards, but it isn't a total potato, either. i5-2500K (best of the unlockable i5 Sandy Bridge cores, and still pretty nippy) with 16GB system RAM to eat, and an ASUS GTX970 Strix 4GB graphics card. Yes, it lag-spikes on occasions with some TS routes, but then, so does even the 1080Ti with latest-model i7s, I'm told! I run things at 1920x1080 for the most part, so I'm still ok for a while - I'm not bothered about 4K resolution just yet. I'm going to spend today tinkering with some test route editing and AI handling, to see if I can get to the bottom of this 'no green aspect shown to AI' issue. Like I said, I've seen it so often in the past (particularly on my scenarios involving many AI in Bristol Temple Meads) that I had put it down as a 'one of those TS things', and not recognised it as a sign of something properly wrong. I want to root that out once and for all, if I can. I also want to climb Everest, become an astronaut, cure cancer, create world peace and get a lung transplant. It's possible I might not get all of those things done today, but one would be nice.
|
|
|
Post by Eddie on Jan 11, 2020 14:08:20 GMT
I'd say ALL of those are possible today with one notable exception..........fixing TS. DTG with all their resources can't fix it. Why does 64 bit mode stutter more than 32 bit on a tile load. In fact why have a tile load in the first place ? it should be buffered ready to go. What we have to remember here is that basically what we are running is a program that has become incredibly powerful, but hugely bloated too, from the original Rail Simulator that it started out as. It's quite remarkable that it runs at all. Where the despatcher and signalling system are concerned it is complex junctions, diamond crossovers, slips et al , all the sort of things found in abundance on LUL metals. These cause all sorts of problems in busy places where lots of services pass through.
For e.g Signalling terminii stations is still a huge problem, because the TS despatcher doesn't necessarily see am empty platform as a clear block. That 03 Training scenario refuses to clear the home W375 , despite the fact the platform is clear, so we made it an opportunity to test the tripcock reset.............:-) You'll be better off watching some paint dry. That's a much more productive use of time than trying to fix DTG's badly coded current build.
|
|