The Massive Obvious BUG Thread

[longbow]

Good post. Pretty much my thoughts exactly.

[AndyUK]

....you cannot expect total accuracy from a £30 software title...

True, but what irritates me most are the things that were wrong in RailSim that could just have easily been right without adding to the cost! A prime example is the way the air brakes are set up on the UK coaches and wagons. They were given triple valves rather than distributors which means that you can't get partial brake release as per prototype. The blueprints allow for distributors and the code seems to be sophisticated enough to simulate the difference. This simple setup mistake was never addressed in either of the Upgrades* despite being pointed out, and with access to the source blueprints it shouldn't have taken more than an hour, max, for them to fix. I'm still waiting to hear whether they fixed it in RailWorks.

Andy L

*Edit - Partial release was enabled on the HST and Class 166 at some point. Looking at the file dates it looks like it was part of the Rolling Stock Physics updates last October.

[Pencader]

it seems to have been designed by the same set of people who have made the same basic decisions.

For certain, a handful of members of the code team where retained from MSTS and MSTS2 and, as you say, have worked along similar lines.

Whilst I agree that a £30 title will never hold the level of fidelity found in commercial simulators, the errors outlined in the OP's posts should really have been avoided, especially at the signaling and route planning level.

However, I do not believe they will be addressed during the life of Railworks - to do so would be to write large sections of the game again from the ground up.

[Kromaatikse]

As far as the signalling/dispatching is concerned, I would be happy (or at least sufficiently happier to stop complaining so loudly) if AI trains did not routinely intrude on my assigned path. (As far as drivers are concerned, signalling and dispatching are two sides of the same coin.)

I do realise that the signals themselves can be customised by scripting, but it's not confined to the UK system - it's also present on the recently-updated German system and the brand-new fictional route set there. It's trivial to trigger a conflict situation with at least one of the default scenarioes. I haven't had it happen to me on the US routes (yet), but the signalling is much less dense and complex there, so the relatively simple system might actually be able to cope with it. I suspect however that the traffic on some scenarioes has been engineered to avoid triggering bugs.

As for the thread title - it's a play on another thread titled "The Little Subtle FIX Thread". Incorrigible punster; do not incorridge.

I'll even answer the charge of "do it yourself if you're so clever". Firstly, cleverness is not sufficient - one needs a lot of time and effort as well. For that reason, I'd prefer to see RailWorks evolve to do things The Right Way with encouragement from the community - they have a head start, you see. But if they refuse to do so, then I might well end up writing my own out of sheer frustration - and I am capable of doing that, especially if the community decides to help out. But as I have better things to do with my time, I hope it doesn't come to that.

Anyway, now we can return to our regularly scheduled Physics lectures.

[Brentingby]

As an ex-signalman, I too have to agree that the signalling side of the sim needs a re-think. I understand that trying to make a sim that is suitable for all may sometimes mean a compromise. People who want more realistic colours or weathering of stock may not have the same priority over somebody trying to compose a really intricate scenario with lots of conflicting movements.

We as users though may have a part to play in the lack of improvement of pathing and movements by basically insisting on backward compatibility of simulators. I cannot see how you can drastically improve a part of the sim whilst allowing poor coding to allow older routes and scenarios to run as their creators intended.


Signalling seems to be a bit of a common flaw with quite a few traim sims.


Just my tuppence worth.

[msdejesus]

Good post. Pretty much my thoughts exactly.

Mine too.

Manuel

Pretty common sense (rather uncommon nowadays).

[Kromaatikse]

Diesel-Electrics

This is another area that has seen exactly no improvement since KRS, despite extensive community discussion. However, unlike the Diesel-Hydraulic model, the D-E model is at least somewhat drivable in most cases. Nevertheless, the problems affect both locomotive performance and driving technique, and limit the locomotives' capabilities quite significantly compared to the prototype.

First let's talk fundamental equations. The equations that apply to a diesel-electric are:

