Topic: More graphical symbols!

[Ranran]

Hi all! Ranran tried an adventurous improvement of some dialog disign. (´・ω・｀)
How about these?

#1:Evaluation from passengers


The snail represents "Too slow". Is this confusing?
Another idea is a tortoise. Can I steal it from Super Mario?

BTW, I had a strange feeling of the order of symbols and numbers so far.
I feel naturally in the opposite position, is this unique feeling of the Japanese?



#2:Signal method

I think this is a failed work...
Can this be used elsewhere?


Here is my Github branch.
Before you start using this, you need to add new symbol pak files to the pakset folder.
I attach the source image and dat file and symbol pak files.


NOTE: This patch is not completed yet, and you can not start up these files if you do not have them.
But I have no idea how to avoid this problem and my skill may make it impossible to accomplish. (´・ω・｀)

[jamespetts]

Thank you for this - this looks very interesting. Before I integrate this, I should be grateful for feedback on others on the clarity of the symbols. One thing that I do wonder is whether, if we are changing the symbols now, it might be better to be clearer (both in symbols and text) about what "unhappy" really means, as it is actually very specific: it means either that the origin stop was overcrowded, and therefore the passenger could not board or that the waiting time was so long that the passengers gave up. I wonder whether there is a clearer way to communicate this?
(Incidentally, I prefer the snail to the tortoise).

[Vladki]

I prefer text instead of icons.
Especially the sad face and the one next to it are absolutely unclear. And yes what is unhappy? Perhaps it should be categories :
Station overcrowded, convoy(s) overcrowded, waiting too long for (any/non overcrowded) convoy, no route at all, route exists but takes too long, route exists but only for higher class

[jamespetts]

Would both text and symbols be satisfactory - perhaps mouseover tooltips?

As to the additional categories - that would involve some quite serious additional coding, especially for the route exists but only for higher class display (which would also very significantly increase computational intensity on higher maps, as it would require route-finding twice in many cases).

[Ranran]

Would both text and symbols be satisfactory - perhaps mouseover tooltips?

I also thought that it is best way to display tooltips by mouseover. Is inserting a tool tip in this place requires complicated code?
I mean this is not a kind of buttons or text boxes.
Are there any currently code that I can refer to?

EDIT: I succeeded in displaying the tooltip on the symbol. It is still necessary to optimize the position.

[DrSuperGood]

The symbols would need explaining at least in the in game help, and better yet with hover over tooltip.

Such hoverover tooltip could read like "Passengers lost due to potential journies being too slow".

[jamespetts]

I am not sure how complex that adding tooltips would be, as I have not looked into this code for a long time

[Frank]

The symbols for the passengers are needed because the previous ones are in the font file. But not every font file contains these.

If you set a different font, then these symbols are usually missing.

[Vladki]

Using symbol for signal method is not consistent with the rest of the dialog.

Using symbols for un/happy, no route etc is visually ok if there would be a mouseover hint with meaning. And that could be more descriptive than just happy or not.

[Ranran]

Yes, I have recognized that I was a failure using symbol this for signal method. On the actual game screen such small symbol was hard to recognize.
However, since the word "signal" was not originally included, I think that it is better to display both text and symbols for the player.

Using symbol for signal method is not consistent with the rest of the dialog

In terms of consistency, the "Current working method" is not a convoy spec (like eco drive mode), so I think there is a merit to making it easier for players to understand.

[Ves]

I agree in some way to let some more symbols into the game. When playing a game like Civ V, you have symbols all over the place, and it can sometimes be a little difficult to remember what each symbols mean. It is, however, extremely consistent so you know that things are the same if it has the same symbol, and you can hover over most of them to get a tooltip. Once you get used to the symbols it is extremely effective, and really makes the information more easily available.

In Simutrans, there currently is a symbol for each waytype, the three major good categories, and a happy face and a sad face if I havent forgotten anything. Already those are not used consistently, for instance the waytype symbols I think could be used in the stop detail window to help differentiate what waytype the different lines has serving the stop, the cargo manifest of the convoy window could display the cargo symbols, together with, or instead of, the cargo category name, just to name a few.
I have tried when I have made GUI-patches to use the existing symbols more, namely the cargo symbols, since those are already very well established in the game. I have used them where it would be too long to write out the good, for instance in the depot window just under the "change prices" button.

What Im worried about is that new symbols doesnt have a meaning yet, for instance the signal symbol you made is very nice I think. It is, however just not established that that symbol would mean "working method". You would need to present that symbol also in the signal info window, and if possible at all also in the tooltip for the signal icon. Otherwise people will not see that symbol enough to connect it with "working method". I would also move the symbol to right before the working method name:
"Current working method: [symbol] one train staff
That way, it would be consistent if you put it into the signal info window right before the working method entry there.

