[vJASS] BlzSetAbilityExtendedTooltip not working or me?

[Pinzu]

Can someone help me find what's wrong here (scroll down): Spell Based Menu System

The method showWindow takes in a pid which is increased by 1 to get the corresponding ability level to match the player. That tooltip is then changed to what is inside the button in the menu at that position.

Everything works fine for player red, but for player blue most buttons don't get any tooltip changes.

I've been beating my head against a wall over this for quite some time and am at a loss over whats going foul here.

The relevant parts of the code relates to showWindow() and maybe onInit.

So my question is what am I doing wrong or is this BlzSetAbilityExtendedTooltip native not working properly (doubt that).

 

[Pyrogasm]

Is it the same tooltips not getting updated every time, or is it random in any capacity? What about if you use player 3, 4, 5...? If you get different tooltips that don't update for different players it's probably something to do with wherever you're using variables based on PlayerID. If it's the same tooltips that don't function then your logic/math might have something hardcoded into it that only works for Player 1 but is funky for everyone else. Based on the screenshot vs. debug data I'd say it's an issue with the new natives, though.

 

[disruptive_]

My first visceral guess is this, as i did this exact thing (1.29 version) but less systmatic:
The ability must have multiple levels equal to the last index of the last player. I would suggest doing a custom player index, because if ie. the last player available is player maroon (12?) then each ability will need to have 13 levels. BlzSetAbilityExtendedTooltip last field is precisely the level of the ability.
For player red (Player(0)), the level 1 is updated ("pid + 1"). For player blue (Player(1)), the level 2 is updated. Obviously nothing will happen if the ability doesn't have level 2 or above.

I remember that GetLocalPlayer will function on string edits well too (another method for achieving what you want in MPI fashion). A trigger that detects the current selected unit of a given player could extend this method to MUI, not sure if flawlessly tho.

 

[Pinzu]

...

Let it not be so <_<

...

- For player 2 it's 7, 9, 11 and 18, 20, 22 (same spellss at the same position each time), for player 3 it's the same deal.
- For player 23 7, 9 and 11 instead don't even show the hotkey, which it previously did.
- All spells have 24 level and yeah it's PID +1. Though slot 24 was never tested so it shouldn't be the issue here (?)
- I'm not looking to make it MUI as there is not much point in it from my perspective. But it's worth considering at least.

I might have found whats wrong with the native! If the default tooltip is blank at that level and you set it to be changed no changes will happen. If however, the default tooltip has a string then the changes will be accepted (need to test this some more though).

 

[TriggerHappy]

Someone reported BlzSetAbilityResearchExtendedTooltip was having issues, maybe it's related to that.

[Feedback] Compiled List of 1.30 / 1.29 Bugs & Issues

 

[Pinzu]

Someone reported BlzSetAbilityResearchExtendedTooltip was having issues, maybe it's related to that.

[Feedback] Compiled List of 1.30 / 1.29 Bugs & Issues

Ye, think it has to do with empty default strings for a given tooltip being null. though not sure. Okay this fixed the problem so it's all but confirmed officially now.

 

[TriggerHappy]

Ye, think it has to do with empty default strings for a given tooltip being null. though not sure. Okay this fixed the problem so it's all but confirmed officially now.

Ah yeah you can't modify tooltips which have no default value in the object editor.

 

[Pinzu]

If only one could manipulate icons in the same way, then this would be really cool, as of right now this feature would require 12*24 abilities to be made. But this could be reduced if they were shareable between players and all weren't used at the same time.

 

[disruptive_]

GetLocalPlayer block + BlzSetAbilityIcon desyncs or doesn't work?

 

[Pinzu]

GetLocalPlayer block + BlzSetAbilityIcon desyncs or doesn't work?

My bet is on desync as more than one code section handles the same ability, but Im not sure.

 

[disruptive_]

I don't have access to my personal laptop right now.
My bet is that it doesn't desync. The analogy would be the standart method for hiding special effects for some players, since the icon parameter is a string.
It could desync if you make a comparisson, like "if GetAbilityIcon(...) == "somepath" and you already changed the icon path for multiple players, or maybe it will not even desync depending on the operation. If in this block you ie. remove a unit, my bet is a desync.
If you make the test, it will be an excellent step stone for the current mod scene i guess.

Also see this, regarding icons path of items (works): Introducing MultiNaming: Hiding Inventory of Enemies & More

 

[Pinzu]

My bet is that it doesn't desync. The analogy would be the standart method for hiding special effects for some players, since the icon parameter is a string.
I could desync if you make a comparisson, like "if GetAbilityIcon(...) == "somepath" and you already changed the icon path for multiple players, or maybe it will not even desync.
If you make the test, it will be an excellent step stone for the current mod scene i guess.

Also see this, regarding icons path of items (works): Introducing MultiNaming: Hiding Inventory of Enemies & More

Many units have the same ability. With special effects, text tags the like it's not shared with anything. I'd want to hear from others what they think but it's worth a test.

 

[disruptive_]

It works for icon path of items (GetLocalPlayer block on SetItemIcon) as the post i presented shows. The item parameter is not even a item type id but a particular item, so it could be different from abilities (only an id is possible).
Special effects can't but be "shared", because GetLocalPlayer block plus "AddSpecialEffect..." functions could desync. The hiding method is precisely giving the targeted players a different string path, but i suppose you are aware of this.

 

[Pyrogasm]

I vote it won't desync. The analogy to locally changed fxpaths is solid and applicable.

 

[Pinzu]

Alright, alright I'll create a tentative versison real quick and then go back to bed. Shame on you for exciting me at this early hour disruptive_! :d

 

[disruptive_]

Don't take it as pressure. I get that pursuing somewhat nonsensical ventures is tiresome. Note that i'm just betting for the solution, i haven't tested it myself.
But i really thing you gave up to soon on the possibility of changing icons of abilities, something that is indeed useful, and nobody had tested it yet, atleast in the sense of a public conclusion so others can use a such feature.