Patch 1.23b, JASS, GUI, and Gaming

[Dark_Dragon]

I also have to agree with DSG about the new natives. I loved Hashtable from the moment i read it used integers instead of strings and that it could save almost ALL handles!

But DSG, Me and Eccho have had some exchange of knowledge and files, but on both of our computers, the new natives didnt work/compile! What did you do to get them to work? =S

this is a must

You don't need to update PJASS or JassHelper to get syntax checking on hashtables to work. Instead, you need to make sure they're using the most recent version of common.j.

 

[Yixx]

Yes i read that, but where to get that? Where to get that Beta Patch or so? Where to put the new file?

 

[Viikuna]

...still if we count best jass maps like DotA or such then y this GUI ones dont stand a chance!...

Lols. Its true that some cool Jass made maps pwn GUI maps, but whats so special in dota that you cant do with GUI?

( And the answer is: you cant do anything with GUI, you need custom script and then you can do some stuff and it will still suck because of that horrible GUI interface )


You can do lots of cool "Jass" stuff with GUI + custom script, and most of dotas thingies too, if Im not mistaken.
The main reason why we use Jass, is because its easier to code with and looks much much better than GUI. ( Ofc better performance is a nice thing to have too.. )

 

[Dark_Dragon]

Lols. Its true that some cool Jass made maps pwn GUI maps, but whats so special in dota that you cant do with GUI?

( And the answer is: you cant do anything with GUI, you need custom script and then you can do some stuff and it will still suck because of that horrible GUI interface )


You can do lots of cool "Jass" stuff with GUI + custom script, and most of dotas thingies too, if Im not mistaken.
The main reason why we use Jass, is because its easier to code with and looks much much better than GUI. ( Ofc better performance is a nice thing to have too.. )

ofc thats what i mean as well i named dota only coz we all know that map and for no other reason!

ofc GUI + custom script lol coz without custom script it means leaks...

Yes i read that, but where to get that? Where to get that Beta Patch or so? Where to put the new file?

huh? i thought u already have installed beta patch! if not then ofc it does not work... i did not test jet beta patch but i know how to install it... and i think that JNGP will load automatically new common.j from patch.mpq or smth!
if not put it in ur warcraft iii directory and ur done!

 

[Dreadnought[dA]]

You either use GUI, in which case there's no problem, or you use vJass in which case you should NOT be using Kattana's handle vars and could fix your map within 1 minute (replace H2I by GetHandleId) or you use jass and are now in big trouble. If the latter is your case, then it's your own stupidity of not using Table & vjass that brought you into the trouble

How can you attach things in JASS without H2I or using tables? lol

 

[Hakeem]

Parallel arrays.

 

[Dreadnought[dA]]

Ah, I get it Loops and Parallel arrays

 

[Anachron]

...still if we count best jass maps like DotA or such then y this GUI ones dont stand a chance!...

You say DotA is one of the best vJASS maps? DotA is using the H2I bug everywhere, in most of the spells. (& Systems). Its pretty easy coded and not modular.

Back to topic, I still want more information about the bug. Is the 'Return bug' fixed in SP now, will they fix it, will they let it, what about it?

 

[Eleandor]

How can you attach things in JASS without H2I or using tables? lol

If you use table, all you got to do is copy/paste Table 3.0, and you're done. Can't say that's the end of the world, can you...

 

[Hoernchen]

Blizzard can go suck a fat one. Seriously, anything but this shit....
Sorry for my language, but I am so pissed at them right now. This pretty much ends map making for me with the World Editor. I can't be fucked rewriting every single fucking thing I ever wrote.

BLIZZARD I HATE YOU

 

[Dr Super Good]

Hoernchen, your making no sense.... The only triggers that will not work are ones which involved the double return bug (JASS). GUI will not be affected at all next to improved a bit.

Any JASS code which did use the double return bug can easilly be fixed so as to be compatiable. Thus I think you misinterpreted what blizzard said, and your maps should be made easilly to work again, if not they still will work.

 

[Dark_Dragon]

Hoernchen, your making no sense.... The only triggers that will not work are ones which involved the double return bug (JASS). GUI will not be affected at all next to improved a bit.

Any JASS code which did use the double return bug can easilly be fixed so as to be compatiable. Thus I think you misinterpreted what blizzard said, and your maps should be made easilly to work again, if not they still will work.

