When playing a large game, I often have many vehicles ply the same route (using the "shared orders" feature, multiple vehicles can have the same route), and it is more important to know where each route goes, instead of where each vehicle goes. This is especially so when playing with cargodist, because large hub stations often have >100 vehicles and >10 routes. Hence, a user interface that focuses on routes instead of individual vehicles would place focus on the information that is important to me.

Part 1: In the window that shows the list of vehicles (i.e. "Runnbury - 4 Road Vehicles"), there should be a way to group the vehicles by shared orders (using a drop-down), so that there are only two items in the list (each item represents a route). Clicking on an item will open the corresponding shared orders vehicle list (i.e. "Shared orders of 2 Vehicles"). Furthermore OpenTTD should remember the drop-down option, just like the "Group By: Via-Destination-Source" option in the station window. So it would look something like this (pardon the font and alignment issues because this is an MS Paint job):

Part 2: When the list of vehicles is set to group by shared orders (but maybe also when in the ungrouped view), there should be a button that will display the route visually on the main map (in the same style as the cargodist linkgraph, but only that particular route is displayed). (Probably the button should be the kind that will stay down when clicked, and will only go up again when another button is pressed down. Something like a checkbox that is styled like a button.)

________________

While writing this post, I realised I asked about part 1 on this forum 7 years ago (viewtopic.php?f=32&t=62361), but with a focus on named vehicle groups. However, the current suggestion is focused on (shared) orders, which are characterised solely by whether vehicles are using the "shared orders" feature. When using (shared) orders (instead of vehicle groups), part 2 makes more sense (like a single train route on a metro map).

I've also read this post (viewtopic.php?f=33&t=11431). It's over ten years old, so I didn't attempt to compile their patches. But from the discussion, it looks like they're responsible for the window that says "Shared orders of 2 Vehicles", and the vehicle grouping system. It isn't a replacement for what I am proposing.

________________

How much community interest is there in such a feature? Is there something like this already being worked on? If there is community interest and the OpenTTD maintainers think this feature is useful, I can try to implement this feature (no deadlines or guarantees though).

Both would be nice to have, although part 1 is already somewhat achievable with the current vehicle-group system, but maybe you can expand on that a bit. Part 2 would be really nice to have, especially on bigger maps with longer routes to see how they cross the map.

The concept of "routes" is probably the one I miss most when I switch between OTTD and Transport Fever. Because you are absolutely right; ultimately that's what's important, not so much individual vehicles, especially when playing with CargoDist.

Now personally, being TF-biased, I'd prefer an implementation from the ground up where you basically create a route as a separate entity and then add vehicles to it instead of that shared order business.

But I'll assume that's beyond the scope of things here So I'll make do with UI improvements

Now personally, being TF-biased, I'd prefer an implementation from the ground up where you basically create a route as a separate entity and then add vehicles to it instead of that shared order business.

Yes, I agree that routes would be nice. But in my opinion, shared orders are easier to manage because you don't need to rename them, and there's much less clicking to do (as compared to setting up an explicit route before adding vehicles to it). So it makes feeder services (with maybe 2 to 4 stops) easier to set up.

I don't have a copy of Transport Fever to play with, but from what you describe, it seems like routes are simply "named shared orders" that do not disappear when there are zero vehicles on the route. (Is my assumption correct?) Perhaps to reconcile shared orders and "routes as a separate entity", we could have "named routes" (like TF) and "unnamed routes" (which is the existing shared order system), and these two kinds of routes only differ by whether they have a name and whether they disappear automatically when you delete the last vehicle. The implementation of shared orders would probably have to be changed somewhat significantly (I don't know for sure), but it should be orthogonal to the UI grouping feature that I'm proposing as part 1 (because named routes and unnamed routes should act the same to my UI). It seems like there's recent discussion about routes here (viewtopic.php?f=32&t=11587), but I'm not sure how the progress is over there. Anyway, named routes would be for another time / another person.

Quote:

Both would be nice to have, although part 1 is already somewhat achievable with the current vehicle-group system, but maybe you can expand on that a bit.

We can view the global list of groups currently, but I don't think there is any way to view it for a particular station? (Correct me if I'm wrong.)

But I think the main difference is that you can have vehicles with different orders inside the same group, and the possibility of having different orders inside the same group makes it a bit difficult to display things that only make sense for shared orders (e.g. editing orders, viewing the route visually on the main map (i.e. part 2)). One of my primary reasons for proposing part 1 is so that part 2 can be accessed directly from the station vehicle list window, making it very easy to visualize which routes stop at a particular station by toggling the button beside each route.

(Just thinking out loud: Perhaps, if someone actually implements routes, then vehicle groups should be made non mutually exclusive (i.e. a vehicle can be from multiple groups), together with the "virtual groups" concept suggested in some other thread...)

On a side note, all the discussions about (named) routes in this forum seem to be very very old. Could anyone please fill me in about the current status of (named) routes?

there's more to TF-routes than that, because they also double up as the "linkgraph", which is handled separately by OpenTTD, and passengers/cargo pick a route to board rather than taking the next vehicle that would get them to their next hop

there are a few things that might be easier with routes as a user interface, like handling vehicle separation. but having to make a route might make it more difficult when you want to have only one vehicle on it anyway.

_________________You might not exactly be interested in Ferion, but if you are, have fun

