Routes, Profiles, or even the latter idea of Includes for Conductor 2 are all vaguely unsatisfactory.

Includes are just a hack in the current v1 script language which do not really solve anything.

The core issue is modularization of the script.

One concept I explored earlier in the 2018-12-08 post and that I still want are routes.

A route is a sequence of blocks and a reservation principle. They have different modes, e.g. global interlocking vs ABS window interlocking. I think this concept is good and should be kept as-is.

One difference with the original idea: in the earlier idea, routes worked with profiles. A profile is a train engine number + a number of parameters, and a route is an unconfigured program, which variables are provided by the profile. The idea was to reuse the same route programming with different trains/engines by simply swapping the profile affected to the route.

Although that’s nice in theory, I don’t see this applying properly to the automation at Randall. Not a single time was I able to update the automation by simply changing an engine number and not changing anything. Eventually I’d hoped to get there, but this hasn’t happened yet. A potential example is the main UP automation. We have 2 exact same engines so ideally we could swap them.

Another part of the idea was to expose only profiles (and not routes) to the UI on the tablet and give operators the ability to trivially change trains in the automation. Unfortunately I don’t have any such staff -- current staff would not have the proficiency to either be trusted to set up the train correctly or change the tablet settings or both.

I think there is some value to the profile idea but it may be more of a generic value, and should not be mandatory. Thus the proposition is to put aside the profile idea for now. It can always be re-introduced later if needed as an orthogonal feature. Note that such profiles can be simulated by having a function create duplicates of the same route for different engine numbers.

So now in the case of Randall, that gives me 3 routes: One Branchline (BL), and two Mainline (Passenger + Freight). The latter needs to alternate.

So now, let’s go back to includes. The idea behind includes is to modularize the ANTLR script. For example, right now when I want to change the branchline, I duplicate the whole script including the mainline, and get a new copy of everything. If I want to revert back to a previous branchline, I need to carefully diff two versions of the script to keep the last version of the mainline yet use the older version of the branchline. The current way works nicely as long as I only modify forward. Includes would make that easier by being able to swap e.g. bl-01 instead of bl-02 into a common “master” script.

On top of that, includes can be used to solve the “profile” idea on the mainline by e.g. being able to include freight-02 instead of freight-01 and not touch the passenger parts. Careful consideration is needed as these would be straight macro-level includes so order and global definitions matter.

The idea of having profiles in a DSL does not preclude the need for includes. The same kind of logistical issue arises: how do I want the end script to look like? As a monolithic block with all the “profiles / routes” options, or as a set of multi-file definitions? Right now the monolithic script does not offer any alternative per route. The goal would be to have at least one backup engine defined in the script and exchange them regularly. So that means having 6 profiles/routes definitions in the script. It may get large and tedious.

That being said, I’m deciding to ignore the issue upfront. If I want to add support for includes, I’m sure I can add it later. And maybe there’s a different solution for example using an import / module mechanism.

The other part of the include / route / profile setup was to have selection made on the tablet by “regular” layout operators. Right now I’m postponing this idea as it does not seem realistic. I simply have no operators with enough proficiency to be trusted to both setup the trains and set up the tablet. I have some who claim to have that proficiency yet have regularly demonstrated they clearly lack it -- for example how hard is it to remember to put 2 trains back on the proper track, and identify when the automation does not start because they didn’t put the right train on the right track. More than once. So no, not happening for now.

That means I’m going to:

• Ignore includes for now.
• Ignore profiles for now.
• I will however define and implement routes as they are useful.

---