I think the smiley faces in the stop window are nice too, they help draw attention to those numbers which, at least I, often tend to forget all about. The same issue here though:
With this emphasize on the smileys, you need to know what those are all about, and that would be great with a tooltip when hovering above the individual smileys.
I would then go out and find more places those smileys could sit, for instance in the "Stop list", found in the "List's" menu and also in the "line management".

What I would wish for is an icon for each cargo type, wich of corse would be pakset specific. Those icons could live many places, for instance in the convoy window, the depot window, the line window, the individual convoy entries in the line window etc.

[Vladki]

Maybe "working method" is not a good wording either. If I wouldn't be so interested in signaling I would have hard time guessing what does it mean. Perhaps "signalling method" would be more appropriate.

[jamespetts]

"Working method" is the correct term - "signalling method" is ambiguous. Also, the term "working method" is used in the signalling tutorial videos.

[Ranran]

Regarding halt info, I modified to display tooltip when mouseover on symbols.

You would need to present that symbol also in the signal info window,

This might be difficult for me.
I have no idea how to modify signal_t::info() or signal_info_t::signal_info_t()...
Although I can add or edit text data, I do not know how to insert an image there.

if possible at all also in the tooltip for the signal icon.

Also the current tooltip seems to only accept text data.


I wish I could do that. (´・ω・｀)

"Current working method: [symbol] one train staff
That way, it would be consistent if you put it into the signal info window right before the working method entry there.

This was helpful and I thought it is better to represent that "Signal symbol" is under control of either signal working methods.

That is, in the case of drive_by_sight, it means that this signal icon is not displayed.

And make sure that you can check it with tooltip when you mouse over this signal symbol. (Please translate it.)

What I would wish for is an icon for each cargo type, wich of corse would be pakset specific. Those icons could live many places, for instance in the convoy window, the depot window, the line window, the individual convoy entries in the line window etc.

That's it! I wanted it too.

Code: [Select]

# categories:
# 0 = type defined (unique)
# 1 = piece good (i.e. crates of XY)
# 2 = bulk good (i.e. ore, sand, coal)
# 3 = oil type fluid
# 4 = piece good refrigerated (i.e. cooled crates of XY)
# 5 = liquid food
# 6 = long goods (planks, steel (any flat-bed))
# 7 = fabric (or any lightweight packed goods - crates, sacks)(catg = 5 and 7 are not used in pak128.britain-EX)

I tried making goods category icons. How's this?

** This is a composite image. Not a in-game screen shot.

As Ves said, it will help the player to distinguish them and useful in many dialogs.

[ACarlotti]

Something to note is that there will be changes to the way that gui windows are built once the recent changes from Standard are merged into Extended. This will probably happen within about a year. So if something seems difficult to do now, then that might change in the future.

[jamespetts]

I am just looking at this again. I note that most of this has been superceded by the improved stop dialogues, but I note that there is the addition of a number of goods category icons. Is there a separate Github branch for this that I could review - or has this idea been discontinued? This does seem to be a good idea in principle, as it would help to give players a clearer and more visual indication of the different types of goods. May I ask where you imagined these symbols being used?

[Ranran]

Is there a separate Github branch for this that I could review - or has this idea been discontinued?

This is just an idea stage, I just made category symbols and have not coding it yet at all.

I think the places to display the goods category can be used anywhere.


(1) depot dialog



(2) industry building information



(3) station details dialog
3a

3b


(4) station information (goods sorter)


(5) convoy information (goods sorter)


(6) convoy information (Proposed in another thread)


(7) Goods list

I thought that inserting or replacing symbols in these places would improve usability and improve the aesthetics.


What I expect is:
- Make it easy to identify the types of freight cars and trucks to prepare for transport
- Not to operate the return route empty, but to make it easy to find something that can be carried
- Make it easy to divert trucks and wagons

But I think it will take work to put symbol on the notepad format. And I think it may be easier after incorporating standard GUI changes.

I think it is (1) (3b) (6) and (7) that I may be able to do it at present.

[jamespetts]

This certainly does seem to be a sensible idea, although we would probably need some sort of text backup for symbols not defined in older paksets or as mouseover text in case the symbols be not clear to players.

[ACarlotti]

I would prefer to see the existing text description remain in those places where it already exists - it's probably more obvious what it means than learning a bunch of symbols, and avoids any risk of having symbols that are hard to distinguish. Adding a symbol in addition to the existing description could be useful, and would also serve as a way of documenting what the symbols mean.

[jamespetts]

There is much to be said for seeing text and symbols next to each other where there is room to familiarise players with the meaning of the symbols in places where there is not room also to have the text - thank you for your feedback on this.

