Topic: Sort Vehicles in Depot Window

[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]

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]

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]

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]

"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]

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]

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]

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.

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.

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?

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.

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]

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.

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]

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.

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]

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....

[jamespetts]

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.

[HyperSim]

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

Code: [Select]

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;


[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]

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]

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]

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.

[prissi]

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

[Ters]

Without having looked at the code, I thought that was in already. What else could the cost in the diagram from 14 November be? Was it removed later?

[Leartin]

Running cost, yes. Running cost per unit, a combination of running cost and capacity, no. Would make sense though.

[Ters]

I thought he meant running cost per unit of distance, which is the only running cost number I've ever seen in the game.

[HyperSim]

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.

I checked your code and it works.
I didn't know well about vector_tpl, so this modification helps me a lot.  However, there are some problem.
The right-bottom corner of depot window is the space for "Resale Value." (see the 2nd image attached)
And in my opinion, saparated filter section and sort section is a bit difficult to use. (I want to hear other opinions)

[Dwachs]

Did not know about this resale value. What about moving the 'Sort by' button below the filter-related stuff, and then moving the text block one line down?

[Dwachs]

Here is an update: fixes the layout problem: the sort button is now below the filter buttons. Also adds running cost per transported unit as sort option.

[HyperSim]

Here is an update: fixes the layout problem: the sort button is now below the filter buttons. Also adds running cost per transported unit as sort option.

I checked it and I now understand what "cost per unit" mean.
It seems nice feature but this patch sorts vehicle in decending order.
And I think the space below "Show all" button is wasteful.
So, I merged your code with mine and make the window simple.

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

[Leartin]

Let me get in on the action

Can't provide a patch, just a mockup. The first is just a rearrangement, as I suggested earlier in this thread.
I like the second one even more, though: By getting rid of the line "X vehicles in this depot", there would be room for a divider, which is very pleasing to my eye. Instead of that line, show the number of vehicles in the tabs. Would be more convenient to find those vehicles in the depot, too.

What do you think?

[Dwachs]

I like the idea of adding a horizontal divider and the Label 'Search'. Also 'X vehicles in deport' seems not to be necessary. However, the order of buttons, filter stuff, and 'append' button is without any logic in your mockups.

[Leartin]

However, the order of buttons, filter stuff, and 'append' button is without any logic in your mockups.

Could you explain how the current/suggested solutions are actually logical? Seems to me as if they are pretty random, basically ordered by date of implementation.

To me, the most important thing is to place the "Show all"-checkmark right next to the append-button. This is to give it some context - "show all" is not a terribly descriptive name, it does not actually show all - it shows "vehicles other than those clickable based on the current state of the append-button". As such, placing button and checkmark next to each other, and relatively isolated from others, is quite important. As it is, they are pretty much as far from each other as they can be. I also don't like how it interacts with "show obsolete" - it always made me think that "show all" would somehow remove the timeline and allow me to see future vehicles, just like "show obsolete" reveals past vehicles.
For the rest, I just put filter, obsolete and searchbar in one line because they are technically all filters, leaving sorting for the top-right corner.

Maybe you disagree with my priorities, but there is definitelly logic.

[Ters]

I like Leartin's Depot2.png, but search and filter should be next to each other, "show all" and "show obsolete" should be the closest to those two and aligned. These four are all kind of filters. That leaves the append button and sort. The number on the tabs could be useful to me, but I am worried that their meaning isn't clear. It could be number of stored vehicle parts (useful to me), or it could be number of vehicles types listed on each tab (possibly the most likely interpretation for new users).

[HyperSim]

I also like the horizontal line and "Search:" label.
But, I don't like the layout because it seems untidy to me.
I think "X vehicles stored here." are needed because I sometimes use that notification,
but if I delete that label and place "Append" button left side of filter, the window will become simple.
However, I don't think this window is useful because it's too cramped.

By the way, what do you think rearranging the vehicle information bottom of the window?

[Leartin]

At least append and show all are close to each other, even if they are not in the same line. Can live with that.

[Dwachs]

I committed the patch in r8344. Please feel free to work on design changes. I will happily submit more patches to modify the layout.

[Leartin]

Should probably be it's own thread, but could we get a similar functionality in the build-citybuilding-dialog?

[Dwachs]

Please do this in an own thread. What should be the sorting criteria?

[HyperSim]

I committed the patch in r8344. Please feel free to work on design changes. I will happily submit more patches to modify the layout.

