The Massive Obvious BUG Thread

[GavNormandale]

hi, i understand all this discussion is needed but i feel it has taken over this bug thread leaving it hard to find if this has been mentioned already but i feel the class 37 brakes are far too good, had a run on bath to templecombe and found going down a 1 in 50 slope, 30-31% brought the train to a stop so quickly i thought id hit the emergency brakes, is this happening for everyone?

Gav

[Kromaatikse]

This thread has spawned a complimentary thread over on TS.com:

http://forums.flightsim.com/vbts/showth ... p?t=282887

This contains some interesting additional observations from a North American perspective.

Yes, I see that.

I have to accept the criticism that I've only covered DC traction motors, but I thought that was a sufficiently complex topic to warrant a post of it's own, especially since it covers no less than four of the locomotives supplied with RailWorks (the 37, 47, HST, and F7). As far as I'm concerned, though, rectified alternators really are just a drop-in replacement for DC generators. That they are more reliable and more capable (in general) is undisputed.

AC motors are run differently, and the more sophisticated control schemes involved are a bit harder to find concrete information about. I have no doubt that I can figure out a sufficiently generic description to allow accurate blueprint specs, though.

@Normandale: I want to cover brakes in detail, just like I've covered other topics here. Have patience.

[davveb]

I have to accept the criticism that I've only covered DC traction motors, but I thought that was a sufficiently complex topic to warrant a post of it's own, especially since it covers no less than four of the locomotives supplied with RailWorks (the 37, 47, HST, and F7). As far as I'm concerned, though, rectified alternators really are just a drop-in replacement for DC generators. That they are more reliable and more capable (in general) is undisputed.

AC motors are run differently, and the more sophisticated control schemes involved are a bit harder to find concrete information about. I have no doubt that I can figure out a sufficiently generic description to allow accurate blueprint specs, though.

There's some good information about traction control techniques here, including AC motor control:

http://www.twoof.freeserve.co.uk/TRACTION3.htm

Dave B

[AndyUK]

Kromaatikse,

Do you have any comments on the way RailWorks models steam consumption? In another thread I posted this observation based on a test of the RailSim Black 5's hill climbing ability:

"One thing I noticed when I did it again and used over 50% regulator the steam consumption dropped to half of what it was at 49% as soon as the regulator was opened to 50%. Now I know that running on the 'big valve' is supposed to be more efficient because the pressure drop across the regulator would be less, but I'm convinced that at a given speed and cut-off the steam consumption should not behave like that, it seems physically impossible."

In your opinion should the steam consumption vary like that bearing in mind the cut off remained the same?

Andy L

[Kromaatikse]

Kromaatikse,

Do you have any comments on the way RailWorks models steam consumption? In another thread I posted this observation based on a test of the RailSim Black 5's hill climbing ability:

"One thing I noticed when I did it again and used over 50% regulator the steam consumption dropped to half of what it was at 49% as soon as the regulator was opened to 50%. Now I know that running on the 'big valve' is supposed to be more efficient because the pressure drop across the regulator would be less, but I'm convinced that at a given speed and cut-off the steam consumption should not behave like that, it seems physically impossible."

In your opinion should the steam consumption vary like that bearing in mind the cut off remained the same?

Andy L

Yes, that was precisely my biggest beef with both MSTS1 and KRS/RW's steam model. I have no idea where they got that stupid idea from. The only even vaguely similar scheme I've ever seen is the Deeley compound engine (aka the Midland Compound), but that is literally one class of loco, among many hundreds of others that do not behave this way.

The second biggest problem, in my view, is that the "steam chest pressure" behaves backwards, apparently using power rather than force as a proxy. This doesn't directly affect the performance, but it does show up on a large and prominent dial in the 7F's cab, and it illustrates perfectly the lack of mechanical sense among the dev team.

[sniper297]

"It's not a false statement. A textual error message is given when confronted with a scenario failed to load," oh that's good news, you're gonna sell me a car that won't start reliably but the upgrade adds something to tell me why it refuses to start.


