WE Unlimited 2 Released - For version 1.20!

Is there any way to protect your entire campaign? I've imported all of my sounds/music/units into my campaign editor to save time and space.

There is no protection at all for Imported sounds/textures so forget about that

Heaps. I love them so much.

The possibilities they represent... it's beautiful. Thank you for putting this wonderful and exciting feature in!

Now. I'm not familiar with how much space things generally take up- and how much that extra space would slow down the average computer, so if you have an idea, could you answer these questions?

(A) Custom values.... when we're talking about these custom values, are these general-use unit-attached variables? That's what they seem to be... if so, that's awesome.

(B) If so, does that mean we can use the integer one to attach heaps (and therefore anything) to units? Would you suggest doing this? If I did this to every unit in a map with, say, 10-150 units average, would it hurt the game's performance?

Uh, I'm surprised anybody really wants to use the heap :p
Regarding space:Including advanced triggers takes up ~250 k in addition, this includes the heap and everything. Regarding speed: Only certain functions slow the game down (for example the spell enhancer), therefore I've created separate Initialize-Actions for these critical features (so if you don't ever call the InitSpellEnhancer function, it won't slow down anything)

For the next version I will include a basic script cleaner. After you have finished your map it can automatically delete those functions that were never used -> map size reduction again. but for now you'll have to live with those 250 kb extra

(A) yes, these are unit attached variables. As for the integer one: it has already been implemented by Blizzard, I only added the custom real, string and boolean values

(B) Yes, using the return bug for type casting you can attach any handle to a unit by saving the handle in the custom integer value

You don't see all the things you can do with them? Why, look: using the custom integer value attachment, you can attach a heap to a unit. Which means that I could essentially create different data fields that every single unit has, using this to create a new combat system. Example:

integer H = NewHeap(8)
SetHeap(H,strength)
SetHeap(H+1,dexterity)
SetHeap(H+2,intelligence)
SetHeap(H+3,constitution)
SetHeap(H+4,wisdom)
SetHeap(H+5,charisma)
SetHeap(H+6,armorclass)
SetHeap(H+7,attackbonus)
SetIntegerValue(unit,H)

I give everyone a miss chance of 100%, change the miss message to an empty string, and then I use special code to make them actually hit using these same stats everyone has, and I suddenly have a D&D combat system. Or, hey, if I wanted to add an addiction system to the drugs of any given life of a peasant/real life/whatever game:

H = NewHeap(2)
SetHeap(H,addictionLevel)
SetHeap(H+1,Rea2Int(lastDrugUsed))
SetIntegerValue(unit,H)

And it's there. The possibilities are endless, and that's just for this particular usage of the heap system. Never mind the other ones. Right now, I'm using the heap for a buff-database. I have an array of integers acting as an array of heaps- they're all two-value heaps. I created the Int2Buff code necessary and have one of the values a buff and the other the trigger that runs when the buff runs out.

I mean, could I do the same thing with multiple arrays? Sure. But this keeps things easy to read- I just have different functions to retrieve the buffs/triggers and run them at the appropriate time. And really, I could create any sort of complex structure I wanted. Heaps within heaps within heaps. It's really exciting.

Yes, I know it's very useful. But game cache exploiting is even more exciting imho. If we didn't have the gamecache I would agree that the heap is the most useful piece of code ever written for war3.
I also want to mention that peppar has originally implemented the heap, I only included it in WEU.

oh and I wanted to correct the figures from my last post: advanced triggers only add 130 kb to a map so it's not that bad.

More exciting than heaps? I must not understand game cache exploiting... what's it good for? I really only understand heaps as a direct result of the documentation of it packaged with weu. Is there a tutorial on game cache exploits?

Well, kudos to peppar.... anyway, you don't think that the extra heap usage would slow down the game a lot? Goodgood- I'll get to work on using this.

@ All: I've uploaded a completely new installer for version 1.15 here.
In addition to the fixes of the 1.15 Hotfix it will also update the included No-Limits-Patch, update some listfiles and parts of the documentation and fix another missing WESTRING.

I recommend you all to download this one and reinstall WEU even if you already have installed the update.

@Slunk:Well, using game cache wie can create arrays with several dimensions and even do pseudo oop.
You will find several examples of how to use game cache in the JASS Vault

Hmm.. a lot smaller than previous one, but that's a good news :)

Isnt there a delay in accessing the gamecache, however?

If you are using strings, the GC is a huge blessing. But for rapid integer manipulation it would likely be faster to utilize the heap, am I correct in this assumption?

Does it still have the bug where it deletes your custom units?

It never had that bug.

Meh, I'm not sure how fast it is, but it's not as slow as you'd think- it's just slower than accessing other stuff. I mean, yeah, accessing hundreds of game cache entries in a row is a bad idea, but you can use it for most data storage, and it'll work great.

How did you edit WE?

AIAndy's and my tests have shown that game cache is about 5 - 6 times slower than accessing a variable. But this is only a problem where speed is essential. But for storing arrays still often faster. That is because when attaching stuff to units in arrays you'll always have to loop through the unit array to find the index of the unit but in gamecache you can simply store your data with the unit handle "as name" of your variable - no more looping needed to find your data.


I don't know such a bug, could you explain it?


Yeah, InnoSetup 4 compresses much better than version 3. :)


Most of the changes to the editor are simple txt and slk-file-editing.
The enhancer is written in VB.