Power = Torque * Speed

Power = Force * Speed

Power = Voltage * Current

Power in = Power out + Power lost

Current total = Current individual * Number of equal parallel paths

Voltage total = Voltage individual * Number of equal series elements

Current in each element in series is identical.

Voltage across each element in parallel is identical.

Voltage = Current * Resistance

Any good student of electronics and/or physics can quote these equations without trouble. To see how they apply to the locomotive, we must examine it's component parts and see how they fit together. It's a lot more complicated than a hydraulic transmission. For simplicity, I'll stick to a conventional locomotive with only one prime mover (sorry, Deltic fans) and conventional DC traction motors (induction motors are a separate topic, though with similar basic principles), and consider a rectified alternator as equivalent to a generator (the practical difference being mostly in reliability).

The first link in the chain is the power handle. This is connected, more or less directly, to the governor (which controls the engine) and the load controller (which controls the main generator). The control laws of this link vary between locomotives - the Class 08 in particular doesn't have a normal load controller! - but generally, for a given throttle position, the governor is given an engine speed to maintain and the load controller is given a power rating to maintain.

The governor is easy to explain - it adjusts the fuel flow to the engine to keep it at the set speed. There doesn't seem to be any conceptual difficulty here. There is probably a set maximum fuel dose per cylinder power stroke, to avoid flooding the engine, but there normally isn't any minimum (except of course zero).

The load controller is much harder to find information about. I happened across some old books that described the state of the art in the 1960s, which is relevant for the 37 and 47 at least, and probably the American locos as well. It turns out that the average load controller adjusts the voltage produced by the generator until the fuel flow corresponds to the desired power. Apparently, diesel engines tend to produce power corresponding closely to the fuel input - turbochargers and intercoolers just let them burn more fuel without flooding - so measuring the fuel flow is easier in real life than measuring the power in the electric circuits.

