[snippet]CliffBound

[Nestharus]

This resource has moved here.

--

gone

 

[Axarion]

Maybe add some sort of filter.

        public method update takes nothing returns nothing
            local unit u = GetUnitById(this)
            local real e
            set prevXc[this] = GetUnitX(u)
            set prevYc[this] = GetUnitY(u)
            call MoveLocation(loc, prevXc[this], prevYc[this])
            set e = GetLocationZ(loc)
            set cliffElevationc[this] = prevZc[this]-e
            set prevZc[this] = e
        endmethod

null the unit and it looks fine

 

[Nestharus]

Done

 

[D4RK_G4ND4LF]

this sure is useful but for me it was bugged
I went up a mountain like on the attached image (really don't know how to explain this in english words ) and was able to get to the top
when I tried again my unit went halfway up and then started bouncing all over the mountain just to stop at a higer position

maybe checking the height at all sorrounding positions could help (but this would also make things slower)

 

[Nestharus]

hmm.. code in demo map isn't latest

i'll check

edit
weird, it didn't used to do that o-o. I should have checked updated code ; D

edit
Updated and fixed

 

[Lambdadelta]

I like this. Looks handy o;

 

[Nestharus]

So I started using this in a map... 10.4 is way too low (was stopping on little hills, haha)

Does anyone know a good value? At the moment I'm trying 15-16. 32 seems way too high ;o.

edit
nvm.. I think imma just use SlopeSpeed and CliffFall : |, meaning I gotta finish Cliff Fall. Cliff Fall should dissuade people from jumping off of cliffs ; P.

 

[Nestharus]

After some fun terraining, doodad placement, and etc, I've finally figured out how surprisingly useful this thing really is.

In most situations, when you have stairs or steps or elevators, you have to spam pathing blockers around them to make it so they can only be entered in one side. This thing is a lifesaver for terraining : O.

Now, one thing that can also be done is making it so units can run under steps, but that's only useful for single player first person style (can't see from birds eye), making this useful for virtually every high quality terrain : O.

Another interesting this is that if the unit's fly height is != 0 (custom terraining), this thing won't interfere. I had primarily designed it with flying units in mind, but surprisingly it allows you to merge regular terrain with custom terrain (custom terrain being units that modify fly height of target, allowing for moving mario style platforms, or multi floor structures, and etc).

This is probably the most useful thing I've ever made...


After a lot of use, I decided a good value for change in z is 32. 32 is a pretty realistic step that a unit should be able to take. 64 would be half of your regular wc3 tile, which would be like a huge, huge step. 45 might even be a good value.

From my old tests on cliffs (watching change in z), I remember that some of the values went to around 48 for actual cliffs, meaning that 40 is probably a good safe, and realistic value to go (remember cliffs have a slant to them, and 128 is a complete vertical slant). 41.6 is probably the best value (128*.325), but I've yet to test it on a plateau of height 50ish.

Have fun with this everybody ^_-.

 

[D4RK_G4ND4LF]

don't know if your testmap uses the most recent code but it is still possible to get quite far by running in a /\/\/\/\ kind of way instead of --------------
didn't manage to get up much further yet but with some more time and more precise clicking it might be possible

 

[Nestharus]

where you ran up is a steep path ;P

 

[Switch33]

I dunno if you really tested your own test map. Cause for me it let me get to that super high cliff. Go to the left of it and keep clicking on the left so it keeps saying "Player 1 has hit a cliff," and then try and click farther out to the right. For some reason the unit jumps back further and further until you get to the top of the cliff meaning this system is useless until it's fixed.

 

[Nestharus]

edit
70% solved, I will apply the fix some time tomorrow.

edit
I need to ponder a bit more about this

 

[Tukki]

I implemented a similar system in Shadows of Everwood and ran into your problem.

The system that I wrote used point-order, though.
My fix was to create an offset from the targeted position by around 32-33 so that I could compare the z-slope between the unit and targeted position with the z-slope between the targeted position and the offset. Based on the result I could determine if the unit was approaching a cliff, trying to walk up on a cliff or approaching a hole etc.


It's not perfect but kinda works

 

[Nestharus]

Not perfect is not a solution ;P

Furthermore, that'll hella bug on destructables ;D.

 

[D4RK_G4ND4LF]

I implemented a similar system in Shadows of Everwood and ran into your problem.

The system that I wrote used point-order, though.
My fix was to create an offset from the targeted position by around 32-33 so that I could compare the z-slope between the unit and targeted position with the z-slope between the targeted position and the offset. Based on the result I could determine if the unit was approaching a cliff, trying to walk up on a cliff or approaching a hole etc.


It's not perfect but kinda works

I tried to make something similar (checking all points around the hero for height and applying acceleration based on that) but I failed because I made an error somewhere

now I tried it again and I did it!
with better adjusted values it might work even better
right now the acceleration is constant (does not depend on z delta) but it shoul not be too hard to change that

maybe it is helpful

 

[Nestharus]

That would fail with destructables/doodads present, would it not?

Also, what kind of overhead is incurred by checking points around a unit.

 

[D4RK_G4ND4LF]

That would fail with destructables/doodads present, would it not?

don't know since I didn't test it yet but usually wc3 recognizes the highest point of a model as terrain height so it should not work too bad
in worst case one could make sure there are no destructables and else handle it somewhow else

Also, what kind of overhead is incurred by checking points around a unit.

combined with your unit move list it should not be too much
but I think it could work with less points (like 3) and a static offset instead of cos and sin so it would not be much slower
another solution could be a single point rotating around the center
the average will probably look smooth if the rotation speed is fast enough

 

[Nestharus]

I'll look into it when I get a chance. I just have a lot on my plate at the moment with my new map project ; |.

 

[Nestharus]

I just figured out how to properly do this. In Terrain Editor, the smallest and highest points for terrain are always +-64 from the unit. When it comes to destructables, it's an instant change (+1 might go from z-height of 0 to z-height of 300).

Given this interesting fact, one can determine first whether the collision was a result of a destructable/height modifying unit or terrain and next stop the change regardless. It can also do allowed changes (destructable might allow a change of 64 where terrain might allow a change of 128).

Furthermore, when applying gravity instead of plain stopping, the unit can be given damage based on change in z and can be automatically pushed forward to the smallest point to maximize damage (so that they don't walk down a hill). In the case of slopes (steep but a change in xy), a bounce can be applied to them to add realism and further damage (bounce every time finished falling based on delta z).

The unit facing would not at all be used as the unit facing would just make the results inaccurate. With this technique, unit facing shouldn't be used.


I'll get to updating this when I can =).



@D4RK_G4ND4LF
Your solution was close, but you forgot about the +-64. If you had thought of that, I woulda done it ; P.

 

[D4RK_G4ND4LF]

@D4RK_G4ND4LF
Your solution was close, but you forgot about the +-64. If you had thought of that, I woulda done it ; P.

that's the static offset I was talking about

 

[Bribe]

This isn't even compatible with the latest version of UnitIndexer

 

[Nestharus]

I know, and it doesn't work at the moment either. I'll make an update to it eventually ;O.

It took me a long time to even figure out what fix was required for this ^_^, but now it's just a matter of me implementing that fix ;P.

 

[Bribe]

Let me know when this is ready to be revived.