Multi-dimensional arrays?

[DivinityX]

Hello. I was simply wondering if you could use multi-dimensional arrays in the editor. If not, then perhaps JASS?

I need three-dimensional arrays to adept the A* algorithm (pathfinding algorithm) to Warcraft Maul X17.

Something like this:

Point[X][Y][Walkability]
Point[X][Y][F]
Point[X][Y][G]
Point[X][Y][H]
Point[X][Y][ParentX]
Point[X][Y][ParentY]

As you can see, it's the only way...
Multiplying X and add Y wouldn't work since 6144*6144 = 37748736, that is only one direction. So it stretches from -37748736 to 37748736. A total of 75497472. War III integers only reach 65534 though.
Please respond. =)

 

[Cheezeman]

Hashtable?
Or are you looking for 3d?
No wait, you are you looking for 3d...
Lemme think of something...

War III integers only reach 65534 though.
Please respond. =)

Yeah and WarCraft III array indexes reach 8191

-------- Edit --------
This system suck, becuase it can only save real numbers and if you're gonna use GetHandleId() (or Key Handle) it will most probably get a really high number...
It uses the same concept as Blizzard's object rawcodes.

Anyway it requires a global hashtable named "ThreeDReal___Hash" and a global integer named "ThreeDReal___OFFSET".
All settings are done in the InitTrig_ function.

//===========================================================================
//==
//== call Save3dReal( integer GrandParent, integer Parent, integer Child, real Value )
//== local real r = Load3dReal( integer GrandParent, integer Parent, integer Child )
//==
//== Or in GUI...
//== Custom script:    call Save3dReal( integer GrandParent, integer Parent, integer Child, real Value )
//==
//== Example of use:
//== Custom script:    call Save3dReal( 3, 2, 1, 100. )

function InitTrig_<Trigger Window Name> takes nothing returns nothing
    set udg_ThreeDReal___OFFSET = 15 //Larger value means more saftey, but the number can get pretty big with GetHandleId()
    set udg_ThreeDReal___Hash = InitHashtable() //Don't touch this
endfunction

function Save3dReal takes real save, integer grandparent, integer parent, integer child returns nothing
    call SaveReal( udg_ThreeDReal___Hash, grandparent * R2I( Pow( I2R( udg_ThreeDReal___OFFSET ), 2. ) + ( parent * udg_ThreeDReal___OFFSET ) ), child, save )
endfunction 

function Load3dReal takes integer grandparent, integer parent, integer child returns real
    return LoadReal( udg_ThreeDReal___Hash, R2I( grandparent * Pow( I2R( udg_ThreeDReal___OFFSET ), 2. ) + ( parent * udg_ThreeDReal___OFFSET ) ), child )
endfunction

-------- Edit --------
I didn't check this system yet, but it should work fine (though some really low grand/-parent keys will cause collisions unless OFFSET is really high)

 

[D4RK_G4ND4LF]

http://www.hiveworkshop.com/forums/trigger-gui-editor-tutorials-279/2d-array-tutorial-123631/

but hashtables have unlimited indexes afaik so you might think about combining both

however there usually are better solutions then 3D-Arrays

 

[DivinityX]

I don't think there is.
I need ( 6144 + 6144 = ) 12288 indexes, because Warcraft doesn't support negative indexes.
One for each buildable point on the map.
That's the map size, -6144 to 6144, -6144 to 6144.
To make it easy I will only use -5000 to 5000 x -5000 to 5000 though. That would cover all the walkable paths.

I don't really understand the JASS functions, would they fill my requirements?
I will learn JASS if it does.

 

[Dr Super Good]

Why do you need such large numbers...
WC3 maps usually are atmost 256*256 (128 each direction) squares.
These squares are broken down into a 2*2 pathing map.
Thus surly you would be after an array of size 512*512 which is 262144 entries?

This makes a hell of a lot more sense as it is pointless storing the same pathing map point more than once.

As for your structure code structure, you are after 2 hashtables woking in dual layer.
Hashtable 1 is an II hash or P hash (2 integers representing a 2D position). This is used to break your map into areas which can return values.
Your second hash is an IS hash (integer and identifier). You asign each position in your level 1 hash a unique integer, which you can then pass to your level 2 hash along with the value identifier to get a value from it.

Logically this is a slow process and especially with so many hash entries, it could become extreemly slow for the WC3 engine. If that occus consider breaking it into hasharrasy, each dealing with a part of the map which will result it less indexes each and probably yield a speed boost.

All in all this is a slow and expensive method, I would advise just using normal WC3 pathing as it seems good enough to me and I doubt a 8-80 times more costly one will be any better. If you could multi thread it thats another story but WC3 is single threaded so its preformance has been capped for like 3 so years.

 

[DivinityX]

I already told you the map name and it's size.

I'm not using this to move units, I'm using it to detect maze blocking.

I want to try it out. If it's too slow, I'll trash the project.

 

[Dr Super Good]

And I told you how to do it, so wheres the problem?
Maybe its that I forgot to mention that the method stated works for any size of map as long as the hashtables do not have a storage limate (which I currently am unaware of)?