[Added] A_CheckLOF (Line of Fire)

Moderator: Developers

Re: [Decorate] A_JumpIfLineOfFire

Postby FDARI » Tue Aug 14, 2012 2:54 am

I'm using an existing Trace function that is also used to determine the actual impact location / actor for a hitscan attack. However, the existing aim-functionality was a little hard to take advantage of, since I wanted a lot of optional functionality. Using existing aim functionality just to retrieve the preferred pitch might save me a bit of headache, though; I wouldn't need to know whether I should consider target floorclip in aim anymore, or what part of the actor to aim for. But I get the impression that there's a lot of adding and subtracting 32*FRACUNITS. So it adds the burden of offsetting the source height to compensate for any default height adjustments in the aiming system. Might be trivial. Especially if it is more similar to existing code.

I should be able to find out, though, if I need to subtract floorclip from target height, in which case I can just do that and not change anything else.

About midtextures: Actual texture data isn't even part of the simulation; purely a rendering feature. If we start detecting stuff by rendering info, then local skins and texture packs break demos and multiplayer. However, the lines themselves are game information. If we're looking for two-sided linedefs that block projectiles it might be doable, if it isn't already happening. I am far from certain. I do not think we can take offsets, texture sizes or actual graphics into account. Each linedef will either block hitscan or not block hitscan (with the addition that height differences can block hitscans because they're hitting a definite wall).
User avatar
FDARI
Bronies eunt domus
 
Joined: 03 Nov 2009

Re: [Decorate] A_JumpIfLineOfFire

Postby FDARI » Sun Aug 19, 2012 12:43 pm

I would like some brief discussion of the finer points of pitch determination and z-origin with this function versus various attack functions.

Point 1: Close enough for jazz. Perfection is not required for usefulness, and the feature as is could probably go in and be used to great effect.

Point 2: Matching existing functions. It's hard to know what attack/related function to match, if any.

* P_AimLineAttack for monster: pitch set from base (actor z) - floorclip + half height + 8 (looks like 28 + 8 to me, which would be about the middle of projectile 8 units tall)
* P_AimLineAttack for player does not add that monstrous 8, but factors in crouching
* P_AimLineAttack does not decide where the hitscan originates, it only adjusts the position and calculates the aim
* The +8 for monsters / crouchadjustment for players is probably only suitable when the origin of the hitscan is dynamically determined, not in functions that take it as arguments

* A_CustomMissile includes a bob-offset that can probably not be accessed by the modder (self->GetBobOffset()), and adds crouchoffset for players
* This feature is mainly to improve monstrous behaviour, so handling crouch is not necessary. With the height-independent offset specification it wouldn't be appropriate either, crouch adjustment would have to be a separate flag.
* Should GetBobOffset() be part of the source location of the attack? Should GetBobOffset() be part of the destination location of the attack?

* P_SpawnMissileXYZ (used by a_custommissile) subtracts floorclip from origin z only if z does not match floor or ceiling height... P_aimLineAttack seems to subtract floorclip always.
* We could make a default behaviour with no implicit adjustments, and use flags to modify all internal calculations using height, crouch, floatbob, floorclip, monster-exclusive +8... It looks like much work, and it might not be necessary. Analysis of the various attack routines one could use a_checkray to test is challenging at the very least. But it might also be the best way to accurately predict the aim and result of any attack function.
* At a glance, P_SpawnMissileXYZ seems to be more base-to-base than middle-to-middle in setting its pitch, unlike P_AimLineAttack. If the actors are similarly tall, a typical attack will still travel towards the middle of the target actor.

Other findings:

* Target floorclip does not appear to be part of the standard aiming routines
* AimTraverse (used by P_AimLineAttack/A_CustomBulletAttack) considers obstructing geometry (3d-floors anyway) when determining pitch. That will certainly not be mirrored by this function's default behaviour.


* Do we need more precision than what this function has already?
* Is there a method of attack that is particularly important to simulate accurately?

Also: There is a potential inner-workings rewrite. I go through a lot of encountered entities using a Trace()-function. It may be that "FPathTraverse" is better suited for the task. (Trace is designed for processing the interrupting entity, FPathTraverse is designed to process entities along the line. a_checkray needs to process everything until a condition is satisfied and jump/nojump can be determined.)
User avatar
FDARI
Bronies eunt domus
 
