Patch 1.23b, JASS, GUI, and Gaming

[BSWhunter]

Has someone made a version of localvars that works with the new system?

 

[TriggerHappy]

Has someone made a version of localvars that works with the new system?

You shouldn't be using LHV in the first place..

And if you looked at the new natives, they're basically a safe/fast version of LHV.

 

[Anachron]

Wait, sure it doesn't work? Its just a Beta of the patch, maybe some file has not been patched.

And why the hell is it for US-English Wc3 Versions only? WHat the hell.

 

[Hakeem]

For breaking backwards compat

Worrying about backwards compatibility impedes development. For JASS this would mean...

And why the hell is it for US-English Wc3 Versions only?

If I had to guess, localization.

 

[Anachron]

If I had to guess, localization.

But even in germany we have US-English versions to buy.

Its blizzard, I guess.

 

[Eleandor]

Every patch of a game is different dependant on the language, so it's obvious that if you have the german version, an english patch won't work on your game. When you log on to battlenet, it checks your game's version, and then downloads the correct patch. Since on the testrealm there are no patches for the german games, you can't connect.

Since it's a testing suite, you can't expect them to make a testpatch in all languages.

 

[Deaod]

Hakeem, they couldve fixed the buffer overflow attack without removing the return bug. We wouldnt have anything to worry about.

 

[PurplePoot]

@TriggerHappy: I know (see the first post), Vex has already contacted them from what I hear

@Deaod: Indeed, although I'm not complaining about the new natives. The pain is mostly breaking backwards compatibility.

 

[MapperMalte]

Hmm.
Can't you use the hook function of the NewGen and Replace
H2I with GetHandleId?

 

[Dr Super Good]

Did anyone even read my comment? Some of the hash natives are broken and not working, espeically those which involve primitive types like integer and reals. The real check definatly is broken, and always returns false even if an allocated real is present.

 

[Yixx]

I read it, and i was about to ask about it,,
HaveSaved*something* returns what? (Ya, boolean but) What does it check for?
And is it only the HaveSavedReal() (so do all HaveSaved*something*() work exept for HaveSavedReal() ) ,, or is it also more?

 

[Dr Super Good]

HaveSavedHandle works fine, and I have tested it. As mentioned it returns true fro when something is saved, false when something has been removed and false when something was never there.

HaveSavedReal always returns false. I think its because the primitive type allocation is currently bugged. Removing primitive types like reals and integers keeps their value. Thus it seems handle hashing is working perfectly, but primitive hashing is incomplete / broken.

 

[Yixx]

Well, that seems quite normal to me. Reals and Integers have no way to be 'null' like handles have. So the only, and quite obvious, solution would be to set to '0'..
But '0' is still a Real/Integer, so it will say false because it still holds an Real/integer,,

I guess you have already figured this out for yourself, but these are my thoughts at least,,

 

[Dr Super Good]

No, as there are natived to "remove" them. Also it is meant to return true when there is a saved real. It however always returns false.

 

[Yixx]

Ok, then i misunderstood it. Yes it seems broken then yeah. Is there anyone who already reported this to Blizzard so they will fix it? (as well as fix Buffer Overflow or Return Bug the Right way this time)

 

[Eleandor]

Besides, there's always NaN, they could use that instead of 0.

 

[aznricepuff]

Integers can't hold NaN (most languages just either fail or start throwing exceptions/errors). And the HaveSaved[nonhandle] bug has been reported and blizz says theyre gonna fix it in the next beta patch.

 

[~Void~]

Which will be in like 5 or 6 months. Keep your panties on, children!

 

[Thanathos]

well ok i read the mainpost and all comments but im still confused… does this mean the good old normal H2I is now usless and will generate a compile error ? Or can i use another H2I or blizzard new native GetHandleId ?

H2I code example

//the normal H2I
function H2I takes handle h returns integer
    return h
    return 0
endfunction

//another H2I version
function H2I_alternative takes handle h returns integer
    return h
endfunction

 

[Anachron]

The new GetHandleId() replaced the H2I Function. Atleast it should, but atleast in singleplayer it works even now with patch. Maybe the epic fail of this year.

 

