[Tutorial] Menus and toolbars

[Yona-TYT]

I have a problem with the menus that only happens with pak192.comic, and that is that during the tutorial some icons should be hidden but for some reason that is not true here.

I have been researching how the tool and menu bars work and I have found a "tool" identified with "0xfffff" that represents a decorative icon, this seems to be the problem.

With "0xfffff":


Without "0xfffff"



This menu does not have an identifier for waytype (wt), so adding that parameter, at least in theory, would solve the problem.

Can we try it? You would have to modify the dat files of the respective decorations for tools: roads, rails, airplanes...

Edit.
The signal menus seem to be broken in the version I have. Where can I get a night version?.

[Leartin]

This menu does not have an identifier for waytype (wt), so adding that parameter, at least in theory, would solve the problem.

Can we try it? You would have to modify the dat files of the respective decorations for tools: roads, rails, airplanes...

Those spacers don't refer to any actual object. They only refer to the icon object, which has no knowledge about waytypes. Therefore, no dat exists that could be modified.

Plus, how are these the problem? At worst, they are some unclickable empty things alongside the icons you need to click, I don't see the harm in that.

What seems to cause an issue compared to other paksets is our choice to refer to objects directly, rather than to refer to them by type. This is seen with the signals - I assume in other paksets, you can remove all signals from the menu in one go, since they are all one line in the menu dat, while p192c requires more work?



Can't check what's off about the signal submenus atm.
Edit: Or do you mean the visual issue with the spacer in front? That's fixed, but has no functional consequence.

[Yona-TYT]

Those spacers don't refer to any actual object. They only refer to the icon object, which has no knowledge about waytypes. Therefore, no dat exists that could be modified.

Plus, how are these the problem? At worst, they are some unclickable empty things alongside the icons you need to click, I don't see the harm in that.

The purpose of hiding some menus and tools is to avoid overwhelming new players with a bunch of icons, so I just want to slowly show only the ones that are going to be used at that moment.

The script does this using a tool id and waytype, in the case of similar tools (way_road and way_rail) they can only be differentiated with the waytype.

I was also trying to understand how the mechanism that allows obtaining these parameters in the simutrans code works, but it is very confusing and I barely understand any of the code.

What seems to cause an issue compared to other paksets is our choice to refer to objects directly, rather than to refer to them by type. This is seen with the signals - I assume in other paksets, you can remove all signals from the menu in one go, since they are all one line in the menu dat, while p192c requires more work?

Can't check what's off about the signal submenus atm.
Edit: Or do you mean the visual issue with the spacer in front? That's fixed, but has no functional consequence.

The sign icons are filtered by waytype as well, so if the script cannot obtain it it will not be able to differentiate a road sign from a train sign for example.

[Yona-TYT]

I did a complete review of the menus since in the case of pak192.comic it was different from the other paksets.

The menus and tools now look simpler and it is easier to know what to do for a novice player.

I also fixed some errors in chapter 3 while reviewing the menus.

The train signals should work fine now, but there may be something wrong, please let me know if you find anything wrong.



https://github.com/simutrans/tutorial_pak192.comic/commit/6ebaa08ece8ceb69db9e8807b5fb0a969a6d7d03

[Leartin]

The purpose of hiding some menus and tools is to avoid overwhelming new players with a bunch of icons

Absolutely, get rid of all that's not needed.
However, that's only the case for actual icons. The spacers are part of the GUI design, especially the start and the end of the menu, which also take part in identifying which menu you interact with. There role is similar to the title bar, except they do a better job.
In fact, the screenshot in your last post is even worse, since you somehow removed the backgrounds, which include the color coding of the menu. Makes it so much harder to know whether it's regular gauge or narrow gauge.

This is especially true for reduced menus. Yes, the player should be able to find the depot button, and reducing the total amount of icons helps. But if there is nothing but the depot button left, you don't actually teach the player that it's in the menu anymore, you just present them with a floating icon and at best may hope they remember what it looks like.