"and you can now add scenario specific route markers to help with the AI traffic handling." useless for me, being a route developer I can add or subtract whatever signals or markers needed to make the AI trains behave - except they don't behave since they have no actual intelligence in the AI, which apparently stands for Artificial Ignorance.

http://forums.flightsim.com/vbts/showth ... p?t=268384

Back to the Dispatcher Mode idea, it strikes me that it would be the simplest and cheapest way to fix it - if you could hit a key that paused the game and brought up a map that you could give simple start / stop / wait-take other exit at this switch / instructions during the scenario, then it wouldn't matter how stupid the AI trains are since the player has the option of untangling it himself. You could even leave the scenario editor unchanged for the majority of people who like to drive high speed passenger trains on 5 track mainlines and wave at the AI trains passing on parallel tracks with no actual interaction.

[AndyUK]

The second biggest problem, in my view, is that the "steam chest pressure" behaves backwards, apparently using power rather than force as a proxy. This doesn't directly affect the performance, but it does show up on a large and prominent dial in the 7F's cab, and it illustrates perfectly the lack of mechanical sense among the dev team.

Kromaatikse,

Thanks for your reply, at least I know that my understanding of physics isn't at fault in this case, despite my glaring error regarding power in an earlier post .

I'd not noticed the odd steam chest pressure behaviour before, I'm usually more focussed on balancing steam consumption against production by the wasteful automatic fireman who seems to insist on leaving the blower on all the time! I look next time and no doubt it will stand out like a sore thumb for ever thereafter.

Andy L

[AndiS]

Regarding the dispatcher, Jim, of course, refers to the US prototype. The Austrian/German/some other continental approach would be this:

Each station as a scheme telling which train type uses which track. Of course, there can be first order and second order options, like relief platforms for certain destinations or a group of tracks where freight trains arrive waiting to be shunted, and this group of tracks is used without too strict order. However, this scheme is made once and for all, and than you only need to define the odd exception (which is always possible), when you implement a certain time table.

KRS takes a first step into this direction, but the destination and origin of trains cannot be considered as a factor when choosing platforms. Also, train type are quite coarse (passenger, freight, yard) and exceptions cannot be defined.

I dare to say that Europeans are not too fond about putting on the dispatcher's hat while driving a train, mostly because trains run pretty fast here and there is far less spontaneity involved as for US freight networks. Passenger services play an important role here and passengers do not approve of any deviation from the plan.

However, I fully agree that the AI dispatcher needs some form of dynamic thinking to allow shunting between trains. This is a popular theme in scenarios and it really adds value to the game play if you need to wait for a passing train during your shunting moves. Here, it is totally unprototypical if all traffic ceases just because the shunting consist failed to use the timeslot originally assigned to it.


Regarding the signalling, it occured to me that if RW want to promote the exchange of trip records via steam ("looking into multiplayer features"), then they need to get the speed evaluation right first. Right now, the system is locked to the UK prototype where (dynamically changing) signals do not prescribe speed and where there are two speed limits, one for freight and one for passenger trains. This is not a problem if you hate the F3 display anyway and you evaluate yourself according to your own ideals, but the evaluation report at the end of the game is worthless as it is now.

In countries where signals prescribe a certain speed, i.e., in the majority of the non-UK world, speed limits depend on the aspect of the signal. For simple cases, this can implemented now by doing double work. If the signal prescribes 40 km/h for the diverging track, you mark a speed limit on the curved track. But if the route builder forgets one location, the record is wrong there. Also, this technique bears the danger of accidentally marking a little bit of straight track with the speed reduction, which looks very stupid then. The signals could be made to read the track speed, then there would not be so much double work, but as they are now, the corresponding system call only works if the train is within 100 m but the aspect must be set when the train is more than 1 block away.

Dynamic speed limits can also depend on the aspect of the next signal, if the distance is less than the normal braking distance.

There are countries where they have 3 general speed limits, and there are countries where they have only one for all types of trains.

There are speed limits based on the radius of the curve (which are not the same for the curved track in switches); and based on the down grade.

