UK DMU - Getting Moving?

[NorthernWarrior]

Interesting to note - all the MEP motive power, including DMU's, runs fine with the autopilot option. So at least you can enjoy the route in OR even if you can't drive it very easily. And AP actually just the ticket at the end of a long day when you just want to take in a bit of scenery and enjoy some "thrash".

[baldwin]

Autopilot uses the same basic physics set as the AI, has nothing to do with what is in the eng file at all beyond exhaust parameters.

[haverfordwest]

Speaking of diesel exhaust paramaters. It is the only thing i don't like about OR, looks totally unrealistic.

[lateagain]

Autopilot uses the same basic physics set as the AI, has nothing to do with what is in the eng file at all beyond exhaust parameters.

....so how realistic are AI physics for UK stock?I have to stress this is academic interest as personally I'm happy to run the route in MSTS as I know how much effort went into making that right.

[baldwin]

AI in both MSTS and OR uses brute force to run a train at or close to speed limits. No actual player style physics involved, zero fuel usage etc.

[lateagain]

AI in both MSTS and OR uses brute force to run a train at or close to speed limits. No actual player style physics involved, zero fuel usage etc.

Each to their own ...but in view of the work I mentioned in post #10 of this thread it seems pretty daft to me to use a Sim where all the physics and environment work done for MEP is negated. Horses for Courses I guess.

[baldwin]

Each to their own ...but in view of the work I mentioned in post #10 of this thread it seems pretty daft to me to use a Sim where all the physics and environment work done for MEP is negated. Horses for Courses I guess.

It matters not which sim you use, both work in the same way where AI is concerned. If you were to apply player physics to AI, every activity ever made for MSTS would need to be completely reworked to run in OR.

Far as the MEP is concerned, the MSTS style physics used for DMUs are a total fudge to get the required performance. That performance could just as easily have been gained by not going down the "fudge" path and applying proper figures.

[lateagain]

ar as the MEP is concerned, the MSTS style physics used for DMUs are a total fudge to get the required performance. That performance could just as easily have been gained by not going down the "fudge" path and applying proper figures.

I suggest you read my post #10 again. ALL of the physics could be called a fudge. The point is that the "fudge" had all the stock performing realistically and relative to one another. I think you'll find that the variation in performance in physics in any of the sims is VERY variable and frequently totally unrealistic. MEP was over 6 years in development, has over 110 activities and was tested by some of the most thorough beta testers. Sadly the hardest working of those is no longer with us so he can no longer testify to this. "real figures" certainly didn't work for MSTS and that's why Mick spent so much effort on the "fudge" as you call it.If AI traffic follows speed limits then where is the difference between a Craven and an HST?

[csantucci]

Can at least one of the MEP activities be mentioned, where the problem is evident?

[dennisat]

Reference the Class 105 and 108 DMU performance in MEP.

I have modified these DMU eng files to give an acceptable performance in OR. I make no claims to them being "right" or representative of the performance of the real vehicles but they run reasonably well on my system. They also still run OK, but probably not realistically, in MSTS.

Examples are attached below, use at your own risk. The power / force figures can be scaled to modify other types of DMU.

Beware that a lot of these sets have one motor car with only a tiny installed power while the car at the other end has all the installed power of the full DMU set. I believe, and I'm probably wrong, that this is because they were created for pre BIN patch MSTS, before swapping driving ends was possible. The creator of the models therefore just put in one eng file at the front of the unit for simplicity. When swapping ends became possible with the BIN patch, the units were modified to change the trailing car from a wag to an eng with minimum power so that the original eng file didn't need modifying.

Dennis

[csantucci]

Dennis preceded me, using just one of the trainsets I also used.
These are the results of my check and test with the MEP-Cravens105R.eng . You will notice that the original file contains this line
MaxForce ( 70kN )
and this line
GearBoxMaxTractiveForceForGears( 7.2kN 5.5kN 4.1kN 3kN )

These lines are clearly incoherent: in first gear max force should be comparable with MaxForce. Instead, in the second line forces are much too low. The values give the impression that they were wrongly divided by ten. I tried multiplying them by ten, and got better results, even if in my impression acceleration in first gear is too high. And in fact the MaxForce value (which I compared with Italian gear-based DMUs) seems too high to me for such a lightweigh DMU.
It would be nice if some real value could be found.
I have seen that Dennis has provided for such line values quite similar to mine.

This is an example for a 42 ton Italian DMU, which runs satisfactorily on OR (clutch apart, but that's another problem) (note that the Cravens 105 is 30.5 tons)

MaxVelocity ( 150km/h )
MaxForce ( 41kN )
GearBoxMaxTractiveForceForGears( 40800N 35200N 28831N 23600N 15200N )



There are two solutions to overcome the problem, which clearly is caused by bad data.
1) creating an OpenRails folder in the DMU trainset folders, copy there the full .eng files and modify in such files the GearBoxMaxTractiveForceForGears() values. Using this way MSTS still uses the original data. This procedure doesn't seem too lengthy to me.
2) inserting a check in OpenRails, wich could be activated by the experimental option "correct questionable braking parameters", that could be reworded "correct questionable .eng parameters". The check could compare the MaxForce line value with the other line values and correct the latter accordingly. This would clearly be a "MEP-friendly" patch, but I think it can be justified, because it is an additional check which makes sense. And I appreciate very much the MEP route and its activities, so I'm prone to insert it.

[baldwin]

Adding a patch as suggested would also need to check and reset the throttle values for these DMUs as they also contain crazy values, 5 notches with values of 0, 1.5, 5, 7 and 10


These oddball values were developed by bavli http://forums.atomic-systems.com/vie...8bae3#p1326087 one of several threads on dmu eng file values.

[csantucci]

Yes, later today I noticed that; also those should be modified, and also the values of the THROTTLE LEVER block within the .cvf file. So the patch becomes a bit more complicated, and I wonder if it is worth the time to develop it.

[Shawmut]

Vern,

Do yourself a favour and download UKTS_37688_sb_Orchestrating_the_KX_Ballet, an activity designed expressly for both MEP and ORTS. This is, without a doubt, one of the best activities I've ever run, on any platform and depicting any time period and railway. Not because it's especially hard; it isn't. But the eye candy is simply phenomenal. It uses the stock from the MEP CD as well as 4 downloads, all again from UKTS. If you like watching intricate train manoeuvres this activity will not disappoint.

Cheers,

David

[csantucci]

I found out it was not too lengthy to cope with the odd values of the DMU .eng files.
Here http://www.interazioni-educative.it/...lation_DMU.zip you can download a .zip file containing two files that have to be unpacked in the Open Rails 1.3 folder - standard version - (after having backed up the originals, that is Orts.Simulation.dll and Orts.Simulation.pdb).
They include a method that recognizes the odd values, and corrects them, that is it multiplies by 10 the values of the max forces for every gear and divides by 10 the values of the throttle percentage.
It is not needed to check specific OR option checkboxes.
A feedback would be welcome.