[jonas]

Maybe the theme of opening single wagon doors is related to trigger animations of shapes by the player in general.
Just as a player can throw a switch by clicking on it (with ALT) any animation provided by a shape could be triggered by clicking on the shape, e.g. windmills, yard gates, gates of roundhouses or even single doors of a wagon could be toggeled this way. Could it be a summarized solution?
In the case of windmills, the animation would have to be permanently activated (or even stopped), while a door alternatively would triggered to open or close.

A similar suggestion I've seen at Trello on the card "Future" named "Additional animations for locomotives".

[James Ross]

roeter, on 05 February 2017 - 05:28 AM, said:

Forced red at station stops : does not apply to timetable as in timetable mode this is controlled by the $hold parameter.

Okay.

roeter, on 05 February 2017 - 05:28 AM, said:

Extended AI train shunting : not available in timetable (when introduced, it will be controlled by timetable parameters).

IIUC this option is like the MSTSBin sound option, in that it controls whether activities have access to new behaviours, and not changing existing behaviours as such. In that sense, I think the option logically applies to all modes but I would prefer that we simply remove the option and always enable the extended AI train shunting operations.

roeter, on 05 February 2017 - 05:28 AM, said:

Autopilot : not available in timetable.

We should allow autopilot in timetable mode.

roeter, on 05 February 2017 - 05:28 AM, said:

Location-based passing processing : default in timetable mode (so not an option).

Okay.

roeter, on 05 February 2017 - 05:28 AM, said:

At present, AI trains opening doors is also not yet available in timetable mode.

We should also allow AI trains opening doors in timetable mode. (And should stop introducing unnecessary differences based on mode like this[1].)

roeter, on 05 February 2017 - 05:28 AM, said:

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.

I'd like to know what these options will be, in that case. Bear in mind that new features you can activate in a timetable (like $hold) that don't apply to activities should not normally have an option, since their use is entirely dictated by the timetable itself.

Experimental options should be reserved for temporarily allowing large new features or potentially largely incompatible changes to be tried out and most such options should eventually be removed. As such, I do not think separating timetable- and activity-specific experimental options is worthwhile.

However, non-experimental options which genuinely only make sense for one or other mode can be labelled as such. If the option only applies to one because "that's the way the code is" then we should fix the code, not label the option.

Edit: [1] I've got an architecture diagram in-progress that'll show how this should be avoided, but in simple terms we need one Train class and that's it.

[Csantucci]

As of options for activity mode: Extended AI shunting and Autopilot should be default and therefore be removed from list of activity options.
Forced red at station stops should remain as a selectable option, as the two cases correspond to real world different ways of operation.
Location-based passing processing option should remain as a selectable option, because probably location-based passing processing may lead to some different working of MSTS activities (but I confess I'm unsure of this, but this is a reason more to leave the option available...).

[RTP]

After more testing, I think that will be more coherent open-close the player trainn doors at starting time.

Regards.

[jonas]

Csantucci, on 07 February 2017 - 12:04 AM, said:

...Forced red at station stops should remain as a selectable option, as the two cases correspond to real world different ways of operation...

Forced red at station stops option has also a big influences on how an activity will work in OR compared to MSTS.
In my AddOn, I strongly recommend to leave this option unselected for at least one certain activity, because otherwise the player train is overtaken by an ai train in a station and this ai train occupies the track ahead the player train. The departure of the player train is therefore considerably delayed.
So Forced red at station stops should remain selectable IMO.

[VicenteIR]

James Ross, on 05 February 2017 - 02:51 PM, said:

We should also allow AI trains opening doors in timetable mode. (And should stop introducing unnecessary differences based on mode like this)


 I've got an architecture diagram in-progress that'll show how this should be avoided, but in simple terms we need one Train class and that's it.

Hi!
Is it something new about AI trains opening doors in timetable mode?
Thank you.

[LeoGarcia]

Caro Santucci,

I am using version X4259 of Open Rails. Unlike the stable version, in the Southern Hemisphere dawns and dusk at logical times. But going to the topic of this thread, I am amazed with the implementation of the doors for AI.

If it was not annoying, I would like to make a few suggestions.

That in the file "OpenRails\route.trk" can be configured the time for before and after the opening and closing of the doors. I understand that this time is not the same in an urban tram as in a railway where the protocol makes from the time of closure to the start of the march is greater.

That this new technology can be implemented to Timetables. If this is not possible, I will try to create an Activities generator from Excel, like the one I have for Timetables.

Best regards.
(My English is very bad, would you prefer that I try to communicate in Italian?)

[Csantucci]

Leo,
thank you for your post. Your English is quite above the standard for foreign people (IMHO), so pls. continue with it :)
Adding this feature to timetable mode is outside of my scope of intervention in Open Rails.
Your proposal about providing the possibility of configuring the time before opening and after closing the doors is interesting, even if I'm not sure that the .trk file is the best place to insert the parameter (for sure it's the simplest one). Anyhow that won't occur before 1.3 is out.