[James Ross]

Currently, three different modes of play are split between two distinct menu options: Activity and Timetable. I believe it would be better merge them together and have a single list containing Explore Route, <activities>, <timetables> and <timetable sets>. We'd keep all the same options but remove the unnecessary choice of two modes (when there's actually three).

The available options would be mixed together and sorted alphabetically, forming the union of the current "Activity" and "Timetable set" lists (the latter contains individual timetables too).

• If you choose Explore Route, you can choose the locomotive, consist, starting at, heading to, time, season and weather.
  
• If you choose an activity, you can't choose anything.
  
• If you choose a timetable set, you can choose a timetable, train, season and weather.
  
• If you choose a timetable, you can choose a train, season and weather.

Blueprint: https://blueprints.l...ties-timetables

[RTP]

Agree.

Regards.

[gpz]

Theoretically, an alternative selection method is also imaginable. The selection preferences might work similarly to the Excel column data filters.

1) The player might start from selecting the "Starting at" preference first, where the list of starting locations might be decorated with icons/colors/whatever based on whether there is an activity/timetable path starts from there, or just an explore route.
2) Then the "Heading to" might be selected, also from a decorated list.
3) "Starting Time" might be the 3rd (or the 2nd, preceding the heading to), also decorated.
Etc... When the user selects something from either lists, the not-anymore-relevant entries from the other lists might get greyed out with ordered to the end of the list.

[James Ross]

gpz, on 20 December 2015 - 06:37 AM, said:

Theoretically, an alternative selection method is also imaginable. The selection preferences might work similarly to the Excel column data filters.

Yeah, I've been wondering about a search box that searches activity names and path start/end names and such like.

I'd like to simplify the menu a bit first, as long as there's no objections to that, and then we can look at improved ways to find things. Feel free to throw some blueprints out there on these ideas though, I should put more of mine up too. :)

[conductorchris]

May I suggest the addition of another choice? That being a static consist set.

Perhaps this is complicated enough to consider another feature and do later? but it's future inclusion is worth considering in the current plans.

We could use this set (or multiple sets) of static consists in timetable mode and explore mode. Perhaps it would be based on the MSTS activity format. Perhaps one could even choose the static consists from existing activities as a choice for timetable mode or explore mode.

Additional software like skyline computing's activity generator or the stalled Open Rails activity editor would come later (or we could use the features of the current timetable editor) to generate static consists with both randomization and some intelligence to place the right sort of equipment for the right siding.

Christopher

[markyisri]

gpz, on 20 December 2015 - 06:37 AM, said:

Theoretically, an alternative selection method is also imaginable. The selection preferences might work similarly to the Excel column data filters.

1) The player might start from selecting the "Starting at" preference first, where the list of starting locations might be decorated with icons/colors/whatever based on whether there is an activity/timetable path starts from there, or just an explore route.
2) Then the "Heading to" might be selected, also from a decorated list.
3) "Starting Time" might be the 3rd (or the 2nd, preceding the heading to), also decorated.
Etc... When the user selects something from either lists, the not-anymore-relevant entries from the other lists might get greyed out with ordered to the end of the list.

The issue with that is that we would have to scan each and every activity and timetable for a path, and what about the cases where a path is shared between several?

[shadowmane]

I say do away with the .con as a legacy file and adopt something along the lines of a block file that would have the information on what the consist is and what product it holds. It would hold information on the point of origin (if any) and destination (if any) of the block. Also, make activities legacy, too, and use a modified timetable mode (or even a modified explore in activity mode) to create work orders. This would free the game up from having set activities, and work orders could be made for different routes and passed around like activities are now. If you had some kind of randomizer to set blocks of active and passive stock out on the route (active being the ones you can attach to... passive being blocks of low-poly cars for looks), then a work order to work from, it would eliminate the job of creating an activity altogether.

You simply activate the randomizer and it chooses the stock based on the industry and whether it will go on the work order or not. It then puts together blocks of cars into trains with appropriate engines on the front and runs them according to a random schedule. You would have an infinite amount of activities. What this would do would eliminate the need for an activity editor. Instead, you would be adding an Activity Manager (or call it Dispatcher Mode) to the game. Blocks of cars are chosen based on destination. Engines are pulled from a pool similar to the pool in Timetable Mode. A block of cars can be anywhere from 1 to 100 (or more) cars. If you want the old activities, you just do that in MSTS legacy mode and keep in trucking.

This is forward-looking, while also keeping the legacy MSTS stuff. If you can blur the lines between Activity Mode and Timetable Mode and expand on the Dispatcher it would begin to give Open Rails a personality that it has lacked. So far, it has acted as an MSTS immulator. It can be much more with a few tweaks.

Edit: I've thought about this some more. I think instead of doing away with the .con file, it can be tweaked and another file type added to cover blocks of cars. .con files would put those blocks together to form consists, which would enable the game (in "explore in activity mode", or the creator of a timetable) to do it on the fly without actually putting together a consist in the consist editor.