At least in Austria & Germany, the maximum speed of a train is reduced if the braking capability does not meet the requirements set by the route description. This is hard to implement in the game because it is not just the one maximum speed that is reduced, but all the speed limits. An approximation would be to define the speed by which all speed limits are generally reduced (in steps of 5 km/h, as a property of one train in one scenario). But speed through diverging track is affected by other factors instead. Today, it is not reduced below 40 km/h even for the slowest freight train, but in steam era, there was one speed limit for passenger trains and another one for freight trains. The bad news for implementing this in KRS/RW is that this property can change when the composition of the consist changes (in particular for freight trains).

For shunting consists, as speed limit of about 25 km/h +/- 5 km/h applies in countries which distinguish between shunting and train movements. Today, this can be raised to 40 km/h (at least in Austria and Germany) if the signaller tells the driver that the path up to a certain location is set and locked.

There are/were also absolute speed limits for pushed consists, trains with bankers, double-heading.

On top of these, infrastructure managers sometimes decide extra speed limits, e.g., to reduce cost of track maintenance, or if some place needs repair.

All these speed limits were noted in the working timetable and a supplement for the temporary speed limits. From the 80ies on, they created an electronic form, the Ebula, which is the box to the right in the 294. It could be implemented in game if there was software to create the working timetable from the scenario and route definition. The result would be a texture file that is slowly scrolled on the screen on the Ebula box. This would also require scenario-specific parts in engines.


Regarding steam, I count myself with the geeks of geeks. I would be glad enough, if the following would happen, and I know it will not.

a) Fire temperature sinks when you close the dampers, and speed influences it significantly. I am not sure if it would rise at a stop, certainly depends on the amount of coal on the grate. Anyway, currently there is next to no reasonable way to get it down. You can only drown the fire in coal.

b) Steam can be lead into the tender resulting in warmer feed water. Feed water temperature should be considered.

c) The exhaust pipe can be moved by the driver, resulting in more or less draught, under the driver's control.

d) Complete in-depth documentation of the existing simulation, so we know how to tweak it to our needs.

With the old MSTS approach, it is very hard to avoid safety valves blowing off after you took the engine to its limits, no matter how well you tune it. You don't get rid of the steam and the fire, and if you let them drop towards the end of the trip, you easily run out of them. In the prototype, this is a challenge, too, but the mentioned measures help the driver.

Coal type can be considered in a holistic manner, and it is hard to get prototype information on the relation between differences in coal and differences in the performance of a single engine. Still, it is one of the key aspects behind the design on engines and one of the reasons for the diversity we see.

With detailed documentation, we might be able to create an acceptable workaround for compounds, which are so common in later periods that it is really a shame not to cover them.

There is a long list of interesting variants that will never make it into this simulation: Meyers and Garretts (slipping easily because one bogey is driven by high-pressure steam and the other by lower-pressure steam), stokers, oil and coal dust burning, condensers, etc etc etc.

Myself, I stopped experimenting with KRS early because of unacceptable exhaust visuals and because the advance over MSTS is minimal. In MSTS, I had some luck in tuning them nicely, but the above limitations spoil the fun of acting out their power in challenging situations.

The thing with the steam consumption is this (taken from memory and going by MSTS): They implemented something as twin-valve that no one means when they talk about twin-valve. It is not about the pilot valve, it is about compounds leading high-pressure steam to the lower-pressure cylinders to get the engine moving, or similar. The conclusion for MSTS was to always use single-valve.

The thing with the blowing safety valves is this: Most people do not understand driving a steam engine. As a consequence, they use far too much steam. To keep them from complaining, engine creators introduce insane steam production to keep people happy. Likewise, the AI fireman could be tuned by Kuju to just keep things going, no matter what the user does. For MSTS, there were lots of complaints about him. However, I never used it anyway, because firing requires planning and if the signals don't know where the train will go, how should the AI fireman know which grades lie ahead and at which speed the driver will take them?

The thing with the AI acceleration is that in MSTS, you set it in the consist file, which was stupid enough. But in KRS, they hid this parameter from the user completely. As a minimum, I would wish for MaxPower to be considered in AI trains, together with vehicle mass and grades. That would get us a long way towards realism, and I am not even mentioning friction and air drag. Very few people do races against the AI, but it is mandatory that it moves up a slope slower than running down, and/or a light engine runs faster than a mineral train, on an up-grade.