Thank you for integration!
Here's an update patch to modify the layout I posted before. (I attach the image again.)

I think reducing lines for vehicle information is needed because there's too many line for the info.
I united "Power:" and "Gear:" lines and "Intro. date:" and "Retire date:" lines. (So, I reduced 1 line.)
I want to know what do you think about it.

[DrSuperGood]

"Active date" sounds bad English I think. Something like "Available" sounds better.

[Leartin]

"Active date" sounds bad English I think. Something like "Available" sounds better.

That would be a translateable string anyways. For the backend, "active date" is a bit clearer even though it's awkward, put the string in Simutranslator and it can be "Available" in the frontend.
I wonder if the way the date is written is translateable too, at least the months. If it is switched (01/1948 instead of 1948/01), the string "01/" could be translated as "Jan. " or "January " instead, in languages or paksets that have the space. Note that paksets can use their own translations for strings, so it should be possible to keep "active date:" empty and replace it have the line written as "January 1948 - January 1968" - you don't usually have to explain dates. Look up any famous person on Wikipedia, chances are the article starts "Name (Date-Date)". The date in the statusbar does not say "Current Date:" either...

[Ters]

I'm not sure the meaning of the two dates in Simutrans are as obvious as the two dates for a person on Wikipedia. For persons, there are only two dates that are relevant without a context: birth and death. For vehicles, it is arguably three: introduced, last produced, retired. Simutrans doesn't have a concept for the middle one, but new players will not know that.

[HyperSim]

"Active date" sounds bad English I think. Something like "Available" sounds better.

I'm not good at English and I didn't come up with exact word.
However, translate file will solve this problem as Leartin mentioned.

I wonder if the way the date is written is translateable too, at least the months. If it is switched (01/1948 instead of 1948/01), the string "01/" could be translated as "Jan. " or "January " instead, in languages or paksets that have the space.

I once planed using the same format displayed in the status bar. (which is defined as "show_month" in simuconf.tab)
If it is ideal, I will start working on.
But, I'm against for omitting "active date:" because I think the window without the index is not clean.

[Dwachs]

I would vote for leaving the text block as it is and just applying the patch to rearrange the buttons and to add the divider line.

[HyperSim]

I updated the patch and suggest two layouts.
Please check the picture attached.

update

• Use the same format as the status bar to show intro. date and retire date. (depending on show_month in simuconf.tab)
• Restore the text block.

.diff file for both design are in the attachement.

[HyperSim]

Is there any opinions for this modifying?

The former layout is smaller but I removed the information to show how many vehicles in the depot.
The latter one is the layout based on the current layout.
In my opinion, the latter is better.

I restored the text block for now, but I think that block should be modified.
Vehicles without engines (ex. carriages and freight cars) do not have "Power:", "Gear:" information, so these space are useless. (Figure1)
And the same for vehicles without "Retire Date". (Figure2)

[Dwachs]

I do not understand, why you want to change the layout of the intro/retire dates. Why not leaving the text block as it is?

Also I like the layout of buttons in the picture depot_layout_01_Other_style.png .

[prissi]

I would just show the text of how manz vehicles stored, if there is no convoi is show in the top row. Otherwise this information is not needed. And the design with the separator indeed looks nice.

[Leartin]

I do not understand, why you want to change the layout of the intro/retire dates. Why not leaving the text block as it is?

Because, quote "Vertical window height is also already at max for those running lower resolution displays. i.e. This dialog be full!" ~ TurfIt
Going by that, you'd need to reduce a line in the text block in order to add an additional line for sorting and the search box. The changes made seem to be the most logical to achieve this - "Gear" as well as "Power" are both meaningless without their counterpart,  they only give useful information together. Introduction and Retirement are both dates, so they go well together as well.
As HyperSim pointed out, these informations don't exist for each vehicle, often leaving holes - especially gear. In a dialog that's "full", holes are a waste of precious space (if not used intentionally, like with the seperator or not having information to the right of the vehicles name)

So it pretty much comes down to the question whether the dialog is indeed full and as big as it can be, which means you'd need to reduce it on one end to add something new, or it can just be expanded.

[HyperSim]

Leartin said what I want to say.

There are two reasons why the text block should be changed.

The one reason is the size of the dialog.
The depot window height is about 500px now if you play pak128, (If you play pak64, it is about 400px.)
and the height of some laptop pc monitor is 768px. (WXGA)
If you play simutrans on these laptops, the screen looks like this.
https://photos.app.goo.gl/31S7a39IgiPNdxf52 (Link to Google photo)
So, we should discuss whether this dialog is too big or not.

