News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Sort Vehicles in Depot Window

Started by HyperSim, October 15, 2017, 05:14:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

HyperSim

This is the implementation of this topic.
http://forum.simutrans.com/index.php?topic=3125.0

I readjusted depot window based on Leartin's idea in that extention request topic, and add a button for sort vehicles.
(See the picture attached.)

This is prototype version, so I want to hear your opinions.
(Which is better button or dropdown-list?  What value for sorting is needed. etc...)

I don't attach patch file this time but you can see source code on my git.
https://github.com/HyperSimu/simutrans/tree/SortInDepot

Leartin

Sadly, I can't test patches :(

Anyway, I have a further suggestion on the placement of options, and while that's not exactly your goal, it might still be the best time to do this.

First, I don't think there is enough space for "show all", "show obsolete", Filter and a search field. For example in German, "show obsolete" becomes "auch veraltete anzeigen". It could be shortened (zeige veraltete) but right above, there should be a currently empty line.
Furthermore, the function of "show all" is hard to grasp. There are several reasons why there would not be all vehicles visible - Filter, Search bar, timeline, electrification,... - none of which are affected by 'show all'. The only thing it DOES affect is whether vehicles that can currently be appended, put in front, or sold are the only vehicles to appear.

First line: Information about how many units are in the depot, and the sorting option to the very right.
Second line: The Append/Put in Front/Sell button. Next to it, the "show all" checkmark, since those two are thematically connected. Additionally, if possible, I'd invert it an change it's text to "show only appendable/sellable/...frontputable?" depending on the active option.
Third line: Start with the filter, then "show obsolete" and the search field. Note how all three options are filters, so they go well together, and using filter as the first element makes it lend it's name to the full line.

Edit: Does "prepend" work in this case for "put in front", making the checkmark "Show only prependable"?

HyperSim

Quote from: Leartin on October 16, 2017, 09:20:50 AM
Anyway, I have a further suggestion on the placement of options, and while that's not exactly your goal, it might still be the best time to do this.

Thank you for your pointing out and suggesting.
I thought "Show all" and "Show obsolete" are related to filtering function, so I placed these checkmark in the same line but your idea sounds nice to me. I will try to implement it.


I forgot introducing new vehicle info field.  I attached an image and please see it.
I think it is simpler than the current one.
Note: I changed displaying month for the introduce/retire date, because there's not enough space.
Should I use shorten month name (Jan., Feb., ...) instead of using digits?

Leartin

Quote from: HyperSim on October 17, 2017, 05:07:18 PM
Note: I changed displaying month for the introduce/retire date, because there's not enough space.
Should I use shorten month name (Jan., Feb., ...) instead of using digits?
I would have removed the description "Active date" instead, as with most of the words before ":", they simply don't provide any extra information. Eg. "Weight: 4.0t". Everyone knows that t is for tons, and that tons is a unit of weight, so writing "weight" there does not really provide valuable information. The first line does not start with "Name: Praga Bus" either...

Ters

Maybe some languages have ambiguous names for units? In particular non-SI units like t.

Leartin

Quote from: Ters on October 17, 2017, 06:54:31 PM
Maybe some languages have ambiguous names for units? In particular non-SI units like t.
Maybe. None of the languages Simutrans is available, though - if it wasn't for a different sign for kW in russian/ukrainian, I'd have thought the units are not even subject to translation (I could not look at chinese). Perhaps if Hindi or Arabic were added - but even then, it's quite likely that there are solutions for those languages, eg. an equivalent of "tons of weight".

Ters

