News:

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

minimap ideas 2.0

Started by Sirius, April 19, 2021, 02:28:40 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sirius

Hey there,
I just had some thoughts about the minimap.

At very first, there had been overflows on huge maps when zoomed in.
These should be fixed already.

Second: Another improvement of the "stop coverage" layer.
Farm fields were highlighted in this layer which was rather confusing.
This should also be fixed already.

Third: Yet another improvement of the "stop coverage" layer.
When the "stop coverage" layer is selected, the freight filter "All freight lines" will be handled in the same way as "passengers", which is rather confusing and inconsistent as enabling the "stop coverage" layer will also hide mail and freight lines from the minimap.
I am not yet quite sure how to handle the coverage area display properly.
It doesn't make much sense to highlight everything covered by any kind of stop, but that's the most consequent solution and, on the other hand, it doesn't make any sense to show pax data only when "all" is selected.

Fourth: Advanced asset filters.
As noticed previously, it's qiute difficult to read the color highlighting of many layers.
Further, a way to filter by Passenger classes is missing.
Something that came in mind to me is an "advanced filter" window, where players can filter assets shown on the minimap.
For example, replace the "Freight, Traffic, Wear, Congestion, Speed Limit, Weight Limit and Tracks" map layer by a single layer with an assigned filter:

[x] Transport mode
    [x] Railway
    [  ] Road
    ...
[x]Special Filter
    [x] Speed min: 160 max: 200
    [x] Electric
    ...
Highlight
( ) Traffic
( ) Wear
( ) Congestion
(*) Speed Limit
( ) Weight Limit
( ) Freight

Will show all electric Railway tracks between 160 and 200 km/h and gray-out the others. The highlighting of tracks in the speed range will be scaled between 160 (red) and 200(green).

A simmilar concept might work on the group of stop related layers, the group of building related layers as well as on the network map.

freddyhayward

another problem: some of the settings reset every time you open the map window

Sirius

I was not aware about this. Which settings are reset?
Another point I noticed is some filters are "reset" in some cases although they are still selected in the UI.

wlindley

Is there a way to at least alphabetize, if not group, the list of industries? It is a bit of a mystery why this is presented in such a terribly confusing way.  I'm pretty sure that sorting is something computers can do.



Sirius

Nope, that's something computers definitely cannot do!  ;D
Seems to be a worthwile improvement, I'll consider this.

Could you elaborate on how to group these?
It's not clear to me how these groups are defined.

Phystam

My little idea:

Each line has different color in the minimap, but the colors are randomly decided and players cannot edit it. I think line colors can be edited and fixed by players. Probably by "line color management" window or tab in schedule window?

Sirius

I kind of like that idea but I suspect that little idea might involve a lot of UI work.
For example, I don't think a color picker or something like that exists yet.
In any case, the major part of this is UI coding, which I don't like to be honest.

wlindley

Regarding grouping:  Perhaps the only simple and useful thing would be A-to-Z for pure suppliers (farms, mines, forests), then A-to-Z for factories (which both consume and produce goods), then A-to-Z for pure consumers (markets, shops, etc.)... is that sensible?

freddyhayward

Quote from: Freahk on April 19, 2021, 05:56:06 PM
I was not aware about this. Which settings are reset?
Another point I noticed is some filters are "reset" in some cases although they are still selected in the UI.
the show buildings / contours checkboxes definitely are

Sirius

#9
"show buildings" reset confirmed.
Cannot conform "show contour" reset though.

Edit: codewise "show buildings" should be the only option suffering from this. Should now be fixed.



Current progress:
Fix done: Overflows on huge maps.
Fix done: "stop coverage" highlighted farm fields
Fix done: "stop coverage" didn't handle the "all lines" filter correctly
Fix done: "show buildings" reset when re-opening the minimap
Code Cleanup partially done.
Feature done: group and sort industry list.
Feature WIP: stop and line display graph rework
Feature paused: advanced object filter and highlighting settings (yet too lazy to get started with the UI code)
Feature todo: player configurable line colors.

So there's still some work to be done.
The fixes wait for incorporation in PR https://github.com/jamespetts/simutrans-extended/pull/372

Make minimap great again! :o

prissi