Joined: 03 Nov 2009

Re: [Decorate] A_JumpIfLineOfFire

Postby NeuralStunner » Sun Aug 19, 2012 1:47 pm

I think it's a matter of getting a scan that's "close enough" for any given purpose. Tying adjustments to individual flags seems rather iffy, one can't expect most modders (I.e. ones who didn't look at source) to know which flags to use for each attack, unless the flag names indicate an attack type and are accurate to that attack's behavior.

Inability to track intercepting 3D midtextures (or easily get a flight path for a "physical" hitbox) is a notable barrier to missile compatibility. I'd defer to hitscan behavior in any case where there's a selection. However, I'd also recommend an ASMISSILE flag that indicates to properly emulate missile aim considerations (where possible, if more can be done in the future that's great and you can add it too).

It seems simple enough to detect whether a calling actor is attached to a player. In these cases, defaulting spawnheight to Height / 2 + AttackZOffset seems wise. (So does halving for crouching players, to reduce modder burden.) If you prefer, add an ASPLAYER flag that enables these checks rather than doing it automatically. (I don't see a lot of reason to, but still.)
User avatar
NeuralStunner
O'Neill with it.
 
Joined: 21 Jul 2009
Location: The Colonies

Re: [Decorate] A_JumpIfLineOfFire

Postby FDARI » Sun Aug 19, 2012 5:51 pm

The reason why I wouldn't default to applying player crouch to the origin of the trace: We have not applied player height in the first place. If you run a trace from height 0 (player base, not middle) and the player crouches, it should not place the origin one crouchoffset below the player's base.
User avatar
FDARI
Bronies eunt domus
 
Joined: 03 Nov 2009

Re: [Decorate] A_JumpIfLineOfFire

Postby NeuralStunner » Sun Aug 19, 2012 5:56 pm

You would still want that offset halved for an accurate attack trace. Otherwise you'd have to do this manually based on querying the current ViewHeight, which is... not simple.

Of course, it wouldn't be defaulting if you need a flag for it. :P
User avatar
NeuralStunner
O'Neill with it.
 
Joined: 21 Jul 2009
Location: The Colonies

Re: [Decorate] A_JumpIfLineOfFire

Postby FDARI » Mon Aug 20, 2012 4:09 am

We could invert that behaviour, of course. Offset xyz from standard hitscan origin by default, and use a flag to offset xyz from actor base instead. The z parameter would then default to 0, and the current default behaviour could be reproduced with the flag CRF_FROMBASE and a z-parameter of 32 (explicit, not default). I think I might like that option. Opinion?
User avatar
FDARI
Bronies eunt domus
 
Joined: 03 Nov 2009

Re: [Decorate] A_JumpIfLineOfFire

Postby NeuralStunner » Mon Aug 20, 2012 4:26 pm

That sounds good, yes.

On another note, IIRC "block projectiles" lines do not hamper hitscans, but "block everything" lines do. In the former case, another reason to have an "as projectile" flag for the function. We at least know traces can affect interceding linedefs...

For 3D midtextures, which I often use for bars and railings, I'm hopeful someone will find a way to detect these along a trace. (Can't see anything in P_Trace that would allow such a thing though.) It's worrysome for monsters to be unable to "detect" such a notable component of level geometry. :(
User avatar
NeuralStunner
O'Neill with it.
 
Joined: 21 Jul 2009
Location: The Colonies

Re: [Decorate] A_JumpIfLineOfFire

Postby FDARI » Thu Aug 23, 2012 3:00 pm

Woah, tired now. Well. Got the easier things done, but untested.

Changes in default behaviour
offsetheight = 0
default origin at natural hitscan origin (8 units above half height for monsters, player adjustment using something like attackzoffset * crouchfactor)

But of course: In many cases this behaviour is what the previous default behaviour was trying to approximate, making the new defaults a more suitable solution.

