• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • ✅ Time to vote for the top 3 models! The POLL for Hive's 6th HD Modeling Contest: Mechanical is now open! 📅 Poll close on July 16, 2024! 🔗 Cast your vote now!

[Snippet] GetTerrainZ | UnitZ

Level 20
Joined
Jul 6, 2009
Messages
1,885
GetTerrainZ

JASS:
library GetTerrainZ /* v1.0.0.0
********************************************************************
*
*    function GetTerrainZ takes real x, real y returns real
*
********************************************************************/

    globals
	    private constant location L = Location(0, 0)
	endglobals

    function GetTerrainZ takes real x, real y returns real
        call MoveLocation(L, x, y)
        return GetLocationZ(L)
    endfunction

endlibrary

UnitZ

JASS:
library UnitZ /* v1.0.0.0
********************************************************************
*
*    */uses/*
*        */ GetTerrainZ /*
*    */optional/*
*        */ AutoFly     /*      hiveworkshop.com/forums/jass-resources-412/snippet-autofly-unitindexer-version-195563/
*
*    function GetUnitZ takes unit whichUnit returns real
*    function SetUnitZ takes unit whichUnit, real z returns real
*
********************************************************************/

    function GetUnitZ takes unit u returns real
        return GetTerrainZ(GetUnitX(u), GetUnitY(u)) + GetUnitFlyHeight(u)
    endfunction
       
    function SetUnitZ takes unit u, real z returns nothing
        call SetUnitFlyHeight(u, z - GetTerrainZ(GetUnitX(u), GetUnitY(u)), 0)
    endfunction
       
endlibrary

This thing has been recreated over and over again, it's time to standardize it.
 
Last edited:
Note

So Garf and I were discussing this all day and we got input from Nestharus and Statharas about the issue of the Z function libraries always being rejected for being too simple and how a perfect Z library should be made so people don't pollute resources with all kinds of variations of them and so there could be one unified set of functions that does the work.

Anyway, we decided on 3 functions:
- GetTerrainZ
- GetUnitZ
- SetUnitZ

The argument for GetTerrainZ's name was pretty long and spanned about an hour arguing about the meaning of "GetPointZ" and the good expressiveness of "GetTerrainHeight". Stat came in and suggested GetTerrainZ and we all liked it, so we just went with that.

Only thing we're not sure about is the organization (Should this be 2 libraries instead of 1)?
We're also not very sure about the library naming. ZUtils is a good placeholder until we can find a decent name.

So yes, this is not another "I'm going to post a short library because I can" resource.
 
I don't recall the Deformation API though.

If you were to create many terrain deformations, you would find that RAM usage in Wc3 is increasing. It's silly :/

Yeah, specifically, it's when you have terrain deformations and you're getting the Z of the location. At least, this is what I remember from those posts Troll-Brain made.

He knows more on the matter than I do. A lot of people do.
 
Level 23
Joined
Apr 16, 2012
Messages
4,041
afaik I think that you desync when you try to use Z point of location that is being deformed and is not rendered for all players
the problem is that terrain deformations are not rendered in fog and GetLocationZ retur z currently rendered height ignoring deformations in fog which causes GetLocationZ to return something else for everyone causing desynchronisation of the game(even in common.j there is note that you should only use GetLocationZ in local code)

even if it didnt desync, it would be weird to reveal the part of the map and see unit flying underground, wouldnt it?

This is 96.4512% accurate why it desyncs(Im leaving some percents just so if Im wrong :D)

also mag you wew saying that you want this to be perfect but there is documentatiin missing for SetUnitZ(add crow form to unit to allow this function to work)
 
Level 31
Joined
Jul 10, 2007
Messages
6,306
How is it poor? It'll eliminate a function call.

#1: no it won't

#2: inlining manually is not a good programming practice, leave that to compilers if they support it, otherwise don't inline

#3: inlining wasn't the reason for bad design, it was the coupling, just like how the unit stuff is currently coupled with the terrain stuff

minimize coupling, maximize cohesion

