Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reusable BWAPI::Units, aid or sham? #113

Closed
heinermann opened this issue Jan 19, 2014 · 2 comments
Closed

reusable BWAPI::Units, aid or sham? #113

heinermann opened this issue Jan 19, 2014 · 2 comments

Comments

@heinermann
Copy link
Member

@heinermann heinermann commented Jan 19, 2014

From goo...@teabix.com on November 18, 2009 09:48:44

Currently even with the BWAPI::Flag::CompleteMapInformation flagg off, the
Unit* pointers do not change after a unit disappeared in for of war and
reappeared again, so practically this is an illegal means of unit
identification. In "real life" people cannot tell if it's the same marine
that escaped earlier or if it's a new one.

SUGGESTION: each time a unit hides in the fog (or cloakes && !sneaks) the
actual Unit* becomes invalid, a new one will be provided when that unit is
being detected again. The callbacks are in control of the lifetime of the
Unit* objects.

onUnitUncloak - creates a Unit*
onUnitCreate - creates a Unit*
onUnitShow - creates a Unit*
onUnitDestroy - destroys a Unit*
onUnitCloak - destroys a Unit*
onUnitHide - destroys a Unit*

POSSIBLE PROBLEM: I've noticed BWAPI currently saves all Unit_s in a
unusedUnits set, in a "not exists" state which refuses all access to
properties. With the suggested behaviour the number of Unit_s in that
array would grow rapidly. Since we're building a callback-based API here,
and like I said, the lifetime of whese object is clear, i oppose the
unusedUnits set.

Original issue: http://code.google.com/p/bwapi/issues/detail?id=114

@heinermann
Copy link
Member Author

@heinermann heinermann commented Jan 19, 2014

From bgwe...@gmail.com on November 18, 2009 22:08:02

The Unit class does not provide a getID method. This would be nice to have, but does
bring up interesting issues. I have to be honest and admit that until we can create
bots that perform well against decent human players, this bug should go un-noticed.
Essentially, this exploit allows the AI to notice all units by a unique key, and
therefore you can't fool the AI into believing that you possess more units than you have.

The good new is, most AI systems don't care about this issue and the bad new is most
AI systems don't care about this issue.

I think that writing bots it hard enough, give the CPU at least some benefit. We can
further constrain bots "once" they are competent.

@heinermann
Copy link
Member Author

@heinermann heinermann commented Jan 19, 2014

From lowerlo...@gmail.com on November 18, 2009 23:18:32

When Flag::CompleteMapInformation is disabled, BWAPI is only supposed to deny access
to units hidden by the fog of war, not make the information provided by BWAPI
strictly identical to what humans players would experience.

If this becomes a highly requested feature, we'll consider adding a new cheat flag
for it, such as Flag::UnitPermanence, but for now we won't be adding this feature.

Status: WontFix

@heinermann heinermann closed this Jan 19, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant