[Added] A_CheckLOF (Line of Fire)

[NeuralStunner]

Yay, another jump function. This one would use a variation the linetarget code to check whether the caller's Target would be hit. If geometry or another solid actor (shootable or no, see Flags) would block the shot, the jump fails.

A_JumpIfLineOfFire (state State, int Flags, float Range, angle HAngle, angle VAngle, float HOffset, float VOffset)

Parameters:

• State: Where to jump to. A state label or offset.
• Flags: should be self-explanatory. A list of proposed flags can be found below.
• Range: Maximum distance at which the check will extend. If the Target is beyond this range, the jump will fail. If 0, do not limit the range.
• HAngle, VAngle: Adjust the test aim by the given angles. This is an absolute adjustment, not a random spread.
• HOffset, VOffset: Adjust the test aim horizontally and vertically: 0,0 originates from the actor's center, at half its height.

Flags:

• JLOFF_IGNOREACTORS: Ignore all actors but the Target, so the LOF check only counts blocking lines and planes. This could be useful for rail attacks, where the firer doesn't care about collateral damage.
• JLOFF_IGNORENONSHOOTABLE: Ignore actors such as decorations that cannot be damaged. These are typically ignored by hitscan attacks anyhow.
• JLOFF_PROJECTILE: Try to get a projectile flight path. (Solid decorations and 3D mid textures can block missiles, though I'm not sure if such things can be checked in the line attack code. So this flag may not be possible. Since a line check can't account for the missile actor's size, the flag would be of limited use...)
• JLOFF_AIMFACING: Aims the check in the caller's current direction, rather than aiming at their Target. HAngle and VAngle will adjust this, if supplied.
• JLOFF_ANYENEMY: The jump succeeds if any hostile actor would be hit. Intervening allies or "neutral" objects will cause the jump to fail. This would allow AI characters to fight enemy groups, and not worry if they can't hit their chosen target but can hit another enemy. (This could perhaps be expanded to "any actor friendly to the target".)

[Ghastly_dragon]

Useful for chaingunner-type monsters that you don't want to mow down other monsters.

[Sodaholic]

Though not nearly as flexible, one could use A_MonsterRefire as a placeholder until this gets in.

[NeuralStunner]

Though not nearly as flexible, one could use A_MonsterRefire as a placeholder until this gets in.

If I only wanted a geometry sight check I'd use A_JumpIfTargetInLOS.

[NeuralStunner]

Was looking at this again, and made some changes to the proposed format. (First post edited.) Useful input is still welcome.

[Major Cooke]

Something was somewhat coded like this: viewtopic.php?f=34&t=31492

Might want to check it first and see if it has what you need.

[NeuralStunner]

It's not.

[FDARI]

HOffset, VOffset: Adjust the test aim horizontally and vertically: 0,0 originates from the actor's center, at half its height.

"Half height = 0" would conflict with A_CustomMissile, wouldn't it? As well as with actor placement functions. Point 0,0 of an actor in almost any context is at its centre and base.

For dynamic height determination I would add a (much desired anyway) decorate expression to retrieve actor dimensions. (They would get the dimensions of the actual actor/class when called.)
ViewHeight / CameraHeight could also go into that list. (Radius, height, viewheight)

[NeuralStunner]

Default missile height is Z + 32, but P_LineAttack is Height / 2. I figured since it most closely emulates a hitscan, that's what it would be used for most. (Projectiles would be a bit more difficult to gauge with this function, since they have a radius and non-instant speed.) I suppose VOffset could still default to half of Height, but be an offset from Z if explicitly given. (Not sure how but it sounds like it'd be possible.)

Also, I do like the idea of Radius/Height Decorate expressions.

[FDARI]

"Default missile height is Z + 32"; I'm not sure exactly what you mean here, but the spawnheight parameter for A_CustomMissile defaults to 32. If you specify 0, you override 32 and spawn a missile at the feet. At least, that's what I think has been happening all these years.

Spoiler: Regarding non-0 defaults

I much prefer to have defaults that are genuine 0's for my functions, so that plotting 0 throughout a parameter list doesn't change anything. I have a slight dislike for A_CustomMissile's spawnheight=32. I don't like to maintain non-0 consistency with a numeric constant from the source, which I must do by specifying 32 when I need to bypass that parameter. It's even worse when a function passes flags by default (A_FireBullets - Flags unspecified: Use ammo. Flags specified: Use ammo only if FBF_USEAMMO is explicitly specified. Specifying any flag-combo without, implicitly disables ammo-use. FBF_NOAMMO with default = 0 would have been better.)

