I am thinking about getting a TrackIR and/or Raildriver to enhance my TSW experience. However, I was also wondering if they work with other games, so that their use would not be limited to TSW but could enhance other experiences as well. It is quite hard to find reliable information, so I would like to address the people here for some help/advise For those of you that own one or both, what is your experience with them in other simulations, for example TramSim (TrackIR and Raildriver) or The Bus (TrackIR). Have you tried them there, do they work? Is it a nice experience, or is it not that worth it (since they might miss native support in the game)? And now asking about this, I am also wondering if anyone has a VR set-up and some experiences to share how well that works? I read that TramSim for example should support it, but does it also work in TSW? I know there is currently no native support, but with the TrackIR support coming, VR is (I know, I will get hate for this simplification, but I just want to put it that abstract) basically the same, just that the screen moves with your head. And for some stuff Steam can serve as a capable middle man, so I was wondering if VR might somewhat work. I am looking forward to your experiences, thanks a lot!
Cramnor Raildriver works with TSW2 (both Steam & Epic versions) - native support TS2021 - external helper needed from the maker of RD (most versions of) Trainz - current 2019 supports it - native support World of Subways 2 and 3 but not 1 or 4 - native support Run8 - native support MSTS - external helper needed from the maker of RD I regularly use it on stream if you want to see it in context of game play (link in signature). I don't have Track-IR but I do run OpenTrack in combination with an Android App SmoothTrack and they work quite nicely in the Epic TSW2 version. It works in TS2021 but is decidedly weird. I've not tried it with anything else, but I've seen people using it on stream with various flight simulators. As for the VR questions, sorry I cannot help with those. Paul
I've used my Raildriver with TS2020 and Trainz, and both work really well with it. The current implementation with TSW2, though native, is not so good so far IMHO. The main attraction, the levers, don't seem to synchronise very well, even after calibration. TSW has only only recently started to support Raildriver with TSW2, and it is said to be in "Beta", so hopefully it will improve. I've discovered from threads on this forum that TSW2 uses sequential keypresses to move the throttle and brake levers rather than analog axis, so it may be difficult to achieve full synchronisation with physical lever positions on the controller.
anorak - its quite variable across the various locomotives - I think the implementation in the 4.26 build on EPG is quite pleasing and playable for the most part except the wiper switch on SPG which when "off" seems to continuously send "wipers off". Curious where you heard its translated to key presses - I've not seen anyone from DTG say that, I've seen plenty of people guessing how it works . Paul
Maybe I've made the wrong assumption with that Paul. I was thinking of Drakoz' Target script for the Warthog throttle control. He went to a lot of trouble writing it so that forward and backward movements of the levers were translated to up and down keypresses, with pauses between them, so that they would stay synchronised. I'm also thinking about the raildriver "calibration" process, where it stores preset positions of the throttle and brake levers, rather than just mapping the axis.
Ah, ok now I get it. RailDriver doesn't work that way, well not quite that way. I have seen the traffic from RailDriver using a USB inspector in the past and it gives discreet values along the axis of movement for each of the levers (and the switches for that matter). All of them are implemented using rotary potentiometers (see wiki https://en.wikipedia.org/wiki/Potentiometer) - they're perfect for analogue things like volume and power controls but notoriously difficult to convert the reading of the POT position which is measured in OHMS into a digital value. POTs by their very nature drift in value with changes in humidity and temperature and other factors. In circuits there is usually a POT that the user controls and a trim POT that a service technician controls to limit or calibrate the POT. In RailDriver the digital calibration process manages the job the service technician would do. POTs are commonly used in joysticks and the like even though there would be much better more digital ways to do it such as rotary incremental encoders (see wiki https://en.wikipedia.org/wiki/Incremental_encoder) but these are much more expensive. To give you an idea, I just checked my local supplier and a POT like the ones in RailDriver is about AU$2 an encoder with a similar range of movement is about AU$75. The difference between the two is that the encoder will always give the same values and will give an exact series of values through the range of movement, POTs give variable values that may increase or decrease through the range of movement. To try and explain this better, if you had an encoder and a lever that gave you say 30 degrees of movement and you "told" the encoder that the 30 degrees represents the values from 0 to 100 it will give you 0, 1, 2, 3, 4, 5... up to 100 in precise increments through the movement. The POT will give you values more like 0, 1, 2, 3, 10, 100, 1500, 25000 through the range of the movement so a very small lever movement can generate a massive change in the resistance of the POT which the RailDriver is in turn digitising. In an ideal world the RailDriver itself would be "smart" and would handle the calibration internally giving discreet values but in reality RailDriver is 20 year old technology from an era when a suitable controller would have been half the production cost of the device which has not changed at all in those 20 years. Even though such a controller would be a minor part of the cost today it would mean games would have to handle the different generations of RailDriver. So to cut a long story short, it isn't really storing the position of the lever, it is storing the boundaries of the range of movement as a number range. You can actually see these values in the file raildriver.ini if you care to look at what is being stored for each of the levers before and after calibration. The software then uses these range values to try and determine where the lever is actually positioned using interpolation of the current reading vs the known range of readings. Some of the early feedback I gave was the TSW2 implementation of the readings needed hysteresis and limiting (meaning don't take the instant reading - the simplest method is to take a average over a short time discarding readings that are wildly different from the normal) and I've been very pleased to see that this has been implemented. I've noticed four distinct changes in the way the levers are read across the releases since the first incarnation. Today in the notching for the throttle in particular I see this working better and better as things progress. Cane Creek for example has a really good implementation, some of the earlier ones are not so good. Its possible this is baked into each locomotive as older ones show some improvement over time but not as much. Paul
I can appreciate the vagueness of resistance measurement at intermediate potentiometer positions Paul, just a simple wiper on a carbon track. ..and also how much more sophisticated encoders are, counting pulses digitally. The surprising thing though, is how weel the raildriver controller works with TS2020 and Trainz, usinf 3rd party and native support. By comparison, the TSW2 accuracy is very disappointing so far.
Trainz uses the DLL from PI Engineering. TS2020 is controlled via API from a separate executable made by PI Engineering that manages RailDriver and communicates withTS2020. Unless it's buried in a pak the PI Engineering DLL is not present in TSW2 so they may have gone their own way. Paul
WOW, that's an explanation and a half! But it turns out that I know something that you might now, so I want to share it with you. When looking into buying a raildriver not so long ago I stumbled into this page: https://xkeys.com/technology/mdmtm.html It is a piece of technology that PI Engineering created and patented and it looks like it is used in the Raildriver controller (scroll down to the bottom of the linked page). From the link above: The RailDriver® Train Cab Controller utilizes MDM™ for all moving levers and switches. The controls are mechanically linked to a single “PCB sandwich” with six separate MDM™ arcs and sliders. Combining all controls on a single PCB footprint simplifies design, lowers production costs, and improves reliability. I think its something interesting to know and you can read the patent documentation here (https://patents.google.com/patent/US7602376), its filled with a large quantity of complicated vocabulary and mathematical equations. That's all from me for now
That's funny, that patent is basically, take a bog standard POT, connect a lever to it, constrain the movement of that lever by putting a fence around it. Well that's about every slider control ever that works in an arc. I doubt their patent would stand, someone from the 1900s would get them on prior art. Yes there is a panel of xkeys buttons in the RailDriver - they are the buttons along the front of the unit. They're basically buttons that can be programmed to do things. Paul
Guys, i appreciate your discussions, but they are completely off topic and no contribution to my original question let's keep this on topic please, still looking for more contributions and experiences
TrackIR is essential for me in most simulators - especially driving and flight, I literally won't play either if I can't have head tracking. So, firm recommendation from me everywhere you can possibly sensibly use it - which is a lot of places these days RailDriver is obviously specific to trains and it works well where it's used but good fun when you do. If you play lots of different train sims that all have support for RailDriver then it's difficult to see a down side. VR is massively more than just head tracking A completely new UI, hand-controller tracking, direct interaction with the 3D world, a different way of doing the "HUD" (as corners of the screen dont exist when you're in VR) and countless other issues to resolve. None of them particularly hard or time consuming to implement, but never the less all needing to be developed. If you want VR make sure you say so in Sam's latest survey, it usually ranks bottom of the list Matt.