[Dr Super Good]

The old H2I will no longer work and will result in the map not loading probably. The native however is faster and does exactly the same.

 

[Eleandor]

Sadly, at this moment H2I & C2I still work, both on the current version and the new patch. Multiplayer on battle.net is still not safe of virusmaps.

 

[Thanathos]

bah since now i hate blizzard ! Did someone read the statement on the official blizzard site ? they are definitely kidding:

Please note that these changes apply to only a small set of custom map developers, and most Warcraft 3 custom maps remain unaffected.

If i got that right there are about 80% of all maps using the old H2I and they are gone now. This is just ridiculous and i (and perhaps some other JASSer´s too) don´t care if the new "native", if it is really a native and not just a hidden BJ, is really faster and until now H2I was fast enough.

Maybe the epic fail of this year.

Oh yea definitely it is ! I have an idea: what is when there are enough people who tell blizzard not to release their patch or at least keep the old H2I running ? Is this not possible ?

 

[Yixx]

But does GetHandleId() return the exact same thing as H2I also? Or does it return something else? (I guess the same since it returns pointer Id right?, but just for clarification)

 

[Dr Super Good]

It returns the exact same thing. It is just faster as it is native and does not have so much code running to do it. Also as it is native it does not have to be added to scripts any more and so boosts general map performance by a nearly unnoticable quantity.
The string one returns the string hash ID, also boosint performance a tad if you use systems like handlevars.

My spell I updated shows realitvly correct and efficent use of the new hashtable system. I advise checking it out. Yes it can be made better once the bugs with primitive types are fixed, but generally they seem pretty good and have greatly improved the efficency and buglessness of my spells.

 

[Eleandor]

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

 

[Yixx]

Why does my JNGP give an error when i try to declare a global Hashtable? =S

 

[Eleandor]

Have you updated war3? And hashtable is with lower case h.

 

[Dr Super Good]

You have to update JNGP components like pjass and stuff to support the new natives.

 

[Yixx]

Ok, havent updated pjass, i will search for it. But i did update TESH, with TriggerHappy's thing, so i know how to write hastable because it turns blue then

But i will search for pjass and jasshelper updates,, thanks =) both

 

[wyrmlord]

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]

Ok, and where to get it? I seached all .mpq files, but none contained the common.j that had type hashtable extends whatever
So where to get it?

 

[Dr Super Good]

patch.mpq needs to be retrieved by direct request or with a listfile for the MPQ as it does not contain one.

 

[Yixx]

So we cannot use hashtable for now? =\,, i already have some things in my map that use it,, but i guess i will have to convert those integers to strings and use gamecache for now instead,,

 

[Dr Super Good]

No, they work fine. Just some things with them are broken. Namingly the primitive destruction and checking. HaveSavedReal() does nothing, and so do the other primitive equivelents. Also removing primitive types maintains their value, when infact they are meant to lose their value or atleast be known as having lost their value via the havesave natives. Handle storing is working beautifully though on the bright side.

All this can be aboived by setting them to their default value before removal so that you can use that to check if something exists. This however is slightly slower than if the natives worked like they are meant to.

Thus, you can use them, just you can not use them as efficently as you could if they worked flawlessly. Also no one knows much about them leaking, so be careful and make sure you remove all values that are no longer needed to prevent lag late game.

Also it seems they axcept both positive and negative indexes as valid storage locations. Keep this in mind when triggering for them.

 

[Yixx]

Ok, thanks for the Load of information

but, how will i make JNGP accept them? I didnt quite understand what you meant with the listfile of Patch.mpq,, Could you tell me what to do exactly?

 

[Captain Griffen]

a) I seriously doubt JNGP is updated for it, and
b) JNGP shouldn't be updated for it, as it's not a release patch and IS going to change. Because Blizzard suck. Badly.

 

[Dreadnought[dA]]

So I tried to DL the patch from Westfall, but it keeps telling me I don't have worldedit.exe
Looked in my folder and there it was. I'm thinking maybe I need 1.23 world editor version. Not sure, but I may still be using 1.22 since it worked with Newgen.

 