All of the above would be much less of a worry if we had a "default" keyword that would evaluate to the default value of the currently processing parameter. Particularly if it could be part of an expression, such as "default + 12" or "default | FBF_NOPITCH". It might be feasible as a load-time constant.

Easily overridable defaults must be constants so a default height based on actor height is not possible. Some functions treat 0 as a special case and apply a default in its stead, but that would rule out 0 as a height of origin.

[NeuralStunner]

[...]the spawnheight parameter for A_CustomMissile defaults to 32. If you specify 0, you override 32 and spawn a missile at the feet. At least, that's what I think has been happening all these years.

Exactly. It makes the function actually usable without having to specify that parameter. In many cases, 32 is an acceptable height.

Easily overridable defaults must be constants so a default height based on actor height is not possible.

I was probably thinking of properties, where "unspecified defaults" are defined in the thingdef code.

In this case I'd suggest moving the offset parameters to right after flags, followed by the angle adjustments, then finally range (which, thinking about it, will probably be most often used at default and doesn't need to be so early in the list).

[FDARI]

Should the xy-offset depend on the xy-angle parameter or just the facing/target direction?
I'm going for a solution where the xy-offset is calculated based on either the actor's facing, or the direction between the caller and the target. The parameter angle is a modification to the ray, applied afterwards.

When not getting pitch from target, should pitch use 0 or caller pitch as base value? Caller pitch is my preference, and matches the logic for angle. However, old functions tend to use 0 here.

PS: I'm not sure how this goes. Clearly it takes some doing.

[FDARI]

Some doing indeed. UNTESTED PATCH ready. I have only verified that zdoom still starts. I have not stuck fully with the suggestion from NeuralStunner -I tried for a bit more flexibility.

One readily uncertain thing: Does floorclipping and other position-adjustments mess with this? I simply don't know. There turned out to be a few points of uncertainty, but either I found out most of it, or I forgot something... (dun dun dun!)

Also, for the time being this relies on the untested assumption that you can hitscan for the next object by temporarily unlinking the object you encountered last. There may be better solutions.

Even if some implementations are wrong, or bad, the function is established with code/flow, so bugfixes might be a piece of cake by comparison. (Ooooh, optimism! Bliiiind optimism.)

A_CheckRay (state jump, int flags = CRF_AIM_VERT|CRF_AIM_HOR, double range = 0, angle angle = 0, angle pitch = 0, double offsetheight = 32, double offsetwidth = 0, int ptr_target = AAPTR_DEFAULT);

jump: standard state parameter
flags: long list follows
range: 0 = infinite (represented by 0x7FFFFFFF as fixed_t, I don't know if that's gonna be fine or not)
angle: offset your aim by this angle (based either on your facing, or direction towards target)
pitch: offset your aim by this pitch (based either on your facing, or direction towards target) <-- high risk of miscalculation (such as needing - where + was used)
offsetheight: change the height from which ray is cast; aim is adjusted to correct for this offset (if pitch is determined by a target)
offsetwidth: cast the ray from the side; aim is not adjusted to correct for this offset
ptr_target: pick an actor to aim for, AAPTR_DEFAULT picks TARGET (to ensure no actor is targeted, use AAPTR_NULL)

EXAMPLE >> Minimalist call: A_CheckRay("shoot")
Jumps to state if the default line of sight (as provided by me, might not correspond well to various hitscan functions) is clear.

Flags (aim)
CRF_AIM_VERT: Aim for target actor if there is one (angle)
CRF_AIM_HOR: Aim for target actor if there is one (pitch)

