More thoughts on determining the altitude (height) of a unit

A while back, I was playing around with the w3e file inside maps to learn about how WC3 handles height inside the game:

http://www.wc3campaigns.com/forums/s...&threadid=9243

It occured to me that this may be the key to creating a system that lets you determine the height of a given position inside the game itself using triggers.

To take a step back, in theory, the most accurate way to assess heights in a map as it stands right now is to create a series of regions for each height variation, and then query units to see which region they're in and assess height from there. Simple math, though, tells you that there are over 1000 possible regions on even a tiny map, to say nothing of large ones. Doing things this way in-game would be impossible if the map were covered with areas of varying height.

But what if we opened the *.w3e file beforehand, and could derive the height data from there? In the w3e format, for those who don't know, the height of each tile is listed (the value refers to the height of the intersection between two grid lines). This is the minimum region size, so if this could be used the two methods would be equivalent.

I'm imagining a program (or series of programs) that could read the height data out of the w3e file and output it as a series of strings. In WE, I could then write a moderately simple trigger that
1) found a unit's position on the map
2) compared that position to the closest height value (the height of each tile on the map would be read in as a string array, each string being a horizontal list of heights)
3) compared that value with values of adjacent tiles to determine the precise height of the point.

One cool application of this would be for naval units. Because water level is also stored in this data, a similar trigger could determine easily if the target point of a move order were above water level.

In terms of creating the program, I am limited to visual basic out of a MS application like excel, but in a certain sense, that's logical at least for a crude program, becuase this data exists in Excel-like "cells" that Excel would have an easy time manipulating.

If anyone has any info or suggestions about this, let me know.

You're gonna have to lookup a max string size. Arrays are really only stable up to 1023 (messing with arrays higher than that has a tendency to cause random glitches from my experience), so a 2-d array wouldn't be terribly practicable. I'd recommend writing a JASS function to compliment the program that would be able to check which grid intersection a unit is nearest to, and then using that height.

Now, besides max array size problems, another one would be memory. War3 has already loaded all the terrain heights into RAM once -- now you're gonna do it again. It might be easier to solve that problem with a simple startup scheme:

-Have the program write everything into those variables
-Then at melee init, it dices it up and stores it in the game cache.
-Game sets original string to ' '
-Then throughout triggers mapper refers to game cache instead of directly to a variable.

This way not all the terrain points are constantly loaded into memory. You should be able to determine which tilepoint is closest to the unit without having to load all the values from the game cache, just make it so that the x/y position of the unit corresponds to where it is in the cache (use convert integer to string). Just make label the x value and category the y value, or something like that.


Really bitchin' idea :D

Without trying, of course, I can't be sure, but I don't think this'll be much of an issue, at least with smaller maps. The height information is stored in the w3e file as a 4 byte number (there's only one number per grid intersection). It would be weird to store it in hex , but if needed, a simple trigger could convert, I hope. So that means a max of about 4 characters per tile. Considering that the smallest maps are 32x32, that means you can get all the way up to 250x250 before you start running into string length problems if string length of about 1000 is an issue (I *know* that strings around 500 are ok, at least). The other dimension is even easier, since 480 is the largest map size (?) and I only need 1 line per tile.
In terms of size 481*481*4 is still less than 1 MB, which is farsmaller than the size of such a map as it is. Anybody that can hold such a huge map in ram (I can't on 128MB) should have no problem with an additional mb. And for smaller maps, the amount of space is smaller. On my 32*32 map, the amount of space used by such an array is less than 5kb.
So this should be practical as it stands right now. Except for the minor matter of *coding* it of course :)

Oh, one correction. The cliff height data is also stored in this file, and presumably, that would have to be added directly to height, or incorporated in the array if there's no other way.

