A_JumpIfTargetInLOS - Extend and improve

[FDARI]

Preferred patch: http://forum.zdoom.org/viewtopic.php?f=34&t=29364

The preferred design for A_JumpIfTargetInLOS depends on A_CheckFlag or something near that being accepted. (http://forum.zdoom.org/viewtopic.php?f= ... 0&p=557775)

Headsup: Three patches are provided. 1 with only the core suggestion, 1 also implementing a related suggestion, and 1 for testing the complete demonstration backstabber dagger.

Improvement on sight checks with target in LOS: Choosing actor to check FOV and SIGHT.

Previously existing possibilities:

A_JumpIfTargetInLOS: Check caller LOS, check caller FOV
A_JumpIfInTargetLOS: Check target LOS, check caller FOV

Missing possibility: Check target LOS, check target FOV
Second possibility: Check caller LOS, check target FOV

Proposed solution: Extend A_JumpIfTargetInLOS to provide all these options with the addition of two flags.

JLOSF_TARGETLOS: Check target's line of sight
JLOSF_FLIPFOV: Check FOV for the actor that does not make a sight check

Using neither flag corresponds to A_JumpIfTargetInLOS (unmodified)
Using both flags corresponds to A_JumpIfInTargetLOS (the original A_JumpIfInTargetLOS has some dubious traits that this function does not share)
Using only JLOSF_TARGETLOS corresponds to the missing possibility: Check target FOV and sight.
Using only JLOSF_FLIPFOV provides the extra option: Check caller sight and target FOV.

Target can be substituted for MASTER/TRACER wherever A_JumpIfTargetInLOS would normally make that substitution.

---

A_JumpIfInTargetLOS does not check if the caller is a player; it fetches stored pointers instead of getting the actor aimed at. I think these are usually NULL for players. Also, it duplicates much code.

I suggest deprecating this function, as it can be wholly replaced with the extended A_JumpIfTargetInLOS with only one difference: That it works for players.

---

Original suggestion: http://forum.zdoom.org/viewtopic.php?f=15&t=29202
New flags:
JLOSF_ALLYNOJUMP: Jump only if the actors are not allied to eachother. Unfriendly monsters have no allies.
JLOSF_NOTEAMNOJUMP: Jump only if at least one of the actors has the +FRIENDLY - flag

Proposed usage:
In painstate, a monster can use this to determine if it was hit by friendly fire. For friendly monsters, the JLOSF_ALLYNOJUMP flag will prevent a jump if the other actor is an ally. For non-friendly monsters, JLOSF_NOTEAMNOJUMP will prevent a jump if both monsters are pure enemies (not friendly).

Friendly monsters seem less than eager to target those who cause them pain, so JLOSF_ALLYNOJUMP is not necessarily crucial. However, it can also be used to determine the friendliness of anything under the player's crosshair, and jump if it is hostile (perhaps from the firing state of a weapon to select a friendly or hostile effect).

---

Includes changes from existing code submission http://forum.zdoom.org/viewtopic.php?f=34&t=29171.

Adds A_JumpIfInInventory with pointer specification (AAPTR_TARGET, AAPTR_MASTER, AAPTR_TRACER, AAPTR_DEFAULT). Also includes safeguards and fixes for a patch that has been added.

Demonstration 1: A strife mod with a punch dagger that has backstab as altfire. It checks that the target is facing away, and you remain locked on target for sufficiently long. The demonstration requires the third patch, as it uses extended A_JumpIfInventory and improved A_JumpIfTargetInLOS.

Demonstration 2: Flags JLOSF_NOTEAMNOJUMP | JLOSF_ALLYNOJUMP. When hurt, the DoomImpLord spawns a helper actor that makes all enemies of the hurting actor change target; they attack the hurting actor. When hurt by a friend, the DoomImpLord must not do this (JLOSF_ALLYNOJUMP). When DoomImpLord is an enemy (and has no friends), it must not react in this way to damage from other friendless monsters (JLOSF_NOTEAMNOJUMP).

Guide for demo 1: Find some peasants or still acolytes. Get behind them. Hold altfire. Try turning away while holding altfire to note that it cancels the attack.

Guide for demo 2: ZombieMan has been boosted to endure prolonged infighting. Get two of them and some room around you. Activate godmode and provoke an infight. Summon a hostile DoomImpLord and shoot it. After its painstate, they should all be after you again.

EDIT: Attachments removed; they have served their purpose.

[Major Cooke]

WOOHOO this sounds like it's going to be exactly what I requested! Pardon me while I go nuts for a second...

Also, a future note, you can simply change the .txt extensions to .diff so things like TortoiseSVN show the syntax highlighting of all changes and what not.

[Major Cooke]

Also I was unaware we could do things like this:

Code: Select all

const int MAX_BACKSTAB_RANGE = 80;
const int BACKSTAB_FOV = 20;
const int VICTIM_FOV = 200;

Can these be modified at all by actors? Something like a global variable? Potentially checked as user variables by multiple actors and/or manipulated?

[Gez]

There are currently no way other way than initialization to assign a value to a global variable. So, wait for Doomscript.

Even if there were, though, you wouldn't be able to change a "const" variable.

[Graf Zahl]

to change a "const" variable.

isn't that a contradiction in terms? Either something is constant or variable but never both at the same time!

[NeuralStunner]

Either something is constant or variable but never both at the same time!

I had the same thought.

Though even the speed of light through vacuum can change depending on gravitational and electromagnetic forces. (I may be oversimplifying the nature of the lightspeed constant, though.)

[Major Cooke]

Anyway, I'm about to finish my ripping of the Spy's Butterfly knife so I can attempt backstabs in Doom. I'll let you know how it turns out...

[Graf Zahl]

(I may be oversimplifying the nature of the lightspeed constant, though.)

Light speed is not a constant, as you so aptly described it.

[Gez]

c is a constant, though.

[Major Cooke]

Anyway, I can officially confirm this works!

Now if there's a suggestion that I would like to ask, can you add a flag such as JLOSF_MONSTERONLY? Simply put, this'll prevent acquiring targets on objects that dont have the +ISMONSTER flag.

Give me a moment to upload the spyknife... Just have to tweak it some.

[FDARI]

Possible solutions for filtering non-monsters:

1 - New flag: JLOSF_MONSTERONLY.
a) As a late addition to this code submission
b) As a subsequent code submission

2 - New action function in separate code submission: A_JumpIfSet(string FLAG, string|int STATE, int checkactor = AAPTR_DEFAULT)

3 - Making both JLOSF_TEAMNOJUMP and JLOSF_ALLYNOJUMP implicitly verify that the target is a monster.

The second idea has a ring of wfds to it, but is probably quite easy to implement, and covers the requested feature (in an extra line of decorate) and may be applied to other uses. If the second way is viable, I don't think I'll write the first one, but if the second is not viable, I too feel the need for a monster-check.

The third idea is somewhat logical, but quite inflexible.

I haven't checked what players have in their ISMONSTER-setting. The WIKI-decorate does not add the flag, and the engine usually doesn't care, when it already knows it is a player. With JLOSF_MONSTERONLY, the player-designation makes a difference.

If you want it to include players, perhaps it needs to be JLOSF_COMBATANTONLY (ugly word, but you get the gist).

[Major Cooke]

NUMBER TWO. Definitely. That's something that would be a GOD-SEND.

However I would do A_JumpIfFlag instead though. That way it's not so confusing.

[FDARI]

Good call.

The JLOSF_NOTEAMNOJUMP is a little clumsy, both in wording and function. All it does is cancel the jump if neither actor is FRIENDLY. I think its responsibility should be transfered to A_JumpIfFlag if that function exists.

The flag JLOSF_COMBATANTONLY is actually a relevant addition. Checking an actor's monsterflag won't be useful for a player, but JLOSF_COMBATANTONLY should treat players and monsters as combatants.

The following would verify that:
* The target is a combatant
* The target is not an ally to the caller
* Target and caller are not both non-friendly

Code: Select all

BeginLogic:
TNT1 A 0 A_JumpIfFlag("FRIENDLY", "AtLeastOneFriendly")
TNT1 A 0 A_JumpIfFlag("FRIENDLY", "AtLeastOneFriendly", AAPTR_TARGET)
goto FailedLogic

AtLeastOneFriendly:
TNT1 A 0 A_JumpIfTargetInLOS("ItsLogical", 0, JLOSF_ALLYNOJUMP | JLOSF_COMBATANTONLY)
goto FailedLogic

However, we then become dependent on A_JumpIfFlag being accepted and not WFDS'ed.

Still, it is my preference. I've got quite a few changes queued now. Should I just keep piling on?

[Major Cooke]

I say go for it, but A_JumpIfFlag aught to potentially be in another thread. That's just me though. My recommendation is to make the new function first, see how well it holds out in the zdoom dev's eyes.

[FDARI]

I have discovered an important design issue that must be dealt with before I can go for A_CheckFlag / A_JumpIfFlag:

Sometimes flags become deprecated. There is a special function in the source code that assigns properties to simulate these flags. Some of the properties translate easily back to their flag counterparts (setting that flag would have caused X, so if X, consider the flag set). Also, flags currently deprecated could simply be restricted from the function. However, if one of the current flags is to become deprecated, a translation from its replacement to something backwards-compatible must be added to the code, in my function.

Maintaining backward compatibility for A_CheckFlag requires some planning.