glitch with "hasHostileTarget" uniform binding

[Commander McLane]

Griff's shaderified ships, and some others as well are using a "hasHostileTarget" uniform binding to change the appearance of a ship during a fight. For instance the Griff Cobras get a red illumination from their cabin windows.

While testing Personalities.oxp I noticed that a Griff Cobra NPC has the same kind of illumination, if the ship is just mining asteroids. This looks odd, and it seems buggy to me.

Surely the shaderified ship has a target, but asteroids, boulders, and splinters should not qualify as "hostile" targets. And cargopods shouldn't as well. I suppose they would have to be somehow excluded in the code, but I barely know anything about shaders and how they work.

[JensAyton]

The shader binding methods are mostly internal state that’s exposed to shaders because it looks potentially useful, rather than being created for the benefit of shaders per se.

hasHostileTarget currently works as follows:

• If there is no primary target, return false.
• If I am a missile, return true.
• If my behaviour mode is any of the following, return true: BEHAVIOUR_ATTACK_TARGET, BEHAVIOUR_ATTACK_FLY_TO_TARGET, BEHAVIOUR_ATTACK_FLY_FROM_TARGET, BEHAVIOUR_RUNNING_DEFENSE, BEHAVIOUR_FLEE_TARGET, BEHAVIOUR_ATTACK_FLY_TO_TARGET_SIX, BEHAVIOUR_ATTACK_MINING_TARGET, BEHAVIOUR_ATTACK_FLY_TO_TARGET_TWELVE.
• Return false.

In other words, it doesn’t actually reflect whether a ship’s target is hostile, but whether the ship is hostile to the target. As far as the game is concerned, miners are hostile to their targets.

I think we can safely exclude BEHAVIOUR_ATTACK_MINING_TARGET. This would make a miner’s turrets ignore the target (which is probably for the best). It would break any custom asteroid AIs that used scanForHostiles or requestNewTarget, though. :-)