Unique vehicle group names

[Hyronymus]

Currently vehicle group names need to be unique across trains, road vehicles, ships and airplanes. Is it possible to change this to group names needing to be unique across the vehicle category only? So you can name a ship route Den Haag Bricks and also name the train route Den Haag Bricks.

[Alberth]

Is there any use of splitting groups on vehicle types in the first place?

[Hyronymus]

Is there any use of splitting groups on vehicle types in the first place?

Is that a question for me?

[Alberth]

Sort of

Personally, I have never bothered to use groups, but it seems to me that splitting groups on vehicle types is completely artificial if you think in lines/routes. This is especially true if you use feeder systems.

Would you (as well as other users) agree or disagree on that statement?


(having said that, I also understand why it is done in this way. Groups become more complicated to implement if you generalize over all vehicle types.)

Edit: s/users/other users/

[Hyronymus]

The use of groups is very efficient in my humble opinion. It's easy to keep track of which group is doing well, especially with road vehicles.

However, it annoys me that you cannot simply name a ship and train rout (i.e.) the same. They are different vehicle categories and that difference should be definable for the game's internals by checking the vehicle category. No need for a player to make that difference known to the game.

[Owen P]

If I can throw in another argument for using groups, I find it helps when upgrading vehicles.

I quite often don't want to upgrade all of one type to another I may sometimes want to stick to older/smaller vehicles if the route doesn't warrant anything larger.

I usually end up adding "Truck" or something like that to the end of the group ID to differentiate them.

[Hyronymus]

If I can throw in another argument for using groups, I find it helps when upgrading vehicles.

I quite often don't want to upgrade all of one type to another I may sometimes want to stick to older/smaller vehicles if the route doesn't warrant anything larger.

I usually end up adding "Truck" or something like that to the end of the group ID to differentiate them.

I use rv for road vehicles, bt for ships and for planes I yet have to think of something. And your argument is a god one indeed, especially when you upgrade to faster trucks. Keeping slow ones on a route only creates queues.

I'm glad I'm not the only one using groups .

[Owen P]

I use rv for road vehicles, bt for ships and for planes I yet have to think of something. And your argument is a god one indeed, especially when you upgrade to faster trucks. Keeping slow ones on a route only creates queues.

I'm glad I'm not the only one using groups .

You could always use AC for planes.

As for rv queues I'm trying to come up with a functioning road layout that avoids that too much, but that is for a different discussion if I get it working (nothing revolutionary just lots of one-way roads). For the moment I stick to differential upgrades.

I've been using groups since I found OpenTTD a few years back; think they were available when I first found it, if not that is a measure of how useful I find them

[John_Smith]

I have no problem with this, I just put a (T) at the end of the group name for trains, (P) for planes, (S) for ships and (L) for lorries. However one problem with groups is that you can not sub group. Also you can not find the total profit of one group.
JS.

[Dwight_K._Schrute]

I have no problem with this, I just put a (T) at the end of the group name for trains, (P) for planes, (S) for ships and (L) for lorries. However one problem with groups is that you can not sub group. Also you can not find the total profit of one group.
JS.

There is a nice patch from MagicBuzz which shows the profit of each group. It's a really nice feature and I use it a lot!

[broodje]

Sort of

Personally, I have never bothered to use groups, but it seems to me that splitting groups on vehicle types is completely artificial if you think in lines/routes. This is especially true if you use feeder systems.

Would you (as well as other users) agree or disagree on that statement?

Hmm, I rather not have trucks in the same list as trains, especialy in larger games you can get a realy large amount of groups, and I don't need even longer lists to scroll trough (I use groups to monitor pofit per group and replacements by the way).
However, I would not find it strange if there was 1 'groups' button in the main menu bar (instead of the 4 now). The menu that opens could have 'tabs' with either trucks/trains/ships/planes. Or even togle buttons to enable a specific vehicle group (so you can choose if you want to see all, or only a selection).

[Hyronymus]

Me neither: keep the lists seperated.

[ChillCore]

Is there any use of splitting groups on vehicle types in the first place?

As in one gui for all vehicles types?

If you are thinking the same thing as I am, see below, then yes it could be one gui without losing overview.
Add 4 default "super groups" (not changeable) for trains, roadvehicles, ships and airplanes to my suggestion below. (my attached picture would go in the roadvehicles "super group" then)

However one problem with groups is that you can not sub group.

Nested groups would be cool and would give total freedom of how one wants to use groups.
eg.

Code: Select all

- Passengers/mail
  -IC
    - North-South
    - East-West
    - ...
  - Local
    - City A
    - City B
    - ...
- Industries
  - Raw materials
    - Iron ore
      - Feed steel mill 1 and 2
      - Feed steel mill 3 and 4
    - ...
  - Finished products
    - To collection point
      - Collect from steel mill 1 and 2
      - Collect from steel mill 3 and 4
    - To delivery point
      - ...
