Add status flags for units

[jgehring]

There's a lot of unit status information accessible via BWAPI as booleans, and
so far we restricted the information in TorchCraft to idle, detected and
visible. However, flags like constructing can also be helpful in certain
situations such as tracking a worker's progress.

Hence, this includes a single 64-bit integer that stores various status bits.
Furthermore, the conditions for including a unit in the frame sent to the client
have been relaxed -- it's now upon the client to ignore units that are not of
interest.

[jgehring]

Reviewers, can you check the additional flags at the BWAPI documentation and comment if further flags should be included?

[syhw]

Looking at the list:

• isAccelerating => meh, we have the current speed and the max speed, plus Orders, could pose problem when ensnared but I don't think we need it.
• isAttackFrame => it's to be frame perfect, we already have cooldown, so no?
• isAttacking => we already have Orders, so no?
• isBeingConstructed => we could infer from HP or from constructor, but may be useful, so yeah?
• isBeingGathered => we could infer from our workers, but if you want to loop over the minerals directly, could be useful, so yeah?
• isBeingHealed => we could infer from our healers, but if you want to loop over the healed directly, could be useful, so yeah? (Quite niche.)
• isBlind => so niche/specific! but it's the only way to know, so yeah?
• isBraking => we have speed and max speed, plus Orders, so no?
• isBurrowed => yes
• isCarryingGas => yes
• isCarryingMinerals => yes
• isCloaked => we can infer from the rest of the state, except for a special case in which a unit (Ghost or Wraith) would be cloaked and detected, and we would like to could it's energy. But then we have access to it's energy already. 🤔 so no?
• isCompleted => it not {constructing | training | morphing | warping in}, so no?
• isConstructing => yes, already in
• isDefenseMatrixed => yes
• isDetected => yes, already in
• isEnsnared => yes
• isFlying => well, units are either of a flying type or not, we already have this in staticdata.isFlyer, so no?
• isFollowing => we already have that in the Orders
• isGatheringGas => see below
• isGatheringMinerals => we have that in the Orders, but as it's about convenience now, yes?
• isHallucination => yes
• isHoldingPosition => no (we have it in Orders)
• isIdle => yes, already in
• isInterruptible => 😐, so yes?
• isInvincible => not gonna happen in real games, so no?
• isIrradiated => yes
• isLifted => yes, already in
• isLoaded => yes, convenient
• isLockedDown => yes
• isMaelstrommed => yes
• isMorphing => yes (if we put others isBeingConstructed et al.)
• isMoving => no? we have speed
• isParasited => yes
• isPatrolling => no, we have Orders
• isPlagued => yes
• isPowered => yes for convenience (it's a "is_in_radius_of_a_Pylon() + special cases for Nexus and Assimilator")
• isRepairing => yes
• isResearching => yes
• isSelected => useless for playing, may be useful for debug purposes (print only stuff about selected units, the programmer selects in SC), so yes?
• isSieged => no, it's already changing the type of the unit
• isStartingAttack => for frame perfectness (we have Cooldown), so no?
• isStasised => yes
• isStimmed => yes
• isStuck => this one has always been super bizarre / unreliable, but yes?
• isTargetable => yes
• isTraining => yes
• isUnderAttack => yes? (convenience only, we have bullets, we have HPs...)
• isUnderDarkSwarm => we have dark swarm's position, for convenience we could put it, not sure it's ever gonna be useful (we want to look at units in the zone of the dark swarm), yes?
• isUnderDisruptionWeb => same as above, yes?
• isUnderStorm => yes
• isUpgrading => yes
• isVisible => yes, already in

[ebetica]

Made some nits, feel free to merge without addressing.

[ebetica]

Might be more clear in binary 0b0000000000000000...1, or just 1 << n ?

[ebetica]

Guess it really doesn't matter but why does it start at 4? :P

[jgehring]

Uh, I actually had the whole list of is* flags in there and then deleted a couple of them after Gabriel provided the necessary context :)

[ebetica]

This should probably be uint64_t?

[jgehring]

Shouldn't matter much but I'll change it.

[jgehring]

Argh, messed up the merge. I pushed this separately in cfa46b7.