Reworked groups

This is a discussion of how to rework vehicle groups to possibly support nested groups, consists, and other new features.


The problem

Shared Orders

Assigning orders to a single vehicle is done by selecting the vehicle, and modifying its order sheet. It's been this way since 1994, and works well. Unfortunately, assigning orders to be shared by a number of vehicles is done in the same way - except by using a Ctrl-modified click on another vehicle instead of a destination. This creates shared orders, which can be modified on any vehicle which uses them. This system works, but not in the most useful way. There are a number of drawbacks:


Liveries can't be arbitrarily assigned to specific services or routes, only types of vehicle. This is a limitation which needs to be overcome.


Changing the consist of a train when its purpose is changed is useful, but not possible at the moment.

Forum threads

Potentially relevant threads at the forums:

The solutions

One solution, which is used in Simutrans and Cities in Motion, is to have a group-like interface (which might or might not be based on the current groups seen in OpenTTD) where an orders sheet is given to a group, and vehicles which are members of that group follow the group's orders sheet rather than their own. This could be extended; membership of a group could bestow a certain livery, or a consist, on a vehicle.

Some basic properties of groups

Some new problems, and their solutions

Duplication and disambiguation

A vehicle might belong to more than one group, which might in turn bestow it with more than one orders list, or livery, etc. Some solutions:

Prevent vehicles from being members of more than one group

This avoids the problem, but limits functionality drastically. Vehicles can't be member of one group for orders, and another for liveries.

Prevent vehicles from being in more than one group which bestows a given property

A nightmare to design; checks would have to be made as to whether groups gave a property to a vehicle to which a property had been given by another group, every time a group was modified, or its membership was modified. It also would produce problems for the player, who might be frustrated at having to remove vehicles or porperties from some groups to assign them to others.

use different lists of groups for different properties, and force each vehicle to be a member of no more than one of each type

This stops a player from making a single group which simply sets both orders and livery, and would be very cluttered indeed.

Hierarchical groups, of which a vehicle can belong to only one or less

Avoids ambiguity, but forces duplication of some properties, once groups become complex.

Arbitrary groups, with a single global precedence number, or a global precedence number for each property

Neatly solves the problem; a list window can be used to order groups for the purposes of orders, livery, consist, etc. If two groups define the same property to a vehicle, the one with the lowest priority number (or the lowest priority number for that property) is the winner.

Groups within groups

If groups can contain groups as well as vehicles, there must be some way of avoiding a circular reference: Groups must not be members of any of their members. The simple way is to enforce a strict hierarchy, although this brings with it its own significant drawbacks. One other solution might be a global precedence number, where a group can only belong to a group with a lower number. This would need some novel interface design.