The second reason is that the current dialog does not looks good.
When you see carriage (or freight car) info, there's a empty line in the middle of text block,
because that vehicle do not have power and gear info.
I think it is a dead space and there should be a better design.

[HyperSim]

Happy new year!

This topic has been stopping for 2 weeks, but there are some issue to discuss.
So, let's start the discussion again.

[prissi]

I had a few tweaks of the dialoge (due to pre-release work) and changing that text will not happen, as it will break the text with the translations. And those are central to the game. Also, there are frei DMU, which use all the lines, as well as passegner EMU too. I do not see how you can save a line here.

[HyperSim]

I had a few tweaks of the dialoge (due to pre-release work) and changing that text will not happen, as it will break the text with the translations. And those are central to the game. Also, there are frei DMU, which use all the lines, as well as passegner EMU too. I do not see how you can save a line here.

Whether the text block are changed or not, we have to edit translate file because there are no translation for "Vehicle Name", "Cost per unit" or "Vehicle Power" in text/XX.tab file.
Therefore, I think we don't have to worry about breaking translations, just add and fix it.
I attached the text block mock-up which uses all the lines.
I merged "Power" and "Gear" into one line, and "Intro. date" and "Retire date" into one line, so we saved one line.

[DrSuperGood]

Gear can probably be removed and replaced with "Effective Power", which is {Power * Gear}, and then swapped places with Power. Power is meant to be semi-realistic but in order for the convoys to work mechanically well gear is used to adjust the in game power. Hence players are much more concerned about the effective power and not the realistic "lore" power of a convoy/component. Gear currently is just some obtuse mechanic to confuse new players as to why a high powered convoy is under performing or a low powered convoy over performs.

[prissi]

Dates like that are problematic, since the month/year order and separators are different among cultures (e.g. Japan year/month versus Germany month.year). Thus there was one central routine to take care of dates.
Also it needsto deal with missing intro or retirement dates.

My suggestion to convert power and gear would be rather a multiplier shown to get the effective power.
Power: 88 kW (x2.0)

And to missing translations: There is a file base.tab, which must be altered, whenever a new text is introduced to simutrans. Not all patches does this, but any translation needed there will end up in text files, if the translation is different from the original. (I am currently try to synchronise this file with reality to prepare for a release.)

But knowing how difficult it is to get new translations and complete translations, I am not easily pushing these concerns to the side.

[Leartin]

Dates like that are problematic, since the month/year order and separators are different among cultures (e.g. Japan year/month versus Germany month.year). Thus there was one central routine to take care of dates.
Also it needsto deal with missing intro or retirement dates.

Are nested translations possible? Could you have the string "$1 $2" in the game to represent the date, but languages could translate it as "$2/$1", effectively changing the order of variables, which then get replaced by the internal months and the year, where the months again get translated? I know variables can be in the translation strings (eg. for the record announcements), but they don't seem to allow switching the variable positions.

Either way - while most people wouldn't tackle a large translation project, this here is about a few strings. Since it's unlikely to get into the current prepared release anyway, how about we use this thread to find out how it should change if it changes, and once that's settled, before it is put in the actual code, we publically ask for translations in the forums (for the few strings needed). Only if they are all provided, it is put in the code. This would make sure the game would not be without that crucial translation even for a moment, but also remind people of the translator who might not even know about it.

[prissi]

It is probably worthwhile to have a short date routine too, also for other places. Still, a japanese data may be wider in characters,
2999年12月
compare with
12.2999
So there is some extra free space needed. Also it needs consideration of things never expiring or never being introduced (intro year=0 the latter certainly more rare and mostly buildings).

And since there is a recent overhaul of translations needed before the next release (which I am doing right now), chnaging translation is probably not a bad time. The only problem is that with many langugaes (finnish, korea) we do not have translators or members, but still quite some downloads. So waiting for these translations will not happen quickly, if ever ...

[HyperSim]

Dates like that are problematic, since the month/year order and separators are different among cultures (e.g. Japan year/month versus Germany month.year). Thus there was one central routine to take care of dates.
Also it needsto deal with missing intro or retirement dates.

I've already solved this problem. Please check the post above.

Use the same format as the status bar to show intro. date and retire date. (depending on show_month in simuconf.tab)[/li][/list]

My suggestion to convert power and gear would be rather a multiplier shown to get the effective power.
Power: 88 kW (x2.0)

