Gamecache - store over 8k real values

Ok so I am making a height grid for my map which is currently 160x160 leading me to need 25,600 real values for a nice Z value grid. However I am not able to add more then about 8k values.

So can I

A: use a system of compression (like a JPG does for picts) that would compress the number of needed points (i would love to be able to do this just I would have a hard time making it and don't know what lag problems it might cause)

or

B: how can i bypass the 8k value limit?

or

C: any ideas?

EDIT: Ok after reading up it looks like the value is exactly 8192 :/ so i think I will need multipul gamecaches... so I was wondering is there any way to pass a gamecache from a player to another player so i could use this limit to my advantage and have the players share the workload of making the gamecache... because 12 equally sharing the workload would only be 2.1k each which would be many times faster especially for slow machines....

You are crazy to need that many values -.-


What is this for?

A single gamecache will be fine. Building it will take a brief moment, as you will have to hack your way around the oplimit with TriggerSleepAction or TriggerEvaluate.

so the 8k is just the limit of a loop or what? Also can i transfer the gamecache from one player to another because I might actually do that ne ways if it is possible.

PS: its so i can use a getlocationZ (or the z equivilent from this gamecache) for a multi level pathed map as well as also use terrain deformations

PPS: Yes i am crazy ask pyrogasm he has seen the crazy stuff i do

Oh, I thought by 8k you meant array size. Yes, that's the op limit then. Run however many you can, then TriggerSleepAction(0.) and continue.

What about the transfer gamecache thing is it possible? and if so then would it be worth merging them into one gamecache or simply leave them seperate?

EDIT: Also how bad would it lag the game if i was to simply sleep it for .01 after every 5 values or so? I know it would make it take 1 minute to get all the values at that rate but would it possibly stop a potential lagspike or is that too much/too little of a buffer???

PS: what does OP limit mean exactly I think it is the max qued trigger actions but i could be wrong

PPS: Could i just use ExecuteFunc and let it chug away in bliss or would i still hit the op limit?

Hay that is actually a great idea, precalculating Z values ....
why didn't I think of that ...

Anyways for a 160x160 map you don't need gamecache to store values
all you need is some form of array extension.

Gimme a 10 min I will make you one.

EDIT:
Here you go:
http://www.wc3campaigns.net/showthre...924#post958924

This can save Z for maps up to 250x250 :D

Precaching z values is a bad idea, and it's going to be slower and less accurate than using the real GetLocationZ, this is all pretty dumb just to get around basing some spells off Warstomp and Shockwave

It will be slower only if gamecache is used.

And how exactly is it going to be less accurate?

EDIT:

Besides making sure that desyncs do not happen by simply importing one trigger vs
chasing possible desync causes is kind of more easy.

And Toadcop would find this really useful I guess :D

I'm pretty sure array lookups will be slower than natives

The reason it's less accurate is because GetLocationZ is very precise, just interpolating between points will be nothing but an approximation.

1. Probably, but not significantly enough to make problems.

2. Yes it would be approximation...
This needs to be tested to see how precise it will be.
But again difference between linear approximation and real Z will
not effect spells like jump because they spread over large distance

LoL I was just looking at grid on the map and it dawned on me:
native getLocationZ is actually using interpolation
So basically this would be the same !!!

EDIT:

In case someone doubts that GetLocationZ is using interpolations here is explanation:
Let us observe small 96x96 map, Since one white grid square is taking 128x128 points
it would take 128*96 X 128*96 = 144MB just to hold Z data for the map,
and war3 takes around 80MB when that sized map is started.

So GetLocationZ is indeed using interpolations Q.E.D.
(probably planar interpolation from 4 surrounding points)

Well, since terrain isn't really smooth, but grid based, having a grid as dense as the wc3 terrain grid (128*128 units) should make it rather acurate, it would even be possible to make it perfectly accurate if you took the triangulation into account and only sampled the nearest 3 points, not 4.

Still, using gamecache or concacenated arrays for applications for which we usualy need GetLocationZ would be really slow, I only mentioned it because botanic insisted.

Yes I saw it was your idea originally.

Gamecache would indeed be slow,
but Extended arrays would not.

Note:
Extended arrays are NOT concatenated, they use binary interpolation,
and they are NOT slow.

you guess with your ass =\
it's a full crap =\ problems got only lamers with hands out of ass.
+ AAA ! ^^ remembered...

so you can CREATE HUGE GRIDS =)

Yes, but three accesses to them, plus interpolation, compared to a single native call? *cough*slooooow*cough*