Z value Grid (new idea)

Ok well I tried getting all the Z values at map init just it got funky with the op limit ect and I figure it will add lag if I ever got it to work so...

I just had an idea ^.^ so my ? where is and how is the map terrain information stored and is it feesable to go that rought to get a Z value grid OR I found a game replay parser (http://w3g.deepnode.de/ google "replay toolkit") Is there any way I can have a list of messages that is a setup style thing that will send the Z values so the replay parser can detect them? With eather method I would then parse those messages into a simple:

function set takes nothing returns nothing
set udg_Z_Value[w/e]
...
endfunction

then couldn't I put that into a map and have it use those values without making it lag???

Or am I missing something?

Actually GetUnitZ function already exists in wc3, it only is not exported to JASS,

It is called internally by Set/GetUnitFlyHeight to make sure units never
get below height zero.

We could probably nag blizzard about exporting this but I don't think it is going to help.

On the other hand this function can probably be generated with some tool like this:

You get all terrain node point heights with that tool,
and then convert those coordinates into a bunch of constants.
Those constants you store into SLK, and make some wrapper jass code around that to make the actual GetUnitZ.

So the question here is who is easier to nag here, blizz or PitzerMike :D

A tough choice

I already bugged mike :P ne ways I got a response and it seems like my idea is possible. If and when I get it working maby I could modify it to add the valuies to an internal slk file.

All this because of terrain deformation desyncs :/

This just screams 'preprocessor plugin for NewGen'.

However there are some open questions about the data storage and the jass interface.
Retrieval speed will most likely matter. So first of all, what's the required accuracy? In the terrain file the heights are stored in a grid of cells that are 32x32 in size each. So when retrieving the height of a specific point we'd have to interpolate between the 4 tilepoints (corners) that form the cell in which the point is. Now there are several options:

A) Store only the tilepoints height in arrays and interpolate in the JASS script at runtime whenever Z value is retrieved (accurate, but slow, doesn't take much storage space)

B) Store only the tilepoints height in arrays and never interpolate, just use the height of the closest tilepoint (fast, little space required, not exactly accurate because the point from which we get the Z value may be at max 16 units off the point for which we retrieved it)

C) Interpolate at compile time and store a more fine grained grid in the JASS script. (more accurate depending on how fine grained it is, more space required, fast retrieval)

Considering the jass max array size the finest we can get is a grid of cells 2x2 in size (if one row should fit in one array). So the retrieved point would at most be 1 off.
If you wanted to store all points precisely that would be 2 arrays per row. With the max map size of 480x480 that would be 960 arrays to hold all points. Less if the map is smaller of course.

Anyway if you can design the JASS storage and retrieval system I may help making the tool that generates the initialization JASS code using the map's terrain file.

Yeah.... that sounds like an incredible waste of time when all you have to do is stop using terrain deformations to avoid desyncs. Terrain deformations are laggy anyway.

Or just use global terrain deformations (non-local ones) and avoid spells which use terrain deformations.

Actually im going to use option D

I will make it get the Z value of every 64 points (the smallest unit that we does terrain with) so that would be lets say 128x128 = 16k points on a decent sized map. Then I would have an interpolate function that would take the points that would make a box around the target point and mathematically create a Z value.

As far as I can tell this would add a small amount of file size while at the same time being a pretty fast function.

Currently my main problem is working with the math to interpolate the points...

I got the formula and such just if anyone can help me understand the math and how to write said math into JASS I would appreciate it.


PS: I know it is stored in a 32x32 grid however 64 points is the smallest unit you can modify in the we and as such I would make 64 the default

EDIT: Also what if I didn't use arrays and instate used the point position for the variable name? (easier to make if you can make strings into variables) how much size would that add in comparison to using arrays? (make all the - into a _)

example:

The issue comes for graphics quality settings, IIRC. "Low" on one of the settings causes terrain deformations to not appear, thus creating desync. Could use gamecache to sync a z value with the host, but that would be rather slow. Just fecking give up terrain deformations.

Which is exactly why I said:

Sigh... If only blizzard made a function to set the spell detail for a player, or a method to remove the terrain deformations of certain hard-coded spells, then we wouldn't need to hack the game ourselves...

so for a map of size 480x480 it will take (4x4)*(480x480) array indexes
4 because size grid is 128 and map remembers 32 = (16 points per size grid)

that would take exactly 450 arrays to store all data
witch means that it will need roundUp(log2(450)) = 9

9 if statements to retrieve just one grid point,
and you would have to do terrain interpolation after that...

We can now officially mark this grid idea as impossible.

Cohadar mikes idea would not take one if statement :/ READ what he said before you post stupid stuff ~.~

PitzerMike would you explain it to him,
and give him some bad rep for arrogant behavior.

Well, it depends how creative you are.
If you're going to use arrays you'll need the ifs to decide (depending on the y value) in which array you have to look. The array index is directly related to the x value, so you don't need ifs there. So yeah, cohadar has already given the formula why you need 9 ifs if you're going to do it with arrays.

Of course there are other possibilities. Gamecache allows for n-dimensional indices. So you could directly use the x/y as the index for you stored Z values. Might be faster than the array solution.

Another option is a huge string whith a sequence of numbers of fixed length and then use substring + S2R to retrieve the data. Something like (x*width + y)*nr_of_digits will give you the position for the SubString call. In a sense we just simulate a float array with "unlimited" elements.

Here's an example, I'm rounding the Z values to whole numbers and use 5 digits for each value. So the range goes from 00000 to 99999. To get rid of the sign (negative heights) I'll just move 0 to 50000.
Exampe:
"50010500905095........"

The top left corner has a Z value of 10, the next point has 90, the next has 95 etc. Would have to see first, if jass allows for such large strings though.


Anyway I think you'd be better off with the default grid size of 32x32 and no interpolation at all. I think 16 tilepoints per cell (as WE uses them, ie 128x128) is accurate enough. Then just always retrieve the Z value of the closest tilepoint.

+1. this kind of stuff maybe be only needed for virtual terrains =) what can be used for my HW