Does anyone else have any views on these UI issues?

[Ves]

I think the icons are brilliant, and should be  displayed alongside the text everywhere possible. Only where there is no room (in the upper side of convoy window and in upper side of Depot window) it could show only the icons. 

Skickat från min ONEPLUS A6003 via Tapatalk

[Ranran]

I worked on the goods category symbols.

(1) depot dialog


The translation text needs to be changed because the symbol is inserted next to "Capacity:".


(7) Goods list



Currently, it does not support Special Freight except Passenger and Mail.

Special Freight, such as livestock and cars, has different numbers and names depending on the pakset, so I wonder how to implement it.
How should I set and load the special freight icon?
via simconf.tab of pakset folder or good.dat or another way?
And I do not know if it is achievable for me.


You need symbol.GoodsCategories.pak to display the symbols.
Please refer to the following about this.
https://github.com/Ranran-the-JuicyPork/simutrans-pak128.britain/commit/3bfdd2f5a85ed9cc5a95e0303cf8a363a9131fbc
Note: There is no problem if there is no symbol pak, but an error occurs if pakset has the symbol pak file and it is less than the number of actual usage categories.
You can avoid it by inserting an empty image in advance.
For example, I put an empty image at number 7.

Code: [Select]

Image[7]=> goods-category.0.7


Here is my github repository:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/goods-category-symbols

I attach the .pak file of the Goods Category symbol.

[jamespetts]

Thank you for that: that looks very interesting.

As to the depot display, I wonder whether it would be simpler and easier to understand if the symbol were placed after the text, as in "Capacity: 32t long goods [SYMBOL]" rather than "Capacity: [SYMBOL] 32t long goods".

As to special goods, the ideal solution would be to have a defined symbol for each type in goods.dat, but also to allow paksets not to define such a symbol.  If that is too difficult to code, then a good alternative would be a generic special goods symbol to use for special goods other than passengers or mail.

[Ranran]

As to the depot display, I wonder whether it would be simpler and easier to understand if the symbol were placed after the text, as in "Capacity: 32t long goods [SYMBOL]" rather than "Capacity: [SYMBOL] 32t long goods".

What do you think about the consistency of the two part which I circled in magenta?


I am concerned if the other goods.pak will not be affected if special goods (goods with catg = 0) can have the image.

then a good alternative would be a generic special goods symbol to use for special goods other than passengers or mail.

It is easy to implement, is it acceptable until I or another coder solves that problem?

[jamespetts]

The issue about the consistency of the two locations is well made; perhaps it would be better for the symbol to be after the text in both places?

I am afraid that I do not fully understand this:

I am concerned if the other goods.pak will not be affected if special goods (goods with catg = 0) can have the image

Can you elaborate?

Subject to that, it is indeed acceptable to have a generic graphic for special goods until a more sophisticated solution can be implemented, as this is better than either not implementing this patch at all, or having symbols for everything but special goods.

[Ranran]

perhaps it would be better for the symbol to be after the text in both places?

However, currently, mail and passenger symbol are displayed on the left.
And the symbol display position of the vertical alignment becomes irregular.

Can you elaborate?

I don't think there are any objects that have and do not have images in the current simutrans, so I have a question whether it is possible.
And I'm sorry I have not made such things yet, so my skill issue will also be affected.

Subject to that, it is indeed acceptable to have a generic graphic for special goods until a more sophisticated solution can be implemented, as this is better than either not implementing this patch at all, or having symbols for everything but special goods.

Does this mean a new symbol dedicated to special goods, not a ware symbol (the current dark brown pile)?
I do not come up with an icon that indicates special goods generically now.

[ACarlotti]

Is this change also useful for Standard?

[jamespetts]

However, currently, mail and passenger symbol are displayed on the left.
And the symbol display position of the vertical alignment becomes irregular.

Yes, I see that it is preferable to have it before the text in that dialogue. Does it have to be always before or always after the text, or can it (without excessive effort/time) be before the text in that dialogue and after the text in the depot dialogue? Or are you concerned that this might be too inconsistent? I should be grateful for people's views on that issue.

I don't think there are any objects that have and do not have images in the current simutrans, so I have a question whether it is possible.
And I'm sorry I have not made such things yet, so my skill issue will also be affected.

I am still a little confused - can you explain what you mean by "any objects that have and do not have images"? My apologies for not understanding.

Does this mean a new symbol dedicated to special goods, not a ware symbol (the current dark brown pile)?
I do not come up with an icon that indicates special goods generically now.