I like prissi's idea more than Leartin's idea, but considering the sorting, sort by "effective power", not "power" would be better...

[prissi]

No, you did not. You wrote 2012/01 but for Germany we need 10.2012 and for Japan ２０１２年１月, which are apparently not the same. Also we need to indicate missing entry of retire dates.

[HyperSim]

No, you did not. You wrote 2012/01 but for Germany we need 10.2012 and for Japan ２０１２年１月, which are apparently not the same. Also we need to indicate missing entry of retire dates.

I understand.
So, if show_month is 2 or 5, the text should be "Available: 2000年1月 - 2012年1月".
If show_month is 3 or 6, the text should be "Available: January 2000 - January 2012".
If show_month is 4 or 7, the text should be "Available: 01.2000 - 01.2012".

The text will be "Available: January 2000 -" for missing entry of retire dates in my plan and I think it is the best way.

[prissi]

But there are countries that use "-" as delimiter between month and year. Maybe better a text or a symbol "*" for undefined dates? Or just the current text string as it is.

[HyperSim]

But there are countries that use "-" as delimiter between month and year. Maybe better a text or a symbol "*" for undefined dates? Or just the current text string as it is.

In simutrans "-" is not used for delimiter, so I don't think it may cause misunderstanding.
Or show "Available: January 2000 - Forever" or something?

[Leartin]

But there are countries that use "-" as delimiter between month and year. Maybe better a text or a symbol "*" for undefined dates? Or just the current text string as it is.

That deliminator would be an ISO8601 conform hyphen, like in Lithuania. For an interval, ISO8601 mainly uses a solidus, but the standard allows for a double hyphen. That somewhat conforms to what it used in normal writing, which isn't a hyphen (-)  but a slightly longer en-dash (–) for intervals, and for full dates usually spaced on both sides.
"2000-01 – 2012-01" doesn't seem like a problem to me, so neither does "2000-01 –", though a placeholder "2000-01 – *" looks even better – especially if it's the other way around in  "* – 2012-01"

[HyperSim]

I refined the window layout and adopted this discussion.

• Merge Power and Gear.
• Merge Intro. and Retire date.
• Use appropriate format to show date. (depot_win_show_month.png)
• If the retire date is not defined, show "*" instead of the date. (vehicle_without_retire_date.png)

I adopted number instead of month name to show date because there's not enough space in some cases. (problem.png)
I wanted to use short month names (Jan., Feb., Mar. ...) but we have to add translation if I use them.

.diff file based on r8365 is in attachment.


By the way, I found a typo in simuconf.tab in line 568.

Code: [Select]

# 5>=show no season but everything else in japan format=5, us format=5, german=6This should be

Code: [Select]

# 5>=show no season but everything else in japan format=5, us format=6, german=7

[HyperSim]

Sorry, I found some mistakes in .diff file.

[TurfIt]

IMHO only show_month = 3 or 4 gives a workable long date string in the status line (December 6 1922, 6 December 1922). However the both 12/1922 and 12.1922 for short dates are gibberish - show_month = 2 for 1922/12 is ok, but then gives garbage for long format.  Hence, if the short date strings are being added, they need their own config setting.

[HyperSim]

IMHO only show_month = 3 or 4 gives a workable long date string in the status line (December 6 1922, 6 December 1922). However the both 12/1922 and 12.1922 for short dates are gibberish - show_month = 2 for 1922/12 is ok, but then gives garbage for long format.  Hence, if the short date strings are being added, they need their own config setting.

I replaced short month name instead of number.  It's not difficult.

However, I think adding new config settings should be discussed in a new topic because we should prepare so many options.
I consdered what option we might pepare.

• show month or not (show_month=0, 1)
• which format to use (Japan style, US style, German style)
• use number, long name or short name

So, we should prepare 2 + 3*3 = 11 options.
I want to listen to other opinions.

[prissi]

Online game info window uses a simpler hack for short dates with "/" only. Maybe we should rather get a rountine from translator.

tranlator::get_short_date( year, month );

[HyperSim]

Online game info window uses a simpler hack for short dates with "/" only. Maybe we should rather get a rountine from translator.

tranlator::get_short_date( year, month );

That sounds nice. I think this routine enables displaying "2000年1月" style. (In english, there are no "年" in date.)

[HyperSim]