New flags
CRF_FROMBASE: Move origin to actor's base
CRF_MUL_HEIGHT: Multiply height offset by actor's height. The attempt to get player height with crouch factor may be horribly borked (I'm not sure what information the crouchfactor really gives)
CRF_MUL_WIDTH: Multiply width offset by actor's radius.

Reproducing previous default behaviour
Include the flag CRF_FROMBASE and give an explicit height offset of 32.

Check from half height wherever that may be
Include flags: CRF_FROMBASE|CRF_MUL_HEIGHT
Explicit height offset: 0.5

Todo, to consider, to whatnot:
Detecting projectile obstacles along the ray. (I don't know what this will take.)
Fixes, if required. (You tell me.)
-- What happens when
Optimizations.
-- A little struct was made to help organize the temporary exclusion of previously detected actors; good/bad? It's lightweight. Allocate, use, delete.
-- I considered using an iterator instead of Trace to escape the need for the above trick. Trace() does a lot of stuff. I don't know if the other functions have what I need.
-- These are style, stability and performance considerations. I think stability is good, and performance seems no less than workable.

Todo, required: Testing. You. On the attached patch. Everything that already worked and the new stuff. (Stuff that worked might require changes to work the same way now/new default behaviour.)

Also, feedback on the relevance and implementation of various flags is welcome as always.


... I just realized that the CRF_ prefix is already used for CustomRailgun. We might need renames in a final patch.
Attachments
A_CheckRay_hitscannish.zip
(3.09 KiB) Downloaded 15 times
User avatar
FDARI
Bronies eunt domus
 
Joined: 03 Nov 2009

Re: [Decorate] A_JumpIfLineOfFire

Postby NeuralStunner » Mon Feb 04, 2013 12:15 pm

I know it's been dormant a while, but after checking this a few times I think you could go ahead and submit it. Any problems found can be fixed later, basic functionality is fine. (It's currently difficult to test thoroughly, for various reasons.)

For a name, how's A_CheckLOF?
User avatar
NeuralStunner
O'Neill with it.
 
Joined: 21 Jul 2009
Location: The Colonies

Re: [Decorate] A_JumpIfLineOfFire

Postby FDARI » Thu Feb 07, 2013 9:42 am

Talking to me? A_CheckLOF seems fair. Hopefully there are no CLF-flags present. I'll submit if I'm on my computer at home and have a few minutes to spare. Unless somebody else fixes it up first; I never know when I'm gonne be both at home, not busy and not lazy.
User avatar
FDARI
Bronies eunt domus
 
Joined: 03 Nov 2009

Re: [Decorate] A_JumpIfLineOfFire

Postby GooberMan » Thu Feb 07, 2013 10:38 am

I'd do it myself because I need this. But then there's that code ownership rubbish I keep harping on about.
User avatar
GooberMan
Best taken in small quantities
 
Joined: 08 Aug 2003
Location: Helsinki, Finland

A_CheckLOF (Line of Fire)

Postby FDARI » Sat Mar 09, 2013 5:18 am

Original suggestion: viewtopic.php?f=15&t=29014

A_CheckLOF (state jump, int flags = 0, float range = 0, float minrange = 0, float angle = 0, float pitch = 0, float offsetheight = 0, float offsetwidth = 0, int ptr_target = AAPTR_DEFAULT);

Test a would-be-hitscan/line of fire to see if anything other than the target is encountered along the way. If the target would be hit, jump to the specified state (first parameter). Flags and parameters allow the decision to be a little more involved. A creature will not necessarily want to refrain shooting at one enemy just because it would hit something else; that something could be another enemy, and a good target.

- Parameters -
Jump: Actor state jump, used if the target or another acceptable victim blocks the line of fire.
Flags: Modifies the function in various ways, see separate list.
Minrange: Fail if the line of fire is blocked too near the shooting actor; useful if a monster is contemplating the use of explosives (that are not configured to spare their originator).
Angle: Offset your aim by this angle. Base aim depends on flags; on target by default.
Pitch: Offset your aim by this angle (vertical). Base aim depends on flags; on target by default.

Offsetheight: Offset the line of fire's point of origin by this value. The base height depends on flags; hitscan emulation (around the middle) by default. When pitch is determined by aiming for target, aim is adjusted to correct for this offset.