....
or any other method of user defined groups.

When you click a group all vehicles in the sub groups are displayed.
If you want to replace vehicles in a certain group just select the proper (sub) group or the group above to select multiple subgroups at once.


To better explain see the attachment. The groups are feeders and grouped by shared orders.
I would not mind having eg. the oil-xxx groups as sub groups of Oil.

[Wolf01]

I'm used to name the groups adding the prefix of the vehicle type: T=Train, RV=Road Vehicle and so on.
I don't need to know to which city the route belongs to, but only which cargo type is (Italian city names could be very long, and I usually have more routes in the same city), just for replacing the vehicle types easily

If group names could be duplicate, I'll be happy too, so I can drop the prefix

[Alberth]

Is there any use of splitting groups on vehicle types in the first place?

As in one gui for all vehicles types?

yes

If you are thinking the same thing as I am, see below, then yes it could be one gui without losing overview.
Add 4 default "super groups" (not changeable) for trains, roadvehicles, ships and airplanes to my suggestion below. (my attached picture would go in the roadvehicles "super group" then)

My thoughts seem to be somewhat more wild; I was thinking to have a set of grouping properties (vehicle type, main cargo, consist, orders, user-defined names, etc).
A grouping property is a way to split your vehicles in one or more groups. ('user-defined names' is what we have now, where you give each group a name, and drag vehicle into it.)

Nested groups would be cool and would give total freedom of how one wants to use groups.

We seem to think in the same direction

These properties above are used to make your nested groups (you generally only need a few properties, and you can shuffle them in any order you like).
The first property splits all vehicles into groups, the second property makes sub-groups, the third property makes sub-sub-groups, etc.

(thus, if you think vehicle type is more important than the route name, first use the vehicle type property, and then a user-defined names sub-group. If you want to see how many coal trains you have, add the 'main cargo' property to the top, and remove the user-defined names property, and the vehicles get grouped on cargo, then on vehicle type).

Like in the advanced settings, you can fold/unfold (sub)groups to keep the list limited in length.

(It sounds quite similar to what Chillcore was saying, I think. Perhaps we are trying to express the same idea. In case of overlap, credit should go to him, as he was earlier than me.)

However one problem with groups is that you can not sub group.

Currently you cannot, however this is the 'suggestions' forum, where wild ideas are encouraged

[ChillCore]

I don't need to know to which city the route belongs to, but only which cargo type is (Italian city names could be very long, and I usually have more routes in the same city), just for replacing the vehicle types easily

I added the town names for my roadvehicles as those run localy. For my trains I did not do that because often they cover the whole map. eg. For IC train connections I use IC-north-south etc.
Making it possible to have longer names for town is just changing one value in the code.
eg.In my patched game I have 250 pixels for vehicle names by changing this line in vehicle_type.h.

Code: Select all

-static const uint MAX_LENGTH_VEHICLE_NAME_PIXELS = 150; ///< The maximum length of a vehicle name in pixels
+static const uint MAX_LENGTH_VEHICLE_NAME_PIXELS = 250; ///< The maximum length of a vehicle name in pixels

I doubt that would work for multiplayer games though without changing trunk or all clients having the same tweak as well as the server.
Credits to SpComb -> CargoDist with sprinkles thread.

Just in case you feel like making some tweaks yourself, see changelog for r21797 for locations of maximum size of other strings.

If you are thinking the same thing as I am, see below, then yes it could be one gui without losing overview.
Add 4 default "super groups" (not changeable) for trains, roadvehicles, ships and airplanes to my suggestion below. (my attached picture would go in the roadvehicles "super group" then)

My thoughts seem to be somewhat more wild; I was thinking to have a set of grouping properties (vehicle type, main cargo, consist, orders, user-defined names, etc).
A grouping property is a way to split your vehicles in one or more groups. ('user-defined names' is what we have now, where you give each group a name, and drag vehicle into it.)

Wild seems good, but to make it a bit more wild ... could we drag user-defined groups into user-defined groups, making subgroups on the fly so to speak, for adjusting existing games, once subgroups would be possible.

Nested groups would be cool and would give total freedom of how one wants to use groups.

We seem to think in the same direction

These properties above are used to make your nested groups (you generally only need a few properties, and you can shuffle them in any order you like).
The first property splits all vehicles into groups, the second property makes sub-groups, the third property makes sub-sub-groups, etc.

(thus, if you think vehicle type is more important than the route name, first use the vehicle type property, and then a user-defined names sub-group. If you want to see how many coal trains you have, add the 'main cargo' property to the top, and remove the user-defined names property, and the vehicles get grouped on cargo, then on vehicle type).

Like in the advanced settings, you can fold/unfold (sub)groups to keep the list limited in length.

I also had the Advanced settings in mind when composing my suggestion in a visual representation.
However what your are suggestion seems more advanced and better.

