Vehicle Orders UI overhaul

[Simons Mith]

As per this thread (item 5.1) http://www.tt-forums.net/viewtopic.php?f=32&t=69835
the vehicle orders UI needs attention. It's powerful but actually getting quite scary.
Caveat: Sorry, but I'm not a competent coder. [Although I am an incompetent
coder. Dunno if that's better than not being a coder at all...] But I do do UI stuff
professionally from time to time.

See also http://www.tt-forums.net/viewtopic.php?f=33&t=54549 but the approach
there is patches rather than anything more radical. I think it's time to get more radical.

If not beaten to it, I'll do a mockup later, but my first thoughts are these:

The orders UI has a number of weaknesses. One is that it mixes different parts of
orders into a single 'stream of consciousness'. What's there, in what order, has
just grown organically over time. Some useful features are hidden. Some defaults
maybe only suit a minority. The UI for conditional jumps is useful but a bit
unforgiving. Clicking on a depot order gives a warning that you can't alter it, even
if all you actually want to do is move it. And finally, sharing identical orders is OK,
but there is no concept of an 'order template'. Imagine if you could set up a generic
order that said

Go to [ specify depot ].
Refit to [ specify cargo ]
Go to station [ A ]
Load 100%
Go to station [ B ]
Unload 100%

Then you could just fill in A, B, depot and cargo into your template. If templates
could be saved and shared, that would be a massive speedup.

Destinations

The first thing to do is to clean up the order system into sections. The first
conceptual section is destinations. Taking a typical order,

Go non-stop to Tillynor Powerplant (no loading) [far end].

The destination-related parts are Tillynor Powerplant, non-stop, and far end,
in that order of priority.

So our new UI might start with a destination column, with checkboxes for non-stop
and end, and maybe even with a future hook for platform numbers, thus:

Code: Select all

Order  Destination             Stopping  Platform  End
1.     Senshaw Train Depot     Non-stop  ---       ---   
2.     Senshaw Tanner Road     Via       1         near
3.     Tillynor Powerplant     Stopping  2-3       far
4.     --- 
5.     Tillynor Train Depot    Non-stop  ---       ---
6.     ---
7.     Senshaw Train Depot     Non-stop  ---       ---

Stations where the train stops are in bold. Implicit orders are in grey,
presumably. After all, when you are checking your train's destinations,
in general that's all you care about.

Refit options
Second concept, probably quite important now we have auto-refits for some cargo
types, is to make sure the refit UI is better. Giving it its own conceptual section
could help enormously.

Loading options
At present, loading and unloading are mixed together in an unholy melange.
In general vehicles either have complex loading options or complex
unloading options, but for both to be complex is rarer. But when you're debugging
a vehicle's orders, you generally want to look at one function at a time. i.e. just the
destinations, just the refits, just the loading orders, etc. So splitting orders
along these conceptual lines might be a big help.

I'd particular like to mention the option of changing 'full load' and 'load if available'
to 'load minimum' and 'load maximum'.

Load: min 100%, max 100% is equivalent to a 'Full load' order.
Load: min 0%, max 100% is equivalent to a 'Load if available' order.
Load: min 0%, max 0% is equivalent to 'No loading'

