[Csantucci]

I was chasing a bug on wheel rotation in Autopilot mode, and noticed that this was related to the Antislip() parameter (that is forced to true for AI trains).
I then removed from the Acela.eng the comment around the Antislip() parameter, because I wanted to check how OR behaved with Antislip = true; well, Antislip remained false.
I looked at the OR code and noticed that OR looks for Antislip() within the engine part of the .eng file, while all MSTS trainsets using antislip have it set in the wagon part.
I looked at the original MSTS .eng and .wag file reference manual, and found that antislip must be set in the engine part.
I remained a bit confused.
I looked then at the tables of truth (Trainsim forum) and found this thread
http://www.trainsim....hlight=Antislip
where Coonskin (Andre Ming) states that it must be placed in the wagon part (and also others comment in other threads that it works, if put there).

Therefore, if there aren't further hidden parts of the story, I would correct the OR code so that it searches for Antislip in the wagon part.
From the OR code I also see that the advanced adhesion is disabled if antislip is true.
Probably a correction must also be done in MSTSWagonViewer.cs to have wheels rotating correctly.

[engmod]

Matej is looking into a wheelslip issue!

https://bugs.launchp...or/+bug/1351812

[roeter]

Anti-slip is set for AI trains as AI trains cannot react to any wheelslip. Wheelslip is only reported at engine level, while AT controls the trains at train level. As there is no report for wheelslip at train level, wheelslip can occur without the AI control knowing of it and thus without reacting to it. The result is a complete loss of power, and an AI train which is firmly stuck.

At present, in timetable mode, when the player train is formed out of an AI train, the antislip setting is 'carried forward' to the player train. This will be corrected soon, with the setting for the player train derived from the setting of the player engine.

And, indeed, advanced adhesion is switched off when antislip is true. In a consist with multiple engines (or an MU), I found that having some engines with antislip (and thus without advance adhesion), and some without antislip, can cause all sorts of problems, with engines even completely shutting down during normal running. Likely, the enormous difference in power (sometimes there is 10 times the difference in output power between the same type of engines, depending on a.a. on or off) causes all kind of trouble with slipping etc.
Perhaps antislip and advance adhesion should be distributed to all engines such that all engines in a consist use the same setting.
And perhaps antislip should indeed just be antislip, and not disable advance adhesion.

In all, there is still some work to do there, I think.

Regards,
Rob Roeterdink

[elvasleis]

Hi,
I am amazed when reading this how you all are looking at making OR perform properly in such detail.
Keep up the good work.

Regards Geoff.

[gpz]

 Csantucci, on 12 February 2015 - 12:04 PM, said:

From the OR code I also see that the advanced adhesion is disabled if antislip is true.
Probably a correction must also be done in MSTSWagonViewer.cs to have wheels rotating correctly.

I agree that antislip should be antislip only. It is good that you noticed this mine, and I think it should be removed now. Such "hidden features" might just make future development harder.

[Csantucci]

Before decoupling advanced adhesion and antislip maybe Matej should intervene, as he has developed the whole advanced adhesion feature.

[disc]

So what is this antislip() is it removes the possibility of wheelslip( physics hack), or this works like in cars? (at wheelslip, the computer reduces the tractive force until the slip stops).

[Matej Pacha]

Well, Matej should have a look at it :offtopic:
The reason why the antislip works this way is, in the times of creating the advanced adhesion, the throttle controller had only one value. There was no possibility to limit throttle without moving the lever, what is nonsense. In real world, the throttle lever is just a command to the control system. The output power is controlled based on many parameters. Anyway, quite recently Peter Gulyas told me about this new feature of the throttle controller and this makes the antislip feature doable. I just need to change the advanced/simple adhesion logic and add this antislip modelling I have tested in my cruise controller version (not published, but working).
It is very hard to find some OR time last year. I have many responsibilities connected with my full time job at the university, I do some traction calculations for my part time job, which has turned into 3 brand new locomotive projects I lead and finally, I'm pretty much involved in IEEE as a section chair. I'm fighting with it and trying to stay in contact with ORTS at least. I know, it's an off-topic, but I just want to say sorry for me not contributing in things I have started. I'll try to do it, because I think ORTS deserves it.
Matej

[gpz]

 Matej Pacha, on 13 February 2015 - 02:24 PM, said:

Anyway, quite recently Peter Gulyas told me about this new feature of the throttle controller and this makes the antislip feature doable. I just need to change the advanced/simple adhesion logic and add this antislip modelling I have tested in my cruise controller version (not published, but working).

Feel free to use MSTSLocomotive.ThrottleIntervention and MSTSLocomotive.DynamicBrakeIntervention variables, currently they aren't used for anything else. Set them to -1 to off, or into range 0-1 to have effect. I just see that I havent't committed the copy of their handling code from MSTSLocomotive to MSTSDieselLocomotive, so I amended it in r2871.

TrainBrakeIntervention and EngineBrakeIntervention is not yet implemented, because I was not sure in how to do it properly. It is more complicated than the above, since the position of apply start within range 0-1 varies from one locomotive to other locomotives, and it would be good to have a common sense for this variable. (Just think of the future scripting.) My original idea was to use
-1 to off,
0-1 range from neutral (hold) to full service, 1 being the full service,
2 to emergency.

There must be an explicit emergency state, since e.g. ETCS handles it also separately. Also, forced "release" intervention might not be necessary at all, I cannot think of a situation, where it could be used. In any case, the effective brake application rate should be the max of the intervention value and the value set by the physical controller. So a "release" intervention practically is the same as switching the intervention off (-1) entirely.

What do you think?