I'm struggling to implement "get_short_date" these days.
I wrote this code below, but the translator does not work well.  (See the picture attached)
The text should be "XXXX年XX月 - XXXX年XX月" but it is "À - À".
I don't know what is wrong.  Please help me.

Code: [Select]

const char *translator::get_short_month_name(uint16 month)
{
static const char *const short_month_names[] = {
"Jan.",
"Feb.",
"Mar.",
"Apr.",
"May",
"June",
"July",
"Aug.",
"Sept.",
"Oct.",
"Nov.",
"Dec."
};
return translate(short_month_names[month % lengthof(short_month_names)]);
}

const char *translator::get_short_date(uint16 year, uint16 month)
{
cbuffer_t buf;
char const* const month_ = get_short_month_name(month);
switch (env_t::show_month) {
case env_t::DATE_FMT_JAPANESE:
case env_t::DATE_FMT_JAPANESE_NO_SEASON:
buf.printf(translate("%4d/%s"), year, month_ );
break;
case env_t::DATE_FMT_GERMAN:
case env_t::DATE_FMT_GERMAN_NO_SEASON:
case env_t::DATE_FMT_US:
case env_t::DATE_FMT_US_NO_SEASON:
default:
buf.printf( "%s %04d", month_, year);
break;
}
return buf.get_str();
}

[prissi]

The buffer is no longer valid after return. You can return either a cstring or use a static cbuffer_t. The proper way would be probably the cstring.

And I would not enforce the space. Just %s%04d%s or for japanese order %04d%s%s with inputs short months, year, year symbol (if there) respective months last for japanese (and other CJK languages). That way the translator can favour Jan/2014 or 1/2014 or 1.1.2017 or whatever by just supplying different translations for the short month string.

[HyperSim]

Here's new version of this patch.
There would be some modifies but I think you will be satisfied.

New features (see the picture attached)

• Add "YEAR_SYMBOL" and "DAY_SYMBOL" to show "年(year)" and "日(day)" in Japanese style date (or the other language).
• Depot window, vehicle info window, timebar(left-down side) and server info window are changed.

.diff file for r8374 is in attachment.
I attach a translation file of Japanese for this patch.
We had to add these words to each translation file...

[HyperSim]

Hello, everyone.
I fixed some bugs and I completed this patch.
New features
-If there's no "YEAR_SYMBOL" or "DAY_SYMBOL" translation in translate file, the program automatically omit these symbol string.
 (So, you don't have to add "YEAR_SYMBOL" and "DAY_SYMBOL" in translation file.)

.diff file for r8374 is in attachment.
I want to listen to other's opinion.
Any questions and ideas to improve this patch are welcome!

[HyperSim]

A month have passed since last post.
Is there no opinions?

[prissi]

This in next or nextnext on my todo list of thigns to include before a release. Please be patient.

TO elaborate more: My new laptop at home in unable to produce a working binary that cn save or load files with MSVC 2012, 2015 or 2017, despite using the same (verbatim) folder of the old laptop. I suspect a problem with the brand new atom processor there. I redownloaded/reinstalled everything many times, to no avail. Hence most development and testing is done on an ancient eeePC, which is rellly slow. The desktop development computer needs a free desktop, a monitor, and a 100V capable power supply, which are also on my todo list. (I moved three times in the last year).

[HyperSim]

This in next or nextnext on my todo list of thigns to include before a release. Please be patient.

TO elaborate more: My new laptop at home in unable to produce a working binary that cn save or load files with MSVC 2012, 2015 or 2017, despite using the same (verbatim) folder of the old laptop. I suspect a problem with the brand new atom processor there. I redownloaded/reinstalled everything many times, to no avail. Hence most development and testing is done on an ancient eeePC, which is rellly slow. The desktop development computer needs a free desktop, a monitor, and a 100V capable power supply, which are also on my todo list. (I moved three times in the last year).

Oh, that's too bad.
I didn't mean to rush you.
I'm patiently waiting for the progress.

[HyperSim]

The algorithmic program should be improved because current version of this patch may make the game slow and I update this patch now.

My friend reported that sorting vehicles makes simutrans too slow.
He plays simutrans with so many addons and when he push a button on depot window, the game freeze for a few seconds.
I cannot reproduce this phenomenon, but I understood this code is not good because whenever a button is pressed, the program start sorting.

The list of vehicles are now stored with pre-sorted in all kinds of keys.
Please check it.

[Ters]

Apart from perhaps sorting by name, there would have to be thousands or millions of vehicles for sorting to take seconds.

[prissi]

Add in -r8569