"x tons of weight" is longer than "Weight: xt", so that is still something to care about. (Then of course, the metric ton(ne) is not a unit of weight at all. It is a unit of mass. I'm not sure if that also applies to UK and US tons, as the pound is a unit of mass, force/weight and money, although with different short forms, even if only slightly for the first two.)

Leartin

Quote from: Ters on October 18, 2017, 05:32:23 AM
"x tons of weight" is longer than "Weight: xt", so that is still something to care about.

In English, yes. In German, you would have "Gewicht: xt" vs. "xt schwer", so it's shorter. Until someone comes up with a specific language where tons are ambigous in the context provided, we are dealing with a hypothetical language, and we have no idea which is longer or shorter. Or whether the current space would be sufficient.

A ton is, in a strictly physical sense, not a unit of weight. That might have significance in a game with applied physics and changing gravitational pull, eg. Kerbal Space Program (never played it though), but for Simutrans, it's the same. I mean, I could turn that into an argument for removing "weight:" - but it just isn't.


prissi

Did zou check this with anz smaller pak? The dialoge is narrower in smaller pak sizes, like 96 or 64 ...

HyperSim

Quote from: prissi on October 18, 2017, 12:41:36 PM
Did zou check this with anz smaller pak? The dialoge is narrower in smaller pak sizes, like 96 or 64 ...

I checked pak64 and 96, but I think the dialog width is as same as pak128.
So, it's not problem at all.

Leartin

Quote from: prissi on October 18, 2017, 12:41:36 PM
Did zou check this with anz smaller pak? The dialoge is narrower in smaller pak sizes, like 96 or 64 ...
No, the dialog has the same width, only the height changes (Though I'm pretty sure that was not always the case)

HyperSim

Here's a candidate version for integration of "Sort Vehicles in Depot patch".

Now, you can use 4 values for sorting.

  • Capacity (as current simutrans do)
  • Max. Speed
  • Price and Running cost (compare Price first, then Running cost)
  • Power

See these pictures and check how it works.

https://photos.app.goo.gl/DEnLoNKkAqb9qMSI2
https://photos.app.goo.gl/2T1ujjyYTiuXEwPn2

.diff file is in attachments. (for the latest source code (r8316 on Oct, 24))
And you can also see source code on git.  https://github.com/HyperSimu/simutrans/tree/SortInDepot

HyperSim

There's no opinion for this feature these days...
I was thinking there's an argument what values use for sorting.
Are these 4 values enough for this patch?

Ves

I would think that as many variables as possible would be the best. Especially if it's a drop down list (have not had the possibility to use the patch so I don't know the physical appearance in the window), it doesn't matter how long the list would be.
If only four variables is available to sort after, I believe it would feel artificially constrained, which I think should be avoided.

Ters

Name is probably a useful thing to sort by, to group related vehicles together. The only other parameter to sort by I can think of are the two dates, but I can't see that being particularly useful.

Another thing, if it hasn't already been done: Make sure each sorting is a stable sort based on the current order. That way, you can sort by multiple criteria by selecting the least important criteria first, followed by increasingly more important criteria.

Ves

Quote from: Ters on November 05, 2017, 08:09:54 PM
Name is probably a useful thing to sort by, to group related vehicles together. The only other parameter to sort by I can think of are the two dates, but I can't see that being particularly useful.

Another thing, if it hasn't already been done: Make sure each sorting is a stable sort based on the current order. That way, you can sort by multiple criteria by selecting the least important criteria first, followed by increasingly more important criteria.
What about by weights? You might have bad rail somewhere and need to choose vehicle based on that?
Or running cost, when you need to run cheap? Or buying cost when you have no money at the moment?
If you want to run a heavy train, you might want the one with the most horse power, alternatively the highest tractive effort. Sorting by those then would help visualize which vehicles are feasible and which are not.
And then let's not talk about speed, cargo amount, cargo type, you name it!

Ters

Power, cost, speed and capacity has already been covered. No need to name them again. The question was if there are more. Although it should perhaps be pointed out that the two costs should be treated separately. Weight isn't much of an issue (yet). In my experience, it scales with capacity, but maybe other pak sets let you choose between cheap-but-heavy and expensive-but-light (or some pointless choice like heavy-and-expensive) for the same cargo type and capacity. Tractive effort isn't even proposed, unless you mean power times gear, but that is what should be meant by power, because the pure power value has no use by itself.

I forgot the obvious cargo type, although we already have a cargo type filter that might be more useful for that kind of thing.

Leartin

I guess Ves was thinking of SimEx, which would have more values to care about.


QuoteAnother thing, if it hasn't already been done: Make sure each sorting is a stable sort based on the current order. That way, you can sort by multiple criteria by selecting the least important criteria first, followed by increasingly more important criteria.
This is indeed very important. It also means that you need to have a dropdown-list where you can jump from one criteria to another, doing it by rotating between the values (jump to the next with each click) would not work.
It also means price and running cost can be seperate criteria, since the suggested price AND cost could be achieved by doing one after the other. Running cost by itself might be more useful than price anyway.

Would optional criteria be possible? Eg. Idle cost of a vehicle would be a criteria by which sorting makes a lot of sense if you already know that vehicle will probably mostly wait in a station. However, most paksets don't utilize that (yet), and those should not even display it. If it was possible to have criterias which are not shown at default but can be added via simuconf if a pakset needs them, I guess you could have pretty much everything as an optional parameter. Eg. while sorting by translated name would make sense in every pakset, sorting by object name would be pretty random in most paksets. Unless they are streamlined for a specific sorting pattern (Eg. country_company_numbering). Sorting by engine type has no gameplay reason at all, but could be interesting for model-railway-fans. I'm sure the issue wouldn't be to program sorting by these parameters, just that it would clutter the menu for most paks/players who would not use them, so having additional options on a pakset or self-set basis would be nice.

Ves

I do also have Ex in mind, but even for standard, I would see no benefit of limiting sort options  :)

