Edit: The Class 60 and 180 revamp packs have been updated in June 2024! Thought I'd make a thread on this one. As many have reported, the MJW Class 60 tends to crash the game, which might be due to scripting issues. It crashes TSC as soon as I select it in the editor and place it onto the track. EDIT: That was probably due to the fact I spawned it on GEML which is known to have issues. I have the DTG Class 60 which is decently modelled but has way off physics. And I've got the vintage JT Class 60 which has good physics but looks heavily outdated and bad compared to the DTG model. As I see it, MJW took the best of both worlds and merged it into the Revamp pack. Anyone got it running or is in contact with the author? Testing it on v72, it works Edit: Just tested on the latest build - it seems to work now.
Now tested on v75.8a (public stable), cloned a South Wales scenario to replace the DTG with the MJW, just selecting it in the list crashes. Works in Academy though... will test the same again and see what LogMate gives. EDIT: Further testing lets me conclude that these crashes only occur in the current v75.8a I had no trouble using it on the beta build - it seems the underlying core issues have been addressed.
I'm not sure it was actually a scripting issue, afaik the script gets activated only as soon as you place the loco on the tracks, does initialization and then halts, but it crashed as soon as selecting it from the stock list in the editor. I've loaded up a South Wales scenario in the beta (scenario 01 of the DTG Class 60 pack) and placed all MJW 60's on the track without any issue, swapped it out succesfully. So we have the TPWS issue left. Let's see about that. Peter's "brute force" method of disabling the route based scripts in the TPWS bin is clever though, but maybe there's another way. The JT Class 60 is no option. It's outdated and pretty ugly. EDIT: Seems to really work stable on latest build
I'm assuming they're all .out scripts in the MJW60, I don't know how you'll get around the TPWS issue, but then your cleverer than me so.. One suggestion is try the other Bens* script, see if that works as intended https://alanthomsonsim.com/downloads/dtg-class-60-scripting-patch/ *I say "the other Ben" because MJW's name is also Ben, there was a hoo haa regarding plagiarised parts of this Bens script being used in MJWs script, and the evidence was pretty damning too. Unfortunately as MJW's version is a whole pack including lots of reskins, child objects and such the other Bens mod will be rather limited in just fixing the physics on the DTG offerings, but may be worth testing to see if it works as intended with v75.8a.
Have you read the comments? Apparently it modifies the original DTG Class 60 scripts - and not for good it seems. MJW is using his own scripts using a different path which are not affected by this it would seem.
Not overly sure as I've never used it myself, I only knew about it because of the Facebook ruckus last year (or year before)
Yeah, no interest in modifying the DTG Class 60 as its main use will be AI, and player locos will be swapped for the MJW on my end. Now playing service 6A12 only to see how massively overpowered the DTG 60 was Struggling... but fun. More time to watch the landscape . Still amazing what the VegEP did to the visuals of the route. Without AP sky and veg it looks completely different and has these black mountains. (Correction: That was NWC with its terrible default TimeOfDay files)
Extract the dummy TPWS grid from the .ap archive, rename it as the default version. Repeat for however many variants you need to fix.
Don't want to fix what's not broken. I'm thinking of trying to disable the TPWS in the loco by hex editing the .out script. The loco scripts waits for a message sent by the grid script. If I just change the message / event name it could work (or crash). Just flipping a single byte could do the trick.
it might just be worth uploaded the updated physics to train sim community i think that would be greatly appreciated
Not easy - it depends. There's many ways to compile a lua script. Some from Maik Goltz are pure unreadable bytecode, some only tokenize commands and leave variable names intact. You will lose all comments anyway and need to figure out what does what. The more knowledge you have writing (TSC) Lua scripts yourself, the easier you can reconstruct the source. But that's nothing I've done yet. I'll just try the direct hex method and change "TPWS" strings to something else like TPXS or whatever, my idea is that the grid's trigger message will not be detected by the loco this way.
a modular collection of lua scripts would be so welcome, but obfuscated .out scripts are considered even more valuable than shape files any .out script can be de-obfuscated, however the resulting pseudo-lua usually won't compile into .out format again, but at least you can study certain functions.
AP have left all their scripts in the Class 37 Pack in plain Lua - highly appreciated. Lots of tricks to learn from there. I'll see how I can mess this up a little Trial and error has always been my way I just checked the TPWS asset script, it seems the message passed between the scripts is the string "overspeed2" which is also found in the loco script - maybe changing that to overspeedX is enough. I have a feeling this triggers the emergency brakes. Aaand I need to setup a test scenario putting me right in front of an active grid...
No luck yet. This is what TPWS does and the messages it sends to the train Code: -- ON CONSIST PASS -- function OnConsistPass ( prevFrontDist, prevBackDist, frontDist, backDist, linkIndex ) -- If the front of the train is before the link and the back is beyond it, -- or vice versa, the train is in the process of crossing the link if ( frontDist > 0 and backDist < 0 ) or ( frontDist < 0 and backDist > 0 ) then -- If the front and back of the train were previously both before the -- link, the train has just started crossing it forwards if ( prevFrontDist > 0 and prevBackDist > 0 ) then -- Request state of next signal local nextSignalState = Call( "GetNextSignalState", "", 1, 1, 0 ) -- Find out how fast the train is going and the speed limit at this point local consistSpeed = Call ( "GetConsistSpeed" ) local speedLimit = Call ( "GetTrackSpeedLimit", 0 ) -- Send the appropriate TPWS_MESSAGE to the train if (nextSignalState == BLOCKED) then Call( "SendConsistMessage", TPWS_MESSAGE, "blocked" ) elseif (consistSpeed > speedLimit) then Call( "SendConsistMessage", TPWS_MESSAGE, "overspeed" ) elseif (nextSignalState == WARNING) then Call( "SendConsistMessage", TPWS_MESSAGE, "warning" ) elseif (nextSignalState == CLEAR) then Call( "SendConsistMessage", TPWS_MESSAGE, "clear" ) end end end end
That would seem to be how TPWS grids should work, so just what is the issue with the class 60...in what way is it faulting?
BritishRail60062 and 749006 reported faulty triggering of emergency brakes on the MJW Class 60. (Though I haven't found a fault yet) And Ctrl+Q should toggle TPWS, it shows a message, but it's permanently active nevertheless. So the goal would be to deactivate it.
So there may not be any issue with the TPWS, other than the false reporting of it's state. As I alluded to in the other thread, Peter hadn't done the obvious--checking the link placement for the grids, and the speed setting in the over-speed grids. There has been numerous reports of "bad" TPWS grids, most fixed by ensuring the grid's link is before Link 0 of the signal it's protecting and DTG's WMCML-S had buried grids in addition to the ones visible so it's worth checking that too.
If the TPWS grids themselves were incorrectly placed/set up, wouldn't that affect any train rather than just this modified class 60?
Yes Steve, but if you read Peter's posts in the other thread you'll see he was lumping several issues with the Cross City signals (think of AWS/TPWS essentially being signals) together in a conversation about the 60, without properly investigating any faulting signal/grid.
No. You assumed I had not checked the grids I had and looking at the those in Bromsgrove station I did not see any faults as they did what they were supposed to. I tested them with the Class 68 and had no false applications
I was replying to to illustrate a simpler way of achieving your outcome---no disabling of scripts needed, just a case of copying and renaming .bin files. Run your tests again, I've just driven from Bromsgrove to New Street with no issues, though I do have a Tracks.bin file outside of the .ap archive dated 16/3/2023 so I may have worked through the route correcting any link placement issues.
I did not disable the scripts - they are still present I stopped the TPWS bin files seeing the scripts by removing the reference to them So I modified the bin files one way - you are suggesting doing it slightly differently.
So is your MJW Class 60 working fine then? I would be more than happy to post a video as proof of the fault which make the Class 60 practically unusable in its current state. It's not so bad on the JT Midland Mainline route but in terms of the orientation of the TPWS ramps. I wonder if some are incorrectly orientated which is cause the TPWS to flip out? Hence that whilst the signal facing the player may be green. The signal away from the player will be at danger and the 2000hz magnet would be armed in that state. If the TPWS ramp is the wrong way route then I bet that is the cause of the false TPWS applications right? Well if that is true then it seems I am stuffed but I suck at coding and scriptiing and I would assume that the routes affected would need to be completely reworked in those affected areas to make the TPWS ramps work properly? So whilst I could do this fine with a cloned route for personal use if that fixes the problem. It means any scenarios I make would be unfit to use with this MJW Class 60 pack?
No. all you need to do is make sure the link for the grid is passed over by trains before the signal's Link 0
As I've not come across issues myself and can't find any valuable exact bug repro steps, I'll not bother with trying to change anything anymore. Swapped it for the SWC Class 60 scenarios and played them w/o issues. It correctly stopped me at a red signal. It stopped me overspeeding in front of a 15 mph speed limit correctly. It did not stop me at clear signals. The only thing is the TPWSActive toggle does not work. Its default ControlValue state is zero, but the script somehow has it set to active permanently. Maybe that can be addressed by MWD at some point. Messing with compiled scripts is not good.
Yes - on v75.8a it crashes most of the time (only got it to work on Academy). Interestingly with a dispatching/network error in the logfile, just by clicking it in the editor - but that core bug obviously got fixed. No crashes whatsoever on my Alpha build (I think I'm allowed to say this), it should be the same as the public Beta in that respect. Reef, you got any idea why I'm not allowed to start a private conversation with you? Get an error message.
My bad, I changed my privacy settings ages ago because an internet warrior from the clan snow of the flake was constantly messaging me, should be OK now, I've just updated my privacy settings.
Again you had a go at me for doing this but you also suggested it yourself.in post #28 Your pedantry has not changed.
You must be running it in the wrong country - No 2000hz magnets on UK Routes. It is dead simple to check if the TPWS Magnet is correct or not. In the Editor double click on is an a Link Box appears with an Arrow pointing in the direction it applies. The is an error with the AWS Magnets as it sounds for wrong direction magnets. Departing Bromsgrove the AWS for the Red signal in the Cheltenham direction sounds even though the train is going the other way.
This is all confusing. What I'm reading here is issues with a route, not the loco. Run any other TPWS equipped stock and see if it makes a difference. Someone can zip a repro scenario and upload it here?
Cross City is the worst offender for the TPWS but it does happen on MML but not as much. I can knock up a video of the issue later if you wanted to see proof.
So, found a bummer. Northbound to University P1, this stopped me on a clear signal. Track speed 50, my speed 40. I will try if another loco does the same, then it's not a MJW issue but a route TPWS issue. Edit: Second try - no issues. The grid is ok. The only difference between the two runs is the first was played straight from the editor, the second one from the Drive menu. Never test using the editor Play button, as signals will not be correctly initialised.
No problem for me with a class 323 set or the default Kuju BR Blue class 47. If it was the MJW class 60 though, surely it'd throw wobbler at every grid?...it's the same script reacting to the same message.
Kuju stock doesn't have TPWS, only AWS. Even the DTG Class 323 is not fitted with TPWS. You can happily run over red signals.
TPWS is enabled by the trackwork... if you move a grids link to be well before a signal and place another train after the signal to cause a stop aspect the default 47 will have an emergency brake application when you pass the grids link. And yes, I've just tested it (twice)
Just tested the 323. The grid may send a signal but it's not processed by the loco script. AP stock features TPWS, but most RSC/DTG stuff doesn't. It'll only end the scenario if Career or "SPAD ends game" enabled. The old Kuju stock only uses the core AWS script provided by the game, once AWS triggers you have 4 seconds to confirm - else emergency. Nothing more. Same for the BCC 323. The game engine will stop you with a message, not the TPWS system as it's not there.
