[roeter]

May I suggest to take all train-control items to separate tabs - one for activity and another for timetable mode (the few 'common' items could be included in both).
Not only will it make the 'experiment' tab less dense, it also makes it quite clear which options apply to which of the two different modes.

Regards,
Rob Roeterdink

[James Ross]

roeter, on 04 February 2017 - 06:25 AM, said:

May I suggest to take all train-control items to separate tabs - one for activity and another for timetable mode (the few 'common' items could be included in both).
Not only will it make the 'experiment' tab less dense, it also makes it quite clear which options apply to which of the two different modes.

Are there actually any items on the "Experimental" tab which only apply to one of those modes, and why would we not want to make them apply to both?

[RTP]

I tested this new feature in a subway route, plenty of AI trains.
Works almost fine, but it seems to affect at the starting time of the AI trains.

Congratulations anyway.

Regards.

[RTP]

A suggestion:
Reduce the open delay time to two seconds and the closing one to five seconds,

Regards.

[Csantucci]

It shouldn't influence starting time.

[roeter]

James Ross, on 04 February 2017 - 08:40 AM, said:

Are there actually any items on the "Experimental" tab which only apply to one of those modes, and why would we not want to make them apply to both?

• Forced red at station stops : does not apply to timetable as in timetable mode this is controlled by the $hold parameter.
  
• Extended AI train shunting : not available in timetable (when introduced, it will be controlled by timetable parameters).
  
• Autopilot : not available in timetable.
  
• Location-based passing processing : default in timetable mode (so not an option).

At present, AI trains opening doors is also not yet available in timetable mode.
Furthermore, specific timetable mode options are likele to be introduced as time goes by which cannot be applied to activities as the related functionality does not exist in activities, and cannot be added because of either MSTS compatibility, or the lack of appropriate methods to set the required parameters. Such options are envisaged in the planned update of timetable mode.

Regards,
Rob Roeterdink

[midneguy]

Carlo,

I'm curious if I can add something to the discussion regarding opening doors on AI trains - which is a neat feature by the way! I haven't tested this personally yet, but just noticing this topic now I thought of something I wanted to put out there... I assume this feature will open the doors on locomotives too when they have door animations? If so, do we want this to be the case? I've made several steam locomotive models which have the front doors of the cab animated so they can be run with the doors either open or closed. Of course the problem with this is that if you have cars in the consist that have door animations, those will all open and close as well which looks pretty odd.

Would it be possible to differentiate between .eng doors and .wag doors and be able to command them separately in the sim?

Derek

[Csantucci]

Hi Derek,
if you want to open a freight engine's door during run, you must not check the option I introduced and you are in the same situation you were before the option was available.
Differentiating between .eng and .wag doors in a straightforward way is not a perfect solution, because in DMUs and EMUs .eng and .wag doors should open/close at the same time. So one should check whether the .eng file has parameter PassengerCapacity ( number ) set or not.
It must be seen whether this feature is of interest of other people, is approved by the ORTS management team and finds a voluntary for implementation :)

[midneguy]

Carlo,

Thanks for your reply - I hadn't considered the cases of DMU's / EMU's, which makes sense after you mentioned it. Your suggestion of using the PassengerCapacity (number) parameter in the .eng file is an interesting one. I assume you were referring to AI trains in your reply, meaning that if this parameter is set to "0" then the doors wouldn't open when an AI train pulled up to a platform? I was thinking more of the behavior of player consists in my original note... Apologies if this is too far off from the thread topic but with door behavior being discussed I couldn't resist asking the question :)

Derek

[Csantucci]

No problem, you raised an interesting issue.
PassengerCapacity, when present, has a value greater than 0. If absent, MSTS and OR assume the trainset carries no passengers. I think that dividing door operation as you suggest is applicable for both player train and AI trains (of course in AI trains doors of non-passenger carrying engines would never open).

[RTP]

At the start of the activity there are two trains stopped at the station.

The AI one, have both sides open, correctly, but the player one have both sides closed and must be also open.

If you open this doors manually, the program does not close them.

Regards.

[Csantucci]

If you are the train driver you will have something to do! So it's to you to open and close doors for the player train, unless you pass to autopilot mode.

[RTP]

Yes, but I am in autopilot mode.

Regards.

[Csantucci]

In the starting station autopilot mode does not open/close doors. It must be done manually.
Also, if you arrive at a station in player mode and pass to autopilot mode when stopped at station, you will have to close doors manually.

[RTP]

OK.

Really, this feature adds life to the simulator.

Regards.