Dodgy physics

[Dan]

I wonder if it is worth trying to devise a 'test' dark route. No scenery or anything like that, but a basic route with the kind of features, layouts etc you might expect to get and then to experiment.

A UK preserved route could serve as a fairly short basic model. Terminus, 3 or 4 passing loops - another terminus but without signalling. It might give us an idea as to how AI operates in such circumstances or if it has a massive hissy fit.

Nick - That makes sense. What I am saying is that if in a dark context we can not get the AI or the dispatcher to respond dynamically to the player train then the alternative would be to make the available scenario dynamic. Let me use the example you gave:

Scenario 1

1) Pull your engines off of Mohawk 7.
2) go to Mohawk 5 and pull the first six cars.
3) Take the engine and your six cars and go to mohawk 4
4) Double to the first 13 cars on Mohawk 4.
5) Back to Mohawk 5 and now grab the remaining 11 and your caboose.

OK. So say it was a single line with two passing loops between Mohawk and Delanson Yard. Now you are scheduled to take 10 minutes to do the switching and make your meet with an AI train at loop A.

I am saying that at this point there should be a divergence. If you do the switching in time then you get to make your meet and you i) don't get held anywhere or ii) get told to meet somewhere else. So if you do you get this scenario

Scenario 2a

6) Now head to Delanson Yard, meet AI at loop A and stop on main 2 at JX Cabin signal.
7) Cut away your engines and pick up two cars off head end off Delanson 1.
8) Head back to train and make your double.
9) Now make cut between cars 8 and 9.
10) Back to Delanson 1 and spot cars 3 to 8 on Delanson for the Altamont Branch Local to work later.
11) Back to Train and double cars 1 and 2>

Lets say for whatever reason you take 25 minutes to do your switching. Well in real life you would be holding up traffic potentially and your scheduled meet might be relocated or you might be forced to wait. So if you take longer than 15 minutes your next scenario looks like this:

Scenario 2b

6) Wait 15 mins for AI train to arrive
Now head to Delanson Yard, and stop on main 2 at JX Cabin signal.
7) Cut away your engines and pick up two cars off head end off Delanson 1.
8) Head back to train and make your double.
9) Now make cut between cars 8 and 9.
10) Back to Delanson 1 and spot cars 3 to 8 on Delanson for the Altamont Branch Local to work later.
11) Back to Train and double cars 1 and 2>

What happens is that what the user sees in terms of AI acting 'dynamically' depends on what they've done, but in reality it is just differently scripted scenarios, but the user can not do 2a if they have taken longer than 15 mins to do their switching. If they do take longer than 15 mins then the scenario available to them is 2b.

The nearest thing I can describe it as is like those 'choose your own adventure books' that children had/have. Do A turn to page 21, do B turn to page 50.

This would then cascade downwards, so from 2a there would be a 3a and 3b depending on if they did their switching at Delanson yard in good time or not. If you had been doing 2b then you'd have 3c and 3d to reflect if you were able to make up time (or not lose any more time) or if you lost more time. And so on and so forth as the whole thing progresses through the day.

[TrainMaster1]

Dan:
That could indeed be interesting to set up "if/then" reasoning to create a variety of packages. That holds no interest for us but could indeed be something interesting for others to tackle... I like that idea a lot but it does not fit with what we do.

What we do not do and will not do in creating our packages is add in trains that were not there in the real world.

I have this question repeatedly from guys who think "I can see you is so important"...That is not true at all as this line saw maybe a total of 20 train in 24 hours. I have run in revenue service freight and passenger and can tell you that well over 90% of your day you do not see another train. Think of it this way...let's say I have 20 trains to move today 10 west and 10 east...you are WB #1...already you will never see WBs #2-10 as they are behind you. (Unless you do something crazy or a priority train catches you, it is your parade to lead.) Okay it is a 4 hour run end to end and trains leave on the hour. 30 miles per hour is the maximum speed on our line and all train are 1 mile in length.

For the first two hours you see nothing. At the two hour mark EB#1 passes you for exactly 1 minute!!! At 30 mph and he is moving at 30 mph, a one mile train is gone in one minute!!! Then you will see EB#2 also for a minute and then EB#3 for a minute and as you pull into the yard at the end of your run at the 4 hour mark EB#4 just getting ready to leave....your run 240 minutes (4 hours) Total I can see you time 3 minutes. We have many current and former RR employees running with us. That is why operations is more important...we know I can see you happens far less than people think it does. Our goal: the railroad is more important than the game so we run right or don't run...that does not mean that guys can't use what we develop and create all kinds of fantasy scenarios of AI traffic whenever they want it. Our packages will not include it though.

Our goal is to create a real day. Only train SU-10 saw that day was PB-100...now in our session he will see it again somewhere between Esperance on the south end and Kelley's on the north end. The DS (in our case a live human) has the say in where he wants the meet to happen...how fast the switching gets done (15 and 25 minutes??? You are lucky if that happens again using real world speeds and rules).

In our session he might see trains as follows:

NWB-4 (If not delayed he will be north of mohawk before SU-10 shows up.)
PB-100
Shippers Special Inspection Train

