Yea man once Patch 1.31 went from PTR to Live all the stuff in this map just became green squares on the screen. I don’t know but I just stopped caring about the system and never looked back. I’d be hard pressed to make the demo run again.
Suffice it to say that while I worked to build this system, everything I used along the way was a total letdown on the part of Blizzard and the APIs that they added. I mean, I don’t support people hating Reforged just to hate like most of the community turned to but I’m just telling you this honestly from trying to build this system.
My first theory was that I would begin the system by querying the constant number of item slots a hero had specified in the editor. Shift enter allows you to enter a number larger than 6, so by the end you could enter 7 or 8 and my system would see it and block out the other slots with the slot filler image.
To make this work my theory was that I would use BlzGetUnitAbilityByIndex and then on each ability test the constant with a name like ABILITY_ILF_ITEM_CAPACITY for a nonzero value. But I was frustrated by failure. When iterating over the abilities that a unit has, you cannot test for “is it an inventory ability” and on non inventory abilities this constant for item capacity returns nonzero bogus values. For example, in this map the Peasant and Town Hall have 1 inventory slot because these queries return 1 for Call to Arms or something. I forget the details. Suffice it to say that there is not anything offered by the API to filter out those false positives.
My next theory after this was to iterate from 1 to N for the number of slots and draw the inventory item. The whole system is a facade made by square images spawned by the UI natives. So the hero only holds one item at a time. Whenever your mouse enters a square are that contains an item image, the hero’s 1 actual item from the legacy 6 slot system is dropped and swapped for the synthetically stored item in the slot you mouse over. Then, the 1 slot that I use from the original system is moved with BlzFrameSetPoints or whatever to be positioned on top of the synthetic UI frame for that item. That way, when you click that real item slot, you get the real mouse behaviors such as the option to drop it. Watch the video again. You will notice points where, if my mouse is carrying an item with the built in system, it goes away if I mouse over a different item square. This same issue occurs and interrupts the Lich’s order to drop an orb near the end. I tell him to drop an orb then mouse over a different item, and he loses the command to drop it. That’s because his underlying 6 slot builtin inventory changes it’s current “real” item to the one that I mused over. At that time, the Lich no longer “has the item” to drop at all. So he just stops and I have to tell him to do it again.
Once I developed all of that theres also the question you’re probably wondering, how was the Lich able to hold 9 orbs and actually gain damage bonus 9 times. I wanted to use BlzGetItemAbilityByIndex and query all the abilities the item had. However this native does not work unless a unit is holding the item, and furthermore cannot give you the integer rawcode of the item’s ability. This was garbage to me. So, instead, I made a giant hashtable for every single item that stored what abilities it was supposed to have in the editor. I did this with an external computer program that I built, which loaded the data from the game and from my map and then dumped out a gigantic JASS file that assigned the value to the table for every ability. That is the depths of how frustrated I was by BlzGetItemAbilityByIndex and how it failed to give me an integer rawcode.
And that’s how this system was made. A facade made from buggy parts stapled together that would probably never work in a production map where you don’t want bugs. Furthermore, I never tested multiplayer but I’m almost certain the way it swaps out hero items and abilities based on mousing over rectangles would cause a desync.