thats exactly true! i mean you dont need to recode whole of your triggers but just replace H2I with GetHandleId and thats all!

 

[Deaod]

and if you used I2H() or S2I() or B2I() or C2I() youre screwed. Not like you werent even before this patch, but recoding a map with ~500 calls to different I2X() is tiresome.

 

[Dark_Dragon]

and if you used I2H() or S2I() or B2I() or C2I() youre screwed. Not like you werent even before this patch, but recoding a map with ~500 calls to different I2X() is tiresome.

yes but if thats the case then this new patch will save that guy from nightmares i had when i was discovering whats wrong! until i learned about HSC!

jet thats just another reason why i love new patch coz well you will be sure to play safe maps not bugged ones! i mean corrupted... lol if only at that time i new about I2X corruption :S

ohh and btw does anyone know will blizzard really completely fix the return bug i mean this:

function H2U takes handle h returns unit
    return h
endfunction

coz well if they will fix that then GUI will be effected:

constant native GetTriggerWidget takes nothing returns widget

function GetDyingDestructable takes nothing returns destructable
    return GetTriggerWidget()
endfunction

well i dont think that this will be fixed but not sure!

 

[Eleandor]

function H2U takes handle h returns unit
return h
endfunction

This is not related to the double return bug...

 

[Deaod]

And yeah, they want to fix that too.

 

[Eleandor]

They do?

I don't understand blizzard anymore...

 

[PurplePoot]

function GetDyingDestructable takes nothing returns destructable
    return GetTriggerWidget()
endfunction

Are you sure they want to fix that? Guess they could just replace such functions with natives, but it looks like they were very intentional.

 

[Dr Super Good]

Unlike other things, widgets all shair simlar features and so they are meant to be highly changable. Thus they should permit easy type casting from widget to unit, destructable or item and vica versa. However they should not allow conversion from unlike fields, like floatingtext to unit as that would cause major errors internally.

Remember that units, items and destructables extend widgets and widgets extend handles. Unlike most types which extend handle.

 

[Illidan(Evil)X]

function GetDyingDestructable takes nothing returns destructable
    return GetTriggerWidget()
endfunction

Are you sure they want to fix that? Guess they could just replace such functions with natives

They already did.

constant native GetTriggerDestructable takes nothing returns destructable

function GetDyingDestructable takes nothing returns destructable
    return GetTriggerDestructable()
endfunction

 

[PurplePoot]

Whoa, guess I should pay more attention to the 1.23b common.j.

 

[Dark_Dragon]

They already did.

constant native GetTriggerDestructable takes nothing returns destructable

function GetDyingDestructable takes nothing returns destructable
    return GetTriggerDestructable()
endfunction

ahh ty i dont have beta version so i did not know!

Unlike other things, widgets all shair simlar features and so they are meant to be highly changable. Thus they should permit easy type casting from widget to unit, destructable or item and vica versa. However they should not allow conversion from unlike fields, like floatingtext to unit as that would cause major errors internally.

Remember that units, items and destructables extend widgets and widgets extend handles. Unlike most types which extend handle.

i know that unit, dest... extend widget not handle but for example if function returns widget and i return destructable its correct but opposite should be wrong coz widget does not extend destructable right?

so if it returns dest then widget would be wrong i guess!
anyway since now i know they already coded native for it then its all logical! they will make strict type handling same as in GUI!


well anyway ty guys and +rep illidanx

 

[Deaod]

Blizzard will remove any kind of unsafe upcasting (that means from widget to destructable, or from handle to trigger). The only way to upcast will be through hashtables. WC3C already has a resource (ab)using this.
However, downcasting is, always was and will be allowed, even implicitly (this only applies to handles and subtypes, implicitly downcasting from handles to integers wont work).

 

[Hoernchen]

No, I understand properly. The H2I system is the system I use the most though, for pretty much every system and every spell I make.

 

[Dreadnought[dA]]

Then why were you telling Blizzard to go suck a big one?

 

[Dark_Dragon]

Then why were you telling Blizzard to go suck a big one?

yes we (users) are the ones that notifyed blizzard about this bug coz if u did not know you could have spread viruses by simply converting code and integer!