SU-10 is lower priority than all 3 of these as NWB is an Expediter, PB 100 is Piggy back hot shot...and well the bosses are riding the Inspection Train so good luck telling them they are waiting for a local. Your next paycheck will be waiting longer.

So SU-10 will only see 2 trains in its almost 4 hour run cause that is how the real road runs...we won't add AI traffic just for the sake of "seeing" something.

Our busiest sessions some trains will see 8 or 9 opposing moves during their run. Again this is on a route with about a 4 hour run...you will have a train in your window about 10-15 minutes out of 4 hours. So you better enjoy looking at trees, ballast, grass, cows for 3 hours and 45 minutes of a typical run.

Only route that might differ from this is on NEC where there seems to be a train every few minutes. We will never use that route in a session as it has zero challenge to dispatch or run properly. If you can make station stops and crank it up to 125 you know are qualified to run the NEC...

Nick

[Kali]

Clone the Falmouth line - it's got 3 passing loops and two small yards at each end ( and some yards in the middle if you want ). Frankly I reckon you could just pull the signals on that underground and run it normally so you can try messing with dispatcher priority levels and see what happens if you're late. You *can* get the dispatcher to be a little dynamic in terms of occupying your path if you're late and so on - you won't get it to suddenly decide to back an AI train in a siding to get out of your way though as a choice ( rather than an explicit event ). It's a case of translating the "wait for block ahead to be clear at time XX:YY" into "wait for train X to pass" when you're setting it up, which in terms of single track timetabled events isn't really that different.

[Kali]

Hmph. Well, I've tried a lot of things, and I can't make handbrakes on cars activate from scripts - so I can't independently control wagon brakes, I'm afraid. At this point I can either a) turn them all into zero power diesel electrics and hope that gives more control ( or borrow the dynamics; if you set everything in straight lines and deactivate at 0 mph it might work, even get shaped brake response ) - I have no idea what that will do to performance or b) make the best of what I can with what we do have. I guess I will give the unpowered engine idea a quick go, but I really don't like that solution much. I don't like the idea of several hundred simulations running...

If that doesn't work there's this to play with:

* EQ gauge
* train brake apply/release timings for the whole consist at once without any propogation.
* compressor settings - don't forget if the train brake is slow to apply, the compressor will start refilling the reservoir before the full application is made
* I could maybe virtualise the compressor/reservoir & just not apply any brakes if the air has run out, in which case I might as well virtualise the brake timing and the rest of the gauges.
* There's no way of deciding that the air reservoirs at the back of the train have run down more ( or more accurately have recharged less ) than the front so that there's proportionately less brakeforce there, other than averaging total consist recharge rates based on length and applying less overall brake.

I'd like some input ( hopefully some pro input ) on the best way to use what's available.

[arizonachris]

Y'all are gonna cry when you see how bad the braking is on the "new" tunnel motors. I can hit 2% brakes and it's already self lapping. Two locomotives at 25% throttle drag to a stop fast wit 2% brakes. I can go to zero brakes from, say, 20% full service (yeah, 20% is full service) and the pressure is back to 90lbs in a second. Way to model, RSC. I was gonna recommend Donner to VORA, but the way it's messed up, better wait.

[GaryG]

I'm taking the 100 car loaded coal train over Donner Pass. Until I modded the Dash traction settings there was no way I could get up the hill.

Braking and dynamics are still a jokes. First Dynamic setting (11%) and minimum trainline pressure drop is enough to control this heavy train on the 1.9% descending grades.

I had a couple ideas that might work and could also allow much more accurate train braking realism.

The ideas - move the "MaxForcePercentOfVehicleWeight" control from bin files and set it using the same script that passes values along the consist, the one that allows all loco throttles to follow the driven loco. This allows for an easy adjustment of all stock with one setting (in the single script) until we find a setting the user is happy with. Set one variable and you have prototype operation, change it to another value and you have toy train operation, you probably get the picture. The script might also be able to add a bit of randomness to introduce a bit of variation in train handling.

The TrainLine pressure changes quickly from end to end of our trains but if we could control the value via the same script we could control the increment or decrement amount at each car in the script thus introducing a delay in the propogation. This assumes the script is controlled by timing rather than just triggers.

The first idea should be fairly quick to test. For the train I was running, three or four files and one script to change (Hopefully, I can try later today).

The second idea will require experimentation; perhaps someone has already played with the parameter passing script and knows if this idea can work.

As for computer impact, I feel most of our computers now have spare CPU time when running this program (graphics being the main bottleneck) so this idea shouldn't cause an impact with the frame rate which we would notice.

GaryG

[Kali]

2 won't work, see previous in the thread. 1 is a matter of saying "this amount of brake handle means this much less actual brake", but that only applies to the engine... so see 2.

The only way any consist-length independent brake control is going to work is to make everything an engine.

[TrainMaster1]

If you are referring to the the independent brake-that only applies to the locos. Independent adds zero braking to the cars other than the fact that the loco(s) is/are stopped and eventually they run up behind the engines. Indy only used at low speed and in switching (shunting). Train line for the cars (automatics). If I understood what was said correctly.