(It sounds quite similar to what Chillcore was saying, I think. Perhaps we are trying to express the same idea. In case of overlap, credit should go to him, as he was earlier than me.)

Yes somewhat the same.
As far as credits go ... I think I saw you make this suggestion earlier in a different thread, maybe not with so many words but you sparked the idea IIRC.

Make it so number A. /me likes

ps:
I would not mind helping you with this, oh mighty one, but I think I would only be holding you back.
I will test however and I'd be happy to include it in my bugpack (while updating as needed) before adding it to trunk if you see the need for testing before committing.

[Alberth]

However what your are suggestion seems more advanced and better.

My thoughts evolve each time I try to explain them.
Also, I had a few bright insights while pondering groups, and I spend a few days on building a(n empty) gui, and some background data.

I would not mind helping you with this, oh mighty one, but I think I would only be holding you back.

Knock yourself out: http://devs.openttd.org/~alberth/diffs/groups
I have two attempts (both are just experiments, code contains lots of missing cases, weird comment lines to mark where I am hacking, etc). The first one has nicely draggable group properties (group splitters I called them). I mentioned a revision number, but I don't think it is critical. Build it, and activate it with the 'train vehicle list' button. It was mostly seeing how drag/drop would work here.

That interface is broken in two ways.
1. All properties are always used for the (at the right, non-existing) tree
2. All properties are instantiated at start up.
(whether 2 is a real problem remains to be seen, 1 seems like a real problem.)

So I started the second attempt. (again, revision number is non-critical.) This is just starting (but I ran out of day so it never got as far as the first attempt.)
At the bottom left, you have (non-working) buttons to create new group properties. You could eg popup query windows or so for getting extra information.
The top-left should be like attempt 1, except that there should be two groups of properties, with some empty space between them.
The top-part is for grouping of the vehicle tree, the bottom part are properties that are still actively maintained and/or stored (eg when replacing a train, it might switch groups for some properties), but are not used to split vehicles in the tree.
The second attempt is mostly non-functional.

While it looks nice as screen shot (except the window colour is too grey), it is really all empty. Not just the gui, but there is also mostly nothing behind the screens. For some properties, you can simply look at the vehicle to decide in which group it belongs (eg vehicle type). For other properties, some computing is needed, and that value should be cached in the vehicle, I think (I added 'Vehicle::group_values' somewhere, although that variable does not exist currently.)

As for the tree, I have no ideas about that part yet. I would already be very happy to just have a display, ie without being able to do anything with the groups. That is already a lot of work.



As for keeping me back, there seems to be plenty of work here (I am currently doing other stuff also needed for this, namely adding a new data structure for storing 'per train' data per train, rather than in the primary vehicle.)

As a result, my group code as explained above is not moving at all, at this time (both gui and non-gui). Any movement you can create is good

I will test however and I'd be happy to include it in my bugpack (while updating as needed) before adding it to trunk if you see the need for testing before committing.

I thought trunk was for that

Albert

[supermop]

I know changes to the groups concept have been talked about for awhile now, and I do think some kind of nested list/subgroup system has its benefits, however, it might be useful to have a label system, like gmail for example. At first I lamented gmail's lack of real folders, and when i did use labels, I just used them like I would a folder, but there are a few ways in which labels can be more useful:

If we have a nested list with folders A, B, C, and N arranged as below,

Code: Select all

A
-B
--C
N

Any train in C must also be in A and B, which may or may not be desired, while at the same time it cannot be in N or any of N's subgroups, whereas with labels, one can assign one or more unrelated groups to a train with or without also assigning their parent groups.

Best,

[andythenorth]

whereas with labels, one can assign one or more unrelated groups to a train with or without also assigning their parent groups.

This is the 'arbitrary groups' concept. It has many advantages in my view.

[Alberth]

Not sure how my idea fits in there.
To explain, a small example.

Suppose we have 4 trains, A, B, C, and D. The user grouped A B C together (let's call this group ABCgroup), and made another group with D (named Dgroup). A and B are coal trains, C and D are passenger trains.
(Note how each property ('main cargo', and 'user-defined groups') defines separately which vehicles belong together in one group (with respect to that property). That is good, as it allows deciding the group of a vehicle separately for each property, without needing to think about the other properties.)

If you sort on user group first and main cargo second, you'd get

Code: Select all

- ABCgroup
  - Coal
    A
    B
  - Passengers
    D
- Dgroup
  - Coal   <-- do we want to show this at all?
  - Passengers
    D

If you sort on main cargo first, you'd get

Code: Select all

- Coal
  - ABCgroup
    A
    B
  - Dgroup
- Passengers
  - ABCgroup
    C
  - Dgroup
    D

This looks like what supermop calls 'nested lists' I think, but the order of the properties to group on is not fixed.

How would this compare with 'arbitrary groups'? I don't really see how those would work.