Some locomotives' load controllers are configured to maintain constant current rather than constant power, but these are rather uncommon. The only ones I've seen are Alcos, and Alco went out of business a very long time ago. All British designs (that I know about, and that's a lot of them) and all modern US designs go for constant power. A side-effect and benefit of constant-power control is that fine control of cruising speed becomes much easier, since the full travel of the power lever remains useful.

The engine also has an auxiliary generator, much smaller than the main one, whose job it is to power everything besides the traction motors and recharge the batteries. This might not be able to produce full power at engine idle, but it will still be able to power all on-board equipment adequately. It has a simple load controller which attempts to maintain constant voltage output, rather than measuring fuel flow. Note that power consumed by this generator is not available for the main generator, but still counts against the fuel budget!

Now obviously there is a maximum voltage that the generator can produce, otherwise it would start arcing, which would be Bad. The load controller will naturally stop advancing when it reaches this limit. There is also a maximum current it can withstand without beginning to overheat - note that the main ammeter in the cab measures the current at the generator, not at a motor.

The motors are not normally wired directly to the generator, but can be switched in different combinations of series and parallel. This allows them to be better matched to the generator's capabilities at different speeds. When in series, the generator's voltage is divided across them, while the current is available in full measure to each of them - this is great for starting, since a motor's torque depends on the current through it. When in parallel, the generator's voltage is available in full to each, while the current is divided between them - this is good for high-speed cruising, since a motor's speed depends mostly on the voltage across it. Most locomotives have an intermediate stage, where (say) the bogies are connected in parallel but the motors on each bogie are connected in series. Or vice versa. This switching arrangement is also used to disconnect the motors during coasting, and to allow reversing.

An important point is that motors generate their own voltage in two ways, which always add up to the voltage at their terminals.

The first, and most relevant at a standstill, is the internal resistance of the motor's windings. At a standstill, all of the power of the engine and generator is lost as heat through this resistance, as described by Ohm's Law. But that's okay, because the current, and the torque that results, is what matters for starting. The current depends only on the value of the resistance (the lower the better - expect a fraction of an ohm in a good motor) and the voltage across that resistance - and vice versa.

The second internal voltage appears when the train is moving, and is a product of the speed and the field strength of the motor. For a given voltage at the motor's terminals, this internal voltage will reduce the voltage across the internal resistance, and therefore reduce the current through the motor, and therefore reduce the torque produced by the motor. For series-wound motors that are typical of DC traction motors, the reduced current also reduces the field strength in the motor, which will tend to cause negative feedback in this process.

It's quite possible, and even advisable, to pre-calculate the current consumed by a given type of motor rotating at any speed with any voltage on it's terminals, and also to pre-calculate the torque produced for a given current and speed. This can quite reasonably be done by engine blueprint writers, or a motor expert consulted by them. It is then simple to pass the correct voltage to each motor (which will depend on the engine speed, the load controller's position, and the motor switching configuration), and then to feed back the current consumed to apply a slowing torque on the engine and a quickening torque on the rail wheels - all provided you assume that all the wheels are rotating at the same speed.

Unfortunately that assumption would be incorrect, though it's a good approximation provided that all the wheels are gripping the rail properly. Diesel-electrics normally power each axle separately, so normally one axle will begin slipping first, and will then run away alone as it robs power from the other motors (at least at slow speeds, while motors are in series). Once slipping has begun, then, it is necessary to revise the voltages across each motor in a series string until the calculated currents are the same (to within some reasonable tolerance) and the voltages still add up to that supplied by the generator. This must be done before the current consumption can be fed back to the generator or the torque fed forward to the wheels. It is for this reason that the torque cannot be calculated directly from the voltage and motor speed.

Incidentally, British locomotives of this vintage usually have an anti-slip brake setting with it's own control button, or else applied automatically by the slip detection circuit. This basically helps to curb the runaway axle and give it half a chance of regaining grip on a more favourable piece of rail, with less power reduction required by the driver. Obviously only the locomotive brake is affected by this, not the train brake.

The result is that when a "transition" occurs (from series to series-parallel, for example), the total induced voltage across the motors will be lower than before, so the current will rise and the load regulator will run down to compensate - but the total power will remain the same. And the same power at the same running speed means the same torque made by each motor, and the same total tractive effort! But the current seen on the main ammeter will indeed rise, in proportion to the lower voltage now required at the generator.

This is important: when the main ammeter needle rises on transition, it does *not* result in a corresponding increase in tractive effort!

[AndiS]

As an ex-signalman, I too have to agree that the signalling side of the sim needs a re-think. I understand that trying to make a sim that is suitable for all may sometimes mean a compromise.

The bit with the compromise is the important one here. I was one of those who did exactly the same shouting one and a half year ago. In the time since then, the unpleasant idea settled in with me that they are selling exactly the same software to
a) a big group of people who want to drive trains
b) a equally big group who what a big virtual model layout
c) a few geeks who scratch their head over operational issues.

For group (a), all that is required is that the signal looks good as you pass it. This is not the case now in many cases, but easy to fix. If you do not implement the system which controls them in the prototypical way, you run into complex problems behind the scenes, because signals cannot always perform as expected it they are only "watching trains and switches". However, there are some ideas how this can be fixed and RSC are not strictly against them, they just did not make it to the top of the list yet.

For group (b), it is mandatory that train safety installations are not as complex as in the prototype. The vast majority just want to place some track and scenery and run trains on it. The current mode of signalling is hard enough to teach to them, even though it is a gross simplification.

This group (b) also wants to freely move trains around like on a model railway layout, ignorant of all the restrictions imposed in the prototype. They would call the programme unusable if they would have to set up a working timetable for any trip they take, and detailed shunting instructions if they want to do a little shunting. This has the dramatic consequence that there are situations in the game play where no one knows what is going on, still the player wants the signals to "work" or "look good" or just get out of the way of his fun. At the same time, sometimes the same people, expect those innocent signals to keep AI traffic from colliding with the spontaneous user.

