[Snippet] Is Pathable

[Nestharus]

But then you have masses of overhead on the creation/destruction of units...

 

[Magtheridon96]

This was tested by mag I think.

It was? This "mag" you speak of sounds handsome and dashing. <3

There's just a dummy unit, and it has a custom inferno ability with 4 levels (different collision sizes for each summon). I order him to cast to a certain point, and if the IssuePointOrder returns false that means that that point is not pathable for that specific collision size. And it works. The only thing is that it ignores trees, but you could most likely get the same result with a Pocket Factory which would not ignore trees.

Sounds like a nice idea.
I wonder if there are any cons.
This would make IsPathable ~2x faster if it works.

edit
Oh, Nes posted while I was typing
Couldn't we order the dummy unit to stop afterwards?

 

[Nestharus]

This would make IsPathable ~2x faster if it works

No it wouldn't.. it'd make it 1/4 speed or slower -.-.

 

[Bribe]

@Nestharus,

I set the ability's cast time to something crazy, like 99999, so it would never cast. So there's never any unit that has to be created or removed for that matter

 

[Nestharus]

I see, so you just order the unit to stop then if it worked?

Ok... and it would cast properly based on the unit pathing of like pocket factory? I'll update IsPathable to work off of that ^)^.

 

[Bribe]

Well I have not tested pocket factory but I imagine it works quite like Inferno, without ignoring trees that is, because it's like sampling a region for a unit's pathing without the unit actually existing.

 

[Magtheridon96]

When you're done, I'll test IsPathBlocked's processing speed

 

[Nestharus]

Bribe, your idea fails.. it only checks for unit obstructions and terrain *walkability*. Your idea will fail with pathing blockers.


I suggest you fix your knockback sys accordingly ; ).


And yes, I tested Inferno as well and it failed in the same scenarios, meaning that your knockback system is currently buggy.

edit

The thing is IssuePointOrder will return false in the case of bad pathing.

Furthermore, I decided to test the ordering idea since you so fervently claim that it works. Well, guess what, it doesn't. It does exactly whoever said it would do.. the unit is ordered, then the unit is ordered to stop.. the order returns as a success -.-... I completed blocked the unit off so it couldn't move and ordered it and got the message "Success," meaning that the order returned true. Furthermore, I tried ordering it in game, and sure enough, the little moving icon was highlighted and then the stop icon was highlighted, meaning that it tried to move and then was ordered to stop.

My suggestion... don't defend your claim unless you've actually seen it work ;p.

Btw, guessing you might have meant that the unit order fails when it is on bad pathing rather than blocked by bad pathing, I covered the unit in towers. It has always been my experience that when the unit is on bad pathing and it is ordered, it will instantly jump to the nearest good pathing. I tried ordering it and guess what happened? It jumped and the order returned true.

I also tried order the unit to its current position (the bad pathing position) and it still jumped and the order still returned true.

You have this habit of saying something is true w/o ever seeing for yourself if it's true... and then you continue to say what you say is true until someone proves you wrong... I don't much appreciate your philosophy of, "I'm right until you prove me wrong."


Idea for using Pocket Factory: Rejected
Idea for using Inferno: Rejected
Idea for using Orders: Rejected

Case closed.

 

[Bribe]

Alternatively you could probably get away with the "inferno" point-order trick

Read the disclaimer next time, and stop trolling with your "case closed" egotism.

 

[Nestharus]

Read the disclaimer next time, and stop trolling with your "case closed" egotism.

Ah, I was just assuming that you were assuming that it worked ; P, my bad ;D.

edit
was just in a very bad mood after spending time changing IsPathable to work with all of the suggestions and finding out that none of those suggestions worked ;p.

 

[Bribe]

I do similar useless stuff and get that feeling of wasted time as well. But you don't fail 10,000 times you simply find 10,000 ways that don't work.

 

[Nestharus]

Improvement to script (pause units)

Various fixes to object generation

 

[Almia]

Based on what i have read in the LUA script,does this uses 6 dummies of different movement types for pathing?
and also how do you get the dummy's raw code id?

 

[ScorpioT1000]

> GetUnitX(u)==x

IEEE 754 floating point precision? no, never heard...

http://www.php.net/float

 

[Magtheridon96]

That doesn't mean anything, two floats can still be equal.

An epsilon is not needed in this context because the path check requires that the floats be exactly identical, meaning no modification is done to the coordinates passed to SetUnitPosition function by the War3 Engine's pathing/collision system.

Hence the equality operator.

If he used an epsilon, this would be an invalid pathing check.

 

[ScorpioT1000]

That doesn't mean anything, two floats can still be equal.

An epsilon is not needed in this context because the path check requires that the floats be exactly identical, meaning no modification is done to the coordinates passed to SetUnitPosition function by the War3 Engine's pathing/collision system.

Hence the equality operator.

If he used an epsilon, this would be an invalid pathing check.

SetUnitPosition (btw VERY FK SLOW FUNCTION, kills the big system already on 0.08 period) doesn't "just set coords", the passed x,y are just assumed coordinates to place unit, not the final. There are many checks and corrections before placing unit on the map.

 

[ScorpioT1000]

Create/Remove dummy instead of SetUnitPosition to check point's path, it's much faster

 

[Magtheridon96]

SetUnitPosition (btw VERY FK SLOW FUNCTION, kills the big system already on 0.08 period) doesn't "just set coords", the passed x,y are just assumed coordinates to place unit, not the final. There are many checks and corrections before placing unit on the map.

The corrections are only done when needed.
(If the area around the position passed in with a radius equal to the collision radius of the unit is unpathable, the coordinates are corrected)
When they are not corrected, the point is pathable (The floats need to be exactly identical)

CreateUnit is faster

It's counter-intuitive that creating a unit would have less overhead because internally, I'd expect that they still have to do the same checks that SetUnitPosition does upon creating the unit to make sure it's placed properly.

// It appears that in the most minimal form, CreateUnit has 1 less character.
// This shouldn't affect the JASS interpreter very much however, so we can ignore 
// speed differences that have to do with the VM running JASS.
CreateUnit(a,b,c,d,e)
SetUnitPosition(a,b,c)

As for the implementations, I wouldn't know.

Benchmarks are called for at this point.

So. Who's willing to do them? :3
(I don't have Warcraft III or a World Editor at the moment, so I can't test anything for real)

 

[Nestharus]

CreateUnit will run UnitIndexer events and so on... that's a no go

Faster? no, not even, lol

edit
and .... this system does work, so u arguing that it won't work is a mute point because it already does work, so what exactly is ur argument again? and if u say it won't work again, imma slap you

 

[Bribe]

lol, CreateUnit is perhaps the slowest function in the game. Let's try to keep the recommendations realistic.

 

[ScorpioT1000]

Prove it with tests please =)

> CreateUnit will run UnitIndexer events
This is third party problem ...

 

[Almia]

@ScorpioT1000
This is Hive not xgm.ru

Btw, I just noticed that xgm.ru resources are a bit outdated.

 

[ScorpioT1000]

Where am I trying to put xgm resources ?

 

[Bribe]

Prove it with tests please =)

> CreateUnit will run UnitIndexer events
This is third party problem ...

Many of us have worked with created units being extremely hard calls. SetUnitPosition, which I have used extensively, doesn't lag my Atom N450 even with a hundred calls per second. CreateUnit will lag after even a dozen calls, and worse if they happen in the same thread. A hundred CreateUnit calls delays my whole game by 2-3 seconds.

If you need to convince yourself, set up a benchmark. But don't expect us to go on a wild goose chase proving or disproving your hypotheses.