[aznricepuff]

JNGP, at least the WE part of it, works fine with 1.23b as it is. Obviously you need to update the jass parser that you use, but otherwise no functionality is lost.

 

[Hakeem]

they couldve fixed the buffer overflow attack without removing the return bug.

You call it a bug and you don't want it fixed? I'll paraphrase something I once heard: "Wouldn't it be nice if we didn't have to rely on their bugs?" I'm pretty sure there were always workarounds to the issue instead of using this bug.

Either way, your logic would seem to be that a bug cannot be fixed because it breaks backwards compatibility with code that used the bug.

Emphasis on the last three words there:
Used the bug.

 

[Dark_Dragon]

It returns the exact same thing. It is just faster as it is native and does not have so much code running to do it. Also as it is native it does not have to be added to scripts any more and so boosts general map performance by a nearly unnoticable quantity.
The string one returns the string hash ID, also boosint performance a tad if you use systems like handlevars.

My spell I updated shows realitvly correct and efficent use of the new hashtable system. I advise checking it out. Yes it can be made better once the bugs with primitive types are fixed, but generally they seem pretty good and have greatly improved the efficency and buglessness of my spells.

wow thats some great news DSP! i cant wait for that mass WE update and they will even add GUI support... blizzard is great i waited so long for this updated (i actualy never thought they will release this patch)

they said that HaveStoredReal will be fixed with new beta patch...
so ty for your testing DSP you are awesome +rep


ohh btw for someone who said (i forgot who) that 80% maps are using H2I...

This guide has been written to help advanced Warcraft III map developers understand the changes that we’ve made to the JASS functionality. Please note that these changes apply to only a small set of custom map developers, and most Warcraft 3 custom maps remain unaffected

and blizzard speaks truth! for this people who dont know (well simple) check out some sites with mass amount of maps and u will see what i mean!

lesser then 14% of maps will be effected by this changes!
there are almost no jass maps they are all fully GUI!
ofc the top maps are in jass but blizzard is fixing something thats called bug-return and that whats bug must be fixed!

and btw this who use cjass:

define {
    H2I = GetHandleId
}

wow its fixed!
i dont want that bug returns i want a fast native works and i agree with Deaod that we dont have whole VM for our spells and systems! thats what he teached me and i must say that he is right only something with top performances is acceptable! currently all this GUI spells suck with performances and finally after 1.23b GUI will become somthing which is acceptable.

so yeah ty for your hard work and making of game blizzard!

Greets all!
~Dark Dragon

 

[Deaod]

Hakeem, the thing is: When the return bug was discovered Blizzard said they are not going to fix it. They had the chance to fix the bug back then, but didnt use it. Everyone started using the bug, relying on Blizzards statement not to fix the bug.

Now its 2009 and a remotely related exploit is found, and Blizzard decides to fix the return bug, screwing over all users who thought it would never get fixed.

And yes, i think not breaking backwards compatibility is more important than fixing a (harmless) bug. If the only way to fix the exploit would be to fix the return bug i wouldnt be complaining, but i am complaining since fixing the return bug was not necessary, not at all.

 

[Hakeem]

When the return bug was discovered Blizzard said they are not going to fix it.

Ah. Did Blizzard happen to say this on April Fools?

It doesn't matter though. Using bugs, no less relying on them, is terrible practice.

 

[Dark_Dragon]

Hakeem, the thing is: When the return bug was discovered Blizzard said they are not going to fix it. They had the chance to fix the bug back then, but didnt use it. Everyone started using the bug, relying on Blizzards statement not to fix the bug.

Now its 2009 and a remotely related exploit is found, and Blizzard decides to fix the return bug, screwing over all users who thought it would never get fixed.

And yes, i think not breaking backwards compatibility is more important than fixing a (harmless) bug. If the only way to fix the exploit would be to fix the return bug i wouldnt be complaining, but i am complaining since fixing the return bug was not necessary, not at all.

Hi Deaod!