btw H2I was always a slow function anyway! so this is more like a blessing! i mean they even added hashtable... they are all natives and are fast! + they will add some more natives like GetTriggerDestructable... and on top of that it will be accessible in GUI...

btw i really dont think that changing H2I to GetHandleId is hard! use some good text editor like n++ and use replace command... thats so simple!

if you where using some other bug returns like I2x then this patch will save your map from HSC!

so i can see only good things about new patch! this maps which are no longer supported by ther creators and are using bug-returns are not 100% safe anyway. so its good to know if you are playing safe game or not...

Greets!
~Dark Dragon

 

[Viikuna]

I was so wise man that I had a Typecasting library for H2I and my attaching systems just required that library.

Now I just need to replace that one H2I and update my Table and it will be allright.

Also, those hashtable functions might be really really fast, which would mean that they could be used like everywhere which would be kinda sick.. ( in a good way )

And H2I was perfectly safe btw. And it seems that GetHandleId is just the same, maybe little faster though.

 

[Storyyeller]

Is there anyway to take advantage of the automatic caching of strings without using I2H?

E.g. every string you use is added to a secret table without having to explicitly store them.

 

[Captain Griffen]

Is there anyway to take advantage of the automatic caching of strings without using I2H?

E.g. every string you use is added to a secret table without having to explicitly store them.

What are you trying to say...? Strings are cached, and there's nothing you can do about it. And it has nothing to do with I2H?

 

[Dark_Dragon]

Is there anyway to take advantage of the automatic caching of strings without using I2H?

no, its not possible to take advantage with or without I2H!

Greets!
~Dark Dragon

 

[Aegis Runestone]

I'm sorry, I haven't been paying attention, has the patch been released yet?

 

[Dr Super Good]

No..... the directors would have made a new or updated news article if it was,

 

[SerraAvenger]

I'm not sure I'm too clear on hashtable safety yet...

// What I'm doing here is storing both the attached and the attaching
// value into the hashtable.

globals
    constant integer Attacher___MODE_KEY = 0
    constant integer Attacher___MODE_VAL = 1

    constant hashtable Table = InitHashtable()
endglobals

    function Attacher___GetHandleKey takes handle typeval returns integer
        return GetHandleId(typeval)
    endfunction

    function Attacher_GethandleKey takes handle typeval returns integer
        return Attacher___GetHandleKey(typeval)
    endfunction

    function Savehandle takes hashtable table,integer mode,integer key,handle typeval returns integer
        if mode == Attacher___MODE_KEY then
            set key = Attacher_GetHandleId(typeval)
        endif
        call SaveHandle(table , key , mode , typeval)
        return key
    endfunction

    function Loadhandle takes hashtable table,integer mode,integer key returns handle
        return LoadHandle(table , key , mode)
    endfunction

    function Havehandle takes hashtable table,integer key returns boolean
        return ( HaveSavedHandle(table , key , Attacher___MODE_KEY) and HaveSavedHandle(table , key , Attacher___MODE_VAL) )
    endfunction


function SetHandleHandle takes handle key_handle, handle val returns nothing
    local integer key = Savehandle( Table, MODE_KEY, 0, key_handle )
    call Savehandle( Table, MODE_VAL, key, val )
endfunction

function GetHandleHandle takes handle key_handle returns handle 
    local integer key = Attacher_GethandleKey( key_handle )
    local handle loaded = Loadhandle( Table, MODE_KEY, key )
    if key_handle == loaded then
        return Loadhandle( Table, MODE_VAL, key )
    endif
    return  null
endfunction

When I'm trying to attach handles to handles, would something like this work?
It should 'leak' all type of handles since it doesn't free handles from memory anymore, correct?

so what would this print:

function Hum takes nothing returns nothing
  local unit u = CreateUnit( 'hfoo', Player( 0 ), 0, 0, 0 )
  local unit z = CreateUnit( 'hpea', Player( 0 ), 100, 0, 0 )
  call SetHandleHandle( u, z ) 
  call SetHandleHandle( z, u ) 
  call KillUnit( u )
  call TriggerSleepAction( 500 )
  if GetHandleHandle( u ) == z then
    call BJDebugMsg( "u -> z: still there" )
  else
    call BJDebugMsg( "u -> z: gone" )
  endif
  if GetHandleHandle( z ) == u then
    call BJDebugMsg( "z -> u: still there" )
  else
    call BJDebugMsg( "z -> u: gone" )
  endif
