Added MF9_BLOCKSIGHT.

[inkoalawetrust]

This flag allows actors with MF9_DOBLOCKSIGHT to have their vision blocked when calling P_CheckSight(), if an obstacle with the flag gets in the way. This can be used to make objects like props that obstruct monster sight, such as for 3D model actors and any additional collision hitboxes they might use, or large sprite props.

The P_CheckForSightBlock() function is also exposed to ZScript as CheckForSightBlocker(), to allow for independently checking for said actors (Doesn't check if the caller has DOBLOCKSIGHT), it returns a pointer to the sight blocker (If any), so you can know who's actually in the way without having to make a slower ZScript LineTracer.

The map below demonstrates the flag by turning it on for the Imp and ZDoom marine, and giving the row of lamps BLOCKSIGHT.

BLOCKSIGHTTEST.zip

[MajorCooke]

Never did I know this was actually a thing that could be done, and I very much need this. Yes please!

[inkoalawetrust]

Never did I know this was actually a thing that could be done, and I very much need this. Yes please!

Well it is. I just made a custom trace that checks for and stops at actors with BLOCKSIGHT every time P_CheckSight() is called (And runs some early trivial checks like CheckReject() first). Perhaps it could be done by changing the actual sight check code, but it's very bespoke™ and unreadable (To me), so I have no idea how I could change it to also check for any actors with the flag caught in the blockmap, or if it's even possible for that matter.

[dileepvr]

The playsim/p_sight.cpp code allegedly measures if "any part" of a target actor is visible to the source actor. But I suspect that it is only handing verticality. I see no reference to the target's radius in it. I'm gonna test it with thin pillars.

[inkoalawetrust]

Yeah, I think the special sight checking code is supposed to handle partial visibility too, and it does, since a monster can still see, say, the feet of an enemy. But the sight traverse code is too esoteric for me to figure out how I could possibly make it work with any other actors getting in the way of the sight check, so I had to use a standard ray cast instead.

[MajorCooke]

You'll need to fix the merge conflicts before this can be taken in.

[inkoalawetrust]

Done, seems like GitHub has a web UI for this at least.

[RicardoLuis0]

these merges are making the commit history too messy, to the point it won't be able to be merged without polluting master, what should be done is a rebase to master, instead of merging it

[inkoalawetrust]

Is this good ? I rebased the branch from the latest master using the Github Desktop UI.

[RicardoLuis0]

much better yeah

[Boondorl]

Just took notice of this. IMO this isn't the right way to handle sight checking if it's going to be an extension of Doom's sight checking function itself. Rather than using a regular tracer it should use the current one with the same logic as sector planes. While traversing through the ray in 2D, the pitch to the top/bottom of the Actor at the hit point should be considered. This unfortunately means if it's hovering the check might have to be done both ways (under it and over it). This will keep the logic consistent between planes and Actors while also making sure two individual tracers don't have to be updated to handle any updates to line flags (though this current one seems to largely ignore them regardless).

[inkoalawetrust]

I'm aware that P_CheckSight is more sophisticated than that since it actually checks for partial visibility through level geometry. But I have no clue how I could implement +BLOCKSIGHT like that myself.