Nick

[Kali]

No, I mean independently controlled braking on each item of stock - independent of the all-at-once train brake we have now. Well you can manually go and toggle handbrakes with the mouse every 2s if you want, but I'd rather something a little more automated :)

[GaryG]

Hi,

I might be confused (more than just age related) but I'm assuming the number two mentioned was the second item of my previous post. The second idea wasn't for using the independent for the train but by playing with one of the variables in the car's file that is normally a fixed value in the xml/bin file. If we remove the setting of 'the' variable from the xml/bin but set it via the script we might be able to have more control of the braking power and application/release times on a per-car basis. Example - if we decide to play with the triple valve value, a zero value would give no braking no matter what the trainline value was. if the script can see a changing trainline value, the script could slowly increase or decrease the triple valve value in the zero to 2.5 range. This way, we now have controllable brake application/release speeds at the car itself. There may also be a way to introduce a propogation delay via the script as well.

The other idea would be based on removing the setting of the "MaxForcePercentOfVehicleWeight" variable from the xml/bin file and setting it to a constant value defined in the script. If this change was applied to all xml/bin files then changing the braking amount value from prototypical values to 'play' values would entail changing the constant in the script, a single edit.

If these can be accomplished via scripting, then we might be able to give ourselves almost prototypical braking control and adjustments; adding a retainer function might be possible later. Additionally, if successful, I would think that the "official powers across the Atlantic" might adopt it and do an official update to give proper braking control for Westinghouse type braking without program code changes.

It does appear that sucessful script tinkering is (at this time) beyond my capabilities - it's not a language I'm familiar with. I guess I'm now just running this idea up the idea flagpole to see if any salutes occur.

GaryG

[Kali]

You can't change blueprint values in script. All you can change is control values, and apparently not many of those in anything but the lead engine. Predefined controls in the controlcontainer section are your variables, everything else is constant.

Well you might if you were prepared to write a whole dll in C/C++/C# or whatever which poked around in the running executable's memory and somehow managed to find where it's storing them, but you can't do it in plain lua.

[GaryG]

Hi Kali

Ok. It was just a thought that I hoped might be possible.

GaryG

[Kali]

It was a nice thought! even just being able to change the weight would be quite something, you could combine it with child objects and make scriptable loading/unloading... or as you say adjust the brake force, although changing the weight of a vehicle has a lot of other effects - momentum, couplers, etc.

[Kali]

Okay, so I've been playing with the air system, slowing the compressor down a lot. Amusing broken item #1: it takes air out of the air reservoir to release the independent brakes - unless US engines do something totally peculiar this is 180 degrees from what it ought to be. Not only that but it runs the air out quite incredibly fast.

Which brings me to the next question; how many full applications & releases would you be expecting to get out of an engine's air reservoirs? I can't imagine it's just once and then you have to recharge the engine air tank; however this is what we currently have in the blueprints and it's not helping with the independent brake the way it is. Actually it appears to be a 1.1 ratio so 11psi in the pipe reduces the main reservoir ( not talking about the EQ system ) by 10psi.

Edit: There appears to be no way to dump brake cylinder pressure no matter what combo of settings you try - if the train pipe pressure isn't climbing, then your cyl pressure isn't falling ( which admittedly is fine for a distributor, but I don't have a distributor set up at the moment ). Except for the first release, that seems to dump pressure fine, after that ... nope. It seems there's magic air tanks too; if I empty the main reservoir using the straight air brake and then apply the auto brake, it will put the full pressure I wanted into the brake cylinders even when there's no air to do it. There's so much fundamentally wrong with this ( I'm sure you could full release any time in RW2 ) I just don't know where to start, and there's no way I'm writing an essay to RSC support about it - I'm pretty sure they don't actually listen to me anyway.

Going to have to wait until I can script the entire system & just use the Direct brake notch I guess.

[Rich_S]

Hi Kali,
Here's another one for you. If you shut the engine down via the "Z" key and just coast down the track, somehow the air tanks magically get recharged as you use air? This is very funny since most EMD's have shaft driven compressor's and most GE's have 3 phase compressors. In both cases if the diesel engine is not running, you don't have an air compressor to recharge the tanks One last note, on most modern locomotives the compressor shuts off at 140 PSI and kicks on at 130 PSI, but you'll find cases were you might drop down to 125 PSI before the compressor kicks on. It usually take several quick applications and releases of the independent brake to drop the pressure from 140 PSI to 130 PSI.

And yes, the independent brakes do seem to work backwards in RW. When apply the brakes there is no drop in main reservoir air pressure, but when you release the independent brake then the main reservoir pressure drops and instantly recharges? The main reservoir pressure should drop as you apply the brakes. Another thing I've noticed is RW seems to treat a independent brake application like a Automatic brake application which is totally incorrect. The independent brake sends air directly to the brake cylinders on the locomotive, so there should not be any delay like you get with a Automatic brake application. I know this is a problem Kuju had before trying to make one size fit all, but in doing so we end up with braking systems that are not working correctly

Regards,
Rich S.