One thing you forget about in your size calculations is that JASS is a scripting language. Since it's not native code, there is no reason to assume arrays are stored linearly and packed... For all you know, it might store each number in the array as a text string, which means a number like 5000 could take up 5 bytes, or even 9 (4 for the characters, 1 for nul, 4 for length as integer), which means it could end up taking a LOT more space than it `needs` to. You might be thiking "but why tf would they do it like that?"... For the same reasons they did so many other messed up things in jass(aka nobody knows) =-)

Of course, they could have done it the intelligent way, but that seems unlikely.

A solution to this problem would be invaluable for the mod I'm creating. The FPS mod. We need to determine a units height for things like camera corrections, jumping, and shooting a units on a diffrent hieght. Out programing is completely set up to work for height by right now all the heights are set to 0 and we are forced to create flat maps. We have been unable to detect height except for detecting the camera z of a camera locked on a unit. Only thing is this won't work because we need the z of both the shooter and the target. We currently run an executable alongside the game to detect keys and mouse movement and i'm shure it could be manipulated to do whatever task you think nessecary. Any help in this department would be greatly appreciated.

All done :)

I have a map here that will display the height of a single unit as it walks across a complicated landscape.

A few comments about the map:
As I mentioned above, I used a hex editor to get this map's w3e file, and converted it to text. Next I went into Excel, and using it's visual basic, wrote a short program which processed the text into usable form, and outputted a database in a format that jass could read.

In a map, each tile is defined by its 4 corners. These corners are what the w3e file keeps track of. So I have a string array full of statements like:
set udg_Height[32]="20004200042000420004200042000420004200042000420004200042000420004200042000420004200042000420004200 0420004200042000420004200042000420004200042000420004200042000420004"

There are 33 5 character "numbers" per line, and 33 lines total (My map is 32x32). The first 4 characters represent the hex of the "true" altitude (this is different than what appears in WE). The fifth character is my way of representing cliff heights and ramps as a single character.

I have a fairly simple program in this map that can read this database, and output WE-style heights (the ones we're all used to dealing with). At least with this small demo version, there is no lag to speak of, and the program has no trouble recalculating height every .3 seconds.

One thing about this map is that it only displays the height of the vertex nearest to the unit. It *doesn't* interpolate height from nearby vertex heights. In other words, each tile will have the same height value at all points. In the future, I hope to make it so that the program will calculate the *precise* height of a given point.

At the moment, my Excel program is geared for 32x32 maps, as is the jass trigger inside this map (feel free to dissect it yourselves). Excel has a limit of 256 columns, so maps above this size cannot be done with Excel. I will try to make my program more customizable in the future. I'll be happy to share the programs I used, but I'd be even happier if somebody more knowledgable in a programming could make a stand-alone version of this which didn't require Excel.

Let me know if anybody has any questions or comments.

WE've been doing Arena at the biggest right now at 96 x 96, and we probably won't go any higher than 128 x 128. I'll see what we can do with the FPS mod on this for camera height, but it might get a bit complicated........

This program has great potential. I guess I'm going to need another hex editor since my current one won't open w3e for some odd reason. Once you get the map to detect the height at any given location it will be perfect because where it stands now if you use say a large ramp it just finds the avergae height of the ramp and thinks no matter where you are on that ramp its the same number. Other then that the idea was outstanding and I'm thouroughly impressed. I just hope this method can work for multiple units simultaneously without lagging or locking up.

Yeah, as it stands right now, all ramps are assumed to be at a height of 64 over the cliff height. Still, it's not so terrible for most uses unless you need really exact heights. When I get around to doing an interpolated version, that'll be adjusted according to surrounding cliff heights and ramps. And of course, it'll (try) to interpolate horizontal positions also. I'll try to have a newer version which does these things, and a program that is more user friendly hopefully by next week.
I haven't really checked, but I suspect this function can be run fairly frequently without bogging things down. As it stands right now, it's run every .3 seconds without any noticable problems. The code itself is fairly simple, so with luck it can run a few times a sec in the background if needed.

I think we should make a stand alone program that opens a map and inserts that code into a custom function inside.