Do you have a way of implementing several of your hero concepts into one map? For example when I try to have both Kael'thas and Archimonde, it gives me errors such as textmacros being redeclared and unable to find spell clone.
Trivia #9: Collision Size In Attack Range - the significant role of collision sizes within an attack range plays within both of the units (an attacker and an attacked). They're included within computation to launch an attack regardless of attack range values. So a unit that's having 1024 for example (a maxed out collision size value in Object Editor) is able to simulate an attack or be attacked within its collision size with or without considering the attack ranges of both unit involved in this event, an attacker's & attacked's collision sizes are computed within from it: let's say both having 1024 collision sizes may able to double extend the range without their attack range values are being manipulated. However, can't claim how much further functions/computations work with this yet as only simple experimentation has been done as of now regarding it.
Trivia #8: KillUnit Fails - KillUnit() to a normal unit that's having Phoenix Morphing (Egg Related) or 'Aphx' ability during its morphing time will only cause a bug that makes the expiration timer of an alternate unit to be stucked forever and therefore not killing the unit instead.
Trivia #7: Disowned Team Color - a model that is newly created on the unit doesn't inherit the actual team color of the unit is using. The models created via 'AddSpecialEffect...()' functions would be defaulted to use a team color of red instead. This already claims not all of the unit's properties are inherited by the model attached to a unit instantly without being preset in Object Editor via model path/file. As workarounds, SetUnitColor() wouldn't work if preceded by model creation so it should be only set after AddSpecialEffectTarget() native is done, this makes the model adjust of its team color based on a unit properly just like how it inherits the other properties. Note that there's also similar special effect natives (set color/playercolor of an effect) that can be manipulated regardless if the model is whether attached or not, which supports this claim.
Kael'thas Spellpack will be deployed to my private beta tester tomorrow. After a feedback, public release version should be on its way. I'm excited and nervous at the same time about this. Nervous as I think it's a bit of a rushed due to my inactivity. Excited as I'm confident enough to release it. I'm in luck to have my available time to finish it. After that, I'll be inactive/dormant again, but it doesn't mean I will abandon and leave the advocacy here. There's more content of mine to come ahead and to be worked upon even a real-life obligation distracts me. As I've anticipated them all to be published/released here as long my creativity lives.
Trivia #6: GetHandleId - works even if the handle is destroyed or removed in-game as long that handle is referenced. For units, this indicates that it's safer than GetUnitUserData. If a script manages to use GetUnitUserData/SetUnitUserData to retrieve a unit data that is removed for an instance, it will break the indexes. As the function would be zeroed at that time thus the index will not be recycled properly for that unit. That's where GetHandleId is superior enough. A map that is intensive when it comes to unit's deaths or explosions, and removals are prone to this risk.
Trivia #5: Moving/Rotating Structure - SetUnitX/Y & SetUnitFacing do malfunction to structures, as obviously they have 0 movement speed. Turn rate only comes to play if the unit's movement speed is >= 1, even the structure having a non-zero movement speed value, SetUnitX/Y would still bug their shadows and tilesets. A proper way to achieve this is to use SetUnitPosition(). If you're intending to move it periodically then make sure the offset value is higher than its pathing map collision as SetUnitPosition() cares for the path the unit moves in. About rotating them, just don't forget to use: SetUnitPosition( structure,GetUnitX(structure),GetUnitY(structure) ) before SetUnitFacing() function. Remember that this simulates instant-facing not considering a turn rate because there's no 'actual' turn rate in move speed 0.
Trivia #4: None Movement Type - this movement type enables your unit to phase: ignoring all kinds of pathing while maintaining its actual collision. However, it can only be set through Object Editor movement fields. Fortunately, you shouldn't worry because SetUnitPathing() is there to achieve this type of movement. If you want your unit to be walkable through then use a trick with 'Windwalk' or 'Ghost'.
Trivia #3: 0 Movement Speed - this movement speed value is what I considered special. Aside from disabling unit's UI movements and causes certain 'set' functions to malfunction. These malfunctions could be useful. SetUnitX/Y leaves the model of the unit to its place while the unit is being moved. The model is only visible for the player's camera if perceives the moved unit. It can be used as illusion to trick players for puzzles, missions, and such. SetUnitFlyHeight can be used to hide the health/mana bar or such player/hero names information hovering above the unit while maintaining to be selectable. Of course, not considerable if the unit's aim to be interactable as the units will also launch the attacks/spells on air even if the model is visually on ground. SetUnitFacing can be used to simulate 'instant-facing' in conjunction with SetUnitPosition: executing SetUnitPosition before SetUnitFacing would work on a unit's movement speed of 0. (As SetUnitPosition functions ignore movement)
Trivia #2: Custom Move Speed - SetUnitMoveSpeed is more peculiar than SetUnitFlyHeight, altering a movement speed of unit via SetUnitMoveSpeed function to 0 would always return 1 value. GetUnitMoveSpeed would return 1 from that unit. GetUnitDefaultMoveSpeed would always return the value derived from the Object Editor. SetUnitMoveSpeed determines its cap value via Gameplay Constants. Gameplay Constants minimum movement speed cap should be 1 and not 0. The zero value is reserved to shutdown unit's UI movements, and causes certain 'set' functions like: SetUnitX/Y, SetUnitMoveSpeed, SetUnitFacing, SetUnitFlyHeight to malfunction obviously as they require movement speed of >= 1. This zero value is only available to be set via Object Editor on the unit's movement field. Unfortunately, you can't use 0.00010 trick or something to obtain the zero value via SetUnitMoveSpeed. Up to this date, solution is nowhere to be found to overcome this limit.
Trivia #1: Custom Fly Height - altering a fly height of unit via SetUnitFlyHeight function to 0 would always return 0.010 value. Thus, GetUnitFlyHeight would return 0.010 from that unit. GetUnitDefaultFlyHeight would always return the normal height value which would cause mismatch if comparing reals GetUnitFlyHeight == GetUnitDefaultFlyHeight. Unfortunately, put 0.000 is also the same thing regardless how many zeroes you're trying to put in its parameter. Luckily, we can use 0.00010 value to normalize this. In conjunction with GetUnitDefaultFlyHeight so: call SetUnitFlyHeight(unit,0.00010 + GetUnitDefaultFlyHeight(unit),0) should resolve this.
In the middle of my work with Jaina Spellpack, it turns out that you can only put aura abilities on a militia unit. This also breaks the notorious pause-method (infinite channel) that I've been using as always on my resources. Now to cover this up, I'm forced to do some band-aids (though this is an internal problem, which means unfixable) but with this term band-aid: I can guarantee that the pause method will adapt if the infinite channel don't work on a certain unit. Considering militias are not the only problem here... silenced, polymorphed, sleeping units also break this method. It would only require optional object data to achieve this though (for just being practical)