r9736 implements factory sorting and grouping for standard (but display is left to right, top to bottom due to the automatic alignment GUI)

jamespetts

Excellent, thank you for this. Now incorporated.
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.

Ranran

Quote from: Sirius on April 20, 2021, 03:39:08 PMCode Cleanup partially done.
https://github.com/jamespetts/simutrans-extended/commit/8336a9a8f22321fc779c88cdbc6de421816a2925
I would like to ask about the justification for this change.
The initialization method does not seem to be found in the entire standard code, and it is not done that way in standard either. It is also inconsistent with other files. Even though much of the code is the same as standard, there are differences in format. This affects the merge from standard.
I'm not a program major, so I don't know much about it but If these changes are justified, I think it would be better to submit similar changes to standard.

wlindley

Is there some way to take the dialog-boxes from the Industry List, and put them on the minimap so it might look something like this?  Along with alphabetically sorting industries within their production/consumption.
Perhaps along with a dropdown box (All industries, Producers only, Manufacturers only, Consumers only).

The current horizontally-sorted-by-no-obvious-way list of industries on the minimap legend is less than useless.  This would make it obvious and useful.
I would code this if I had a clue how to share dialog boxes between classes, whether there exists or how to use a sort function on translated industry names, or what "virtual" means in a function definition, or all the old-style C++-isms in the codebase (I'm a C programmer from 1981 and a perl programmer since 1994, humor me please).


Sirius

#14
Quote from: Ranran on February 07, 2022, 12:49:24 PMThe initialization method does not seem to be found in the entire standard code, and it is not done that way in standard either. It is also inconsistent with other files. Even though much of the code is the same as standard, there are differences in format. This affects the merge from standard.

The initialisation syntax used is called "default member initialisation" or "inline initialisation"
This is a C++ 11 feature (which might be the reason why you cannot find it in old code) and there are multiple advantages in using this.

At first, the syntax that was used in minimap.cc  before was assignment, not initialisation!
That means, whenever class types are involved, a new default constructed object is created on initialisation, then in the constructor the assignment operator `=` is used to change the value of that object.
Whilst this practically doesn't matter on primitives, it matters on object types. As it doesn't hurt to use initialisation on primitives, it is encouraged to always use initialisation over simple assignment.
More complex initialisation shall remain in the constructor though.

At second, the old fashioned way to perform initialisations is via initialisation lists on the constructor.
Compared to this, inline initialisation has the advantage of code locality. If you define an initial value in the same location where you declare it, it is less likely that you forget to initialise a variable.
If you access an uninitialised variable, you will enter the world of undefined behavior. A world, where anything can happen including pink elephants falling from the sky.

At third, the brace syntax will protect you from narrowing conversions, whilst the other initialisation syntaxes won't.
What does uint8 var = 256 result in? Exactly! 0!
What does uint8 var {256} result in? Exactly! A compile error!
And brace initialisation is a direct initialisation whilst equal sign initialisation is a copy initialisation. With a decent level of optimisations in a modern compiler, the additional copy will be optimised away, but still the equals sign initialisation will require the assignement operator to exist, even if it won't be used in the end. Otherwise the code won't compile.
And finally, I think it is good practice to follow the cpp core guidelines: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es23-prefer-the--initializer-syntax

I guess you are totally right and this might best be applied to standard first.

ceeac

Quote from: Sirius on February 21, 2022, 10:48:34 PMWhat does uint8 var = 256 result in? Exactly! 0!
Clang has -Werror=constant-conversion, which causes it to reject this code, too (GCC only has -Werror=conversion as far as I know, which also causes lots of other errors so it's not really practical to enable at the moment).

Sirius

#16
Indeed, but why should one rely on something that might work... Depending on the compiler, compiler version, flags and whatever, when you can instead rely on something well defined in the C++11 standard.
That standard is nowdays well-supported and has made its way into simutrans standard as far as I know.
It might be a good idea to enable that flag anyways to detect such issues on old code, but when touching the line of code anyways, I don't see much of an advantage in sticking with the old syntax that, besides narrowing conversions, has further issues that the new syntax doesn't.

Ranran

QuoteThe current horizontally-sorted-by-no-obvious-way list of industries on the minimap legend is less than useless.  This would make it obvious and useful.
The main reason I don't like the (current) minimap factory legend is that it moves the minimap display position down and the visible range of minimap will be narrower...  ::-\
I think it might be better to open a separate window. That way, the position and size of the minimap will not change.


QuoteIs there some way to take the dialog-boxes from the Industry List, and put them on the minimap so it might look something like this?
I think this means that you want to use the combo box for the factory list filter, but from this point of view, it may be safer to separate it into a separate dialog.
Common use of the same thing or duplicate a similar conmobox will probably cause confusion and generate complexity. Currently it is already somewhat convoluted.
I remember seeing somewhere in the past that Bernd Gabriel or someone left a code that would open another dialog right next to the current winndow, but I'm not sure.
Secondly, in my frank opinion, "show only used" is always on and I think it's okay. That is, we don't need this option button. In a sense this seems to exist only for debugging purposes of the pakset creator.  ??? Options such as those suggested instead would be useful.

QuoteThis would make it obvious and useful.
The current left-to-right fill-in method is the simplest implementation, and there is no doubt that other coding efforts will be required.
Especially for the display as proposed, the corresponding number varies in each frame, so it may be a problem to adjust the display position and reduce the dead space.



I think the reason this kind of layout is difficult for me is that the size of this framework is not constant, and this example just happens to have less dead space.
For example, dead space, such as orange, can occur within every frame.
I think it's just a coincidence that the yellow frame and the red frame fit in two vertical lines.

Secondly, because the factories are divided into output and input, I feel that it is a little difficult to understand that there are two identical factories and which factory has both.
IMO, what the player wants to focus on here is the direction of transportation, i.e. whether the item is produced or consumed, and that should take precedence over the producer/manufacturer/cosumer distinction. In other words, there are two big frameworks, one that matches with output and the other that matches with input. This is because the first step in planning a transportation route is to start from the place where the cargo will be generated. Then create a route between the points that are generated and the points that are consumed.
Strictly speaking, the producer is at the top of the transport flow, since it performs production without materials. Naturally this distinction is necessary, but it is made within the framework of the producing side. I mean, they are arranged in the order of yellow and blue, not the order of yellow and red.
For example, in extreme cases, if the point of occurrence is ● and the point of consumption is ▲, we can connect ● and ▲. It's actually more complicated than that, though, so we need to make it smarter and easier to grasp.
I've always planned to introduce a symbol that distinguishes between producers and factories, but I haven't made any progress because I can't think of a good design. In the real world, producers can be as different as mining, agriculture, forestry, and fishing. However, simutrans does not distinguish between them as such. And there is the restriction of very small icons.


QuoteI would code this if I had a clue how to share dialog boxes between classes, whether there exists or how to use a sort function on translated industry names,
I've always wondered how easy it would be if I could code to query the database to arrange the data.
Sorting in c++ is something I'm not very good at. I can only copy simutrans code written by someone else. (´・ω・`)
However, at present, it is sorted in alphabetical order and in the order of producer / manufacturer / consumer.


QuoteI guess you are totally right and this might best be applied to standard first.
Given that the German-to-English replacement is progressing very slowly over the years, I think it will be a long-term project or will not change unless someone actively carries it out.
We may also want to maintain documentation such as documentation/coding_styles.txt.
It's old, but the standard code follows some of its text, so if the code brought from standard is extended and intact, breaking that format with extended will increase the amount of merge work. That is also what A. Carlotti previously advised. I've sometimes made my patches similar in coding style in anticipation of someone else taking the functionality out of extended and into the standard, or running it themselves in the future, but I don't think there are any such constraints in the extended-specific code.

wlindley

Quote from: Sirius on February 22, 2022, 09:44:47 AMI think it might be better to open a separate window. That way, the position and size of the minimap will not change.
It sounds like adding just that separate window, containing a single scrollable column of industries, (perhaps with the headings, "producer", "manufacturer", "consumer") that would make the existing order much more understandable, save space, and let the user place the legend wherever desired.  In fact that one change would accomplish everything I suggested?

jamespetts

Excellent - a great improvement. Now incorporated.
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.

Sirius

@wlindley I am quite sure I have never written what you have quoted...