• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

[vJASS] BlzSetAbilityExtendedTooltip not working or me?

Status
Not open for further replies.
Level 15
Joined
Nov 30, 2007
Messages
1,202
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).
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
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.
 
Level 8
Joined
Mar 19, 2017
Messages
248
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.
 
Level 15
Joined
Nov 30, 2007
Messages
1,202
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).
 
Last edited:
Level 15
Joined
Nov 30, 2007
Messages
1,202
Last edited:
Level 8
Joined
Mar 19, 2017
Messages
248
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
 
Last edited:
Level 15
Joined
Nov 30, 2007
Messages
1,202
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.
 
Level 8
Joined
Mar 19, 2017
Messages
248
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.
 
Level 8
Joined
Mar 19, 2017
Messages
248
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.
 
Status
Not open for further replies.
Top