[ohanlon]

Kromaatikse
and it illustrates perfectly the lack of mechanical sense among the dev team.

Well I do know they had some very good advisers pointing to RS of course, if their
Input was ignored for the sake of it the game being aimed at a very low playing age,
which it was. 100% for reverser, brakes running through percentage numbers for all
types of models steam diesel electric, goes for bad planning and yes lack of mechanical
knowledge on all.

So we can surely assume it is just for looking at and wishing it was for real, fingers crossed
they might invite someone along to iron out a few of it faults and there are a few.

ohanlon

[AndyUK]

c) The exhaust pipe can be moved by the driver, resulting in more or less draught, under the driver's control.

AndiS,

I've never heard of that facility before, on British locos anyway; do you know if it was widely used? There was however an unofficial "mod" by some drivers that involved putting something across the blastpipe orifice to help the draught.

The thing with the steam consumption is this (taken from memory and going by MSTS): They implemented something as twin-valve that no one means when they talk about twin-valve. It is not about the pilot valve, it is about compounds leading high-pressure steam to the lower-pressure cylinders to get the engine moving, or similar. The conclusion for MSTS was to always use single-valve.

Thanks for adding to Kromaatiske's reply on that. From my observations it certainly seems that the Black 5 and 7F are using that erroneous model.

Andy L

[CaptainBazza]

The exhaust pipe can be moved by the driver, resulting in more or less draught, under the driver's control.

I recently read a reference to this, but don't know where. Sorry.

Cheers Bazza

[TheTazman]

Yes i have done this also. Feels bit to sensitve.

[AndiS]

c) The exhaust pipe can be moved by the driver, resulting in more or less draught, under the driver's control.

I've never heard of that facility before, on British locos anyway; do you know if it was widely used? There was however an unofficial "mod" by some drivers that involved putting something across the blastpipe orifice to help the draught.

A German book ("Der Lokomotivkessel" by Brosius & Koch who issued a standard text book series at their time, reprint of 6th edition from 1887) say that there are exhausts with fixed and variable cross-section. The depicted variable one features a hollow cone slipped into the exhaust pipe from below where it peeks into the bottom end of the stack. So it is not the exhaust pipe that is moved itself (would be hard to do that anyway), and not some flaps like I remembered, but some conical ring inserted into the exhaust pipe to reduce its sectional area.

The German Wikipedia says that "from 1900 on" various designs aimed at higher efficiency by creating variable exhausts, and introducing arrangements of multiple exhaust pipes.

I only found one reference to variable exhausts in English (at the URL below): The Lemaitre Exhaust featured "a variable area nozzle" in addition to 5 fixed ones. Most designers seem to focus on fixed exhaust size and clever pipe design.
http://www.trainweb.org/tusp/ex_dwgs.html

I did not mention the exhaust design at all because given the holistic approach of MSTS & KRS, you simply have to factor the efficiency into the given parameters of the game, just like you model feedwater pipes as "injectors".

Given the fact that only few designs feature the variable exhaust, I might be overrating its practical value, and control of the fire while running is more performed using the firedoor and the dampers. (The firedoor effect again is a very crude thing in MSTS & KRS, and an undocumented one, too.)

[AndyUK]

Interesting, thank you AndiS.

Andy L

[Kromaatikse]

Some GWR designs did use the "lifting cone" blastpipe nozzle as you describe. But AFAIK that was an automatic device, which lifted when the blastpipe pressure reached a certain value. I think the aim was to improve the smokebox coupling (ie. the draught) at relatively light working rates, while not causing an enormous fire-lifting draught when the engine was being worked hard.

And I suppose I did miss out the "ram air" effect on the damper. That would also be rather important, I suppose, as it strongly affects the amount of air flowing through the grate. I do know that tank locos usually had two dampers (one forward and one aft of the grate), while tender locos often only had one, pointing forward.

ETA: the "ram air" effect can be modelled by dynamically changing the pressure on the "atmosphere" side of the damper valve(s). If RW ever gets around to modelling wind, that will have to be included in that effect, of course.