HyperSim

I updated this patch and change button to drop-down list box. (See this picture)
https://photos.app.goo.gl/UuwBhoESKW3QZt8v1 (Link to Google Photo)

Now, you can use 8 elements for sorting.

  • Capacity
  • Price (compare price first, then running cost)
  • Running cost (compare running cost first, then price)
  • Max. speed
  • Power (gear is not considered)
  • Weight
  • Intro. date
  • Retire date

.diff file is in attachments. (for the latest source code (r8321 on Nov, 2))
And you can also see source code on git.  https://github.com/HyperSimu/simutrans/tree/SortInDepot

As you see the source code, there are so many functions for sorting. (you will find eight "sort_by_XXX" function in depot_frame.cc)
I think this should be shortened but I have no idea.  Does anyone have a good idea to solve this?

Quote from: Ters on November 05, 2017, 08:09:54 PM
Name is probably a useful thing to sort by, to group related vehicles together. The only other parameter to sort by I can think of are the two dates, but I can't see that being particularly useful.

In my opinion, depot window already have name filter and sorting by name is not needed.

Quote from: Leartin on November 06, 2017, 07:29:57 AM
I'm sure the issue wouldn't be to program sorting by these parameters, just that it would clutter the menu for most paks/players who would not use them, so having additional options on a pakset or self-set basis would be nice.

That sounds nice but implementing that would be difficult.
I don't come up with the idea how to define additional options in config file.
Anyway, I add combo box to select sort elements, and if that problem will solved, adding extra sort options is not so hard I believe.

Ters

#20
Quote from: Ves on November 07, 2017, 12:44:55 AM
I do also have Ex in mind, but even for standard, I would see no benefit of limiting sort options  :)

Nobody was limiting sort options. We were expanding the list, but we need to know what to expand it with. Options don't fill themselves in. People have to come up with them.


However, too many options can overwhelm the user, which is bad. One can keep less useful options at the far end of the list, but one still need to prioritize.

Quote from: HyperSim on November 07, 2017, 03:10:27 AM
In my opinion, depot window already have name filter and sorting by name is not needed.

I got a feeling that sorting for names might add something that filtering doesn't, but I can't come up with a case.

HyperSim

Quote from: Ters on November 07, 2017, 06:12:21 AM
However, too many options can overwhelm the user, which is bad. One can keep less useful options at the far end of the list, but one still need to prioritize.
I think so and I choose 4 parameter for sorting at first.
But I don't know which is better less parameter or more parameter.
I want to listen to others' opinions.

Quote
I got a feeling that sorting for names might add something that filtering doesn't, but I can't come up with a case.
I think adding sorting for names is better than not adding it, but there's one problem, which name should use for sorting, original name or translated name.
There are so many addons but some addons don't have translate file.
So, I'm afraid that sorting for names does not satisfy us in either case.

Leartin

Quote from: HyperSim on November 07, 2017, 07:39:46 AM
I think adding sorting for names is better than not adding it, but there's one problem, which name should use for sorting, original name or translated name.

The translated name, or "what the player sees". Since the original names are mostly invisible, players could hardly understand the order, rendering it pretty useless.

Vladki

If I recall correctly, openttd has option to sort the depot by power/running cost. That used to be my favorite option.

But I fear it might be problematic in extended, where we have power + tractive force, an cost per km and monthly costs....

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

