Guard Posts v1.3 [GUI] - AI System

[Moderator]

Guard Posts v1.3 | Reviewed by Maker | 23rd Jul 2013

Approved

This is a useful system Don't make units face angle, if they are already approximately facing the angle. It makes them twitch Remove the asdaf debug message from Guard Post Remove AI - Ignore GP_GuardingUnit's guard position doesn't work on heroes

[tr]

Hidden 10th Nov 2011 Bribe: "GPostLooper1" and "GPostLooper2" should "return nothing". I am not even sure how it compiles the way you have them return false. This should use FirstOfGroup loops not filters, no need for the filters, just use "null". The public API should be more readable, like "GuardPostSetUnit". Your internal codes can have the less readable prefix "GPost" but having it more clear for the users also helps distinguish their presence.

 

[Magtheridon96]

Mckill, I really wish you'd do something with structs

 

[baassee]

You really should post the function in JASS and explain all their parameters as no one will get your example right now (GUIers) and especially not demo 2 as it uses coordinates which GUIers don't use. Please change the demo 2 using a location instead and just use GetLocationX/Y in the function call.

A bit more down here:

-if distance > udg_GPostReturnOffset

Skip the squareroot and just set udg_GPostReturnOffset^2 instead.

-I know that GUIers don't mess with the hp but still IsUnitType(whichunit, UNIT_TYPE_DEAD) is safer than the GetWidgetLife check (or you can use both, Bribe will complain about it either way so )

