Questions

33 views
Skip to first unread message

SimonC

unread,
Sep 24, 2011, 11:58:04 AM9/24/11
to bwapi
Hey guys, two things:

- Since the BWAPI:Unit* pointers do not change when an enemy goes in
and out of the fog of war, this removes the need for the AI agent to
"track" the enemy units by matching their current position/hit points/
etc to the ones of previously scouted units. However it doesn't remove
the possibility of doing so, if one is reluctant to use this
"exploit". My question then is how do you guys feel about an AI agent
taking advantage of this in a tournament?

- The other thing has to do with the order of the onUnitEvade/
onUnitDestroy callbacks. At the moment, when a unit dies the AI module
receives the onUnitEvade callback first and then the onUnitDestroy
callback. If some process wants to discriminate according to whether a
particular enemy unit is destroyed or instead evades in the fog of
war, it will have some problem doing so (as I haven't found a way to
know if the unit is destroyed from the BWAPI::Unit* pointer provided
in the onUnitEvade callback). I think having onUnitDestroy before
onUnitEvade would make sense, as the former is more specific than the
latter. I understand however that it is likely impossible to change
that without breaking a lot of existing code, but I would be
interested to hear your take on this.

Thanks,
Simon

Krasimir Krystev

unread,
Sep 24, 2011, 12:25:13 PM9/24/11
to bw...@googlegroups.com
hey
1) When a unit goes in the FoW, many of its attribs become unknown, including its position or used to last time I checked. 
2) did you try ->exists()? In the case the latter doesn't do, you could also check if ->getHitpoints() > 0 (I am not sure if there is ->isAlive()...)

BR

Santi Ontañón

unread,
Sep 24, 2011, 12:29:28 PM9/24/11
to bw...@googlegroups.com
On sep 24, 2011, at 6:25 p.m., Krasimir Krystev wrote:

hey
1) When a unit goes in the FoW, many of its attribs become unknown, including its position or used to last time I checked. 

Sure, but what Simon means is that when it becomes available again, you know it's the same unit as before. So, the AI does not have to reason about whether it's the same unit as before, or it's a new unit.

Krasimir Krystev

unread,
Sep 24, 2011, 12:33:42 PM9/24/11
to bw...@googlegroups.com
Oh, I get it now, thanks, Santi!
Well, believe me, writing a decent tactics capable bot is hard enough even with that extra info (we're engaging the same unit(s) from a little while), so I think it's even recommended to "take advantage" on this one.
--
BR

SimonC

unread,
Sep 24, 2011, 1:11:50 PM9/24/11
to bwapi
Indeed thanks Santi that's what I meant. For example if the AI bot
spots a hydralisk at some point, then later on sees a lurker with the
same unit pointer, it can automatically deduce that the enemy got one
less hydralisk (and one more lurker). It is thus particularly easy to
keep track of the enemy army composition and prevent him from "faking"
having additional units.

> 2) did you try ->exists()? In the case the latter doesn't do, you
could also check if ->getHitpoints() > 0 (I am not sure if there is -
>isAlive()...)

Last time I checked getHitPoints() is always > 0 during both the
onUnitEvade and onUnitDestroy callbacks. I'm not sure exists() is 100%
appropriate for enemy units, since the doc states "if exists() returns
false and the unit is not owned by self(), then the unit may or may
not exist" which seems a little ambiguous. isAlive() doesn't exist,
unfortunately :-p

On Sep 24, 12:29 pm, Santi Ontañón <santi.onta...@gmail.com> wrote:
> On sep 24, 2011, at 6:25 p.m., Krasimir Krystev wrote:
>
> > hey
> > 1) When a unit goes in the FoW, many of its attribs become unknown, including its position or used to last time I checked.
>
> Sure, but what Simon means is that when it becomes available again, you know it's the same unit as before. So, the AI does not have to reason about whether it's the same unit as before, or it's a new unit.
>
>
>
>
>
>
>
> > 2) did you try ->exists()? In the case the latter doesn't do, you could also check if ->getHitpoints() > 0 (I am not sure if there is ->isAlive()...)
>
> > BR
>

Adam Heinermann

unread,
Jul 3, 2012, 4:54:57 PM7/3/12
to bw...@googlegroups.com
exists() is used to check if a unit is both alive and visible. If it's either dead or not visible then it will return false. As far as bot developers are concerned if exists() returns false then the unit no longer exists in the game.

You should NOT check HP to determine if a unit is dead. While this may work in most cases, it is incorrect and there are extremely rare cases that it will not.

A little about alive 0 HP units:
 - Invulnerable to all conventional attacks (can't lose HP so cannot initiate death order).
 - Can be destroyed with broodlings, frozen with an ability that stops movement, mind controlled. (also possibly healed/repaired and then killed but I'm not sure)
 - Can appear in Use Map Settings games with default HP settings.
 - Can appear in a Melee game by using a hack-initiated exploit.

Units can also have negative HP, but these will die immediately after taking any damage.
Reply all
Reply to author
Forward
0 new messages