[ZS] libtooltipmenu 0.2.4 -- add tooltips to your MENUDEF

[ToxicFrog]

This is a simple one-file ZScript library that lets you easily add tooltips to your menus. I wrote it because I wanted something nicer than filling a menu with StaticText to explain all the options.

Features:

• Drop-in replacement for OptionMenu and ListMenu
• MENUDEF support for adding tooltips to static menus
• ZScript API for adding tooltips to dynamically generated menus
• Configurable position, size, font, and background for tooltips
• Full Print escape and LANGUAGE lump reference support

It's released under the MIT license, free to use for any purpose (including commercial and closed-source). Feel free to add it as a dependency, bundle the pk3 with your mod, or copy the zscript into your own codebase (but if you do, please rename the classes to avoid conflicts).

It is used by Corruption Cards, Satanic Gameshow Deluxe, and my own mods Gun Bonsai and Indestructable.

---

View the Documentation
Download the PK3
Browse the Source
Example uses here (simple) and here (more complicated).

---

[ToxicFrog]

Released 0.1.2. This fixes a rendering bug and is backwards compatible with 0.1.1.

[ToxicFrog]

Released 0.1.3. This fixes an intermittent crash when opening the menu.

[ToxicFrog]

This adds automatic tooltip text scaling based on resolution, along with the ability to override that scaling in the MENUDEF.

[ToxicFrog]

This fixes a bug where using localized strings in tooltips ruined everything. Bug found & fixed by idiotbitz on github.

Download here.

[MFG38]

Cool stuff, put this into my own gameplay mod and it works like a charm. I'm curious about something, though - my initial thought was to make a custom SkillMenu with tooltips using this, but that plan sort of flew out the window for the time being when I found out that classes to be used in ListMenu-based menus need to inherit from ListMenu. Bearing that in mind, how difficult would it be to adapt this for ListMenus? Would it be as simple as replacing all instances of OptionMenu with ListMenu in the code or would it be a more involved process?

[ToxicFrog]

It might be! I have some upgrades I want to make to this to support improvements to my other mods (in particular, dynamic tooltip creation at runtime), and while I'm at that I can experiment with ListMenu support -- or you can try it and submit a patch if it works, and I'll include it in the next release.

E: after testing, yes, it is that simple, I'm going to do some tidying and then release 0.2.2 with ListMenu support.

[ToxicFrog]

Released 0.2.2! It adds ListMenu support and a better API for adding tooltips to dynamic menus. You can download it from the link in the OP.

[ToxicFrog]

Bugfix release: 0.2.3

This fixes an inconsistency between the MENUDEF API and the dynamic menu construction API.

[ToxicFrog]

Updated the OP to list known mods using this library -- if you know of others please let me know

[generic name guy]

Having this in the main menu screws up the textitem that is selected automatically, so if NewGame is the first one, it'll select LoadGame, any idea on what is happening?

[ToxicFrog]

I don't, and I've never experimented with using this on the main menu -- do you have example code I could poke at?

[generic name guy]

I don't, and I've never experimented with using this on the main menu -- do you have example code I could poke at?

Yes, some old code from the PB menu overhaul i was tinkering around with, i could send it your way once i find it on my computer.

And i'm pretty sure it doesn't only happen with main menus, it happens with any menu that has a non-selectable item at the top, like a statictext or staticpatch.

[ToxicFrog]

I think I see what's going on -- tooltip setup happens after Init(), which means after the initial mSelectedItem is determined. However, as part of tooltip setup, it deletes MenuItems that represent tooltips or tooltip configuration data. So right after Init() returns, the menu structure looks like this:

Code: Select all

[0] TooltipGeometry
[1] TooltipAppearance
[2] StaticText
[3] Option  <- mSelectedItem = 3
[4] Tooltip
[5] Option
[6] Tooltip
[7] Option
[8] Tooltip

but by the time the menu actually displays, the tooltip processor has extracted all those tooltip pseudo-items into its own internal data structures and boiled things down to the real menu:

Code: Select all

[0] StaticText
[1] Option
[2] Option
[3] Option <- mSelectedItem = 3

which means that mSelectedItem now points further down in the menu than it should. Depending on the menu, this can result in it pointing to the wrong item, or to a non-selectable item, or to an invisible item off to the side of the screen -- the possibilities are endless!

I should have a fix out later today; it's just a matter of saving the MenuItem that mSelectedItem points to before beginning tooltip processing, and afterwards, trying to find it again in the list of menu items.

[ToxicFrog]

Fixed. I think.