[Rohit]

Dear all,

Is it possible to operate the locomotive wuthout the user in a mode where the system itself control and operate the locimotive as per the time-table.

[Matej Pacha]

Hi,
You can set up an activity or a timetable and switch the view to follow an AI train. That should do the same as you probably want.
However, I have some concepts on automatic cruise control (speed controller), but it's far from being released now.

How it helped.

Matej

[gpz]

I am in a process of implementing Railworks-like engine scripting, which actually allows writing of an automatic speed control script, although I have not written such a script yet. Actually such a scripting already works on my computer, but I am waiting with starting the discussion about this API until the waves around 1.0 release are flattened. This scripting interface unifies the current TCS interface (replaces it) with the ability of overriding existing MSTS cabview controls input data, issuing any locomotive command currently available built-in in OpenRails, overriding controls (e.g. throttle) without modifying their positions (like a real-world on-board speed controlling does), and defining per-locomotive custom controls in a custom keymap. These custom controls would be (at a later time) exposed to the animation handling subroutines, so that custom animations could be hooked onto them. These mostly work already for me, but it is not a good time to come out with such proposals now. I just wanted to inform you, to avoid parallel efforts. :)

[disc]

I think he asks about activity/timetable debug style AI train control. Currently for this i just created a service on a siding without stops, and just a small path.

[Rohit]

What that i meant was that the possibility of switching the control of our train to the computer so that it operates as per the timetable without our intervention.............

[copperpen]

Doing that just makes it another AI train. Personally I fail to see any useful purpose in this.

[Csantucci]

It is useful to debug activities. As already mentioned some times here, a workaround is to create a testing activity where the player train is transformed into an AI train, and where a dummy player train with a short path is created.
It is also the first step towards switching player trains (I mean appointing different player trains in different moments during simulation).

[copperpen]

If it is a step towards selectable player trains while in an activity, I can see a use for it, as is the debug facility. Both worthy candidates post version 1.

[roeter]

A few points here.
First of all, there is a significant difference between activities and timetable mode when it comes to possible switching of trains.
For timetables, all trains are equal, and no distinction is made between player and AI when processing the timetable details. Therefor, switching would be easier as all trains have all required info and details. The only limitation at this at the moment is that, as the actual run starts, the player train is an instance of the train class, while AI trains are instances of AITrain class which is a child of the train class. It is not possible to cast a parent to a child or vice versa so, at present, it is not possible to convert the player train to AI or convert an AI to player train. I'm looking into possible ways to overcome this but that will take some time, however the possibility to switch is important for timetable mode as certain actions (e.g. attach and detach) require the possibility to switch the player from one train to another.
For activities, things are much more complicated as specific items like station stops for the player train are not held in the train data but in the activity data. Switching between player and AI train would therefor require conversion of activity data to AI control data and vice versa - clearly much more complicated. Any triggers etc. defined in an activity can not be copied at all and would be lost.

A further complication is that the program does need a player train - it simply cannot live without it. So even if one day switching between trains would be possible, aborting the player train and just sit as passenger (camera 5) or as lineside observer (camera 8) will not be possible. I tried this, and the program just crashes left, right and centre - and that was without any HUD display, most of which are, ofcourse, directly linked to player train information and most certainly also would crash without an active player train.

Regards,
Rob Roeterdink

[mauried]

MSTS had a little documented feature called Introductory Train Ride mode where the Player Train
was driven by an AI Engineer.
ie it simply made the player train an AI train, but the train was still called the Player Train.
There are a lot of benefits in being able to do this in route debugging.
Firstly, it allows you to ride in the cab and watch whats going on.
You can watch the track monitor and see what the signals ahead are showing and
it allows fault finding where you dont have to sit at the computer for long periods of time waiting
until you get to a particular location in the route.
The feature in MSTS was enabled by changing 1 variable in the Activity script.
Whether this is possible in OR I dont know, but if it can easily be coded in , its a really useful feature to have.
The line in the Activity File which enables the feature is this one
Mode ( 2 ), which has to be changed to Mode ( 0 ) for Introductory Ride Mode.

