[Snippet] GetTerrainZ | UnitZ

[Garfield1337]

GetTerrainZ

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

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.

 

[Zeatherann]

Commonly desyncs on mac with terrain deformations.

 

[Garfield1337]

That's more of a problem with deformations, and not the only one.

 

[Xonok]

Commonly desyncs on mac with terrain deformations.

This is a commonly known problem with GetLocationZ and the best known solution is avoiding deformations.

 

[Magtheridon96]

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.

 

[Xonok]

SetUnitZ is like flying in a proper projectile system? (AKA, height is universal, not compared to terrain)

 

[Zeatherann]

GetUnitZ will get the flying height of the unit + the terrain height. I'd imagine SetUnitZ will work similarly.

Edit: Why no SetTerrainZ?

 

[Xonok]

GetUnitZ will get the flying height of the unit + the terrain height. I'd imagine SetUnitZ will work similarly.

Edit: Why no SetTerrainZ?

In that case I like it, very useful indeed. (even though it's basic. I'm lazy afterall)

 

[Magtheridon96]

SetTerrainZ would require the use of terrain deformations, which have a lot of problems already (They cause permanent leaks and could desync Macs sometimes)

 

[Zeatherann]

Mag, can you post something to educate me on the leaks you mentioned?

And deformations alone do not desync macs.

 

[Magtheridon96]

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.

 

[edo494]

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 )

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)

 

[Nestharus]

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

 

[Zeatherann]

Why not inline AutoFly? Also; are you sure that terrain deformations are not rendered in fog? I know my terrain in Infection is rendered correctly.

 

[Nestharus]

cuz inlining auto fly is very poor design?

Also, I believe that the location can be constant

 

[Zeatherann]

How is it poor? It'll eliminate a function call.

 

[Maker]

Did you discuss SetDestructableZ?

 

[Nestharus]

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

 

[WaterKnight]

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]

seems very useful.
so if I would do something like:

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?

 

[ScorpioT1000]

Breaking news? =) clone thread I hope ...

 

[Magtheridon96]

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.

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.

 

[ScorpioT1000]

As I remember in ru community everybody used DGUI header, it contains the code above)

 

[Magtheridon96]

You use a whole pack of resources?

 

[ScorpioT1000]

No there are 3 libs... doesn't matter
btw I can translate dgui documentation bcz the library is really awesome and it is strange this is not popular here =(

 

[Magtheridon96]

I've made 2 attempts to completely rewrite DGUI before.
I failed because I lost motivation and because I had other things to focus on :/

 

[edo494]

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

 

[Almia]

How about some EffectZ or DestructableZ with Otip height manip? Look at Purgey-poo's lib in wc3jass.com

I was going to post that this would be graveyarded just like what happened to overcold_ice's resource.

 

[Magtheridon96]

~ Modularity has no limits ~
Modularity is God

Also, I love splitting things into many libraries. My Game Engine has
over 200 source files at this point.

 

[Almia]

God, that purple color is too annoying. I'll use Braille than that color.

 

[ScorpioT1000]

Modularity has standards, for example you can create module "Geometry" and add some kinda Matrix and Vector funcs but the Location and Unit funcs should be placed separately. Actually they be in Unit and Location classes if jass would OOP lang

 

[Magtheridon96]

vJASS gets us close, but the OOP-mimicking facilities don't satisfy us :/

 

[WaterKnight]

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

I also have that GetTerrainZ or for me it's Spot.GetHeight bundled with other terrain-based functions like deformations, getSlope/normal or pathing.

 

[Zeatherann]

If this is split into five or so different libraries will it run faster than if it was all inlined?

Please post compiled jass code of such a library to prove either side.

 

[edo494]

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

 

[Xonok]

For me the whole point of modularity is to make things easier to modify/import/understand.
Making a separate library for just 1 function seems baaaad in that light.

 

[Zeatherann]

I ment inlining the function call that adds/removed crow form from the unit. This makes it faster.

At least make 'autofly' optional

 

[Nestharus]

I see no urls

*    */uses/*
*        */ AutoFly /*
*        */ GetTerrainZ /*

and no, including AutoFly won't make it any faster...

 

[Garfield1337]

Hm, there are multiple AutoFly-s. The one on Hive uses UnitIndexer which isn't used by everyone (though I guess I'll link that one).
GetTerrainZ needs no link atm, if this gets split up in 2 threads, then I'll add link.

 

[Nestharus]

Link to whichever AutoFly you want, you can even link to multiple AutoFly libs, it doesn't matter, just link to one so that people don't have to hunt for it

 

[Magtheridon96]

Approved. Grats.

Add the AutoFly link to wrap this up.

 

[Nestharus]

I thought that it's against policy to approve multiple resources in 1 thread...

it's never been allowed before, so why the sudden exception?

 

[Magtheridon96]

They're too closely related to be segregated. It's like how we put AndByte and And32 in the same thread :/

 

[Zeatherann]

Still no proof Nes, and I know no one will listen to me due to my hate of vJASS and your shining popularity Nes.

 

[Nestharus]

Still no proof Nes, and I know no one will listen to me due to my hate of vJASS and your shining popularity Nes.

because what ur proposing is absolutely ridiculous, it doesn't need proof, lol

 

[Yixx]

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)

 

[WaterKnight]

Amrf only works due to being a morphing ability with a flyer as target shape btw.

 

[Zeatherann]

Oh, inlining is only useful if you inline functions that aren't called everywhere.

Anyways: I learned this lib doesn't call AutoFly, or even use it, just requires it is included so units (any unit) can have their flying height set.

 

[AGD]

    function GetUnitZ takes unit u returns real
        return GetTerrainZ(GetUnitX(u), GetUnitY(u)) + GetUnitFlyHeight(u)
    endfunction

Syntax Error Nevermind

Anyway, we have more standard library here that covers all the things here. Moving to Graveyard.