Discussion in 'General Discussion' started by Wheelzz, Apr 1, 2018.
Does anyone know if TSW now has rail driver support or is getting it soon?
No, Raildriver is not supported and I don't think it will be soon.
We are getting a lot of requests for it to be made compatible with TSW but at this time there's no Raildriver support. We won't rule out the possibility of it coming to the game eventually though!
But why "eventually" and not "for sure" if you get that many requests? Is it that hard to build in support?
It is so much nicer and more realistic to play with this device instead of clicking around or using the keyboard! Please, give it priority...
I think it's pretty clear that "eventually" means
There's a whole load of stuff that's higher in priority and which will benefit many more people than just those who own a raildriver.
Jay is not going to say "for sure" as that commits DTG to adding that functionality and once he does that people start complaining it's not been added yet and demanding it's done right NOW.
As I recall the reason TSxx has raildriver support has a lot do with DTG Matt. The same Matt that's currently the senior producer of TSW and who I'm sure would love to be able to use his raildriver with TSW if only there won't all these other higher priority issues such as the Passenger Information System, erratic and downright wrong AI dispatch and signalling, missing 6 car 166s in GWE, sound quality, scenery optimisation that doesn't just mean reducing the quality and a whole host of other issues in front of it.
I'm sorry, but everywhere that I read about the Raildriver not being supported by TSW coupled with the question why the support isn't there and an eventual window of when we can expect such support to be a reality, there's this weird pushback from DTG-apologists who (surprise, surprise) don't own a Raildriver. Sour grapes much, guys?
Imagine X-Plane 11 without Saitek support. People would scream at the top of their lungs and quite surely no one would tell them to stash their Saitek away and to stop asking for support until some intern gets around to adding basic support at their leisure because they have better things to do. The whole spiel is ludicrous, if you ask me.
Like any Saitek stuff for flightsims, Raildriver is a dedicated controller for trainsims and Underground sims. (Yes, a €19 unpolished underground simulator has Raildriver support out of the box.) Support should've been present and three meager 'expansions' later, we can only pay DTG and still not see support for a dedicated trainsim controldeck. We're not exactly asking for the world here.
Immersion and realism is strengthened by the Raildriver and as long as support isn't in the package, I'm not buying the bare-bones 'expansions' beyond GWR (That I bought when I still believed that DTG was serious with TSW.). Not that DTG will notice me not throwing monies at them anymore, but it's the only real course of action that's an option.
On the other hand, if DTG is getting ready to have TSW go the way of the Do-do like FSW, they should just focus on digging through the wallets of the white-knights. That seems to work quite well for them.
Imagine X-Plane 1 , or at a real push X-Plane 3, without Saitek support and you get nearer to the situation with TSW. TSW has been out for about 15 months. I believe X-Plane has been in existence for at least 15 years. That's a big part of why we still don't have a scenario or route editor, Passenger Information System, consistent AI dispatch and signalling, 6 car 166s in GWE, decent sound quality and scenery optimisation that doesn't just mean reducing the quality of the existing scenery.
If you look at my posting history you will see that I am far from an apologist for DTG, I do however (sometimes) cut them some slack because I know it's pretty much impossible to get everything right first time especially when working with a limited budget. In retrospect it's clear that DTG made errors in their planning and implementation of TSW. One of the reasons the editors have been delayed is because nobody investigated an an early enough stage just how to let users modify TSW without giving then access to the TSW code. Equally it's now pretty obvious that TSW should have been released as early access initially.
I see this kind of reasoning a lot, but it doesn't really work. New products get developed with prior experiences. Train Sim World may be relatively new ("out" for 15 months, but in development for much longer), but Dovetail Games has been developing train simulator products for a very long time and, more importantly, do support the Raildriver in their other train simulator already. Adding support for it is surely not all that complex of a task.
You're comparing the standards and expectations of today, to those of decades ago.
Nobody today would create a flight sim without joystick support, so the X-Plane 1 comparison doesn't apply. No one would take it seriously.
But, I stop just short of saying the the same about TSW. First of all, we live in the age of the first person shooter where a keyboard and mouse is all anyone cares about anymore (or a game pad). But more importantly, unlike a flight sim, a keyboard and mouse actually is adequate to run a train. I'm not happy with that and I think if more people used real levers and knobs to run a train, they would demand support. But I realize that people like me are in the minority.
The concern, though, is not adding it now can screw it up later. Even TS20xx does not correctly support the RailDriver. Locomotives controlled using the virtual controller method have issues which includes most newer engines and the better more complex ones. TS20xx has no support for generic DirectInput devices like Joysticks or more specifically throttle quadrants either. You have to use CobraOne's "TS20xx RailDriver and Joystick Interface" for proper support. It works great and even fixes the RailDriver for TS20xx in a way that neither DTG or PI Engineering cared to address. But because the mod has to hack the LUA scripts for every single locomotive, it is a little intimidating to install. I mean, it really works amazingly well, but there is a chance of difficulties and that turns people off. But the effort to develop this mod for TS20xx is about 100x the effort it would have taken to just add such support directly in the sim from the beginning. Because DTG did not do this, they created the situation that causes even the RailDriver to not work correctly for all locomotives in TS20xx.
Sadly, the situation is worse with TSW as it is not mod friendly at all. We have to depend on DTG adding support. I have, for the short term, solved the problem with my own custom programing for the Thrustmaster Warthog Throttle, but that script takes a few hours of effort to be updated for every new engine that comes out, and what I did will not work with other game controllers (only Thrustmaster devices that work with TARGET). Plus, if DTG makes a fundamental change to TSW's keyboard input mechanism, it could completely mess up what I did.
Adding DirectInput support, which would work with all common game controllers, is game developer 101 stuff. Sadly, though, the RailDriver is not a DirectInput device. PI Engineering chose to use their own proprietary interface even though their device could easily be supported as a DirectInput device. Adding RailDriver support and DirectInput support ends up being two tasks (argh!) which further complicates things. I hope DTG will just bite the bullet and add both one day. I don't think the RailDriver is, in all cases, the best way to run a train.
I know, most of you only care about the RailDriver. But not everyone wants to shell out $200 for a RailDriver. There are much cheaper alternatives that work just fine or even better in some cases - and those devices are useful for other games like flight sims. A Saitek Throttle Quadrant is just $60, and makes a very competent train controller. In TS20xx, I use 3 of them plus a Thrustmaster Warthog Throttle to control steam engines. A RailDriver just doesn't compare, and I could never go back to just the keyboard and mouse. Though my example is perhaps extreme, I bought those three Saitek Quadrants for less than the cost of a RailDriver and because they are useful for more than just a train simulator, I get much better bang for my buck.
BTW, I'm not attacking the RailDriver. It is a nice device and I plan to buy one in fact (mostly because I am working on some software related to it). But if DTG adds controller support, the RailDriver should not be the only game in town.
I did hear Matt say that he wants to make sure that RailDriver support is done "right" with TSW, so it will be compatible with any DLC that could come out down the road and avoid some of the problems it has in TS2018 such as not working properly with certain locos etc. I can appreciate that and I would rather wait and have it done right too, problem is it can take DTG a LONG time to get something right if ever.
I am very glad to hear that. I can be patient for it to happen as long as when it happens, it isn't too late to solve issues like what occurred with TS20xx. But they have to define the ground work for how it works now before things get out of hand. Even if they don't have time to implement controller support now, defining how it works (and placing hooks in the code now) will prevent what happened with TS20xx. Also, once defined, whether they add RailDriver only, or RailDriver and DirectInput support - it's the same either way because the ground work will allow both to work the same.
There are quite a lot of difficulties in getting Raildriver to work with Train Simulators in general.
With Flight Sims it's fairly simple as most aircraft have very similar controls; a single engine Cessna and Boeing 747 both have throttles which go from 0 - 100% and a yoke with the same number of axes.
Trains have a lot of differences in controls. Some throttles are 0 - 100%, some have a varying number of notches (not all for applying power) and some have a combined throttle/brake. There is no catch all way of getting a generic piece of hardware to understand the different throttle types. You would need code in TSW available to Raildriver to describe the type of throttle being used and then a corresponding piece of code in the Raildriver driver that knows how it should behave with that throttle type. To have Raildriver work with every piece of DLC would require an update to the Raildriver driver for every new throttle/brake/reverser type it may come across. Perhaps DTG could create a dumb version of the throttle code for each locomotive that would allow the Raildriver to function as a simple 0 - 100% throttle controller, but that's far from an ideal solution.
Unfortunately I don't think we'll ever see TSW being properly compatible with Raildriver, it's just too difficult to implement for it to be financially viable as so few people actually own Raildriver controllers.
Yes, this is exactly the kind of hoops the TS20xx RailDriver and Joystick Interface software jumps through to make controllers work with TS20xx. It queries the engine control script to see what controls are available and then offers that list to the user to configure which axis and buttons (on the RailDriver, or on a generic DirectInput game controller) to assign to which engine control. For most engines, there is a Throttle, or a Throttle/Brake control, and the RailDriver and Joystick Interface software offers a default for both that tends to work. But for many engines, these levers have different names, or different functionality. For example, the Smokebox UP FEF-3 has several unique control names that don't match other common engines.
In TSW, this would all be easily handled by offering profiles for different kinds of engines. One profile would work fine for the SD/GP-38/40 type engines. But a different profile would be used for the AC4400CW, for example. Then it doesn't matter if different engines have different or unique controls. The user just needs to select a profile to use with that engine. You could create maybe 3-4 profiles and that would cover 98% of all the engines that would likely be created. This is exactly how the RailDriver and Joystick Interface software works for TS20xx.
So to implement this in TSW, DTG needs to be willing to create a "per engine type" profile system for configuring controls. This is no different than what is available in most of the better flight sims (DCS, X-Plane, etc.), and it works very well even though different aircraft are radically different sometimes.
Or, if DTG defines all this up front, they have much more control over how all this works and can significantly simplify things by assigning default engine controls to a default set of controllers. I.e. There is either a throttle or a throttle/brake, but from a controller point of view, these are one in the same, and not both found on an engine at the same time. So if there is an axis called Throttle, then that axis would perform the job of Throttle, or Throttle/Brake and this would all be defined behind the scenes so the user doesn't have to care. That is how I would start if I was DTG.
It's not an easy task. Lets take the Class 47 and Class 08/09 as examples.
In Railworks the Class 08 and Class 47 had simple throttles that effectively went 0 - 100%. So the controller could be mapped with the 0 position as 0% and 1 as 100%.
In TSW things are much more complex. The Class 09 for example as an OFF position, Notch 1 to Notch 3 with increments in between and no increments between Notch 3 and 4. The Class 47 has an OFF position and an ON position, followed by 0 - 100%.
In terms of British traction we have:
Class 09 - OFF/N1-N2-N3/N4
Class 47 - OFF/ON/0-100%
Class 43 - OFF/N1/N2/N3/N4/N5
Class 66 - OFF/N1/N2/N3/N4/N5/N6/N7/N8
Class 166 - EMR/B3/B2/B1/OFF/N1/N2/N3/N4/N5/N6/N7
You could perhaps make the Class 43 and Class 66 throttles work with a standard "Idle/n Notches" profile. The rest would each need their own profile. So that's four profiles to cover just five traction types. This also assumes that the throttles will all be using a script from a standard directory, it's likely that developers will in the future have additional scripts called for by the standard throttle script, further complicating matters.
The other thing to remember is how few people actually own Raildriver controllers. With Flight Simulators I would imagine those who own joysticks is >90%, where as for Train Simulators the number of people who own Raildrivers is probably <5%. It's a lot of effort to go to for such a small part of the market.
The task is made easy by expecting the engine control code (created by the team that creates each specific locomotive) to interpret the game controller axis positions and apply them rather than have the game controller axis interface understanding each engine's controls, which is the case for CobraOne's "RailDriver and Joystick Interface" (RJI for short), or my Thrusmaster TARGET script for TSW.
Digital Drafsman, what you describe is exactly the issue I had to deal with on my TARGET script. I had to make a custom table for every single engine to map the Warthog Throttle lever positions to the "notched positions" on the engine control levers. For example, on the GP/SD-38/40 engines, I had to map the reverser as 0-33%, 33-66%, and 66-100% for the reverse, neutral, and forward positions. But for the Class 66, or 43 HST, I had to add the engine off position. I mapped this more like 0-30, 30-60, 60-90 for reverse, neutral, and forward, but 90-100% as the engine off position. CobraOne's RJI has to do the same thing, but he had to figure out a way to map these settings to a few hundred different engines.
To explain, the way it is now for TS20xx, CobraOne's RJI must read the engine control script to determine where and how many of those notches there are for each locomotive lever, then reads the game controller axis to get it's position (0 to 100%), and then it compares them and tells the engine control script which notch the engine lever should be in based on the game controller axis position. RJI must figure this out individually for every single engine because of the differences described by Digital Draftsman above. Thankfully, 95% of the time, RJI is able to figure this out on it's own with no user input, but sometimes the user must tell it what controller value to change and what the position notches are. I am simplifying this for brevity because what really happens is much more complex. Anyway, this is the wrong way to do it. It means that the game controller code (RJI, or my TARGET script) must have fore knowledge of the control lever notches for the engine before it can tell the engine where to set the levers.
The better way to handle this is, instead of the game controller code understanding the engine, is to make sure that the engine control code understands the concept of game controller axis and does the mapping on it's own. That way, the game controller code only has to tell the engine control code where the game controller axis is in percent (0 to 100%), and it is put upon the engine control code (or rather upon the developer of the specific engine) to interpret that position and move the engine lever to the right position.
For example, a 9 position throttle has Idle, and settings 1 through 8, or a brake lever might have Release, Initial Reduction, then an analog range of "Brakes Applied 0 through 100%", then Suppression, Handle Off, and Emergency. So that is 6 positions, where one of those positions is an analog range from 0 to100%. This entire scheme is designed to work with a keyboard. But in the engine, the physical control that makes this 9 position throttle or multi-position brake lever work is still a lever, and that lever has a range of motion that can be described as moving from 0 to 100%. Hence, it is easy to make a game controller axis match an in game lever by simply matching the % positions of the two. The place to do that is in the engine code, not the game controller code.
Hence, for the 9 position throttle, if the game controller axis is between 66.7% and 77.8%, then the engine's throttle lever would be placed in position 2 (100% / 9 = 11.1% per position, so position 2 is between 66.7 and 77.8% or 22.2% and 33.3% if the axis is reversed). For the brake lever, the engine developer would similarly map the 0 to 100% game controller axis position to the 6 different positions on the brake lever, including the special "0 to 100% brakes applied" range which would match to (for example) 20% to 60% on the game controller axis. Again, the game controller axis and the lever in the engine would be moved such that they match each other, 0 to 100%. Sorry, it's a long way of saying, move the real game controller axis, and the engine lever moves the same amount.
So you compartmentalize the game controller axis code (which just reports the axis 0 to 100%) and the engine controller code which is specific to every engine, but since it is developed by the person that makes the engine, they deal with the mapping. Because TS20xx and TSW do not understand this concept today (i.e. there is no SDK that allows us to tell an engine the position of our game controller axis), CobraOne and I have had to do the reverse which is write game controller code that not only reads the game controller axis position, but also fully understands all the locomotive notch positions. That is why I said failing to set the stage correctly now can result in 100x the effort later, and that is exactly what happened with TS20xx.
I should mention, I understand this issue intimately because I've been looking at how to solve it for years. CobraOne found an elegant way to do it in RJI but it took a lot of effort. A couple other people have done similar efforts (Havner, and Cadde - users on the UKTrainSim forums and I applaud their efforts). I also had to deal with all this difficulty to make my TARGET script work.
I have also written code to initialize, and use DirectInput (DirectX) devices, and it is the easiest stuff in the world. You can practically copy the code examples right off the MSDN website or there are dozens of open source examples. Maybe the Unreal Engine already has joystick support. That is why I am surprised that DTG has never implemented this stuff directly. DTG did implement the Xbox controller, but I believe they used Xinput to do it, which is Xbox specific and supported on Windows too. Sadly, if they had used DirectInput, they would have already done half the work and I think it would still have supported the Xbox controller. The harder part is implementing the UI to allow the user to assign the axes to specific engine levers. Making a good UI takes a little effort. Actually mapping the axis to engine controls, even though they might be different for different engines, is otherwise very simple.
I only suggested the idea of profiles because the best way to handle this on a custom basis is to let the user define a subset of profiles for specific types of engines. For most the engines, you would need to say "this is the throttle", "this is the automatic brake", "this is the independent brake", or maybe "this is the throttle/brake" for those engines that have this combined. Once TSW or TS20xx know these mappings, it should be able to generically apply them to 95% of all engines without a special profile. Profiles would just make it easier to handle those odd engines with levers that are special (like steam engines), or an engine like the Class 166 which has a throttle/brake lever, but the center (0 throttle, 0 braking) is not at 50% of the lever travel.
My last comment is regarding things like the RailDriver throttle/brake lever and how to map it to the AC4400CW (which could probably work as a direct 1 to 1 mapping, hump and all) vs. say the Type 166, where the throttle maps to the lower 60% of lever travel vs. the brake mapping to the upper 40%, and no hump in the middle. For the Type 166, the hump on the RailDriver doesn't match up. This is the special case where the game controller interface must have sliders to adjust where the axis middle dead zone and center point is. So you could create a dead zone to tell TSW to ignore the hump, and move the center of the RailDriver axis to about the 60% mark so that below the hump on the RailDriver will handle the 60% range for Throttle, and above the hump would handle the 40% for braking.
This is an example where a profile specific to the Class 166 would be needed because no other engine works like this. On the other hand, another profile for the ACS-64 and Talent 2 might be needed to place a dead zone around the hump so that the entire hump, as well as the position just below and just above the hump would represent 0 throttle/0 brakes. This is where the RailDriver's hump becomes a hinderance, but if the game controller interface adds the dead zone and center adjustment features, then the problem goes away. Again, this is all very simple stuff (simple math), and the only hard part about it is the UI because doing a nice clean UI takes some time.
BTW, in all the above, when I talk about a game controller, I generically mean both a RailDriver and common DirectInput game controllers. It is just unfortunate that the RailDriver is not a DirectX device. It's custom interface means any train sim company that wants to support it as well as DirectX devices have to write two input interfaces. Thankfully, doing so is relatively trivial. After the interface is created, the RailDriver would look like any normal DirectX device and use the same configuration UI and profiles. Unfortunately, it seems RailDriver is the only device anyone wants to support. That is a tragic mistake (or maybe a planned monopoly?). It's great for PI Engineering, but not so great for the train sim users.
Again, maybe nobody here cares about using generic DirectX devices with TS20xx and TSW. But again, I argue that if the support was there, a lot more people would use it due to access to cheaper controllers, and maybe instead of begging DTG to add RailDriver support, the larger user base would have justified adding the feature from the start.
Sorry for the long post. If you read to this point, I applaud you and thank you for wanting to understand these details better.
As one who currently uses the keyboard I have to say it would be far nicer if I could use my joystick instead and I fully support your campaign for DTG to implement Directinput support.
Very interested in this topic, as i made this a few years ago for TS2014,
A mix of real switches from a german train, industrial controls and some time on a lathe to make the power/brake lever.. and use of a laser cutter to make the desk top and my trusty vinyl cutter for the decals.
It contains an arduino and a minimus usb board running KADE, the latter handles the 24 button inputs as one joystick, and the arduino handles the 2 joystick axis using the unojoy sketch, the reverser/direction switch is an axis as thats how TS20xx sees it... i also have a USB3 connection to it, and a usb output for a usb to old laptop screen conversion i did for adding an 'MFA' to it at a later date (screen with the gauges and warning lights on it... began to get that working with TS... it's really designed for Zusi.. the hard core german train sim based on real life operation over fancy looks .. but then real life got in the way... i'm no coder tho, others helped me with that part, i do the hardware stuff best)
it's based loosely on the DB 4xx series commuter train controls, i went through a phase of only driving a 442 tallent 2 for a while when i made this.
To use it in TS20xx i use 'cobra1's' excellent RJI program,
it would be nice to be able to use it in TSW too.
Not to mention the entire driving desk with all controls, gauges, Ebula computer, radio, seat etc that i have from a DB BR120's driving trailer (wittenberger steuerwagen) that i am slowly converting from air / high voltage controls to 5 volt usb friendly potentiometers and switches that i'd love to be able to use in TSW in the future (i've made the main power lever's detents adjustable to allow me to switch between train types so i'm not stuck driving the very hard to drive BR120 with the 28 power notches controlled by an up/down lever)
ps, i have a raildriver too, but after handling real train controls, i hardly use that as its too toy like... BUT it is a great step up from tapping away on the keyboard.... i also used a saitek throttle quadrant for a while, and highly recommend them as an alternative.
That's a nice bit of kit Gazz!
I have often thought about building my own Arduino based controller. I did get some hardware together and start writing some code to convert controller movements to keystrokes for TS. I was planning on using a 24 pole rotary switch for the power handle. The switch was wired to the pins of the Ardunio, the code looking at whether the previous pin to be energized was a higher or lower number pin than the current pin, thus determining whether power handle was being moved forward or backward and whether to make an 'A' keystroke or a 'D' keystroke input. It seemed to work alright, though the duration of the keystroke needed tweaking, because if it wasn't held long enough TS wouldn't react, and if it was held too long you'd advance two notches. I never got beyond the design phase, but it's nice to see someone taking a similar project to completion and making a really nice job of it. Well done!
I was going to build my set up into a replica of Class 150 Sprinter control desk as it's a nice compact and complete set up:
A way to diminish that is to start using a X-box or DS4 controller. I find that way more immersive than Keyboard and Mouse.
Separate names with a comma.