To handle multi-cargo trains, these would need to be selectable per cargo. Hence
a button that set selected ones to 100% ('Full load all' = everything to 100%) would
be useful. ('Full load any' would mean 'at least one cargo to 100%', so the code to
implement all the current functionality isn't completely trivial.)

But this way we could also gain the facility to tell a single train to leave when it's
50%+ full rather than waiting interminably for a full 100% load. Greater flexibility
and greater clarity at the same time. I would also suggest being able to specify
loading by units rather than as a percentage.

Obviously, refitting and loading are closely related.

Unloading options
Similarly for unloading. This might allow you to set up one train to deliver 10t
of the same cargo to a string of small stations, rather than the first one grabbing
the lot.

For loading, it's refits that complicate things. For unloading, we have transfer orders.

Conditional orders
I would suggest, rather than having the 'Jump to order' text string, which I for one
find quite hard to follow, might it be possible to represent the flow graphically, using
lines with arrows on? Big win if so, probably. Then the logic flow is arrows, and the
conditional orders section can just become a list of conditions. That would be better
than now, I think.

Timetabling
Timetabling is complex enough to have been relegated to its own screen. But if the
other order options get streamlined, I think it might be possible to integrate it
better with them, at last.

Order sharing
A possible new section. Better controls over order sharing/order templates would
logically fit here - if the game had them.


Overall

Overall I'm starting to envision a single window where the Destination station/depot
remains visible at all times, along with expandable buttons for extra Destination options,
Refit options, Loading, Unloading, Conditions, Timetable and Sharing, and so on, and you
can turn some of these on or off at the same time, and the window shrinks or expands
to suit. Possibly some should stay segregated in their own panes, the way Timetables
are now, I don't know yet.

I expect to come back to further edit this later, but these are my first-pass thoughts.

[YNM]

Regarding order template, I think it's fairly simple that players just need to make sure that every vehicles that would have the exact same orders must have shared orders, then player just need to fill in the orders once. Fairly not useful for me (as I have a load of intermediary stops or intermediary waypoints which might have different amount in each group of vehicles, unless that could be automatized too). Regarding that, could different vehicle types shares the same order, as long as their respective stations/stops is available ? ex. bus and truck, train and bus / truck, planes with trains, etc. (I have this setup on my metros, where passenger goes on trains, mail goes on trucks)

That new schedule (or orders) display is quite... too long. Simply don't write them if they're not used, right ? (kinda like the "detailed" option when you see folders/files in your computer)

Minimum & maximum loading / unloading factually just come across my mind... could it be actually done, with a still simple interface ?

[Eddi]

shared orders

this is about the display of the orders, not about the inner workings. all this stuff should be adressed in a separate patch

That new schedule (or orders) display is quite... too long. Simply don't write them if they're not used, right ? (kinda like the "detailed" option when you see folders/files in your computer)

what do you mean? i always use the 'detailed' view of folders.

[3298]

But when you're debugging
a vehicle's orders, you generally want to look at one function at a time. i.e. just the
destinations, just the refits, just the loading orders, etc. So splitting orders
along these conceptual lines might be a big help.

And when creating orders, splitting the window into parts where only one is shown is not helpful at all.
The way you described it, I'd have to assign the orders in multiple passes: first all destinations, then all load options, then all unload options, then maybe a couple of depot refits, and finally find the depot order where the vehicle shall be serviced. Okay, the current order window is not much better, but the Ctrl+Click feature when selecting the destination already helps a lot.
The patches in the development forum topic you linked focus on accelerating the order creation, your approach seems to slow it down. ("Was this the order that should get the unload or is it still one of the loading orders? *Click* *Click* Okay, I set a load option in the previous pass." In the current order window, the load option is visible, so I'd just scroll past the load orders without having to switch to a different view just to check for the existence of the load option.)

If all order option parts could be shown at the same time, I'd just turn them all on once (like I always do with the file browser's detailed view when I start it for the first time after reinstalling my OS) and moan about the increased size of the order window - a bunch of new useless buttons to hide information I want to see all the time. When you drop these buttons, you'll end up with adf88's mockup I already pointed you to in the annoyance collection thread - maybe still with texts, though. I'd even go as far as integrating the timetable, so the window becomes an omnipotent order management window.

For templates, there is this patch: http://www.tt-forums.net/viewtopic.php?f=33&t=63721
Apparently it also merges the order and timetable windows, but the long strings you complained about are still present.

[Simons Mith]

Hah, at this stage I'm not even thinking about the in-game implementation. The first steps are to identify what information is available, what's needed, when it's needed, and which bits of info logically group together.

I also want to identify what info is currently presented in a needlessly verbose or unclear way. To me, 'Min' and 'Max' loading already looks like a probable win over 'Full load all', 'full load any', 'no loading' and 'load if available'.

My next stage is to do a wireframe or two, and we're not even ready for that yet. I certainly have no plans for in-game mockups any time soon, because then the existing game window furniture just becomes a distraction.

Longer term, I admit I do vaguely envision a wide window with 10? 20? columns, some of which are always on and some of which can be turned off, but making that concrete is a long way off.

[YNM]

It's different to say "maximum load" and "maximum weight", through. "Full load all" is intended to makes all cargo types in the vehicle to load until full, while "full load any" means that if your vehicle carry two cargo types (ie. grain and livestock), once only the grain / livestock is full, it's considered as "full load" and the vehicle leaves.

[adf88]

I like the idea of splitting destinations from tasks. It can make the window more readable and easier editable. It gives also new possibilities like multiple actions (e.g. dual refit) or more detailed actions (e.g. load percentage).

The window could look like this:

orders_mockup_unfolded.png (70.13 KiB) Viewed 5047 times

orders_mockup_folded.png (33.59 KiB) Viewed 5047 times

Description:
[NS] - "non-stop" switch (icon), turn on/off when clicked
near end/far end/middle - stop location, switch when clicked
[L][O][R] - buttons (icons) for adding actions:
- unload (set "transfer" if CTRL-clicked)
- load (set "full load" if CTRL-clicked)
- service
- stop
- refit
always/if accepted/(transfer) - unload options, switch when clicked
at least/at most - load options, switch when clicked
any cargo/all cargo/[certain cargo] – which cargo to (un)load or refit to, pick when clicked (additional pop-up window)
--|---- - graphical, interactive trackbar
[GT][DT][ND][CO][SO] - buttons (icons) for adding destinations:
- go to (unload if accepted, load if available) | go load (unload if accepted, full load any)
- (NEW) deliver to (unload all, no loading) | transfer to (transfer all, no loading)
- go to nearest depot
- conditional order
- share orders
[#] - show vehicles sharing the orders
[X][-][|][/] - window buttons (close, fold, pin, resize)

Implicit rules:
- "no loading" if there are no "load" actions at a station (e.g. #6)
- "no unloading" if there are no "unload" actions at a station (e.g. #1)
- "go via" if the action list of a station is empty (e.g. #5)

[Simons Mith]

I like the idea of 'deliver to'/'transfer to'. That's a good conceptual split that I think might be modifier friendly.

At this stage I'm also wondering how some of what's currently text in the order string could be made into icons and/or buttons.

For example - near end, middle, far end - I very rarely change these. They're also a bit out of the way, being bolted on to the end ot the order string. As a graphical representation of the same thing, I want to raise the idea of an underlay behind the station name. One end of a station name is highlighted or bolded or the background colour behind it is changed or becomes a train graphic or something, depending on where the train will stop. I've used colours here, but there are many other compact ways this could be highlighted.

Similarly Go non-stop, Go via; I almost always use non-stop. So a speedy train icon for non-stop, a faded one, perhaps, for go via, and a slow train icon for a stopping service saves a few more words. In the mockup I've used --->, -> and --->, -> for these four combinations. Again, it's something you don't often change, so a graphical icon to indicate the current setting plus a button is I think the way to go. (BTW I'm also big on making sure that all settings are always displayed, rather than having hidden 'implicit' settings which are easy to overlook. So stopping services, which currently don't get an icon, now do, so that they're not the odd one out. This means when you scan down an order list by eye, discontinuities stand out, making debugging orders just a tiny bit easier.)

In the sample below note how the entire station column is used as an 'end' indicator, regardless of the length of the station name. Having done this, the rarely-used 'end' function could become a button which steps from Near-Middle-Far as you click it. And the rest of the time it's out of the way, and orders are all slightly shorter. For completeness I've also had a guess at how platform destination management might be done - probably with its own column.

Destination                                                               Platform
--->  Ardinsgworth Stationwithaverylongname South__ 1-3, 7       ('non-stop' and 'middle')
--->  Shortby_________________________________  any           ('non-stop via' and 'far end')
--->  Ardinsgworth Waypoint_____________________                 ('non-stop', 'end' not applicable)
->    Geaby Great Cross_________________________ 2              ('stopping' and 'near end')
->     Geaby Mediocre Cross______________________ even         ('stopping via', and 'near end')
->     Geaby Cross Depot________________________                 ('stopping via', 'end' not applicable)

[Eddi]

that is some truely horrible suggestion...

[Simons Mith]

For loading and unloading, compactness is a high priority.
If we did start specifiying individual cargo types, you could have a long train with one truck of everything on board. So this is clearly an area that could demand a lot of coding effort to cope with some edge cases that will only be used by players trying to be creatively awkward.

We also need to cope compactly with 'full load any', which is a case requiring slightly special coding, and well as some of the other rare loading combinations, such as 'no unloading and take cargo'. The hope, obviously, is to have all the functionality we have now with a simplified UI, and if we can get more flexibility reasonably painlessly then, I'm in favour of it. The bit below just enumerates what options the system currently provides, for a vehicle with three different cargos. Another approach I'm still pondering, rather than min and max, is whether + and - ranges could be more compact.

Code: Select all

Loading

    Min     Max    Cargo
-------------------------
      0     100     Goods   \
      0     100     Goodies  |-Load if available
      0     100     Stuff   /

    100     100     Goods   \
    100     100     Goodies  |-Full load all
    100     100     Stuff   /

                  / Goods   \
    100     100 -|  Goodies  |- Full load any - Note 1
                  \ Stuff   /

current current     Goods   \
current current     Goodies  |- No loading
current current     Stuff   /


Unloading

    Min     Max    Cargo
-------------------------
      0     100     Goods   \
      0     100     Goodies  |-Unload if accepted - Note 2
      0     100     Stuff   /

    100     100     Goods   \
    100     100     Goodies  |-Unload all
    100     100     Stuff   /

    100     100       Goods   \
    100     100       Goodies  |- Transfer - Note 3, interesting!
    100     100       Stuff   /

current current     Goods   \
current current     Goodies  |- No unloading
current current     Stuff   /

Note 1: 'Full load any' is implemented by having a single shared threshold for all cargos; as soon as any one of the crosses the threshold the train is free to leave.

Note 2: For 'Unload if accepted' - see how by reducing the Max value you could 'ration' an accepting industry.

Note 3: Oho, there's no practical difference between 'Unload all' and 'Transfer' except that in a transfer the vehicle gets a partial credit for the delivery. So that's actually a financial twist that has sneaked into the cargo system. I hadn't fully appreciated that! This has exposed another potential part of the UI; at present, transfer credit is a configured setting, and this necessarily requires a global compromise across one's entire transport empire. In the unloading screen it is revealed as a parameter. So we could have 'Transfer credit X%' as part of an unload order, and set more appropriate values than the global default, if we needed to. That would never have occured to me without putting the order system under close scrutiny.

[Simons Mith]

@Eddi I haven't even made any proper suggestions yet. I'm still dissecting the current system.
@YNM I know, and I mentoined that minor wrinkle in an earlier post.

[Eddi]

@Eddi I haven't even made any proper suggestions yet. I'm still dissecting the current system.

i meant the part about highlighting a part of the station name to indicate where to stop...

[Simons Mith]

More thoughts:

There are three types of vehicle destination: Depots, Waypoints and Stations.
At a depot you can refit, service or stop. Or, theoretically, combinations of those. A possible future hook might be for 'split' and 'join', and 'go empty to depot', 'service empty at depot', and 'go empty to depot and stop' might be a useful additional order options.
At a waypoint, you can't do anything I can think of.
At a station, you can load, unload, refit or transfer. Again, most combinations of these are currently permissible. And in future you might be able to 'split' and 'join' at stations too.

At a decision point, which occur 'between stations', your train logic jumps to some other order, depending on a condition. Conditions contain three components - if <load percentage> is <less than> <50>. Another possible future hook could be to use decision points for comments or blank lines.

If a vehicle's orders tell it to go to its current station, it shouldn't leave the current station in order to come back to it.

That, with what I've already suggested, possibly implies an order structure like this
Column 1
Decision arrow tree

Column 2
Destination (includes destination modifiers such as non-stop, go via, speed (currently on the timetable tab), platform and end.)

Column 3
Action(s), dynamically determined by whether destination is a station, a depot a waypoint or a decision point.

I've been experimenting with rather more sophisticated orders than usual, and it's hard bloody work. Especially as in the absence of an order template system you have to make extensive alterations to existing orders in order to customise them for a new route. What I wanted was to have all my trains using standard load orders rather than full load orders, then return empty to depot and stopping if they were unable to fill to 90%+. I also wanted them to go to depot and stop if their reliability after servicing was less than 40-50% or so, indicating they were end-of-life vehicle models (even if that particular vehicle was only a few years old), and I wanted some trains serving multiple sources and/or multiple destinations, or loading cargo at both ends of their journeys. I wanted cargo transports to auto-refit as appropriate depending on their current duties. And finally, when a passenger vehicle went for servicing, I wanted it to unload and go to the depot empty. This produced vehicle order sets like this (may be slightly buggy, I've been mucking about with it). If there are bugs, that would tend to prove one of my points:

Medium complex orders.png (45.89 KiB) Viewed 4782 times

I wouldn't even class that as 'very complex'. That's only a medium complex order. And with the limitations of the current UI, it's quite hard to follow.

And even this doesn't quite do what I'd like. What I was really after was for the train to load whichever of the three cargo sets is available, in priority order, and only go to the depot and stop if none are available. Orders like this currently result in a lot of to-ing and fro-ing to the depot as the train loads, finds it doesn't have enough cargo, does a 'quick' out-and-back to the depot that still takes a couple of game weeks, then tries again with the next cargo, and so on. Why does it have to load in order to find out this information? Partial answer - because conditional orders can only trigger 'between' stations, so at the particular point where a decision would be most useful, the only options available are full load any, full load all, load available and load nothing. So you have to load what's there, see how much you've got, then decide what to do next. Trying to manage cargos 'properly' has really rubbed my nose in the things the current system handles poorly.

So taking this as a template, how might it be better handled? The object is to make the following things visible on one screen, as now, and scannable by eye: Stations/depots, loading activities, unloading/transfer activities, conditional orders. Timetable stuff as well, if it can fit. At present, if you just have a simple list of destinations, order lists aren't too bad. It's conditional orders in particular that break up the flow and make things difficult to follow, although the rather verbose auto-refit instructions ain't so good either. So some sort of visual split between conditional orders and station/depot orders might be very useful. Make order text grey and station/depot text black for example, so that you can more easily focus on one or the other.

With no new functionality

Code: Select all

1   /--     /-> /->  Jump to order 19                   -                   Requires service  equals        Yes
2   |       |   |    Gresway Tanner Road                non-stop, near end  Unload ALL        -             Load available (Coal)
3   |   /-- |   |    Jump to order 7                    -                   Loaded            less than     90%
4   |   |   |   |    Soningdon Green Industrial Park    non-stop, near end  Unload accepted   -             Load NONE
5   |   |   |   |    Soningdon Park Train Depot         -                   Service           -             -
6   |   |   \-- |    Jump to order 1                    -                   ALWAYS            -             -
7   |   \-> /-> |    Gresway Train Depot                -                   ALWAYS            -             -
8   |       |   |    Gresway Tanner Road                non-stop, near end  Unload ALL        -             Load available (Coal)
9   |   /-- |   |    Jump to order 13                   -                   Loaded            less than     90%
10  |   |   |   |    Great Accgrove Rivers Powerplant   non-stop, near end  -                 Transfer ALL  Load NONE                
11  |   |   |   |    Great Accgrove Rivers Train Depot  -                   Service           -             -
12  |   |   \-- |    Jump to order 7                    -                   ALWAYS            -             -
13  |   \->     |    Gresway Train Depot                -                   ALWAYS            -             -
14  |           |    Gresway Tanner Road                non-stop, near end  Unload ALL        -             Load available (Iron Ore)
15  |   /--     |    Jump to order 21                   -                   Loaded            less than     90%
16  |   |       |    Great Accgrove Rivers Powerplant   non-stop, near end  Unload accepted   -             Load NONE
17  |   |       |    Great Accgrove Rivers Train Depot  -                   Service           -             -
18  |   |       \--  Jump to order 1                    -                   ALWAYS            -             -
19  \-> |            Gresway Train Depot                -                   ALWAYS            -             -
20  /-- |            Jump to order 22                   -                   Reliability       less than     50%
21  |   \->          Gresway Train Depot                -                   ALWAYS            -             -
22  \->              Gresway Tanner Road                non-stop, near end  Unload ALL        -             Load NONE
23                   Gresway Train Depot                -                   ALWAYS            STOP          -

Notes:
1. I would suggest 'always', 'none', 'stop' and 'all' should be highlighted in some way.
2. For unloads, the options are Unload ALL, Unload accepted (the default) and Unload NONE.
3. For loads, the present options are Full load ALL, Full load ANY, Load available (the default)
and Load NONE.
4. These orders use auto-refits. Rather than 'Auto-refit to coal', why not just specify
Load ALL (coal)'? 'Load available (coal)' and 'Load NONE (coal)', with the auto-refit option
in brackets? For non-refittable trains, the option would be (current loadout), and auto-refit
to available would just be (auto-refit). (Strings for trains with a mixture of refittable and
non-refittable wagons TBC.)
5. The jump to orders arrows column would be much clearer in graphics rather than ASCII. I'd
suggest using solid arrows for unconditional jumps, dotted ones for conditionals. I'd also like to
be able to toggle or blank out the 'jump to order' text, and drag both ends of the 'jump arrows'.
6. If I'm right that the destination options column is rarely altered, perhaps its visibility
could be togglable. That way, you set it, and then once it's correct you can hide it and avoid
accidentally disturbing it again. Perhaps similarly for the 'Jump to orders' arrows. I still think
graphical icons for non-stop, near end et al would be clearer than using text for them.
7. As I said, it's conditional orders that do most of the damage in breaking the visual flow.
Making them grey vs. black for orders might make quite a difference. Or Bold for stations,
plain for depots and waypoints, italic for conditional orders.
8. By splitting Transfer into its own column, separate from the unload orders, it becomes
clearer how additional transfer functionality could be added. Transfer ALL (the only option
available for transfers at present), Transfer accepted, Transfer NONE (the default) are obvious
ways that fit in with what the game already does. And a payment% option (e.g. Transfer ALL
(credit 40%) would allow you to customise transfer credits to suite a particular route. You could
also do Unload accepted, Transfer remainder as a new option not currently available.

In this sample, columns 3, 5 and 7 are the important ones. If the text formatting for code was
less in-your face, it would be clearer still. I think normally all the jump to lines would be faded,
that 'jump to order' text might be omitted entirely, and column 4 would probably be hidden.
Those changes lead to this, which is about the same size as the present order window, but
I think potentially easier to follow.

Code: Select all

1   /--     /-> /->                                     Requires service  equals        Yes
2   |       |   |    Gresway Tanner Road                Unload ALL        -             Load available (Coal)
3   |   /-- |   |                                       Loaded            less than     90%
4   |   |   |   |    Soningdon Green Industrial Park    Unload accepted   -             Load NONE
5   |   |   |   |    Soningdon Park Train Depot         Service           -             -
6   |   |   \-- |                                       ALWAYS            -             -
7   |   \-> /-> |    Gresway Train Depot                ALWAYS            -             -
8   |       |   |    Gresway Tanner Road                Unload ALL        -             Load available (Coal)
9   |   /-- |   |                                       Loaded            less than     90%
10  |   |   |   |    Great Accgrove Rivers Powerplant   -                 Transfer ALL  Load NONE                
11  |   |   |   |    Great Accgrove Rivers Train Depot  Service           -             -
12  |   |   \-- |                                       ALWAYS            -             -
13  |   \->     |    Gresway Train Depot                ALWAYS            -             -
14  |           |    Gresway Tanner Road                Unload ALL        -             Load available (Iron Ore)
15  |   /--     |                                       Loaded            less than     90%
16  |   |       |    Great Accgrove Rivers Powerplant   Unload accepted   -             Load NONE
17  |   |       |    Great Accgrove Rivers Train Depot  Service           -             -
18  |   |       \--                                     ALWAYS            -             -
19  \-> |            Gresway Train Depot                ALWAYS            -             -
20  /-- |                                               Reliability       less than     50%
21  |   \->          Gresway Train Depot                ALWAYS            -             -
22  \->              Gresway Tanner Road                Unload ALL        -             Load NONE
23                   Gresway Train Depot                ALWAYS            STOP          -

Additional functionality:
The Depot column typically has only one option. There's now space to combine Service, Refit
and Stop all into one visit. If Split or Join became future orders, then I do think Split
and Join should probably become a separate page. Perhaps you would have to have a page that
let you split Train 1 into Trains 2 and 3, and these became 'virtual trains' in one's vehicle
list.

Other long-standing requests have been for drive-through depots and continual loading stations
(where trains move through a 1-2 tile station at low speed loading continually). It seems to me
that abolishing/blurring the distinction between depots, waypoints and stations would do much of
this. If stations could service and provide 'turn train round' facilities (which they sometimes
do, sometimes don't ATM depending on your config settings), then they do most of what a
drive-through depot needs. Similarly a waypoint with a 5mph speed limit that can load cargo onto
certain truck types might address demand for a continual-loader.

Not considered:
I haven't re-looked yet at further customisation of the load and unload orders by cargo type.
Nor have I looked at how nicely this system interacts with implicit orders.

[aantono]

Just wanted to checkin to see if any progress has been made on this. I am looking into adding support of "sized" orders for loading and unloading, since that would be very helpful in a complex economy even with CargoDist. It would be a lot easier to have one train to go to multiple pickup stations and partially load itself or partially unload itself (for example with FIRS you don't want a whole train to deliver Engineering/other Supplies to a Mine, as it won't have the proportional effect. But if your supply production is on the other side of the map, it is easier to have one train haul all of it and just make multiple stops along the way rather then do very complicated transfers [not to mention that this is how it is done in reality]). So I was thinking to just keeping it simple and add ability to specify the % to load (just like we have Load vs Load Full, there would be an addition of Load %), so code-wise it should just be an extra check to check not only for 100%, which is what Load Full is, but for any number of %, and "Load Full" would internally be treated as Load 100%.

Any thoughts on this, especially from the OpenTTD devs? Want to discuss this as a possible addition to the trunk effort, to gauge plausibility, before I embark on the coding effort.

[Alberth]

To me, better control over percentages loaded/unloaded is different (and even independent from) UI overhaul. Don't try to merge them.

For me, a overhaul of the order UI would be the first step, as I don't see how you can reasonably add more stuff to the order gui in its current state.

As for adding better load/unload control, it should work with and without cargo dist (in the former case, cargo dist should also know about it). Also, the immediate next idea you're going to get is to have this for different cargoes (load X% for cargo A, unload Y% for cargo B, and full load cargo C). You may want to think about that.
I cannot really help you further, as I don't know much about orders and cargo stuff.

[aantono]

Thanks for the tips, will definitely think about the further evolution of the original concept. I guess my first question was to gauge the possibility of this feature to be merged into trunk at some not-too-distant future (obviously after all the code is brought into compliance and functions). I want to avoid those long-running patches that live forever on the branch and don't really have a change to be merged into the trunk cause the official devs don't think the feature warrants it.

So if there is good chance of this feature enhancement being accepted, I'll try to embark on making the coding part happen (though might need some help from someone who knows about orders functionality to guide me through the complexities, like why some enums are regular, and others have bit-mask escapes, i.e. OrderUnloadFlags)

[ic111]

I just came across this thread...

What I did in my Timetable Improvement Patch was adding three small buttons to the upper left section of the timetable window, that control which lines are shown.

Full means: Show both timetable and the well-known destination-related information (Destination, Full load, Non stop, etc.)
Dest means: Show only the destination-related information
Time means: Show only the timetable-related information (that is, Destination, and Arrivals, Departures, Speed limit in a tabular manner).

Screenshot of Full version: http://www.tt-forums.net/viewtopic.php? ... 0#p1128411
Screenshot of Time version: http://www.tt-forums.net/viewtopic.php? ... 0#p1128414

That kind of functionality is completely working in my patch.

Obviously, one could think about using the same concept for more things (although I personally currently don´t see a third group beside destination information and timetable information that needs to be addressed - but that may be based on my personal playing style).

Also, as my timetable window (timetable_gui) as shown in the screenshot can do anything the old order window (order_gui) can do, strictly speaking I wouldn´t need the latter any longer.

And yes, my patch (and the more heightlevel patch also) probably is one of "that live forever on the branch", just because of its size, but honestly, I don´t know of any other way to write patches when trying to change some aspect of game in a rather fundamental manner. Changing the data structures of timetables unfortunately triggers changing the GUI, and if I change GUI, I want to produce a good result in terms of GUI handling. (this just as a side note here).