Offsetwidth: Offset the line of fire's point of origin by this value (horizonal). Aim is not adjusted to correct for this value.

ptr_target: Pick an actor to aim for, AAPTR_DEFAULT picks TARGET (to ensure no actor is targeted, use AAPTR_NULL)

- Flags (CLOFF_...) -

Aim
NOAIM_VERT to disable vertical aim.
NOAIM_HORZ to disable horizonal aim.

Point of origin
FROMBASE: Move origin to actor's base
MUL_HEIGHT: Multiply height offset by actor's height. When called by a player, crouching is taken into account (if I succeeded in my coding).
MUL_WIDTH: Multiply width offset by actor's radius.

Additional jump qualifiers (jump if any of these occur)
JUMPENEMY: Enemy breaks line of fire
JUMPFRIEND: Friend breaks line of fire
JUMPOBJECT: Non-monster breaks line of fire
JUMPNONHOSTILE: Non-enemy breaks line of fire (I think "wild" monsters may see eachother as non-enemies unless they're set to fight over everything all the time)

Pretend the following obstacles do not exist, unless they are valid jump qualifiers (the chosen target or additional jump qualifiers)
SKIPENEMY: Enemies
SKIPFRIEND: Allies
SKIPOBJECT: Non-monsters
SKIPNONHOSTILE: Non-enemies

Exclude actors that conflict with the given criteria (they will cause neither success/jump nor failure); these criteria do not apply to the actor targeted by the line of fire check
MUSTBESHOOTABLE: Ignore actors that are not shootable (checks SHOOTABLE and NONSHOOTABLE)
MUSTBEGHOST: Ignore actors that are not ghosts
IGNOREGHOST: Ignore actors that are ghosts
MUSTBESOLID: Ignore actors that are not solid

Miscellaneous
SKIPTARGET: Ignore the target actor breaking the ray
-- None of the other filters apply to the target actor, they only apply to intercepting actors
BEYONDTARGET: Trace past the targeted actor (requires SKIPTARGET, and is only useful if you're checking for some of the additional jump qualifiers)

ALLOWNULL: Cast the ray even if target is NULL. When there is no target, caller aim (pitch, angle) is used regardless of aim-flags.
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

CLOFF_SKIPOBSTACLES = CLOFF_SKIPENEMY|CLOFF_SKIPFRIEND|CLOFF_SKIPOBJECT|CLOFF_SKIPNONHOSTILE
(You can override some of these with jump-flags, such as CLOFF_SKIPOBSTACLES|CLOFF_JUMPFRIEND)

CLOFF_NOAIM = CLOFF_NOAIM_VERT|CLOFF_NOAIM_HORZ

Other details: Point of origin
Default origin at natural hitscan origin (8 units above half height for monsters, player adjustment using something like attackzoffset * crouchfactor)

Firing from a specific height above actor base (feet)
Include the flag CLOFF_FROMBASE and give an explicit height offset (32 matching the default from a_custommissile)

Check from half height wherever that may be
Include flags: CLOFF_FROMBASE|CLOFF_MUL_HEIGHT
Explicit height offset: 0.5
Attachments
A_CheckLOF.zip
(3.1 KiB) Downloaded 5 times
User avatar
FDARI
Bronies eunt domus
 
Joined: 03 Nov 2009

Re: A_CheckLOF (Line of Fire)

Postby Xtyfe » Sat Mar 09, 2013 10:55 am

YES, its ready to go :D Been watching it closely
Xtyfe
 
Joined: 14 Dec 2007
Location: Kitchener, Ontario

Re: A_CheckLOF (Line of Fire)

Postby Major Cooke » Thu Mar 21, 2013 6:20 pm

This is a highly recommended function. Please add! :D
User avatar
Major Cooke
That's how my uncle stole christmas three times in a row in a single year. -DBT
 
Joined: 28 Jan 2007

Re: A_CheckLOF (Line of Fire)

Postby GooberMan » Fri Mar 22, 2013 5:53 am

Sweet, glad to see you finished it.

+1 for integration in to main.
User avatar
GooberMan
Best taken in small quantities
 
Joined: 08 Aug 2003
Location: Helsinki, Finland

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests