Included in http://forum.zdoom.org/viewtopic.php?f=34&t=29292 (using either patch 2 or patch 3)
I wish to discuss a possible feature. I'll readily write the code for it later, if there is any chance that it will be accepted. (Provided that it does not turn out to be overly difficult afterall.)
You might want infighting to be fully enabled, and still be able to make an actor distinguish between being shot by a friend and being shot by an enemy. Damage-type hacks are possible. A more explicit way of doing it, without using damage type to represent faction (unnatural use), would be to extend A_JumpIfTargetInLOS with a flag: JLOSF_FRIENDNOJUMP. It should also apply to A_JumpIfInTargetLOS, and may be possible to combine with JLOSF_CHECKMASTER and/or JLOSF_PROJECTILE.
Keep in mind, though, that not jumping is not proof that you're targeting a friend. It could also imply that your target is not in sight, not alive, or that you have no target.
Some consideration of the originating actor might be required. It is possible that the flag FRIENDNOJUMP will have effect only if both actors are qualified as players or monsters.
Friendliness condition for A_JumpIfTargetInLOS
Moderator: GZDoom Developers
Friendliness condition for A_JumpIfTargetInLOS
Last edited by FDARI on Tue Apr 05, 2011 2:47 am, edited 1 time in total.
- Major Cooke
- Posts: 8209
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: Friendliness condition for A_JumpIfTargetInLOS
It'd also be handy if we could get something to measure DesignatedTeam.
Re: Friendliness condition for A_JumpIfTargetInLOS
I've had a look at the possibilities. JLOSF_TEAMNOJUMP might be a better word. The engine has a test called "IsFriend" that one monster can call on another. If either of the monsters is not FRIENDLY at all, the function will return false (not friend). This means monsters that are not friendly to a player, are nobody's friends. The IsFriend-function looks like it takes teams into account wherever teamplay is possible.
A second flag would be needed to make one unfriendly monster avoid another unfriendly monster. (As mentioned, monsters without FRIENDLY-flag are enemies to everyone.) All it would do is prevent the jump if neither monster is friendly. Together, the two flags would work as the originally proposed JLOSF_FRIENDNOJUMP.
But what's a good name for the second flag?
JLOSF_TEAMNOJUMP: Prevents the jump if both monsters are associated with the same team. Does not prevent the jump if either monster is not associated with a team.
JLOSF_...NOJUMP: Prevents the jump if both monsters are non-friendly/hostile.
A second flag would be needed to make one unfriendly monster avoid another unfriendly monster. (As mentioned, monsters without FRIENDLY-flag are enemies to everyone.) All it would do is prevent the jump if neither monster is friendly. Together, the two flags would work as the originally proposed JLOSF_FRIENDNOJUMP.
But what's a good name for the second flag?
JLOSF_TEAMNOJUMP: Prevents the jump if both monsters are associated with the same team. Does not prevent the jump if either monster is not associated with a team.
JLOSF_...NOJUMP: Prevents the jump if both monsters are non-friendly/hostile.