InitHashtable

So I looked into the upcoming patch (1.23b) and I'm reasonably enthusiastic about the new natives that are being added. Pretty much any map that I've ever played should be able to convert from their current attachment method to use the new hashtable data type with incredible ease. It will almost indubitably be faster and cleaner than the CSData attachment system that I've become fond of, although I doubt it will be faster than using structs from vJASS.

I'd like to point out, however, that this new patch will not disable any vJASS functionality, as vJASS is simply a programmer-end tool that allows someone to write in an object oriented fashion instead of getting elbow-deep in array call funk. It converts all code you write into JASS and the only way that a patch could actually stop vJASS from functioning is disallowing global variable/array declarations (not going to happen), taking up one of the generated function names that vJASS uses with natives (not going to happen and easy to fix), or change the way TriggerEvaluate and TriggerExecute work to somehow stop some of the function-as-object convenience that vJASS provides (I've never used this feature of vJASS but I've use the same methodology to attach functions to instances of projectiles)

Basically you'll probably need a new version of NewGen to program vJASS comfortably after the patch. If you don't understand much of what I've said, but you program in vJASS, I would highly recommend writing some code with vJASS features, saving the map, extracting the war3map.j file from the map and reading it in a text editor (JassCraft works well) to see what happens behind the scenes. It is quite enlightening.

Edit: Also, they have added a few new data types in the common.j file that fill me with hope, such as the "event" data type, which is a reference to a trigger event registration. This could mean that trigger events could be possibly unregistered, and this would allow damage detection systems to work in a manner that isn't pathetic.

That's awesome, it sounds like this patch has no downsides at all and multiple upsides. When is it coming out? Also, will damage detection really be more viable after this? There are a couple of different maps that I know of which have a hard time tracking units attack and how much damage they deal not to mention damage dealt by spells. I'm sure there are other good things too if it's as awesome as it sounds.

Yeah, damage detection would be much more viable if they allow trigger events to be unregistered. The main problem currently is that you have to register a separate event for each unit, then when the unit dies, the event is still attached to the trigger and you have no way to remove it.

This results in leakage that can only really be solved by tracking every unit on the map and which trigger their event is attached to, and when a trigger is empty, destroy it and create a new one, and have a rotation type system, which is messy at best.

So after the patch you might not have to deal with all of that and just kill the event after the unit dies. Sadly, there probably won't be an event response for damage type and all that, so you'd need some alternative detection system, like a dummy unit being the source for all spell damage from a player, so you can tell the difference between attacks and spells.

You are correct though, it appears to be all good news.

Edit: Actually "event" might not be new, haha, I was distracted by the "agent" thing (They made a new data type that extends handle and changed what a lot of other data types that used to be extending handle to extending agent). But hopes are still high otherwise, I'm not sure why they would ever have an event data type with no natives that actually take it as an argument. I hope that explains my misinterpretation. It's like allowing numbers with no operators like addition, subtraction and so on.

actually to my knowledge it fixes a bug that quite a few mappers, like icefrog and dreamraider use. Here is a quote

DreamRaider wrote:

Allow me to explain this... as you know there has beena warcraft exploit around for a long ass time that can basically spread viruses easily by maps. This is due to things such the Return Bug. The return bug is a warcraft exploit used by many mappers (Including me, shini, icefrog) that made their maps even possible. However blizzard annouced their next patch (Currently in westfall server) that they will remove this exploit for a permanent fix the virus exploit inexchange it will remove the return bug.

Long story short, many many many mapmakers who use jass or vjass will either have to recode their maps in order to be compatible with the patch otherwise it cannot be played.

My plan currently is to use this new patch and get my stuff done using it before it becomes official, otherwise it will be IMPOSSIBLE to continue to mapmake. In the upside, there are some new stuff that can help us alot however the cost is far too great.

For those who have no clue what i said above, i will phrase it like this. SW cannot be released until the 1.23b+ patch is complete, until then it will have to be tested on westfall server. I have to do this cuz NVB and SW uses the return bug and i don't have a choice really....

Yeah, the only reason they use the bug is to convert a unit, timer, or other handle to a handle index to attach other data structures to it using an array. The new native GetHandleId does exactly that. Updating from the bug to the new native is as simple as find and replace. Updating from an array based data structure attachment systems to hashtables is also fairly simple, but will require a little more thinking on the part of the map maker.

Long story short, complaining about having to find and replace H2I with GetHandleId makes that guy sound awfully amateurish.

Actually, all you will do is change your:

Code:

function H2I takes handle h returns integer
    return h
    return 0
endfunction

to:

Code:

function H2I takes handle h returns integer
    return GetHandleId( h )
endfunction

No need to find and replace. Besides, if you're using a recent vJass Pack, it would inline the single line function anyways, so it would be the same as find/replace without all the work.

True, I forgot about the function inline feature. Without that though all the extra function calls would be bad, but with it there's just the extra junk code, which I personally could live with, haha.

Very good catch.

Code:

GetHandleId takes handle h returns integer
    return h
    return 0
endfunction

Best current fix/test available, IMO.