Flags (jump on intercept)
CRF_JUMPENEMY: Jump if an enemy breaks the ray
CRF_JUMPFRIEND: Jump if a friend breaks the ray
CRF_JUMPOBJECT: Jump if a non-monster breaks the ray
CRF_JUMPNONHOSTILE: Jump if a non-enemy breaks the ray (I think "wild" monsters may see eachother as non-enemies unless they're set to fight over everything all the time)

Flags (skip on intercept) (jump has precedence over skip)
CRF_SKIPENEMY: Ignore enemies breaking the ray
CRF_SKIPFRIEND: Ignore friends breaking the ray
CRF_SKIPOBJECT: Ignore non-monsters breaking the ray
CRF_SKIPNONHOSTILE: Ignore non-hostiles breaking the ray

Flags (filter on intercept) (has precedence over jump)
CRF_MUSTBESHOOTABLE: Ignore actors that are not shootable (checks SHOOTABLE and NONSHOOTABLE)
CRF_MUSTBEGHOST: Ignore actors that are not ghosts
CRF_IGNOREGHOST: Ignore actors that are ghosts
CRF_MUSTBESOLID: Ignore actors that are not solid

Flags (misc)
CRF_SKIPTARGET: Ignore the target actor breaking the ray
-- The ray has to reach the target actor for the target actor to be returned
-- None of the other filters apply to the target actor, they only apply to intercepting actors
CRF_BEYONDTARGET: Trace past the targeted actor (requires SKIPTARGET)

CRF_ALLOWNULL: Cast the ray even if target is NULL. When there is no target, caller aim (pitch, angle) is used regardless of aim-flags.
CRF_CHECKPARTIAL: Perform the check even if the target itself is actually out of range. Useful if you're still interested in closer intercepting actors.

Flag combos

CRF_SKIPOBSTACLES = CRF_SKIPENEMY|CRF_SKIPFRIEND|CRF_SKIPOBJECT|CRF_SKIPNONHOSTILE
(You can override some of these with jump-flags, such as CRF_SKIPOBSTACLES|CRF_JUMPFRIEND)

EXAMPLE >> Don't shoot if there's a friend somewhere on the way: A_CheckRay("dontshoot", CRF_SKIPTARGET|CRF_JUMPFRIEND|CRF_SKIPOBSTACLES|CRF_MUSTBESHOOTABLE)
EXAMPLE >> Don't shoot if a friend will catch it: A_CheckRay("dontshoot", CRF_SKIPTARGET|CRF_JUMPFRIEND|CRF_MUSTBESHOOTABLE)
-- The first one skips obstacles, assuming that the shot will/may go through them; the shooter simply does not wish to shoot in the direction of a friend
-- The second one hits anything, and jumps (aborting fire) if it is a friend; if the first obstacle is not a friend, the jump will not happen

It is a distinct possiblity that this will, for any odd reason, not work.
It is a distinct possibility that a sane cap must be introduced on search range. (0x7fffffff represents "unlimited" in a Doom map)

EXAMPLE >> Just don't shoot in the direction of a friend: A_CheckRay("dontshoot", CRF_SKIPTARGET|CRF_BEYONDTARGET|CRF_JUMPFRIEND|CRF_SKIPOBSTACLES|CRF_MUSTBESHOOTABLE)
For attacks that risk going through the target and hitting your good friend behind the target.

None of these examples do anything to limit range. And with the offsets and angles it is fully possible to miss the target entirely. That may be what you want. While it may change, for now I'm trying to allow "infinite" range when it is unspecified.


I hope you find my version understandable and useful, and I hope it works. Changes, additions, questions, regrets; bring them forth. (Objections?)

Corrections, advice, fixes... Anything you have.

Spoiler: Fixed and adjustments in version 2

Replaces position with offset (needs to add offset, of course): "pos = offset" corrected to "pos += offset"
VERT/HOR mixed up? Seems that way: flags used in proper locations
FixedMul used to generate offsets according to angle.
Players acquire their linetarget by default.

Successful tests:
Player weapon that will only shoot if "a_checkray(1)" jumps. (Only if player is looking directly at something. Not much more effective than A_JumpIfTargetInLOS when used so plainly by a player. Players will relly only need it for strange and advanced stuff I think.)

Untested stuff: Most of it
non-0 offsets (width, height)
non-0 angle/pitch settings
traces that don't actually encounter the target, running with nigh unlimited range
traces that run into intercepting actors
the many flag combinations
monster actions


EDIT: NEW FILE download/file.php?id=13750; NEW DETAILS viewtopic.php?f=15&t=29014&p=637925#p637925

[NeuralStunner]

Wow, somehow I missed this.

CRF_AIM_VERT: Aim for target actor if there is one (angle)
CRF_AIM_HOR: Aim for target actor if there is one (pitch)

Typically, attack functions would try to aim directly at the target by default. From the sound of it, these flags would be required to do that: I think the reverse would be better.

It actually sounds like you got everything I'd need, thoguh. Now I just need a GZDoom build to test this out in. (Going to ask Ryan if he'll drop it in ToB for me.)

[Enjay]

Just dropping my £0.02 in, I'd really like to see this in. It would be perfect for supposedly intelligent enemies to prevent them firing on the player regardless of how many of their buddies were between the shooter and the player.