-Instead of "not IsUnitEnemy" use IsUnitAllie (or how it's spelled)

-Why do you use a trigger and attach a timer event to it + conditions? Just use two timers instead.

Anyway I like the idea of the system although using this with lots of units will make every 3 second lagg when it re-orders the units and lots of orders equal to lagg.

 

[Deuterium]

okay this should most probably lead to an argument, but there are two schools regarding to this:

function GPostGetDistance takes real x1, real y1, real x2, real y2 returns real
    return SquareRoot((x2-x1)*(x2-x1)+(y2-y1)*(y2-y1))
endfunction

could be:

function GPostGetDistance takes real x1, real y1, real x2, real y2 returns real
    local real x = x2-x1
    local real y = y2-y1

    return SquareRoot(x*x + y*y)
endfunction

as to my own opinion, the second method is better since ur calculating each of the 2 differences only once... some people however argue that creating the locals would be basically cancelling the effect of time gained by reducing the calculations..

 

[mckill2009]

@Mags

I've created a vJASS for this as an inpiration from my EngageSystem but decided to post this version instead.

@baassee

You really should post the function in JASS and explain all their parameters as no one will get your example right now (GUIers) and especially not demo 2 as it uses coordinates which GUIers don't use. Please change the demo 2 using a location instead and just use GetLocationX/Y in the function call.

I'm not really good in explaining things but I'll try harder next time ...
I'm just gonna make an optional location as well...

- if distance > udg_GPostReturnOffset

Skip the squareroot and just set udg_GPostReturnOffset^2 instead.

>>>pls explain further on how to achieve this without using squareroot?...<<< NVM

-I know that GUIers don't mess with the hp but still IsUnitType(whichunit, UNIT_TYPE_DEAD) is safer than the GetWidgetLife check (or you can use both, Bribe will complain about it either way so )

-Instead of "not IsUnitEnemy" use IsUnitAllie (or how it's spelled)

Yeah Bribe is a perfectionist, lol!, sorry bribe ...

-Why do you use a trigger and attach a timer event to it + conditions? Just use two timers instead.

hehe, no comment, I'll just change it next...I thought It'd be easier...

Anyway I like the idea of the system although using this with lots of units will make every 3 second lagg when it re-orders the units and lots of orders equal to lagg.

Next I'll just add a condition on WHEN the unit will move/follow...


In all thank you guys...


EDIT:
@Deuterium
Thanks...I did that to reduce lines not knowing which is better, however if the 2nd method is better, then I'll edit that...

 

[Orcnet]

What a great spell! >)

 

[Bannar]

All the GetWidgetLife(u) < 0.405 should have been replaced with:

if not IsUnitType(u, UNIT_TYPE_DEAD) and GetUnitTypeId(u) != 0 then
    // unit is alive
endif

You can use statement about as function, so instead of using 'if' everytime just call the function which returns boolean depending if unit is alive or not:

function GPostIsAlive takes unit u returns boolean
    return not IsUnitType(u, UNIT_TYPE_DEAD) and GetUnitTypeId(u) !=0
endfunction

To omit convertion string into order use ById function types:

call IssueTargetOrder(u, "attack", target)
// ->>
call IssueTargetOrderById(u, 851983, target)

call IssuePointOrder(u, "smart", x, y)
// ->>
call IssuePointOrderById(u, 851971, x, y)

Deuterium mentioned about Square root will make calculation faster although:
- square root seems to be one of slower functions. To get rid of it you can:

• Set GPostReturnOffset = 200.00
• // user sets stuff, and on the bottom:
• Set GPostReturnOffset = GPostReturnOffset x GPostReturnOffset

Now in script:
- remove GPostGetDistance() function.
- in GPostReturn remove 'distance' local and do

if (udg_GPostX[i] - x) * (udg_GPostX[i] - x) + (udg_GPostX[i] - y) * (udg_GPostX[i] - y) > udg_GPostReturnOffset then
    // is out of range
endif

GPostPeriodic() needs similar healing, but in this case locals x1, y2 and waste of memory. You are using those only once anyways:

local real x1
local real y1
set x1 = x + 200 * Cos(angle)
set y1 = y + 200 * Sin(angle)
call IssuePointOrder(u, "smart", x1, y1)

// ->>
call IssuePointOrder(u, "smart", x + 200 * Cos(angle), y + 200 * Sin(angle))

Function GPostFindEnemy() - I really feel like declaring two locals + calling GetFilterUnit() is slower than calling GetFilterUnit() two times:

function GPostFindEnemy takes nothing returns boolean
    local unit u = GetFilterUnit()
    local boolean b = GetWidgetLife(u) > 0.405 and IsUnitEnemy(u, GetOwningPlayer(udg_GPostTempUnit))       
    set u = null
    return b
endfunction

// ->>
function GPostFindEnemy takes nothing returns boolean
    return GPostIsAlive(GetFilterUnit()) and IsUnitEnemy(GetFilterUnit(), GetOwningPlayer(udg_GPostTempUnit))       
endfunction

Interval within call TriggerRegisterTimerEvent(udg_GPostTrigP, 3.0, true) (for both triggers) should be constant function at the top.
Additionaly: you might consider raplacing time-events with timers.

 

[mckill2009]

tnx spin but most of the one you mentioned except the "IsUnitType(u, UNIT_TYPE_DEAD)" and the last one, damn...your fast ...in the next update Ima apply all of it although Im not sure about this...

if (udg_GPostX[i] - x) * (udg_GPostX[i] - x) + (udg_GPostX[i] - y) * (udg_GPostX[i] - y) > udg_GPostReturnOffset then
    // is out of range
endif

coz Im planning to put it in a separate function rather than inside the main code itself...

 

[Bannar]

Post updated.

coz Im planning to put it in a separate function rather than inside the main code itself...

If you are willing to use calculation more than once, go ahead, but still omit the SR.

 

[Magtheridon96]

function GPostGetDistance takes real x1, real y1, real x2, real y2 returns real
    local real x = x2-x1
    local real y = y2-y1

    return SquareRoot(x*x + y*y)
endfunction

->

function GPostGetDistance takes real x1, real y1, real x2, real y2 returns real
    return SquareRoot((x2-x1)*(x2-x1) + (y2-y1)*(y2-y1))
endfunction

This way, it inlines and you can avoid creating 2 locals and the huge overhead of a function call.

 

[mckill2009]

Spin, declaring two locals is more efficient vs. getting the GetFilterUnit() and calling another function...

you might consider raplacing time-events with timers.

baassee already suggested, which Im doing btw...

Ima test the 'without' SR thing...

Mags, I already done that....

 

[Bannar]

@mckill2009 I haven't read baassee post, sorry baassee <3

And no, you are mistaken:

function GPostFindEnemy takes nothing returns boolean
    local unit u = GetFilterUnit()
    local boolean b = GetWidgetLife(u) > 0.405 and IsUnitEnemy(u, GetOwningPlayer(udg_GPostTempUnit))       
    set u = null
    return b
endfunction

// Should be:
function GPostIsAlive takes unit u returns boolean
    return not IsUnitType(u, UNIT_TYPE_DEAD) and GetUnitTypeId(u) != 0
endfunction

function GPostFindEnemy takes nothing returns boolean
    local unit u = GetFilterUnit()
    local boolean b = GPostIsAlive(u) > 0.405 and IsUnitEnemy(u, GetOwningPlayer(udg_GPostTempUnit))       
    set u = null
    return b
endfunction


// And my idea is a bit faster:
function GPostIsAlive takes unit u returns boolean
    return not IsUnitType(u, UNIT_TYPE_DEAD) and GetUnitTypeId(u) != 0
endfunction

function GPostFindEnemy takes nothing returns boolean
    return GPostIsAlive(GetFilterUnit()) and IsUnitEnemy(GetFilterUnit(), GetOwningPlayer(udg_GPostTempUnit))       
endfunction

GetWidgetLife() isn't accurate, you must ensure if unit is truly dead.
Why GPostIsAlive() function usage? In case you are checking if unit is alive many times. Function seems to be more handy that writing everything manually.



@Maggy, you nob ;S You can omit the square root, read my post.

 

[mckill2009]

dude, UNIT_TYPE_DEAD is fine, but Im not talking about it but the GetFilterUnit() which is suppose to be stored in a local, like...

function GPostFindEnemy takes nothing returns boolean
    local unit u = GetFilterUnit()
    local boolean b = GPostIsAlive(u) and IsUnitEnemy(u, GetOwningPlayer(udg_GPostTempUnit))       
    set u = null
    return b
endfunction

BTW you really cant do this >>> GetUnitTypeId(u) coz it will error that integer, it should be...

function GPostIsAlive takes unit u1, unit u2 returns boolean
    return not IsUnitType(u1, UNIT_TYPE_DEAD) and u1!=u2 and not IsUnitEnemy(u1, GetOwningPlayer(u2))
endfunction

 

[baassee]

GetWidgetLife is accurate as long as people don't play with SetUnitState/SetWidgetLife (and actually I have no idea if OE heal ability plays with SetUnitState either so maybe it's not that accurate but still, I haven't had any problems with it).

And it will not inline anyway, not without JH (and this is supposed to be used with the vanilla editor?).

BTW you really cant do this >>> GetUnitTypeId(u) coz it will error that integer, it should be...

It's because Spinn forgot that it returns an integer in the last post. Should be

GetUnitTypeId(u) != null (or 0, dunno which one that is the correct one)

EDIT:

And the local is not needed as it's merely two function calls for the filtering unit. If people use JH it will inline without the local but with the local it will not. That's what they're talking about.

 

[Bannar]

@mckill209 I had just forgotten about '!=0'. Post edited. If unit-type id is equal to 0 unit doesn't exist or it's decay time is over.

I guess we all want to be as accurate as possible, so I recommend using compasiron mentioned above my me. And again, my solution is faster than yours.
Two GetFilterUnit() >>> GetFilterUnit() plus two locals.

 

[baassee]

You never read my posts Spinn (!) </3

 

[mckill2009]

thanks guys, I already edited that in post #13 fixing the GetUnitTypeId(u) != 0 and did u1!=u2 instead...

 

[Bribe]

The only time you need the GetUnitTypeId()!=0 check is when you are checking for already-stored units, but if you are enumerating units in range or in a rect then removed units will not be counted so you just need the IsUnitType check.

 

[baassee]

Never used GetUnitTypeId actually... only seen others using it.

 

[Bribe]

GetUnitTypeId just checks if the unit was removed, so if you have a variable already set like a stack of targets or the original casting unit, it could be important to check if the unit type id is not equal to 0. But if you are enumerating units you just need the check IsUnitType(unit, UNIT_TYPE_DEAD).

 

[baassee]

Should be a rather useless check as the user would be just stupid to remove units at random double protection is unnecessary if this is a user protection...

 

[Bribe]

It's useful for projectile systems like if you have one projectile homing in on another, and the target projectile is at some point removed.

But I agree in most cases it's fine, and many spells work just fine whether the target is null or not (special effect just won't show if unit is null, for example)

 

[baassee]

So this check is rather optional in 95% of all occasions

 

[Bribe]

The most important thing is to not check a unit's HP but rather the IsUnitType check

 

[sentrywiz]

This reminds me of search the maze algorhytms, but much complex and better looking for the eyes. Love it anyway, even though I understand jack-sh1t from jass.

 

[mckill2009]

Don't make units face angle, if they are already
approximately facing the angle. It makes them twitch

I cant seem to fix this coz GetUnitFacing seems bugged...

Remove the asdaf debug message from Guard Post Remove

Opps, I forgot ...

AI - Ignore GP_GuardingUnit's guard position
doesn't work on heroes

I know, also peon types or workers, maybe I just make a condition to filter out those units...