(I'd also argue: If the player can't tell apart spacers and clickable buttons, it's an issue on the visual design. But I think that's pretty clear, if anything the submenu icons don't look clickable enough (Hi, Dani), which is okay as they are not needed to play.)

The script does this using a tool id and waytype, in the case of similar tools (way_road and way_rail) they can only be differentiated with the waytype.

The signals in the track, ng and tram menu are defined like this:

Code Select Expand

toolbar[5][9]=general_tool[20],113,,track_signalThere is no waytype, but rather a reference to an object by name, which already knows the waytype. In contrast, the signal-submenu works like this:

Code Select Expand

toolbar[18][1]=signs(8)which is the same as other paksets.

This is something baked into p192c now, we won't get rid of it. More likely that we'd do the same trick with more stuff like stations next.
So either the scripting has an option to remove specific objects from the menu and removes them individually, or you consider it a bug that a script to remove all signals of waytype 8 does not remove signals of waytype 8 added by direct reference, and ask DWachs to fix it. (or expand functionality if you won't call it a bug)


As for the tracks, it's similar, but not exactly the same. Here, we just gave all ways we wanted in the main menu the subtype 69, which has no functional meaning. I'd assume scripting can deal with subtypes though, and you just didn't check the p192c menuconf to find out about the subtype 69? (tbh I forget about it too, since that trick only works with ways)

[Yona-TYT]

Absolutely, get rid of all that's not needed.
However, that's only the case for actual icons. The spacers are part of the GUI design, especially the start and the end of the menu, which also take part in identifying which menu you interact with. There role is similar to the title bar, except they do a better job.
In fact, the screenshot in your last post is even worse, since you somehow removed the backgrounds, which include the color coding of the menu. Makes it so much harder to know whether it's regular gauge or narrow gauge.

The internal workings of this mechanism should remove the icons from the toolbar if it no longer has submenus available (as in the image below) however it seems that the decoration does not allow the submenu to remain empty and therefore the icon The one on the menu does not disappear.

The signals in the track, ng and tram menu are defined like this:
Code Select
toolbar[5][9]=general_tool[20],113,,track_signal
There is no waytype, but rather a reference to an object by name, which already knows the waytype. In contrast, the signal-submenu works like this:
Code Select
toolbar[18][1]=signs(
which is the same as other paksets.

This is something baked into p192c now, we won't get rid of it. More likely that we'd do the same trick with more stuff like stations next.
So either the scripting has an option to remove specific objects from the menu and removes them individually, or you consider it a bug that a script to remove all signals of waytype 8 does not remove signals of waytype 8 added by direct reference, and ask DWachs to fix it. (or expand functionality if you won't call it a bug)

There may be something missing in the signals that prevents them from being filtered by the API, this does not occur pak128.

The following line of code filter to 4 waytype:

Code Select Expand

if(wt ==wt_tram || wt == wt_rail || wt == 8 || wt == wt_monorail ) return false
This is what the result looks like in pak192.comic



And in pak128 there is no signal in sight (Only the Railroad Tools icon remains)

As for the tracks, it's similar, but not exactly the same. Here, we just gave all ways we wanted in the main menu the subtype 69, which has no functional meaning. I'd assume scripting can deal with subtypes though, and you just didn't check the p192c menuconf to find out about the subtype 69? (tbh I forget about it too, since that trick only works with ways)

I think this parameter is not processed from the scripts and I'm afraid I don't understand it very well.




Edit.

I made this script especially for testing.
test-tools.zip

[prissi]

As a tutorial is for learning the real game, I am not sure removing everything from a menu is good. Because the menu in the game will never look like that.

[Yona-TYT]

As a tutorial is for learning the real game, I am not sure removing everything from a menu is good. Because the menu in the game will never look like that.

If we could implement something that highlights the tool(s) that will be used at a given time then there would no longer be any confusion with the tools that would be evident to the eye.

For example, in other games I have seen that in the tutorial the tool that needs to be used will be intermittent (it appears and disappears until it is clicked) and it becomes obvious to the player.

I would really like to be able to understand how these mechanisms that control the menus in the internal code of simutras work, so I could contribute with some solutions. 



 Now I understand, 69 is a system_type, but for some reason it doesn't have a constant defined where it should.

Code Select Expand

/**
 * System types for ways
 */
enum systemtype_t {
type_flat     = 0,   ///< flat track
type_elevated = 1,   ///< flag for elevated ways
type_runway   = 1,   ///< flag for runway (only aircrafts)
type_tram     = 7,   ///< tram track (waytype = track_wt)
type_river    = 255, ///< flag for river
type_all      = 255  ///< special ?
};

[Leartin]

69 is a system_type, but for some reason it doesn't have a constant defined

The reason is that the game does not use it. You can define any number from 0 to 255, the game does not care and does not treat them any different, except for 1, 7 and 255 (and I'm not sure 255 does anything either)
69 has no significance to the game, it was chosen by the pakset. We chose 69 to avoid future system-types to interfere, as you'd typically choose low numbers (3, 5) round numbers (100, 200) or base 2 round numbers (64, 128) and if you are silly enough to pick a joke number like us, you'd go for 42 first.

As a tutorial is for learning the real game, I am not sure removing everything from a menu is good. Because the menu in the game will never look like that.

Exactly, players will lack the context. It's fine to reduce the menus making it easier to find stuff, but if you'd need to remove all other waytypes in order for the player to find the road tools, it's a serious issue of icon readability.
I still see no harm in having all toolbars available despite containing no clickable icons. Players can't go wrong and accidentially build an airport, they have no options, but they need to actually look at the icons. Frankly, if you are told to build stations on the road and you unironically click on the icon with a boat, a train or a zeppelin instead of the truck, Simutrans might be too hard for you.

[Yona-TYT]

Great, now that we have this ADD new function is_tool_active, we can do better things here.


I would like, for example, in chapter 2:

- It starts showing only the road tools, then the depot tool but leaving the previous one shadowed and so on.

What do you think ?.

[Flemmbrav]

fancy!

[prissi]

I think you should not hide any tool. Skripts should not mess with the menu as it is now consistently updated. Show everything, just disable the tools with the new function.

Anyway, pak64 tutorial is not working at all.

[Yona-TYT]

The new function to darken menus is still being implemented:
https://github.com/simutrans/tutorial_pak192.comic/commit/3e4ee389fa6880fecacd38b610059e2976d685f0