Group (c) clearly is at odds, but not because the creators of KRS & RW are evil or stupid, but because they are a small minority. There are several alternative reactions to this.

1) Create your own simulation based on an available game engine.
2) Use the most suitable train game as a basis your extensions to it.
2a) Doing so, keep it all for yourself.
2b) Try to set up standards with congenials so you can swap creations with them.

If you go for (2b), do not expect the majority to follow your lead. Some may admire your work, some might find it boring or stupidly complicating matters and spoiling the fun. (Search for braking distance of HST or driving a steam engine on these forums to get an idea.)

[Kromaatikse]

That's a worthwhile point, I suppose. It's easy to forget that there are an enormous number of people out there who Do Not Care about details. This includes young children, too.

And yet, when you look at the flight simulation community, realism is king and has been steadily increasing over the past 2-3 decades. The most recent situation is - shock, horror! - that MSFS (a behaviour-driven simulator) has been cancelled as a project, while X-Plane and FlightGear (both physics-driven simulators, one of which is open-source) are still going strong. Do you think there might be a lesson here?

In any case, I think "low end" users - the ones who Do Not Care - are well served by the easier scenarioes and the simplified control models. (The aviation equivalent is flying a docile and powerful airliner in perfect weather.)

"Layout" users are not obliged to put signalling on their track at all, unless they want AI traffic to behave reasonably in conflicted situations. If the signalling behaves like in the prototype, then it's easier to find information on how it works - I think I see more confusion on the forums about how it differs from prototype behaviour. There's quite a lot of unnecessary complication in the way it has to be set up, too, which doesn't help. Layouts usually have a simple enough track plan that the simpler types of signals will be sufficient.

In the real world, shunting operations can be conducted under the blanket protection of a block section or other posession, without the complications of shunting signals, provided that only one train needs to use that particular yard at a time. Usually these are replaced by hand signals from a person-in-charge-of-shunting. Simulators tend to replace these hand signals with extended flying-camera options, so the driver can see what's going on for himself. So I think the shunting signals are more prolific on the UK routes than they should be - Kuju decided that "dwarf signals are point indicators", and decided to provide them as such.

There's absolutely no reason that "a bit of shunting" has to be done under a massively detailed working timetable. The main uses for shunting signals in the prototype are in "busy" yards and at terminal/major stations, both places where multiple traffic is wanting to make "unusual" movements on a regular basis. Otherwise, signals control entry to and exit from the yard area, which for simplicity might include the local station on quiet routes.

Funnily enough, you should just look at the instructions presently required to set up a scenario with any shunting in it at all! They are remarkably detailed, specifying what order you must couple and uncouple things. The real requirements are more like "get these wagons attached to your train, somehow, and possibly in some particular order", and "leave all the other wagons in sidings in the yard", and "leave Siding X free afterwards because that's the run-around loop". The challenge of shunting should include planning how to do it.

Anyway, I'm prepared to give railsimmers - even the younger ones - a bit more credit when it comes to understanding what has to go on. I don't believe in catering only to the lowest common denominator - that only lowers the bar even further. Railsimming is a geeky activity, at bottom, and tools to enable it (like RailWorks) should be designed with that in mind.

[longbow]

The most recent situation is - shock, horror! - that MSFS (a behaviour-driven simulator) has been cancelled as a project, while X-Plane and FlightGear (both physics-driven simulators, one of which is open-source) are still going strong. Do you think there might be a lesson here?

Yes - never, never trust Microsoft.

Seriously, the analogy to flightsims is not a good one in terms of the importance of accurate physics to the overall game experience. Flightsims are highly focused on the cockpit. The appeal of trainsims is broader - like many here, I spend very little of my trainsimming time actually driving.

[AndiS]

In the real world,