Quote from: Vladki on November 07, 2017, 04:38:05 PM
If I recall correctly, openttd has option to sort the depot by power/running cost. That used to be my favorite option.

But I fear it might be problematic in extended, where we have power + tractive force, an cost per km and monthly costs....

Indeed - the whole point of many of Extended's features is to make sure that optimum vehicle choice cannot be reduced to a very simple ratio in every case, but to require the player to think more wholistically about the simulated world and the vehicle's place in it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

HyperSim

#25
I implemented name sorting (based on translated name), and changed my mind.  Name sorting is useful.
Here's a screenshot for name sorting with many Japanese train addons.
Vehicles in same campany form groups and I can easily find vehicles.
https://photos.app.goo.gl/4zkeFd9WsBjFNJ0z2  (Link to Google Photo)

I don't know well about simutrans extend, and I don't know what extend players consider during game.
So, what I can do is making code easier to read and understand and extend developer can easily add sorting feature.

HyperSim

I implemented name sorting and shorten code.
So, please check and try it.

.diff file is in attachment. (based on r8328)
exe file(Win only) : https://drive.google.com/open?id=1dJD0-9qcY82sbSbUO2pf6X4uSQdOt-qc
git : https://github.com/HyperSimu/simutrans/tree/SortInDepot

Dwachs

I think the huge switch block can be simplified by falling through the options like

case sb_name:
cmp = strcmp(translator::translate(a->get_name()), translator::translate(b->get_name()));
if (cmp != 0) return cmp < 0;
case sb_capacity:
cmp = compare_capacity(a, b);
if (cmp != 0) return cmp < 0;
cmp = compare_engine(a, b);
if (cmp != 0) return cmp < 0;
case sb_speed:
cmp = compare_topspeed(a, b);
if (cmp != 0) return cmp < 0;
case sb_power:
cmp = compare_power(a, b);
if (cmp != 0) return cmp < 0;
cmp = compare_intro_year_month(a, b);
// etc
break;
Parsley, sage, rosemary, and maggikraut.

Ters

That looks like it would ruin cumulative sorting. If name is equal, it will then sort by capacity, not by whatever the previous selection was. So you can't sort by name, then by speed. If name is equal, it should return 0, which would cause a stable sorting algorithm to preserve the existing ordering of the two items being compared.

Leartin

Are all vehicles sorted, or only those currently in the depot, or only those visible? Or the other way around: Are vehicles sorted anew each time you open the depot, new vehicles become available, or you change what's visible in the depot (filter, "show all", "show obsolete"...)?
Only if all vehicles (or at least all available to the timeline) are sorted would cumulative sorting be useful.

HyperSim

Quote from: Dwachs on November 13, 2017, 07:54:48 AM
I think the huge switch block can be simplified by falling through the options like
I was thinking the switch block can be simplified but I had no idea how to do.
Your code gave me a hint.  Thank you very much!

Now, I could simplified the code.  (About 100 lines were reduced.)
algorithm.gif in attachment is a figure for reference.

.diff file is in attachment. (based on r8328)
exe file(Win only) : https://drive.google.com/open?id=1dJD0-9qcY82sbSbUO2pf6X4uSQdOt-qc
git : https://github.com/HyperSimu/simutrans/tree/SortInDepot

HyperSim

Quote from: Leartin on November 14, 2017, 07:21:33 AM
Are all vehicles sorted, or only those currently in the depot, or only those visible? Or the other way around: Are vehicles sorted anew each time you open the depot, new vehicles become available, or you change what's visible in the depot (filter, "show all", "show obsolete"...)?
Only if all vehicles (or at least all available to the timeline) are sorted would cumulative sorting be useful.

I just inserted sorting before building vehicle list available in the depot.
Therefore, filters, "show all" and "show obsolete" work well with sorting, so I think you don't have to worry.

The Transporter

Looks good!
I would like to have it in the stable version.

Dwachs

#33
Here is a modification of the patch: I moved the sort-button to the last line of the depot window: it made more sense to me. In this way, the 'show all', 'show obsolete' buttons and the filter are on the same line, which is consistent. Also used std::sort directly to sort a vector_tpl of pointers. If there are no objections, I would like to submit the patch.

Parsley, sage, rosemary, and maggikraut.

prissi

Maybe one should have something to sort by running cost per unit?