this resource, in its current state, is breaking all of the rules, and you are wanting it to break even more rules ;p

mag'll know what i'm talking about here, so i'll just leave it to him to deal with this


also did not discuss SetDestructableZ
 
Level 26
Joined
Aug 18, 2009
Messages
4,097
edo494 is correct, GetLocationZ depends on the rendering state as players do not see the deformation through the fog either. That is, the final result of permanent deformations is forced through the fog but the transition and temporary variants are not and do get reset when rendering is aborted.

You won't see a unit fly underground though or how do you want to display it without the terrain below it?
 

Chaosy

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,198
seems very useful.
so if I would do something like:

JASS:
local real r = GetTerrainZ(x,y)
call SetUnitZ(someUnit, r + 300)

this would set the fly height to 300 over the terrain no matter where you are?
(no need to comment on syntax errors, wrote it on the phone)

oh and what do the call MoveLocation do and where do you get the l variable from?
 
Last edited by a moderator:
ScorpioT1000 said:
Breaking news? =) clone thread I hope ...

Of course.

The only purpose of this resource is so that we actually have a GetTerrainZ function to use in public resources so we don't have to always use our own in the code (It's better to have all libraries use one GetTerrainZ function than to have each library come with its own)

Split these two sets of functions apart. They don't belong in one resource.

Require AutoFly for the unit z one.

All in one packs are a no go

The z lib for units should require the z lib for terrain

I knew you'd say that.
Only reason Garf didn't do that is so only 1 location handle is created.
(Aesthetic shit, really doesn't matter)

So yeah.

JASS:
library GetTerrainZ
    function GetTerrainZ takes real x, real y returns real
endlibrary

library UnitZ requires GetTerrainZ, AutoFly
    function GetUnitZ takes unit u returns real
    function SetUnitZ takes unit u, real z returns nothing
endlibrary

That's better now.
You know what to do Garf.
 
Level 23
Joined
Apr 16, 2012
Messages
4,041
lol I think it is pointless to have library with 1 function called GetPointZ and having function GetPointZ, I would rather write my own private function in that case, Im not going to open 6 different threads just because of the fact people want to be so modular that they will soon put local variables into modules in separate libraries

Modularity is great, but there are limits to that
 
Level 26
Joined
Aug 18, 2009
Messages
4,097
I knew you'd say that.
Only reason Garf didn't do that is so only 1 location handle is created.

Write another required lib then that only provides a dummy location :ogre_hurrhurr:

I also have that GetTerrainZ or for me it's Spot.GetHeight bundled with other terrain-based functions like deformations, getSlope/normal or pathing.
 
Level 23
Joined
Apr 16, 2012
Messages
4,041
the fact that something is in other library doesnt mean it will be slower, it will generate the same function call as if it would in one library, it will be just more split

Im partly fan of modularity but Im not fan of spliting everything up so that even every line of code is in its own module etc
 
Level 16
Joined
Oct 12, 2008
Messages
1,570
Though I feel no love for Nestharus, I must agree here with him, and disagree with you, Zeatherann. Using resources that have been tested, useful and implemented before is almost always better. The most simple example I could think of right now where your method would fail would be one where there seems to have been a bug in the AutoFly library (maybe due to a Blizzard update?) so that it's functionality is useless or has reduced functionality. Nestharus (Or any writer of another AutoFly library) would only have to update the resource, whereas you would have to search through your code (which can become a nasty work when doing big projects) for every instance of where you have inlined AutoFly, thus doing alot of work yourself, where you could have just let Nestharus have done it, so you would only have to update 1 resource. Alternatively you could try to fix the resource yourself, meaning even then there would be less work because, as a project grows bigger, you will more likely be using the resource more and more, meaning YOU would be inlining alot of shit, doing tremendous extra work when indeed there seems to be a problem with the resource.

(And as you might have noticed: Nowhere have I said anything about (v)JASS specific, only examples taken from it, as the principle remains over different domains, even outside Programming/Computer Science)
 
Last edited:
Top