ahh i know what u mean! yeah they did not fix it on time and i think u want to say that u would like blizzard to fix buffer overflow! i think it is harder then fixing return bug, anyway i still think one thing is good... we will no longer need a tone of private H2I functions and in GUI it will as well be possible to access handle id... anyway i get ur point and well i agree with u 2 but if we look at great features and not bad ones i think it will be acceptable! and thous who dont use cjass can always use notepad++ which with few click Ctrl+H and typing replace H2I with GetHandleId will be quite fast

Best Regards!
~Dark Dragon

 

[Eleandor]

and blizzard speaks truth! for this people who dont know (well simple) check out some sites with mass amount of maps and u will see what i mean!

lesser then 14% of maps will be effected by this changes!

Hello there, random number pulled straight out of your ass...

If you're ofcourse talking about the tons of maps that use unmodified melee heroes and lacking any form of gameplay that seem to be spammed on battle.net, then indeed the majority of maps won't be affected. But the quality of that majority of maps is basically poop.

Nevertheless I'm all for new natives, and I personally am willing to sacrifice compatibility, but just nodding "yes, yes" without thinking it through yourself just because blizzard says so is cowpoop.

Every map made in jass that wasn't made by a half-assed loonatic will be screwed up.

 

[Dark_Dragon]

Hello there, random number pulled straight out of your ass...

If you're ofcourse talking about the tons of maps that use unmodified melee heroes and lacking any form of gameplay that seem to be spammed on battle.net, then indeed the majority of maps won't be affected. But the quality of that majority of maps is basically poop.

Nevertheless I'm all for new natives, and I personally am willing to sacrifice compatibility, but just nodding "yes, yes" without thinking it through yourself just because blizzard says so is cowpoop.

Every map made in jass that wasn't made by a half-assed loonatic will be screwed up.

yap i am talking about all maps i dont care is map advanced or not its a map and blizzard said maps (not only advanced maps) since there are maybe only 1000 maps made by using return bug... anyway i am as well for new natives and if i have to recode H2I to GetHandleId for no corruption or faster natives its a np for me!

that 14% yes is random number and well y i think about all maps since blizzard means that as well! melee maps are in count to! they are maps! blizzard said most of maps will be uneffected and its true!

ofc i said it already advanced jass maps will be effected but if they are made by advanced user there is no problem for autor to fix something like that for better performances and ofc to clear all private H2I functions...

well thats how i think, as well i am human and humans are wrong so i can be wrong but thats how i think!

Greets!
~Dark Dragon

 

[Yixx]

And i think you are being naive. Counting Melee maps with those maps? Yes they are maps but they got no coding! (yeah the Melee setup, but that is all!),, and those crappy maps will not be affected,, but who plays them? I think you should count the amount of maps that is actually played instead of thinking of all maps ever made, then you can also include the 5 maps i once started but never finished because i couldnt make a hero spawn (dark past),,

 

[Dr Super Good]

Trust me, it is worth it for the new natives.
I have tested them out with an update for my old spell pack and they are working beautifully and less buggy han ever before without serious performance drains.

 

[Dark_Dragon]

And i think you are being naive. Counting Melee maps with those maps? Yes they are maps but they got no coding! (yeah the Melee setup, but that is all!),, and those crappy maps will not be affected,, but who plays them? I think you should count the amount of maps that is actually played instead of thinking of all maps ever made, then you can also include the 5 maps i once started but never finished because i couldnt make a hero spawn (dark past),,

yeah i know but still a lot people play melee maps belive it or not and basically i dont care how much people play melee maps, blizzard only said that most of maps will not be effected and melee and maps which are not so good are still maps. btw i know a lot of maps which are fully GUI coded and are better then many of jass ones! i am not talking about performances GUI cant win against jass in that but autors where working hard and they know only GUI so they made maps in GUI and they turned quite good! still if we count best jass maps like DotA or such then y this GUI ones dont stand a chance! but once again blizzard said that advanced map makers will have to change things in there code i simply said nothing else than that :/

Trust me, it is worth it for the new natives.
I have tested them out with an update for my old spell pack and they are working beautifully and less buggy han ever before without serious performance drains.

i agree!

 

[Yixx]

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