endfunction

My guess would be that still everything is there, so the handle indicies will never get recycled. Is that correct?

 

[Deaod]

yes, the datas still there. Unlike gamecache, hashtables are ref-counted, meaning storing handles in it will increase the ref-counter of the stored handles. You have to flush those keys manually (to de-reference those handles, thus decreasing their ref-count).

Note: handles casted to integers dont increase the ref-count anymore (not like they ever did). Using handles as keys for hashtables still doesnt increase the ref-counter (and it probably never will).

 

[Viikuna]

8mb map limit luls. Doomsday clock just moved few minutes towards the destruction.

 

[Yixx]

An update has been released!

I tried to enter WestFall battle.net, and it gave me an update message.
I clicked cancel to see if it was also on Northrend Server, and it was.

Is this the official update? Holding a fully fixed return bug and fully working hashtable/new natives?

 

[PurplePoot]

Checked Asia, USEast, and North, and none f them have a new patch.

 

[Dr Super Good]

Whats probably happened is a fixed beta is released on westfall.

 

[Coolty44]

The upgrade to GUI with the adding of hashtables can only be downloaded by connecting to westfall. As soon as you join another server you get updated to the stuff before the fix.

 

[Captain Griffen]

According to Hindar, HaveSavedX now works, but so does the return bug work around...

 

[Hijax]

Question: how can i use hashtables in vJass? since the jasshelper/JNGP arent updated to patch 1.23.

 

[Yixx]

@ Purplepoot, I probably didnt have the latest patch from northrend? =\ Because it showed a patch log going up to 1.23 still,,
But when i downloaded the Westfall patch, the update log showed 1.24.

My patch log:

Patch Log

--------------------------------------------------------------------------
  WARCRAFT III: THE FROZEN THRONE VERSION HISTORY
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Patch 1.24
--------------------------------------------------------------------------
PC WORLD EDITOR CHANGES
- Added new JASS hash table functions to replace the lost functionality from 
   fixing unsafe type casting.
   - Hash Table - Save Item Handle
   - Hash Table - Save Unit Handle
   - ...
   - Hash Table - Load Item Handle
   - Hash Table - Load Unit Handle
   - ...
   - Hash Table - Get Handle ID
FIXES
- Fixed an exploit related to unsafe type casting that allowed users to 
   execute arbitrary code in maps.
- Fixed the JASS unsafe type casting exploit ("return bug").
- Fixed several World Editor crashes.
--------------------------------------------------------------------------
Patch 1.23
--------------------------------------------------------------------------
FEATURES
.....

 

[Dark_Dragon]

According to Hindar, HaveSavedX now works, but so does the return bug work around...

the bug return does not work for me!
any map with return bug is not playable with v1.24 i just tested it!

Question: how can i use hashtables in vJass? since the jasshelper/JNGP arent updated to patch 1.23.

interesting you said v1.23? i mean 1.23 is already out some time now but v1.23b came out some time now and was a little bugged so now with 1.24 it seems quite stable and you jasshelper has nothing to do with wc3 update to 1.24 hashtables work on 1.24 with jh 0.9.H.2!

keys work as well so enjoy!

 

[Deaod]

the return bug still works the same way it worked in 1.23b.

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

 

[Dr Super Good]

The traditional easy way does not. It however still does exist in one form or another.

 

[Dark_Dragon]

the return bug still works the same way it worked in 1.23b.

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

wow that actually works! did not know that and i hope blizz fix it coz if not i see no point in this new patch at all :S

 

[SerraAvenger]

Wouldn't it theoretically be possible to create a huge dictionary of all variables and functions and their types and then match 'return var/func' against the type of the current function at compile time?

 

[Eleandor]

Normally that should happen in the first place with any compiler, and it wouldn't even be that difficult to do. God knows why blizzard didn't implement some decent typechecking.

 

[Captain Griffen]

a) Code after the return should not be allowed.
b) All returns should be of the right type as the function.

Simple to check, and would solve the return bug instantly.

 

[Dr Super Good]

Solution b is the best. a would cause more compatibility issues as even GUI uses return to skip remainin actions and also you can use multiple returns of the same type in a function practically.