Yes, that is what I had in mind - the dark brown pile represents goods generally, so it might be better to have a separate symbol. However, there may be something to be said for using the generic goods symbol as a fallback in the case of any graphics for a specific type of goods being not defined so as to maximise pakset compatibility.

[Ranran]

Is this change also useful for Standard?

Maybe I think so. But that is only the basic part of this patch. It needs to be placed in the GUI by themselves. For example, there is no function to display goods categories at the top of the current standard's depot dialog.

Does it have to be always before or always after the text, or can it (without excessive effort/time) be before the text in that dialogue and after the text in the depot dialogue? Or are you concerned that this might be too inconsistent?

In most cases, it is necessary to embed symbol in the notepad format, in which case it is necessary to calculate the category name and the length of the character of the numelic value and place it behind. And every time that position is different. So it's easy to display left. It's always at the fixed place.

For example, considering that there are multiple categories in the case of (3a), I think it is easier to see on the left side.

"any objects that have and do not have images"?

I think the work is going well now.

there may be something to be said for using the generic goods symbol as a fallback in the case of any graphics for a specific type of goods being not defined so as to maximise pakset compatibility.

Display the image of category 0 first and display the dark brown pile if it has no image. But this is a temporary thing.

[prissi]

I wonder if these symbol scale properly with increasing font size? At least in standard, that will be a problem.

[Vladki]

How is the scaling done in standard? Are there multiple versions of pax/mail/goods icons? Should all std paksets have them?

[prissi]

In principle the icons could be scaled independently from the rest. At the moment they are not scaled at all.

[Leartin]

I rarely look at Extended Threads, but I want to say that I'd really, really appriciate those icons, especially for goods.

I don't think scaling should be an issue for them specifically - after all, it's an issue that would need to be solved anyway for other symbols (eg. pax, post, goods).

[jamespetts]

Normally, when something is to be incorporated into Standard in the near future, I generally defer incorporating it into Extended so that the version adopted in Standard can be implemented to avoid unnecessary differences between the two. If we are going to have this change, and I should very much like to see this, it might be helpful to have a patch for Standard, if Ranran would like to do it this way, and then for the version that is incorporated into Standard in due course to be backported to Extended.

Please let me know if there is any problem with doing it this way and, if so, we can think a little more about how to deal with this.

[Ranran]

Please let me know if there is any problem with doing it this way

I think there is no problem with it.

it might be helpful to have a patch for Standard, if Ranran would like to do it this way

However, unfortunately, I can not compile from the standard source. (´・ω・｀)
I put the library of miniupmp.
Are other required libraries different between standard and extended? 

Code: [Select]

1>image_reader.obj : error LNK2019: 未解決の外部シンボル _adler32 が関数 "public: virtual class obj_desc_t * __thiscall image_reader_t::read_node(struct _iobuf *,struct obj_node_info_t &)" (?read_node@image_reader_t@@UAEPAVobj_desc_t@@PAU_iobuf@@AAUobj_node_info_t@@@Z) で参照されました。
1>loadsave.obj : error LNK2019: 未解決の外部シンボル _gzread が関数 "private: unsigned int __thiscall loadsave_t::read(void *,unsigned int)" (?read@loadsave_t@@AAEIPAXI@Z) で参照されました。
1>loadsave.obj : error LNK2019: 未解決の外部シンボル _gzwrite が関数 "private: unsigned int __thiscall loadsave_t::write(void const *,unsigned int)" (?write@loadsave_t@@AAEIPBXI@Z) で参照されました。
1>loadsave.obj : error LNK2019: 未解決の外部シンボル _gzgets が関数 "public: bool __thiscall loadsave_t::rd_open(char const *)" (?rd_open@loadsave_t@@QAE_NPBD@Z) で参照されました。
1>loadsave.obj : error LNK2019: 未解決の外部シンボル _gzeof が関数 "public: bool __thiscall loadsave_t::is_eof(void)" (?is_eof@loadsave_t@@QAE_NXZ) で参照されました。
1>loadsave.obj : error LNK2019: 未解決の外部シンボル _gzclose が関数 "public: char const * __thiscall loadsave_t::close(void)" (?close@loadsave_t@@QAEPBDXZ) で参照されました。
1>loadsave.obj : error LNK2019: 未解決の外部シンボル _gzerror が関数 "public: char const * __thiscall loadsave_t::close(void)" (?close@loadsave_t@@QAEPBDXZ) で参照されました。
1>simsys.obj : error LNK2019: 未解決の外部シンボル _gzopen_w が関数 "struct gzFile_s * __cdecl dr_gzopen(char const *,char const *)" (?dr_gzopen@@YAPAUgzFile_s@@PBD0@Z) で参照されました。


EDIT:
I spent much time solving it but I can not compile the standard code, so others will need to carry it out.