Anybody has this? It's not working for me. Shift-B does nothing, I can't setup that loco no matter if QuickDrive or in a scenario. I have checked the InputMapper, that's the vR standard keybind and should work. It seems the mapper doesn't get loaded at all. W/S also doesn't move the reverser which it should even with battery off. Edit: It seems this loco really only works in 32 bit (Edit: I just chose the other loco not knowing only one has the issue, so it seemed the cause) - I have contacted VR after checking their site for a 64 bit fix to no avail. Also testing on a pre core update install, it was already 64bit incompatible at that time. File stamps show 2015. What did Maik Goltz do there? The scripts for the 103 run perfectly well on 64 bit.
I have the BR 120 VRot and although I can move the controls, I have the Pantograph up and the main switch in. But the loco will not take power More important the Brake Gauges don't show any pressure The HUD shows brakes applied or released but the loco won't move.
Doesn't matter, the 120 ORot IR EL was already broken there in 64bit. Honestly, I think the DTG version (looks like a Reppo model) looks much better. I can't stand the ugly instrument lights in VR locos.
More experimenting with the current version As you go in to the Cab the Brake is in Emergency and needle moves to 0.Bar No changing of the brake handle will cause the brakes to release. I swapped to the non Expert line and that works perfectly
That's normal, cold and dark state Expert Line. You should then press Shift+B to turn the battery on, reverser to Cab Only, start the compressor and activate PZB, wait for main reservoir to fill, release the brakes to 4.7 bar, select panto, raise panto, close MCB. Release handbrake and you're set. All that works - but not in the 120EL.
The scripts are quite different on those two locos. The 103 uses a script base that i call V1. The 120 uses V2 and since the 101 (2015) it was V3. And tbh i don't remember anything as that is over 10 years ago since i made them. I guess it started doing the code in a sort of OOP style and the V2 script was a transition between non OOP and with OOP.
I ran the VRot EL version not long ago without any problems - I did not turn the compressor on in the test I did
The state of the main reservoir is random. Sometimes it's down so you need to fill it to 10bar. Sometimes it's full at start.
Latest test on v72.3 with VRot EL loco The loco told me to switch the compressor on - it was at 7.bar which I had thought would be enough - it was not. Having got 10 Bar it was Panto selected then raised Main Switch on Brakes released and depart
I can hammer Shift-B but it just won't do anything unless I start in 32bit. No matter if I start it from C:\Steam installation or in my E:\Railworks path. I can rule out any DRM issues that expect the game to be in Program Files (x86) Ulf just said I'd be the first to report this. No idea what's going on. Tested on v72, v75 and latest version. New standard scenario, placed the loco, added driver. Nothing. The last thing I'm checking may sound weird, but I've seen horses puking. I'll see if it's related to the frame rate and cap it at 30 (normally running at 75).
Sounds more like a input mapper problem than one with the loco itself. You might have some other DLC that collide with the 120s input mapper what would explain the Shift+B not working as its probably overridden by a different mapper with the same mapper name. A common problem in TSC. I don't think that there is a 64bit only issue. If there would be an issue with the loco it also would not work on 32bit. The older 64bit problem with the "0.000000" not being 0 but "0.000061" was solved after i spent days in explaining what was happening to DTG back then and they have fixed that issue.
Simple standard scenario, using 120+9 IR wagen consist. Nothing, battery won't turn on. I can move the handles but only by mouse, not keyboard. So no FPS timing issue. I'll just redownload the pack from the store now.
That's the file name, not the mapper name. The mapper name is in the file as field called "ID" i guess. Such an ID can only be once game wide. If any other DLC uses the same ID it collides in an random order. And that tells definitely that it might be a mapper problem. It's not the loco. Some other DLC/Mod has a mapper with the same ID.
Reinstallation seems to have fixed it. What's even weirder is that the reinstallation shows no difference other than the .xml files I have deleted. Does the game need these? I'm even more confused. I'm always deleting xml, tgt and cost files.
Wait - I have modified the headlights - I'm usually removing the ugly lensflares this way. Maybe the script that allows headlight dimming has an issue with that. As I hate the lensflares, I'll just replace the texture here with an empty transparent bitmap as a fix.
Edit: Again. It's not the flares. So it must be the xml files. No it's not. It's the preload. The 9 IR wagons doesn't work - it's using the Dynamic numbering version. It looks like this is the one that's affected. The 7 car IR does work, it's using the nondynamic version. Damn I can't give up.
What version of the 120 do you (try to) run? I have never been able to run the dynamic numbered version (as you say keys don't work) but the numbered version works OK. Since this was one of the first (if not the first) vR addon I brought I have always stayed away from dynamic numbered vR-locos as player loco.
Maik Goltz Here's the issue: The ORot DynNr version references the VRot mapper which I don't have. That's why nobody complains as most have both packs. It's like DTM couplers which refer to textures from other DTM locos The LocalisedEngineName is also VRot - copypaste job with a tiny but consequential mistake. Change "V" to "O", issue solved and reported to Ulf. Will delete the xml junkfiles again. Now my QD is working Yes the Direct brake is still applied even if the lever is in the release position. Small quirk, just move it a little and it'll release. Time for a well deserved beer. Drink and drive, PZB's there Fix is attached. I have also corrected the localised engine names from VRot to ORot correctly in both engine blueprints.
Hmm, that's an ugly issue there. I don't remember why. But i usually did not named the mappers by their livery when the technical sides are the same, to prevent such things. Probably happend by batch renaming the paths in the files to do the ORot copy. Curious that over the years (at least until end of 2018 where i left vR) no one reported such an issue to the support. Maybe because all bought both variants and so the mapper was there anyways. And no, i can't fix it. It's not on my behalf anymore to do that. Try to get Ulf to fix it. He claimed all my work for himself when i left.
As the cause has been located, I don't need Ulf to fix it. Checking rail-sim.de, I've seen people saying to just not use the DynNr. Probably no one did report the issue. And probably Orientrot is the least popular (and thus short-lived) DB paint scheme. The 103 in ORot with that white bib is considered a visual crime
