Ability Preload Order erratics

[Zwiebelchen]

So, as you guys know; the order in which abilities get placed inside a spellbook is determined by the order in which the abilities are first initialized in ANY spellbook.


So if I put three abilities inside spellbook A: let's call them "P", "Q" and "R" at the beginning of the game, then create a second unit and attempt to add the spellbooks B, C and D to the unit (all spellbooks share the same order id), which all hold only one of these three spells, then the order in which they got added in spellbook A will be restored, no matter in what order I add the spellbooks B, C and D.

So far so good.

I used this trick to give dynamically learned abilities inside a spellbook fixed positions based on their hotkey layout.

Now here's the twist: this all works fine and perfect as long as the level of these abilities won't change. Suddenly, as soon as I level one of these abilities via SetUnitAbilityLevel beyond level 1, the abilities will be thrown out of order again and (in most cases) get pushed to the last free slot or even get pushed out of the command card if there isn't any more free slot.

This is ... bad ... I don't even have the slightest clue on how to workaround that issue. Even preloading the different levels via IncUnitAbilityLevel() in the same way I preloaded the abilities into the correct order doesn't seem to help.

 

[PurgeandFire]

What happens if you SetUnitAbilityLevel beyond level 1 for that ability, and then SetUnitAbilityLevel all abilities after it within the command card up and back down to their current level? This is assuming that the abilities always get pushed to the last free slot. If that doesn't always happen, then I guess this method wouldn't work.

 

[Zwiebelchen]

What happens if you SetUnitAbilityLevel beyond level 1 for that ability, and then SetUnitAbilityLevel all abilities after it within the command card up and back down to their current level? This is assuming that the abilities always get pushed to the last free slot. If that doesn't always happen, then I guess this method wouldn't work.

I did some more testing on this, and it seems that my original assumption was wrong. I tried that with a different ability also based on channel and it worked flawless with that.

After some more troubleshooting, I found out that the LUA script I used to generate the abilities fucked up the data fields that take a true integer argument instead of a string typecast:
'target type' and 'options'

Since these fields can not be entered via LUA normally (they cant be copy and pasted either), I used this trick to typecast to integer manually:
//! i makechange(current, "Ncl2", abilcount, string.char("1"))

It seems that this worked some time ... but not anymore, for a random reason. Maybe this is because I migrated to W10? I'm completely dumbfounded why it just stopped working.
The most interesting thing about this: it actually displays the correct thing in the OE. But it doesn't get recognized by the game until I manually retype the entry once.


EDIT: I'll try to compile this on my laptop that still has W8 later and see if it works there.

 

[Zwiebelchen]

Okay, I did further testing on this, tried two different versions of newgen and two different OS; result:

It's neither the OS nor Newgen that is the problem.
It is definitely string.char("1"). The value seems to get written properly for the Object editor to recognize, but somehow is not properly written into the map MPQ itself.

Anyone has an idea on how to fix this? Manually setting all these flags is not an option, unfortunately; that's just way too much work to do every time I save. :/

 

[Xonok]

Are you sure that it should be string.char("1") instead of string.char(1)?

 

[Zwiebelchen]

Are you sure that it should be string.char("1") instead of string.char(1)?

It doesn't matter; LUA automaticly typecasts to the correct input.

But just to go sure I tried both and both resulted in the same "problem":
It inputs the correct number, but when you actually try it ingame, the value is not considered as if it wasn't written into the ability data files.


I tried many alternatives now, like giving a hex input or using string.byte() or tostring() and tonumber().
All of them will write 48 if you use 0 as input. The only thing that prevents the OE from typecasting your input is string.char().

I also tried arithmetics (like 0-0) to try to trick the compiler, but it doesn't work.
This has been fucked up by blizzard, as channel is the only ability that has two true-integer input fields.


I'm out of ideas. I tried literally any trick in the LUA book to make this work, but the WE just refuses to go with it.


Did nobody try to use LUA to generate channel abilities before? Somehow I find it hard to believe that I'm the first person to ever have this problem.

 

[Xonok]

Channel abilities work perfectly fine for me. Maybe you just don't have the hotfix.

 

[Zwiebelchen]

Channel abilities work perfectly fine for me. Maybe you just don't have the hotfix.

... it was the hotfix.

Goddamnit. I really thought 2.0.7 had that integrated.


Anyway, you saved me A TON of work with that. I was already thinking about all kinds of horrible horrible workarounds...