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:

• When a new vehicle is created, in order to get its orders sheet shared with others requires finding another vehicle which already uses those orders. this is not easy:
  • There's no list of shared orders sheets.
  • There's no outwardly obvious way to tell whether a vehicle's using a shared orders sheet.
  • Even if a vehicle is using a shared orders sheet, there's no way to tell if it's the right one straight away, especially with the method of copying a sheet being so close to the method for sharing a sheet.
  • There are ways to try to find a suitable train quickly (station lists, groups, etc) but none of these are guaranteed to find the train you want, first time.
• When the last train using an orders sheet is destroyed (or sold), the shared orders list evaporates. Doesn't matter how complex it was; it's gone.
• When upgrading a route from railroad to monorail, it's easy to convert the tracks, but the trains have to be sold and then new trains have to be built manually to match the previous configuration and orders.
• You can't plan a route for a vehicle before the vehicle exists. This might seem counter-intuitive, but creating an orders sheet station by station as the stations are constructed, and then assigning trains to that orders sheet, is something that players might find very useful.

Liveries

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

Consists

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:

• Shared train patterns
• Advanced vehicle replace for trains
• Replacing whole trains Train template library
• Autoreplace Wagon Removal suggestion
• Unique vehicle group names What people like with respect to group names and other group properties.

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

• Groups would be able to contain zero or more vehicles. An empty group would not vanish; the player would have to delete the group.
• Groups would be selectable from a global list, and would each have a control where certain properties, normally associated with vehicles, could be edited.
  • Liveries could be changed.
  • Orders sheet could be edited.
  • The consist (of trains) could be edited; changes would not apply to the train directly, but would take place a the next visit to a depot (funds permitting).
  • The servicing interval could be defined.
  • Other properties could be defined.

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.