What real world? Which period, which country, which route or class of station?

There's absolutely no reason that "a bit of shunting" has to be done under a massively detailed working timetable.

In most countries (including UK, I believe), shunting signals (colour light for sure, disk signals, too, I guess), are only cleared if required for a pending movement. I.e., they default to danger like "normal" signals for block protected train movements. This means, that like for train movements, the system (i.e., the signals and the part of the software informing the signals) needs to know where the engine will go next.

Without such information, you can only clear both shunting signals at the end of a loop which looks stupid and is not done in the prototype. Furthermore, there are signals with call-on arm which can both show "clear for train movement" (green light and/or main arm of semaphore) and "clear for shunting movement" (two white lights arranged diagonally, or shunt arm of semaphore). If a train/consist is near such a signal, be it in approach, at halt after approach, or after passing it in reverse, the signal must "know" which of the two aspects, if any, should be shown.

In the prototype, someone has some list -- however you name it -- which prescribes what is going on, and this someone -- shunter or signaller -- sets the switches and then the signals. In the game, you could extract such information from the scenario instructions, which is complex; or the game informs the signals when TAB, W, S, and maybe some other keys are pressed; or you can just observe the train movements and switch changes.

In the latter case, you cannot discern between shunting movements and train movements; and there is some danger that the driver (player) waits for the signal to clear while the signal waits for the engine to move (to know whether it should clear or not). The second case is not yet implemented in RW, but I hope for it.

The main uses for shunting signals in the prototype are in "busy" yards and at terminal/major stations, both places where multiple traffic is wanting to make "unusual" movements on a regular basis.

I know lots of places in the prototype (in contemporary Germany and Austria, same will be seen in neighbouring countries) where shunting signals are used to protect passing trains against shunting movements which only happen a few times per week. Since these stations are controlled remotely, these signals (dwarfs like the UK ones) are an integral part of the design.

Otherwise, signals control entry to and exit from the yard area, which for simplicity might include the local station on quiet routes.

I do not understand this sentence. You mean local stations should be considered yard areas as a whole? Which signals do you refer to?

Railsimming is a geeky activity, at bottom, and tools to enable it (like RailWorks) should be designed with that in mind.

Geeky can refer to a lot of things. Many people thing that doing anything with trains is geeky by itself, even if the alleged geek knows nothing about prototypical railway operation. Then, you can be geeky about signal aspects, signal placement, and signal construction, independent of each other. You can also be geeky about embankment design, station layout, track construction details, catenary, bridges, buildings, vegetation, passengers, road traffic, rail vehicles (physics, outside design, inside design, consist composition, numbering and labelling, all independent again). All these geek factions will consider themselves the centre of the world and all others laymen or young children.

[davveb]

Wow Kromaatiksi, you certainly don't believe in leaving out the detail. Agree with pretty much all of it, particularly:

The result is that when a "transition" occurs (from series to series-parallel, for example), the total induced voltage across the motors will be lower than before, so the current will rise and the load regulator will run down to compensate - but the total power will remain the same. And the same power at the same running speed means the same torque made by each motor, and the same total tractive effort! But the current seen on the main ammeter will indeed rise, in proportion to the lower voltage now required at the generator.

This is important: when the main ammeter needle rises on transition, it does *not* result in a corresponding increase in tractive effort!

Hear hear! I was beginning to think I was the only one who had noticed this. The implemented "field weakening" behaviour is not appropriate for diesel electrics. It would be suitable for classic electrics, but this field weakening is not available in the electric engine model - Arghhh!
Just a little clarification for people - series -> series/parallel -> parallel transistions are common on North American locomotives, but not on UK diesel designs, which generally have fixed motor wiring, usually series/parallel (most class 47s were all parallel). Instead "transistions" are performed by traction motor field diversion. If you want more appropriate power/current modelling have a look at the class 66 physics update, where I "fudge" the ammeter to give transistion current increases without corresponding spikes in the tractive effort.

