Author Topic: defining explicit object in menuconfig without explicit image not possible?  (Read 3127 times)

0 Members and 1 Guest are viewing this topic.

Online Leartin

  • Devotee
  • *
  • Posts: 796
  • Total likes: 287
  • Helpful: 44
  • !!!!!This user was banned for double posting!!!!!
  • Languages: DE, EN
This might be intended or just not used, but it strikes me as strange, so I report it.

In the menuconfig it is possible to define the position of a single object, eg. like this:
Code: [Select]
toolbar[1][1]=general_tool[14],4,,dirt_roadthis works, and I am able to place a dirt_road with that configuration. However, even though the dirt_road has it's own icon, the following does not work:
Code: [Select]
toolbar[1][1]=general_tool[14],,,dirt_roadThe dirt_road is available at every time. When using another way, the icon was visible but the way not yet available, so you couldn't click on the icon. It worked fine once the way was available.

The desired effect would be for the toolbar to show the icon that comes with the object, only as long as the object is available, or show nothing at all if the named object could not be found.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8795
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
It only shows something different, if the icon is assigned to that tool explicitely. Otherwise it should not have an icon, if it is not available. I have to check for an error indeed.

Online Leartin

  • Devotee
  • *
  • Posts: 796
  • Total likes: 287
  • Helpful: 44
  • !!!!!This user was banned for double posting!!!!!
  • Languages: DE, EN
May I bump this? (I think it's forgotten...)

It's still as stated before
- either I do assign an icon in the menuconf, and it's always on the menu, but not clickable if the way is not available at the time
- or I do not assign an icon in the menuconf, and it's never on the menu, even if the time is right.

I'd think the intended behaviour is to show the icon only if the way is available, regardless whether an icon is assigned in the menuconf or not.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8795
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
The waybuilder does not know which way to build when the menu icon is generated as it does not know its argument yet (the icon is argument independent!). As such it cannot show a "correct" image. There is an internal tool generated by the waybuilder though.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4247
  • Total likes: 175
  • Helpful: 149
  • Languages: EN, DE, AT
Why not modify tool_build_way_t::get_icon to check for availability of the way object?
Parsley, sage, rosemary, and maggikraut.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8795
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
try r7697

Online Leartin

  • Devotee
  • *
  • Posts: 796
  • Total likes: 287
  • Helpful: 44
  • !!!!!This user was banned for double posting!!!!!
  • Languages: DE, EN
Prissi, thank you for taking the time to do that. Sadly, it only applies for ways.
While I used a way as an example in this thread, it really was just an example, and I hoped there would be a solution for all kinds of objects (bridges, tunnels, stations, signals, wayobjects, possibly even depot and extension buildings for consistency, even though these probably don't need it)

Looking at the code you used, wouldn't it be possible to remove the parts about trams and underground mode (except for stations) and apply it to the other kinds of objects? At least stations check for underground mode already anyway, so a get_icon function is already called, wouldn't it be sufficient to replace
Code: [Select]
if (besch == NULL) {
return IMG_LEER;
}
with the relevant parts of the other code:
Code: [Select]
image_id bild = icon;
if(  besch  ) {
if(  bild ==  IMG_LEER  ) {
bild = besch->get_cursor()->get_bild_nr(1);
}
if(  !besch->is_available( world()->get_timeline_year_month() )  ) {
return IMG_LEER;
}
}
(If I read it correctly, the first inner if gets the icon from the object so it can be displayed, while the second returns an empty image if the object is not available at the time.
If so, wouldn't it be marginally faster to swap position, so it would not even get the image if it isn't going to be displayed?)

-Sorry, I cannot program and it might be completely wrong.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8795
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Compared to the time actually drawing anything it will not matter.

And for any other object the code will have to be copied, as you noticed. I am travelling on MOnday, so I am not able to do this, but gladly accept patches on that.

Online Leartin

  • Devotee
  • *
  • Posts: 796
  • Total likes: 287
  • Helpful: 44
  • !!!!!This user was banned for double posting!!!!!
  • Languages: DE, EN
So this was one of the things I wanted to try for myself after I get a working compiling setup, since it seems like something doable via trial and error. But since I could not even get anything to run, would someone be so kind to do this for me please?

In case someone wonders what that is good for:
A) You could add more buildable elements to the base pakset if they would not clutter the menu. With this, we can choose precisely which elements, eg. which extension buildings or which signals are in the main railway menu, while the 'normal' way to define those elements in bunches would be put in purposefully cluttered sub-menus for advances players. One would only have one signal per type in the main menu, but via a sub menu you could still choose among various graphical representations for the same functionality. Therefore, those who seek functionality and those who seek beauty don't need to fight over what should be in a pakset.
B) Putting things that belong together together, even if they are different objects. One could combine a way, elevated way, tunnel portal and bridge with the same speed and design and have them together in the menu. Or even different ways that belong together stylistically, eg. all the harbour-ways in p96c.