[Matej Pacha]

mauried, on 09 November 2014 - 06:39 PM, said:

MSTS had a little documented feature called Introductory Train Ride mode where the Player Train
was driven by an AI Engineer.
ie it simply made the player train an AI train, but the train was still called the Player Train.
There are a lot of benefits in being able to do this in route debugging.
Firstly, it allows you to ride in the cab and watch whats going on.
You can watch the track monitor and see what the signals ahead are showing and
it allows fault finding where you dont have to sit at the computer for long periods of time waiting
until you get to a particular location in the route.
The feature in MSTS was enabled by changing 1 variable in the Activity script.
Whether this is possible in OR I dont know, but if it can easily be coded in , its a really useful feature to have.
The line in the Activity File which enables the feature is this one
Mode ( 2 ), which has to be changed to Mode ( 0 ) for Introductory Ride Mode.

What about the "Replay" feature? You can record a ride and then you can just watch. Since we don't have any ORTS content (as MSTS does), there is no intrudoctory mode, but you can create one.

Matej

[Matej Pacha]

gpz, on 08 November 2014 - 07:52 AM, said:

I am in a process of implementing Railworks-like engine scripting, which actually allows writing of an automatic speed control script, although I have not written such a script yet. Actually such a scripting already works on my computer, but I am waiting with starting the discussion about this API until the waves around 1.0 release are flattened. This scripting interface unifies the current TCS interface (replaces it) with the ability of overriding existing MSTS cabview controls input data, issuing any locomotive command currently available built-in in OpenRails, overriding controls (e.g. throttle) without modifying their positions (like a real-world on-board speed controlling does), and defining per-locomotive custom controls in a custom keymap. These custom controls would be (at a later time) exposed to the animation handling subroutines, so that custom animations could be hooked onto them. These mostly work already for me, but it is not a good time to come out with such proposals now. I just wanted to inform you, to avoid parallel efforts. :Neeeedsleeep:

Well, your efforts will be highly appreciated! I'll be happy to transfer the control algorithms to your script. But are you able to add a keyboard assignment? Or to control the brake system?
Thanks,
Matej

[gpz]

Yes for both. In current form a custom keymap can be created for a locomotive in json format. This keymap can contain built-in keyboard commands for being able to remap them onto a different key, and can also contain custom control names, which ones are available to use in the custom script for whatever function needed. The script can take over control on the brake controller, and is able to adjust the brake line pressure directly. In fact the latter can also be done with the existing brake control scripting interface, but it is in its current form is not enough for a full speed control. I think our decision with the splitted scripting APIs was wrong, and must be amended by merging them into a single one. This will be needed because different types of scriptable controls need functions that are already available in an other set. Fortunately there are only a very limited number of scripts exist yet, so it is not a hard decision to step on this way.

[Rohit]

Sir,

It is observed from the beginning that if we switch over to auto pilot mode, the train is always running behind the schedule considerably. is there any solution for that?. Also the reversal of the locomotive and attaching it to the other end of the train is not done by the auto pilot......Also the speed pick up and braking when in auto pilot mode is totally unrealistic. we may have to look into that also.........i congratulate the developers for introducing more and more sophisticated features on to Open rails so that the simulator becomes more and more close to reality. Kindly note down and rectify the above limitations.

[Csantucci]

Rohit,
thank you for appreciation.
I haven't the experience that the train is always running behind the schedule considerably. Maybe when the player drives the train he does not consider speed limits? :)
If reversals are within the path, they are executed. Loco uncoupling instead is not executed, because it is not within the path; OR obviously cannot interpret activity message where it is written "Now uncouple the loco". You have to press CTRL/A there, uncouple the loco, and then press CTRL/A again. Coupling instead occurs automatically, if the path is well behaved.
Referring to the use of throttle and brakes, it has been explained some times (also in the first post of the "Autopilot Mode" thread), that when the train is autopiloted, it behaves like an AI train, and AI trains behave like that. Autopilot mode is not a cruise control, which is a much more sophisticated feature that maybe will be implemented beyond release 1.0.