there's more to TF-routes than that, because they also double up as the "linkgraph", which is handled separately by OpenTTD, and passengers/cargo pick a route to board rather than taking the next vehicle that would get them to their next hop

I think I understand the part about passengers/cargo picking a route to board rather than taking the next vehicle that would get them to their next hop - this would be mitigate long loading times due to passengers/cargo transferring excessively.

But could you elaborate on what you mean by 'because they also double up as the "linkgraph"'? To me, the OpenTTD linkgraph refers to the visual overlay over the main viewport that is enabled using the "Cargo Flow Legend" menu item. This is a purely UI-only feature, so I'm not sure what you mean when you say that TF-routes double up as the linkgraph.

Well ... hopefully I'm not talking complete rubbish now since I usually only pay attention to aesthetics.

But in OTTD, you just connect stations, right? Let's say station A is a combined airplane, bus, train station, and station B the same. Then you connect them with all vehicles. It's just one "link" for all of those. Doesn't really care much about anything beyond that.

In TF, in the same situation, you'd have three different links, one for each mode of transport. This matter since TF passengers at least care about whether they want to travel cheap or fast or ...

There's also the nuance that routes in TF are fixed. A bus will always drive exactly its route (unless the map changes obviously). In OTTD, routes are just about the destination. That's more flexible, particularly with trains. But it also means that if you want them to go a specific route you have to jump through a few extra hoops. On the other hand, if you do want your vehicles on the same route separated into different lanes (or whatever) you can't easily do that in TF; you'd have to have an extra route (and that's usually not a great idea).

But anyway as you say this seems all pretty much beyond what you are trying to do here

But in OTTD, you just connect stations, right? Let's say station A is a combined airplane, bus, train station, and station B the same. Then you connect them with all vehicles. It's just one "link" for all of those. Doesn't really care much about anything beyond that.

Ah, that makes so much more sense! I've never thought about that because in my OpenTTD games I never purposely create such a situation

Mind, that the linkgraph is the visual front-end of the cargodistribution feature. That is disabled by default (iirc?) - and with it disabled, cargo just goes wherever you send it and it is accepted. With it enabled... cargo transfers itself when it can reach its planned destination.

Mind, that the linkgraph is the visual front-end of the cargodistribution feature.

Yeah, that was what I thought.

To me:Cargodist = the feature that consists of the complicated algorithm that gives cargo their own destinations and makes cargo transfer itself to get thereLinkgraph = the visual overlay on the main viewport (which can be enabled/disabled regardless of whether cargodist is enabled); so this is a UI-only feature

Linkgraph = the visual overlay on the main viewport (which can be enabled/disabled regardless of whether cargodist is enabled); so this is a UI-only feature

Does this seem correct?

Apparently it depends on who you talk to.

The Cargodist algorithm builds a graph (ie the mathematical thing https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) ) of linked stations (ie a link graph), so it can compute where cargo from a given station can flow to (and in how many hops etc), and how busy each link is. As such, link graph is a part of the cargodist algorithm.This graph information is also displayed in a view port for the user, ie the visual overlay you talk about. Confusingly, that is also called linkgraph, although on the other hand, it's all the same data, so it's understandable as well.

To make clear what you talk about, I'd avoid the name "link graph" on its own, and use "visual link graph" or "visual link display" (or anything else) if you talk about the thing on the screen, and "link graph data structure" or so if you talk about the link graph in the algorithm (ie the graph storing all link information between stations).

_________________Being a OpenTTD developer does not mean I know what I am doing.Also, other OpenTTD developers may have different opinions.

To make clear what you talk about, I'd avoid the name "link graph" on its own, and use "visual link graph" or "visual link display" (or anything else) if you talk about the thing on the screen, and "link graph data structure" or so if you talk about the link graph in the algorithm (ie the graph storing all link information between stations).

Quote:

In en-gb translation, the visual representation of the link graph is called 'cargo flow legend' when it's an overlay of the main map, and the mini-map view is called 'cargo flow'.

Thanks for clarifying

To remove any ambiguity: Every mention of "linkgraph" in my original post is supposed to mean the cargo flow legend - the UI-only feature - and nothing else.

This is my first attempt at OpenTTD development, so apologies if I'm doing horribly wrong things there

It is a rough implementation, and these are issues that I'm aware of:1) The window caption shows the number of list items, instead of the number of vehicles.2) The "Shared orders of X vehicles" window still has the dropdown menu to group by shared orders (which is kinda pointless).3) Can't do vehicle operations (e.g. clone vehicle, clone orders) when the list is grouped by shared orders.

Issue 1 and 2 should be relatively straightforward to implement. But issue 3 needs some design decisions (e.g. what does it mean to clone a vehicle, since vehicles of different model can share the same orders), so maybe I'll leave that to sometime later. It would be nice to be able to Ctrl+Click to clone vehicle directly from a list that is grouped by shared orders if the vehicles are all of the same model though.

Also, only a maximum of three vehicles are drawn per list item. This is because GUIList doesn't respect constructors/destructors, so there would be memory leaks if each object in the GUIList allocates memory dynamically. I'm not sure what is the best way to work around this. GUIList extends from SmallVector and I could make SmallVector call constructors/destructors properly, but since SmallVector is used by lots of other stuff, I might accidentally change the behaviour of those other stuff Can anyone give me pointers if there is a "standard" way to solve this problem in OpenTTD?

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum