Using the Antislip line in AI engine files

[TGM]

Hi all,

Here's a question for you all.

I want to know what your guys thinking is with regard to this line added to a AI engine file: Antislip ( 1 )

Does O\R treat this the same MSTS? , or are the O\R engine physics for AI engines better so that this line is not required?

I would be interested in your thoughts.

regards Tom

[R. Steele]

I think I remember reading in the threads (at Elvas) that in OR antislip is set for AI trains because they cannot detect wheelslip whereas, the Player loco uses the advanced adhesion model.

Search the OR threads here and at Elvas using "antislip"

[TGM]

Thank you for that Gerry.

[plainsman]

I don't think you should use the antislip line (even empty or with a 0 inside ) in OR on any files!

[TGM]

Bob,

If I may be so bold. Could you please tell me your reason(s) for thinking it should not be used? Every engine I have is using a version of your physics so your opinion counts to me.

regards Tom

[plainsman]

According to Matej, if the program finds the antislip line present, it reverts to the simple physics model. When the ORTSadhesion ( ORTSCurtius_Kniffler ( 7.5 43.7 0.1619 0.7 ) ) line is fully functional (it may be this weekend?), this will be even more important. The problem with OR right now, is there is a default adhesion setup being used until the ORTSadhesion line gets fully implemented. This works more or less OK for a modern DC diesel, but hopelessly underperforms on something like an ES44AC or SD70ACe. The problem is partly the failure to put in an auto sanding option. Once the line is working correctly, I can write the files for near sanding adhesion in the stable region, which is essentially what I had to do in MSTS. With the default, max continuous tractive effort for an ES44AC was about 111,000 pounds when it ought to be about 180,000 pounds (some heavy CSX units weighing 432,000 pounds have the computer adjusted to bring it up to 198,000 pounds). To show what this means, a real world C42-8 has a continuous tractive effort of ~109,000 pounds, and the DASH 9 is about the same, (electrically both are power limited to 4,000 HP at the minimum continuous speed). So until the line is working correctly, a SD70ACe is no better than a C42-8 on a heavy coal drag.
BTW, Thanks for the comment, I am glad you have found the files helpful!!

[TGM]

Thank you for clearing that up Bob.

Your files have certainly made a huge difference (well at least to me). I even use them on most if not all of hundreds of freight cars that seem to keep appearing in my collection.

Anyway Bob, keep up the good work, it is appreciated.

regards tom

[gpz]

When the ORTSadhesion ( ORTSCurtius_Kniffler ( 7.5 43.7 0.1619 0.7 ) ) line is fully functional (it may be this weekend?)

No, it was the previous weekend, r2922.

[Gary54]

I've been following this and other similar discussions relative to ORTS adhesion for some time. I should point out that all of my locomotives use Bob's physics files. It appears from the above that I need to remove the AntiSlip ( 1 ) statement from the AI engines and include the following statement; ORTSadhesion( ORTSCurtius_Kniffler ( 7.5 43.7 0.1619 0.7 ) ).

I have three questions that I hope to get some insight regarding. My first question relates to what form this statement should take in the *.eng file. That is, do I simply include the line as spelled out above? (2) Can this line substitute for the MSTS line, "Adheasion ( 0.76 0.85 2.0 0 )", assuming that I have no plans to use the engine file in MSTS? In that case, it may be possible to make the substitution for multiple engines using a utility like RouteRiter. Finally, will the A,B,C, and D values used in the ORTS statement vary as a function of locomotive type?

Thanks very much for any insight regarding these questions. By the way, Bob's mention of the reduced pulling power of such engines as the ES44AC is rather evident. I'm running a coal train comprised of 110 loads powered by an ES44AC and a D9-44CW at the head-end and two ES44ACs (based on an observed consist on that route). According to Conbuilder, the train weighs in at 16,700 tons and has a HP/ton of 1.03. I'm running it on the NS East River Route and it's a struggle. I, for one, look forward to Bob's near sanding adhesion in the stable region files.

Gary

[baldwin]

Far as I am aware, if the ORTSadhesion line is not present, it should default to the MSTS adhesion figures. What I would like to know is how do the experimental adhesion sliders fit in to the equation, and what are they modifying exactly.

EDIT: There is also the the setting for the moving average filter size. What does this do, and what would the optimal setting be for it?.

[plainsman]

That isn't true Baldwin, not according to Matej. The default is built in. They never did figure out how to deal with the way MSTS defines adhesion (adheasion). The numwheels thing threw them off, and they wrote all that while I was moving.
Yes Gary, For OR files you won't use in MSTS, take out the antislip line altogether, remove the TWO numwheels lines, and substitute the new adhesion line for the old MSTS adheasion line. You will also need to divide the power setting in V4.7 and newer files by 0.972. The program has a built in power net for prime mover loss, so you have to return that power in my files, as I took a net of all transmission efficiency loss to the rail. I will talk more about the settings in a later post, maybe this afternoon?

[baldwin]

Well Bob, Looking at the code in MSTSwagon.cs we have these two code segments,

        public float Adhesion1 = .27f;   // 1st MSTS adhesion value
        public float Adhesion2 = .49f;   // 2nd MSTS adhesion value
        public float Adhesion3 = 2;   // 3rd MSTS adhesion value
        public float Curtius_KnifflerA = 7.5f;               //Curtius-Kniffler constants                   A
        public float Curtius_KnifflerB = 44.0f;              // (adhesion coeficient)       umax = ---------------------  + C
        public float Curtius_KnifflerC = 0.161f;             //                                      speedMpS * 3.6 + B
        public float AdhesionK = 0.7f;   //slip characteristics slope

and

     case "wagon(adheasion":
                    stf.MustMatch("(");
                    Adhesion1 = stf.ReadFloat(STFReader.UNITS.None, null);
                    Adhesion2 = stf.ReadFloat(STFReader.UNITS.None, null);
                    Adhesion3 = stf.ReadFloat(STFReader.UNITS.None, null);
                    stf.ReadFloat(STFReader.UNITS.None, null);
                    stf.SkipRestOfBlock();
                    break;
                case "wagon(ortsadhesion(ortscurtius_kniffler":
                    //e.g. Wagon ( ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) ) )
                    stf.MustMatch("(");
                    Curtius_KnifflerA = stf.ReadFloat(STFReader.UNITS.None, 7.5f); if (Curtius_KnifflerA <= 0) Curtius_KnifflerA = 7.5f;
                    Curtius_KnifflerB = stf.ReadFloat(STFReader.UNITS.None, 44.0f); if (Curtius_KnifflerB <= 0) Curtius_KnifflerB = 44.0f;
                    Curtius_KnifflerC = stf.ReadFloat(STFReader.UNITS.None, 0.161f); if (Curtius_KnifflerC <= 0) Curtius_KnifflerC = 0.161f;
                    AdhesionK = stf.ReadFloat(STFReader.UNITS.None, 0.7f); if (AdhesionK <= 0) AdhesionK = 0.7f;
                    stf.SkipRestOfBlock();
                    break;

These have both MSTS adheasion and ORTSadhesion and this has to be so, because not everyone is going to be writing Curtius-Kniffler into their eng files. So, if Curtius-Kniffler is not present the fall back aka default is the MSTS adheasion line as I see it. I may be wrong in my assessment, perhaps Matej can clarify. Actually it was Peter (gpz) who made the change in X2922 so it now reads as shown above.

[Gary54]

Thanks very much, Bob. Regarding the changing of the power setting; are you referring to the "MaxPower" rating in the *.eng file?

Thanks again. Looking forward to your further discussion on this topic.

Gary

[gpz]

These have both MSTS adheasion and ORTSadhesion and this has to be so, because not everyone is going to be writing Curtius-Kniffler into their eng files. So, if Curtius-Kniffler is not present the fall back aka default is the MSTS adheasion line as I see it. I may be wrong in my assessment

The parser is there for "Adheasion" indeed, but the values are not used for anything, except the first one in case AntiSlip(1). In all other cases the default ORTSCurtius_Kniffler() values are used.

[baldwin]

I see. So I can actually strip out the old MSTS adheasion line and antislip from the eng files as they are in fact redundant now.