|
Post by bigjacko on Jan 11, 2020 15:56:50 GMT
LOL - don't get me wrong, Eddie... I'm not looking to fix TS; just to see whether the 'borked bit' in mine, is borked for everyone else, or a specific, locally-introduced borkedness that only applies to my install! I'm just trying to get to 'standardised borkedness level', that's all As an aside, an old Argonaut colleague of mine worked for Kuju on the original Railsimulator for EA, where things like the Editor core decisions where taken, and still remain for the most part. Needless to say, he has had nothing to do with it since then. And this is TS's root problem; it's had so many owners, and so many follow-up developers, that its tricks and techniques, documentation and even some of its core knowledge or long-term plan have been long since utterly lost in the intervening years. It's why certain much-called-for fixes to really obvious things, have never been addressed. Simply put, it's not worth the forensic object-code debug that it would entail, without documented source-code (assuming such ever existed. Knowing the aforementioned dev concerned, who shall remain nameless, he had a tendency to label routines in his source with things like 'Brian' and 'Hetty' rather than useful label-names that made sense six months later when optimising. Not massively helpful, tbh). On the 1261 files issue, I found this post of old, which is moderately interesting. steamcommunity.com/app/24010/discussions/14/492379439688864898/Seems it may be a red herring, and inadvisable (or at least a waste of time) to do too many file integrity checks. Apparently the 1261 files warning caused by blueprint.pak files - not sure whether it's seeing new, freshly-compiled ones and barfing at the different timestamps on the referenced files these paks refer to, or whether it's complaining about the pak files being old (though I only seem to have about 43 paks, not 1261, so it's most likely the things they're pointing to, rather than the paks themselves). Anyway, the 'solution' is apparently to wipe the blueprint cache (either using the DOS script in the post, or using the TS Settings Clear Cache operation, which is apparently exactly the same thing, embedded into the game itself). Then they won't signal a conflict, and won't cause this 1261 files jazz. I have yet to put that to some solid testing, though... It does line up with my situation, though - despite not having had any crashes since the 8th Jan, I did run the editor (once), and I did do a specific blueprint refresh in the blueprint editor once too - either of which would've changed the timestamps on my pak files, and thus de-synced them with the files they point to. I think that's what's going on in my case. In any event, it only seems to matter if the game won't run - and then usually more than 1261 files are at fault anyway (as was the case in my first FIC on the 9th - I had 1266, not that it actually stopped me running the game, but clearly more was going on than 'normal' integrity issues caused by these blueprints). TTFN
|
|
|
Post by bigjacko on Feb 3, 2020 0:40:10 GMT
Yay! SOLVED IT!! Yes, it was down to me and my install 'being different'... because I had only the S7+1 and not the S8 installed. The problem is due to the fact that the VDL utilises the S8 triggerpoints from the Railworks\Assets\JustTrains\S8Stock\RailNetwork\TriggerPoints folder, and not from the (apparently) more universal Railworks\Assets\JustTrains\S_StockMarkers\RailNetwork\Triggerpoints folder. I say 'more universal', but I don't have much to go on other than a hunch that JT are intending for the S8 triggerpoints to be reachable for S7+1 owners via this method, but forgetting that they are duplicated in the S8's own folder tree. For example, I do not know whether you end up having that S_StockMarkers folder if you possess only the S8 Stock, in which case, there may be problems in the future (for more than just VDL, frankly). If you are an S7+1 owner (like me) there are a shedload of triggers in Railworks\Assets\JustTrains\S7+1Stock\RailNetwork\TriggerPoints, but these are all specific to the S7+1 - at least in terms of their names. They all follow the naming pattern jt_triggerpoint_s7+1_thingy.xml whereas the S8 ones all follow the jt_triggerpoint_s8_thingy.xml pattern ( where thingy means the type of trigger, obv - substitute sensible names here!). This has the effect that when VDL goes looking for the triggers on its station tracks, it's looking in Railworks\Assets\JustTrains\S8Stock\RailNetwork\TriggerPoints and finding sweet nothing there. Silently, this partially wrecks signal behaviours thereafter, but not totally (which is where the real debugging hell starts!) I've not quite worked out whether there are particular signal-types prone to fail, after the missing S8 triggerpoints have been invoked, or whether it's literally just down to the order they appear in the track.bin or one of the other Networks files - but frankly, I don't care much now I've fixed it! THE SOLUTION:If you're an S7+1 owner, copy all of the content from Railworks\Assets\JustTrains\S_StockMarkers\RailNetwork\Triggerpoints and its Textures subfolder into Railworks\Assets\JustTrains\S8Stock\RailNetwork\TriggerPoints (recreating the Textures subfolder there too, of course). If you don't have an S8Stock folder, make one first and recreate the folder tree from there. You probably will have one, if you've installed the audio tweaks for the S-Stock, but if not, just make one, with a RailNetworks folder inside it, and a Triggerpoints folder inside that, and put the stuff in there, etc, etc so you end up with the same result as above). I have tested tonight, and now the depot-exit signal at ECMDT West Outlet in the first Training scenario finally swivels round!!! Similarly, the WM23B signal that holds the 73TS just prior to its arrival at ECM, now does a proper clear to green and yellow before the 73TS lurches away. The key to my solving this? The District Rover, believe it or not. I had a similar issue with signal GM14 not clearing - the one before Kew Gardens. AI would do its normal pathing, but the signals behind it didn't clear, and I couldn't continue without TABing (same as was the case at ECMDT exit, if you recall). Every signal thereafter was also red. And these were UK Pro signals, not LU ones, so I really began to think my whole signal install was up the creek. Once again, I ripped my install apart looking for errors and corruptions, but found nothing. Then today, during a conversation with Simon King at JustTrains (with whom I've been discussing the cost of the S8 and the S7+1, and how essentially they are 100% the same object with nothing to distinguish them apart, other than a handful of Aylesbury scenarios that would seem very overpriced to an S7+1 owner!). He said that JT's original view was that nobody would need to buy both, and that JT thought they were interchangeable, basically. I replied that the S7+1 has its own triggerpoints, and the S8 had different ones, so clearly any route constructed with S8 triggerpoints wasn't going to work properly for an S7+1 owner, therefore of course people would feel compelled to buy both. And that got me thinking... and then during a dig in the Editor on my cloned copy of VDL, I noticed that the S8 triggerpoint under the track at Kew Gardens was showing up as a milk-bottle. I remembered something about default milk-bottles, and realised that this means TS doesn't really 'see' that asset, in the editor. That is to say, it's not wired in, not selected in the Object Browser. After a bit of hunting in the files and folders, I discovered that I did already possess those S8 triggerpoint assets, just not in the place that VDL was looking for them! So I took a punt, and copied them over to where the route expected them to be, as explained above. And then when I looked at the S8 triggerpoint at Kew again, this time it was a nice green box with S8 words on it, like it should be. So I gingerly re-tried District Rover, and bingo... that GM14 signal cleared. I was grinning from ear to ear, and crossing my fingers with anticipation and hope... quit out, and tried the 01 Training scenario... and it darn well worked just as it should! I nearly woke the household up with my cheers! Dogged persistence is my middle name, evidently. Anyway... now I can carry on enjoying VDL as it should be enjoyed. I haven't yet tried the Lillie Bridge 02 scenario yet (to see if the Earl's Court platform entry signal clears), but I am sure it will. I've played a lot of the excellent scenarios in the VDL pack, and many do complete (though occasionally a TAB was needed here and there) - but I am sure they'll all be fine again now. I guess the 64,000 dollar question is whether it would be better for VDL to depend on the S_StockMarkers triggers, rather than the S8Stock triggers, for full universality between whichever S Stock units users have bought, but I guess that may all depend on whether JT have created them in that S_StockMarkers folder for S8-only users too. If they are not, please let me know, and I will suggest to JT that they ensure this folder is created for both the S8 and the S7+1, and at least that should help route creators in the future. FWIW, I have asked JT for some documentation on the LULibrary signals, and am hopeful of some response (it's been referred to the right team, apparently), so they do appear to be listening and taking stuff on board - after all, the more these S Stock units are supported and enjoyed across various routes, the better it is for them and their brand. And if JT are genuine in their view that they didn't expect people to buy both, they'll improve their reputation if people don't feel like they're being ripped off (which is the case now, I'm sure, given what I've seen from reviewers who've all questioned the wisdom of JT's current price policy). Cheers for now... off to drive the District a bit more before bedtime! Still beaming from ear to ear!
|
|
|
Post by Jimi on Feb 3, 2020 4:10:37 GMT
Good work Jacko. We had already changed the markers in our in-development v2.1 version to be the "S:S" versions (rather than S8), as this better suits the District. A quick check in the editor shows these are sourced from jt-triggerpoint_s7+1_stop_etc. I sense (and stand to be corrected by Xavier) that this means the S7+1 is a requirement now. In light of your discovery we may need to look at this more closely. We will discuss as a team quietly, and report back here.
However, this is VERY good news that it solves the rogue signals issues as we were all at a loss to understand the cause.
|
|
|
Post by Eddie on Feb 3, 2020 12:52:21 GMT
We changed the stopping boards Jimi to be S:S but I think we left the old trigger points in place, unless I'm recalling it wrong. In which case what Jacko has discovered could have implications for people without the S8 anyway. I've used the old JT AI S8 as static objects here and there in scenarios. Looks to me like S8 AND S7+1 should be requirements unless we rebuild some old scenarios.
|
|
|
Post by Jimi on Feb 3, 2020 16:00:40 GMT
Ed - I dbl-clicked on a stop box (under the track) and the provider/product was jt-triggerpoint_s7+1_stop_etc, and not s8_stop. I believe Xavier has changed out (via TS Tools?) both the stop trigger boxes and the visible S:S stop boards. Let's discuss quietly as a team and determine any impact on pre-reqs (e.g. S7+1).
|
|
|
Post by bigjacko on Feb 3, 2020 17:04:24 GMT
One thing to consider, chaps... and that is what is JT's policy on supplying the triggerpoints for the 'other' S-Stock that the user (maybe) didn't buy. Like I said, in my case (which is S7+1 only), I have all my S7+1 triggers inside the S7+1Stock subfolder. These same S7+1 triggers DO NOT exist in the 'common' S_StockMarkers folder - only the S8 triggers exist there. It's my guess (but I'd love to know for sure) that the converse situation - an S8 owner without the S7+1 - will have all their S8 triggers in their S8Stock folder, and the only things in the common S_StockMarkers folder will be those for the missing S7+1. In which case, this is mayhem, really, and JT need a thump. As I mentioned, I'm in 'mid-discussion' (albeit delayed by a few days inbetween exchanges) with JT's team, and I've already raised the point with them that the S7+1 and S8 are clearly NOT perfectly interchangeable, and that route-creators are going to have a nightmare knowing which to support. The specific case I raised is where a route covers, say, top Circle Line, where S7 H&C, Circle and District stock as well as S8 Met stock, will co-exist on the same lines. Which triggerpoints is a route-creator meant to put on those platforms? And if they are not 'universal', how is a player with just one set of the S Stock going to get the route to work properly? I await to see if there is some magical response along the lines of 'the S7 and S8 triggers are identical and the LUA code they spit out has the same effect on either model' (which would be lovely, because the problem of players needing to buy both models is then truly gone). OTOH, they might come back and say that they've goofed, and that yes, players may need both, and thus the S-Stock pricing is therefore ludicrous, and do a better bundle (I live in hope!). In any event, whatever the outcome of that conversation, I think it is imperative that JT bundle up BOTH S-Stock packages with ALL the S7+1 and S8 triggers in the common S_StockMarkers folder, or else route-creators will never stand a chance. If they did that, then route-creators can just pick one - whichever suits them for their route - and at the very least, anyone missing 'the other S-stock' will not suffer, because they'll still have the triggers available (in the S_StockMarkers folder) for the train they don't have. Remember, it's only the ABSENCE of the triggers that are built into the route, which breaks the signalling; it's perfectly feasible to have triggers that don't apply to the S-Stock model purchased. The route would still run, error-free; it's just that the TCMS and CCTV displays probably wouldn't show up (big deal, meh). I'll let you know what pans out! IMHO, JT need to sort this out before you can realistically decide what to do. And remember, they say they DON'T expect players to need or want BOTH S Stocks, so if you make both a requirement for VDL, it may well bring in JT more cash, but it will also bug some of your prospective users no end, I expect. Time for us to see if JT is as good as its word!
|
|
|
Post by bigjacko on Feb 3, 2020 17:14:18 GMT
One other thing I noticed, which frustrates useful examination via the Editor...
The Editor only reports the pathname of the triggerpoints from \RailNetworks\ downwards... so it's impossible to tell whether these are expected to be in the S8Stock, S7+1Stock, or S_StockMarkers folder, by using the pop-out menu. You can figure it out in some cases by referring to the Object Browser, and by a process of elimination, maybe work it out (i.e. if the S_StockMarkers and S7+1Stock folders are NOT referenced in the OB, then you know it has to be looking in S8Stock (and that should show up as ticked in the OB). However, if all three are 'included' in the OB, you don't have a clue!
Only way then to find out, is to de-SERZ the various Network files and see which is referenced there in the un-binned XMLs. PITA to be sure!
|
|
|
Post by 23kdahs on Feb 3, 2020 21:03:46 GMT
I brought this up on the JT Twitch channel They could if you buy one you get the other one free.
|
|
|
Post by bigjacko on Feb 3, 2020 21:50:51 GMT
Jimi - little bug-ette, maybe? Just discovered signal W371, at the southbound end of Wimbledon Park Platform 2, doesn't appear to cover the crossover from Wimbledon Depot exit (the one from Wimbledon SWT 1 line, into Wimbledon Park P1). I discovered this on Yawwie's District Rover, when I got slammed in the side by the 1653 Wimbledon Depot-Waterloo (via East Putney 3 SWR) Class 444 that ran from Wimbledon Siding 2 along that depot road, and then crossed (or tried to) right through me! I had passed W371 on yellow, not red, I promise! It's a 3-aspect auto, 0-link. I suspect maybe it needs to be a 3-aspect 1-link, with link 1 on the other side of the crossover, on the SB line from Wimbledon Park? Maybe? I also noticed that there were some signals guarding the platforms at Richmond and Wimbledon which have their plates stuck out in the track (they cut through cabsides as you're passing). I'm guessing this is a bug in the placement of the plate on the JT model (it's the tunnel 2-aspect auto 0T, I think. Are you seeing the same effect? If so, has JT been made aware? I might squeeze that into my convo with their signals team (when they get in touch), if you like? Cheers EDIT - also picked up that the free roam for ECT has a bit of corruption in the UTF-8 charset, line 124, I think. The 'P' of platform has been turned into a hex zero. RW_Tools and the Name-my-Route widget pick it up, but I don't expect it'd stop the scenario from actually running (haven't tried it yet, tbh, and I have since 'fixed' my copy of the file).
|
|
|
Post by Jimi on Feb 4, 2020 0:34:10 GMT
Good catch. That signal, among others, fixed in the next update. So far we have link fixes or other changes for: WG15 / WG4 (PBR WB/EB, change sig type) W371 (WPK WB starter, read across SWT depot EB x-over)
W373R (WIM approach, new approach control repeater) WB33 (WKN EB, read across OLY x-over to ECT tunnel and EC300/EC3)
WK1A (CPK-GUN diveunder merge - added repeater head to give more advanced warn of WK1B at red) GB15R (KEW-RMD, new approach control repeater) OP5 (ERD WB P3 starter, moved so starter visible from all cabs, incl S7)
The various repeaters were added as SPAD mitigation changes, to give the operator more warning of a possible red ahead, especially at converging junctions. Some of the new scenarios (part of next update) can have another service with priority so you have to be alert...and stop in time. Dummies guide to LUL Signals:Green - it's your turn Yellow - it's about to not be your turn
Red - it's someone else's turn Green over yellow - it's your turn, for now, but about not to be.
Regarding the tunnel signals and the plates - we will fix that in due time. As it seems very likely that the JT Met will be a VDL requirement going forward, one big benefit that gives is we can leverage all the extra LUL signals, especially the new tunnel types, that the JT Met added to the LUL Signals Set. That signals change won't happen in the upcoming update (v2.1) but will as we expand the route further around the Sth Circle as part of future work. Please (everyone) don't ask when - we don't have schedules :-)
|
|
|
Post by Eddie on Feb 4, 2020 13:20:54 GMT
Jacko, you're in good company getting sideswiped at Wimbledon Park Depot. It happened to Thomas who runs JT's TV channel. He posted a great video on YT reviewing this scenario by Vulcan Productions. As Jimi points out above,we have now fixed this signal ( and improved many others too ), as part of the update. However, it is worth watching because Thomas really loves this route, and I venture to suggest it had an impact on JT's Met line as a result. Particularly, the quality of the stations, which are well up to Richard Scott levels. :-)
|
|
|
Post by bigjacko on Feb 4, 2020 15:17:59 GMT
Thanks guys - really appreciate that, Jimi and I'll make sure not to mention those ones if I encounter them. I am spending so much time on VDL - it really is my most favourite route on TS, ever. Hard to say why - it's just so many variations, such great detail, so immersive and every run I discover some new asset that is a head-turner. It is *really* well made. How on earth you did this for free, I shall never know - but it truly does shine through as a labour of love. I am really grateful to you all. And more than happy to help in any way, if you need an occasional guinea-pig/beta-tester/proof-reader. "Yellow - it's about to not be your turn" - I'm still giggling at that one. Many a true word spoken in jest! LOL @eddie I had seen (the existence of) that YT video, and normally I watch all of Tom's stuff (including his Twitch channel a couple of weeks ago where he gave me some hints about JT's LUL signals). However, I *deliberately* did not watch this District Rover video, because I wanted to experience it first-hand and knew it would be a massive spoiler if I watched it before playing! Haha, so the 444 nailed him too, did it? I shall have to watch that just for his reaction. It completely took me by surprise. I think I may have said something rude very loudly in front of the kids. Oops! OOOh - while I think of it... you probably already know this but last night I did some playing around with the S stock triggerpoints. I've got a little dummy route that I cooked up to test my JT signals when I first started having the problem with that disc shunt signal at ECMDT, remember? Turns out that the S7+1 train (which is all I have) DOES respond to BOTH the S8 and the S7+1 trigger-points, insofar as EITHER will turn on the CCTV screens in the cab. This might be useful - but of course there is still the problem of where JT puts the damned things. If they put the S7+1 ones into the S_StockMarkers folder only when you own an S8, and vice versa, then it still means from a route-creators point of view, you cannot 100% depend on the existence of either being in S_StockMarkers, and thus make the route able to interchangeable use either S-Stock. The only logical solution for this is for ALL of the S-Stock trains to forget about looking in their local folder for these triggers, and for BOTH trainsets to have ALL of their triggers - and the missing S-Stock's triggers too - in that shared S_StockMarkers folder. It's too much to expect users to make pseudo-folders for the missing S-train they don't have, and copy it all across (like I outlined a few posts ago). It works, but it's a PITA for users to have to do. No, really, JustTrains have to rethink this, and ideally, before too long. I'll see what they say (still waiting for a reply to my messages at the weekend). Something else I figured out (but again, you probably know this, but then again, maybe not, going by the triggerpoint I found at Kew Gardens). Each of the triggerpoints for the stopping point has a number+number in the name. I'm pretty sure this is for the formation length. Thus an 8-car S8 needs the 4+4 one; an S7 needs either the 4+3 or the 3+4 one. The other combinations I think are for different-lengthed units. As far as I can tell, it dictates either the point at which the CCTV screens go OFF, when leaving the station, and/or the doors indication on the TCMS. It does seem a bit hardwired and inflexible, if it supposed to detect the train (which might be any length, in theory) - but then again, if it dictates to the train the MAXIMUM length available on the platform for doors-opening, and suppresses the door-opening symbols on the TCMS, that might explain it. I'll do some more testing, but I believe that's what they're about. Cheers!
|
|
|
Post by Jimi on Feb 4, 2020 18:40:38 GMT
The numbers in the stop triggers (e.g. 4+4) refer to the number of cameras and thus images in each screen. Longer or curvier platforms use more cameras. When I sited the triggers, I checked how many cameras Ed had placed on the platform and used that number - so if a picker of nits or counter of rivets checked, the images would match the platform cameras. Just because we can :-)
And the screens appear to turn off after the whole train has passed the berth point - or thereabouts. Roughly the length of an S8.
|
|
|
Post by bigjacko on Feb 4, 2020 18:46:31 GMT
The numbers in the stop triggers (e.g. 4+4) refer to the number of cameras and thus images in each screen. Longer or curvier platforms use more cameras. When I sited the triggers, I checked how many cameras Ed had placed on the platform and used that number - so if a picker of nits or counter of rivets checked, the images would match the platform cameras. Just because we can :-) Ahhh, makes sense. My bad, then, sorry. I guess I was looking at the wrong rivets in that instance! I'll have a play with that tonight, as well as the other triggers that look interesting. I've seen Tom demonstrate most of them, but there are couple in there that I'd like to run through their paces to see what's going on. I'm curious now about how they make the 'short-platform' door interlock work... I'm sure I've seen that on the Met or somewhere.
|
|
|
Post by Eddie on Feb 4, 2020 19:25:11 GMT
Correct name for that is SDO.................selected door operation. I believe the real train uses sensitive edge to work out which doors are disabled. I don't think the JT train actually simulates this, but the sensitive edge alarm can be triggered in a scenario, if one wants.
|
|
|
Post by 23kdahs on Feb 5, 2020 12:51:55 GMT
Wait does TS do this if a door is off the platform although it does not open any doors on that car. So it is halfway implanted into the game.
|
|
|
Post by Xavier on Feb 5, 2020 13:56:57 GMT
Wait does TS do this if a door is off the platform although it does not open any doors on that car. So it is halfway implanted into the game. No but if it were, that's how it would appear.
S-stock is an exception though as the door open controls will open all of them anyway. At the moment, the markers only control the CCTV monitors in the cab.
|
|
|
Post by Eddie on Feb 5, 2020 16:11:04 GMT
Underground stock often does have all doors open, which can be seen in bay platforms whilst the train is waiting for departure time. So, I imagine the S-Stock had this feature built in for realism. It can certainly catch you out if your driving gets too casual.
|
|
|
Post by timbo1963 on Apr 26, 2020 22:15:25 GMT
Hi there,
This is a terrific project, and I must thank all the creators and builders of this project for it's creation. I am having some problems in getting the standard tube stock in Phase II to work. For some reason I cannot get the master controller, (Deadman's Handle) to engage to set the reverser to the FOR position for some strange reason? can't set the Weak Field flag setting either? Keyboard controls don't seem to function either. The brake lever is the only thing that seems to work using only the mouse. The only other controls I can get to work are some of the switches using the mouse, (Cab light, Headlights) and that's about it. I can use all the other stock just fine, including the Met electric loco with no problems at all. Any ideas or advice would really be appreciated! Many Thanks, and looking forward to the rumours of the R49 stock too!
Cheers
Tim
|
|
|
Post by Xavier on Apr 26, 2020 22:46:40 GMT
Hi there, This is a terrific project, and I must thank all the creators and builders of this project for it's creation. I am having some problems in getting the standard tube stock in Phase II to work. For some reason I cannot get the master controller, (Deadman's Handle) to engage to set the reverser to the FOR position for some strange reason? can't set the Weak Field flag setting either? Keyboard controls don't seem to function either. The brake lever is the only thing that seems to work using only the mouse. The only other controls I can get to work are some of the switches using the mouse, (Cab light, Headlights) and that's about it. I can use all the other stock just fine, including the Met electric loco with no problems at all. Any ideas or advice would really be appreciated! Many Thanks, and looking forward to the rumours of the R49 stock too! Cheers Tim Assuming you are a relatively new user, at the end of installer you should have got a batch command window up (black with white text) which is an automatic command to delete a number of old inputmappers which were from previous versions of standard stock and others. I don't suppose you saw whether it ran ok? It ahould have paused before closing. Because it sounds like the inputmappers are still there. You could check by going to your Railworks installation folder, then going to Assets/Kuju/RailSimulatorCore/InputMappers and if you see the following files, just delete them: standard_expert.bin 4sub_expert.bin 4sub.bin
|
|
|
Post by DeepChillWolf on Apr 27, 2020 20:42:05 GMT
I have noticed that it seems like S7 stopping markers are causing my TS to crash occasionally. When the train encounters the object, my game either crashes or hits a mostly unnoticeable lag spike. I assume this is a bug, as I am not having issues otherwise (except for one crash on a junction and in the main menu).
|
|
|
Post by DeepChillWolf on Apr 27, 2020 20:44:45 GMT
I have noticed that it seems like S7 stopping markers are causing my TS to crash occasionally. When the train encounters the object, my game either crashes or hits a mostly unnoticeable lag spike. I assume this is a bug, as I am not having issues otherwise (except for one crash on a junction and in the main menu). Sometimes it'll give me an out of memory error. However, it haven't got one recently so I can't take a screenshot.
|
|
|
Post by Eddie on Apr 28, 2020 12:49:24 GMT
Go into your Railworks folder and open up the TempDump folder. Delete everything in there. Should stop that happening.
|
|
|
Post by nati045 on May 29, 2020 10:18:18 GMT
Hello Devs,
I found a bug recently when playing the scenario with announcements (shuttle service from Olympia to High street Ken and back multiple times.) At task 7 out of 12, Shuttle service 2 stays stationary just before High street Ken platform 3. He is held by a red aspect (ED11), there for I can't pull into High street ken platform 4. The platform seems empty to me so just wanted to report that.
|
|
|
Post by Eddie on May 29, 2020 16:14:03 GMT
Try this : Go into your Railworks folder and find the Content folder. Open that up and look for the file SDBCache.bin. Delete it. Don't worry TS will rebuild it next time you launch the game.
Then restart the scenario.
|
|