Usage of compiletime structures in TooltipGenerator resulted in unused data in war3map.j

[rolandc85]

@compiletime function createFeedback()
let tgen = new LotsAbilityTooltipGenerator("Burns an opponent's mana on each attack, dealing mana burned as damage to the target.", Targettype.PASSIVE)
new AbilityDefinitionFeedback(FEEDBACK_ABIL_ID)
..registerTooltipGenerator(tgen)
..tooltipStartListen()
..preset("Feedback", Hotkey.E)
..addTooltipProperty("Mana Burned per Hit", (int lvl) -> (MANA_DRAINED_PER_LVL * lvl).toString())
..tooltipStopListen() //endoftooltip

In this case, the "Mana Burned per Hit" is used for tooltip generation. After which, during compile time, it is stored in a

private var propMap = new IterableMap<string, StringLevelClosure>

The tooltip generator was like the one in this thread

https://www.hiveworkshop.com/threads/wurst-ability-tooltip-generator.253389/

I notice that in the war3map.j

The string was initialised like this.

call SaveStr(cS,2,523856396,"Mana Burned per Hit")

However, this string is not required at all. It's only used for generating the tooltip for the ability. Will the -opt flag be able check if 523856396 is not accessed, then exclude it from the compiled script.

Just to add, I have also made attempts to destroy the propMap after using it but to no avail.

[peq]

@Frotty I guess we need to remove the compiletime support from the StdLib Hastables again (and provide different data structures for transferring values.

[Frotty]

I think the migration should not be the default, tbh.
Do you propose a specific class that has to be used, or what?

[peq]

The problem is the static hashtable. Is the number of hashtables still so limited that we need this optimization? If it was a normal field, Wurst could figure out which hashtables to transfer.