TriggerRegisterDestDeathInRegionEvent

[Imp Midna]

Im currently writing a jass parser (to replace the syntax check of the world editor for performance sake), which starts off parsing the common.j and blizzard.j files (to gather functions, vars etc.)

Now, oddly, my program is giving me a syntax error in the blizzard.j. The bad function is this one:

function TriggerRegisterDestDeathInRegionEvent takes trigger trig, rect r returns event
    set bj_destInRegionDiesTrig = trig
    set bj_destInRegionDiesCount = 0
    call EnumDestructablesInRect(r, null, function RegisterDestDeathInRegionEnum)
    return trig
endfunction

This function seemingly manages to cast a trigger to an event, which is something one should not be capable of doing. Basically, if i copy and paste the function into my map script and rename it, the world editors very own parser will tell me that its not allowed.
Am i missing something, or is the blizzard.j just more powerful than what we can write?

 

[WaterKnight]

Which version is that? The latest looks like this:

function TriggerRegisterDestDeathInRegionEvent takes trigger trig, rect r returns nothing
    set bj_destInRegionDiesTrig = trig
    set bj_destInRegionDiesCount = 0
    call EnumDestructablesInRect(r, null, function RegisterDestDeathInRegionEnum)
endfunction

But yeah, I remember an incident like this before:

function GetDyingDestructable takes nothing returns destructable
    return GetTriggerWidget()
endfunction

was patched to

function GetDyingDestructable takes nothing returns destructable
    return GetTriggerDestructable()
endfunction

 

[Imp Midna]

Hm, i just googled for common.j and blizzard.j and pasted the first link it would spill out into a text file, assuming it would be the newest version (i mean, wc hasn't been updated for quite a while). The newest one (from my war3patch.mpq) really seems to have it fixed.

The GetDyingDestrucable thing was really brutal though. If this is a reoccurring issue, wouldn't that mean that we could basically reintroduce typecasts ala return bug if we managed to make our map load a modified blizzard.j? (e.g, by modify the warcraft 3 archives) Would certainly be awesome in many ways.

 

[WaterKnight]

The return bug can be simulated through SaveFogState. Anyway, besides fixing old maps, there should be almost no use to it.

 

[Imp Midna]

Might be useful. Like, you could save a handle into a units custom value or something. Or give a value as a timer parameter.
Problem is, the fog state bug does not allow you to do the awesome things that the return bug did. It allows you to cast an integer back into its correct handle type, but not cool stuff like unit -> item or int -> real. It would definitely be fun to fool around with those kind of casts.

 

[PurgeandFire]

Btw, why don't you want to use pJASS?

 

[WaterKnight]

Like, you could save a handle into a units custom value or something. Or give a value as a timer parameter.

I attach an object to its id in a hashtable when the object is being created. Of course, this means you have to wrap and monitor the object's life cycle.

It allows you to cast an integer back into its correct handle type, but not cool stuff like unit -> item or int -> real. It would definitely be fun to fool around with those kind of casts.

Only for testing purposes. Mapmaking on the base of such dangerous bugs is error-prone and a reason why now a lot of old maps do not work anymore.

 

[Imp Midna]

Btw, why don't you want to use pJASS?

Multiple reasons
- learning by doing: i learned everything i know about c++ and assembler because i wrote programs that definitely already existed. I wouldn't have moved a single inch if i always used those existing programs
- I got the source code and know whats in there, so i can put in more features if i desire (like, a macro to read data from the w3o file, so i can later on modify my triggered spells using the object editor only, i can let it preload files when the WE started and than just send messages to it instead of opening a whole new exe when the map is saved, i know it doesn't collide with my speed-up-save hack for sure, etc etc)
- i have fun coding. I don't have fun copy and pasting though. That's also why i dont like using systems.

I attach an object to its id in a hashtable when the object is being created. Of course, this means you have to wrap and monitor the object's life cycle.

Also a significant performance decrease if you only want to bind a single handle to a unit and have a map with a lot (and i mean A LOT) units that frequently vanish and spawn again.
Well, you are right, it would rarely be useful,but definitely a fun alternative to come around a few limitations (Handle->int->real->timer-custom-value, in the timer callback real->int->handle instead of being forced to use a global array or hashtable for this)

Only for testing purposes. Mapmaking on the base of such dangerous bugs is error-prone and a reason why now a lot of old maps do not work anymore.

I personally don't belive that Warcraft is ever gonna be updated again (tbh: i don't believe that they are ever going to pay any attention to it again, as they are concentrating on starcraft right now, and you'd think maintaining two rts at the same time wouldn't be the best idea), and while you of course are right, if there was some astonishing new feature (like, changing hero names or manually increasing / decreasing cooldown of a spell) i couldn't come around using this bug somehow, as it would be just too cool. And even if not, fooling around with it on a testing base is fun enough to fill a few hours of entertainment.

 

[WaterKnight]

Also a significant performance decrease if you only want to bind a single handle to a unit and have a map with a lot (and i mean A LOT) units that frequently vanish and spawn again.

That's the least. And no, you do not want to bind a single piece of information to the unit. It's better to have a shared unit indexer then.