Dave B
ps
If people are interested in class 47 locomotive technicalities I recommend they read this months (July 2009) Traction magazine, which has an excellent article.

[AndyUK]

Diesel-Electrics
Nevertheless, the problems affect both locomotive performance and driving technique, and limit the locomotives' capabilities quite significantly compared to the prototype.

Maybe, but apart from your final line you don't say what the problems are! Is there more to come? Like your Diesel-Hydraulic piece there are a few factual errors which I've commented on below. If anyone is interested in reading more on this topic then I recommend "The Railwayman's Diesel Manual" and "Diesel Traction - Manual For Enginemen" the latter being probably the better one in this context.

relevant for the 37 and 47 at least, and probably the American locos as well. It turns out that the average load controller adjusts the voltage produced by the generator until the fuel flow corresponds to the desired power. Apparently, diesel engines tend to produce power corresponding closely to the fuel input - turbochargers and intercoolers just let them burn more fuel without flooding - so measuring the fuel flow is easier in real life than measuring the power in the electric circuits.

Put another way the load regulator adjusts the main generator excitation so that the generator output power matches the available power from the diesel engine at the speed set by the driver's controller position. The fuel flow is not measured, but the engine speed is sensed by the governor and if for a set controller position the speed tends to fall the load regulator reduces the generator output and vice-versa.

The motors are not normally wired directly to the generator, but can be switched in different combinations of series and parallel.

This is common practice in many "straight electric" applications like the slam door Southern EMUs but unless my memory's at fault I've never heard of it being applied to British Diesel-Electrics. There the traction motors are permanently connected in series, parallel or series-parallel combinations.

The first, and most relevant at a standstill, is the internal resistance of the motor's windings. At a standstill, all of the power of the engine and generator is lost as heat through this resistance, as described by Ohm's Law.

If that were true then there would be no power available to move the train! Some power is lost as heat in both motors and generator at all speeds.

The result is that when a "transition" occurs (from series to series-parallel, for example)

A better example is when a stage of field diversion kicks in - as I see Dave B has just pointed out!

Andy L

Edit: Kromaatikse, I'm sorry if it looks like I've marked your homework I didn't mean it to come across like that! I commented in case anyone from RS.com is following this thread with a view to updating their code.

[growler37]

Hi
As with any high street sim title, be it train or flight sim,total realism is a myth,as i stated earlier,commercial simulators are very expensive and complicated tools, and are treated as training aids.
the purpose of high street sim is to entertain,a friend of mine is an ex Royal Navy helicopter pilot,who now flies civilian aircraft,i asked him how accurate a program like fsx is, he said there ok for a bit of fun,but not to be taken too seriously,after all why would companys pay millions of pounds for a flight simulator,if you could nip to pc world and buy a dell inspiron and a copy of fsx for a few hundred pounds,so as i said before the big word is compromise,these titles are first and foremost created to entertain and entertain as wide an audience as possible.
However software companys dont do themselves any favours by putting out statements like "acurate this! and highly detailed that!"maybe some of the hype needs toning down a little.
With Thanks
Kevin

[AndyUK]

i asked him how accurate a program like fsx is, he said there ok for a bit of fun,but not to be taken too seriously,after all why would companys pay millions of pounds for a flight simulator,if you could nip to pc world and buy a dell inspiron and a copy of fsx for a few hundred pounds,so as i said before the big word is compromise,these titles are first and foremost created to entertain and entertain as wide an audience as possible.

The FAA, Federal Aviation Administration not Fleet Air Arm!, approve both Microsoft Flight Sim and X-Plane for certain aspects of real world flying training, so they can't be too bad! I also understand that the more fully featured aircraft addons for MSFS are used by some airline pilots as procedural training aids to prepare for check flights in the pukka multi-million pound simulators. Maybe in time RailWorks will catch up in the accuracy stakes.

Andy L