[g4.15pre-45-g162ab3c4e] Player detection issue

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: [g4.15pre-45-g162ab3c4e] Player detection issue

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Enjay » Sat Feb 01, 2025 9:05 am

For what it's worth, I also tried your original procedure too - same result: I was able to spawn enemies in without them knowing I was there, despite having fired my weapon before they spawned.

I did follow your procedure exactly, but I also tried it without notarget.

i.e.
Spawn an enemy
shoot and kill it
start running backwards but then open the console
spawn another enemy
close the console
your momentum from moving before you opened the console takes you out of "touch" range
the enemy should appear and be unaware of your presence.

Useful tip, in case you don't know
summon doomimp
will always spawn an imp facing east.
Adding a number to that spawns it at an angle relative to you.
e.g.
summon doomimp 0
will spawn an imp that is facing away from you.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Xtyfe » Sat Feb 01, 2025 8:53 am

This is very strange then. Thank you for testing this out. It must be something on my end somehow.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Enjay » Sat Feb 01, 2025 8:41 am

Hmmm, I don't know what to tell you. I just tried Kinsie's test map (the one you linked to) with both 4.14 and yesterday's git build. In both cases, I was able to spawn an enemy, fight it (and kill it) then use a switch to spawn a new enemy that seemed to be unaware of me. I tried it simply by getting out of the way really quickly before it spotted me (tricky). I also tried cheaty ways : trying both the freeze and notarget commands separately to allow me to get out of sight before re-enabling normal gameplay, as well as just quickly engaging noclip and running through a wall and out of sight.

In all cases, I was able to spawn an enemy, fight it, then spawn a new one that did not go into chase mode until I either moved into the enemy's vision, or I fired a shot that it could hear.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Xtyfe » Sat Feb 01, 2025 8:12 am

I suppose then my question is, how do I turn this off? If the compat option won't do it, is that a bug, or is this something else?

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Enjay » Sat Feb 01, 2025 7:15 am

I forgot about Pain Elementals.

I had actually wondered if it might have been a change for Doom2. Interesting that it wasn't. As you said, these things were not in the original Doom. They all also tend to happen wherever the player has already been fighting in game. So, it seemed likely to me that id wanted a simple way of ensuring enemies spawned in these ways would go straight into "hunting the player" mode. Having some sort of "a noise has already happened here" marker would do that.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Rachael » Sat Feb 01, 2025 6:43 am

Xtyfe wrote: Fri Jan 31, 2025 7:01 am To my knowledge "flood-filling sectors with their sound pointer" is not a standard feature of doom. In fact, it was not like this as far back as gzdoom 4.13.
It is. Every time you shoot your weapon, every sector recursively adjacent to the last gets its SoundTarget set to the emitter, and the recursion continues until a wall is hit or 2 sound-blocking lines are hit. In the A_Look action pointer, monsters check this pointer to determine if they should activate or ambush the player depending on their own flags. This has been Doom behaviour since 0.99.
Enjay wrote: Fri Jan 31, 2025 9:39 am I don't think it was a problem as such in the original Doom mainly because there wasn't really a way to spawn new enemies into the game. So, having them appear and not be "awake" wasn't really a thing. The closest would be enemies teleporting in from elsewhere (already "awake") or being resurrected by an archvile - where springing into action immediately would be desirable. Maybe spawning from the boss cubes too?
Quite right, archie rezzing and boss cubes were both ways to bring in new enemies to the map, other than the pain elemental spawning lost souls, that was another way to add monsters to the map. None of this existed in the original Doom game but they were added in Doom 2, as far as I know Doom 2 did not alter the original behaviour which seems to have not accounted for these new ways monsters could enter the map (or they just didn't care).

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Enjay » Fri Jan 31, 2025 9:39 am

I don't think it was a problem as such in the original Doom mainly because there wasn't really a way to spawn new enemies into the game. So, having them appear and not be "awake" wasn't really a thing. The closest would be enemies teleporting in from elsewhere (already "awake") or being resurrected by an archvile - where springing into action immediately would be desirable. Maybe spawning from the boss cubes too?

However, the more I think about it, the more sure I am that I had this as a problem many years ago in ZDoom. I was probably repopulating a map with spawned enemies so that it would be busy when the player had to retrace their steps, and the spawned enemies were automagically waking even if the player wasn't in the immediate vicinity. I'm sure that it was Randi that explained it to me at the time. Who knows? It could even have been on the old ZDoom notgod phorum. It was certainly a long time ago.

Anyway, if you are observing this behaviour, and the flag is set for this not to happen, then it does seem as if something is up.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Xtyfe » Fri Jan 31, 2025 9:30 am

Enjay wrote: Fri Jan 31, 2025 9:24 am I have a fuzzy recollection that there was something like this in the original doom. I remember having a discussion about it a very long time ago - but I can't find anything to back it up. so, pleas forgive me if this is wrong but, isn't there some sort of behaviour in Doom where once a sound has been made in an area, then it is remembered that the area in question is now one where monsters will automatically go into searching mode. So, provided the game has not actually been restarted, an enemy spawning into an area where the player has made noise will automatically be aware of the player's presence?

Is that a thing, or have I just had a complete brain-fart?
Perhaps that's the "Use original sound target handling" that has already been mentioned?
Yes, that is exactly what I'm talking about. Whether this was a problem in classic doom or not, I certainly don't remember anything like this happening. I could also be wrong, I'll accept that.

The "Use original sound target handling" thing is turned off for me. Unless this option is now suddenly being ignored.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Enjay » Fri Jan 31, 2025 9:24 am

I have a fuzzy recollection that there was something like this in the original doom. I remember having a discussion about it a very long time ago - but I can't find anything to back it up. so, pleas forgive me if this is wrong but, isn't there some sort of behaviour in Doom where once a sound has been made in an area, then it is remembered that the area in question is now one where monsters will automatically go into searching mode. So, provided the game has not actually been restarted, an enemy spawning into an area where the player has made noise will automatically be aware of the player's presence?

Is that a thing, or have I just had a complete brain-fart?
Perhaps that's the "Use original sound target handling" that has already been mentioned?

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Xtyfe » Fri Jan 31, 2025 7:01 am

Rachael wrote: Fri Jan 31, 2025 6:48 am Ultimately this is a cheat, so unless it reveals any quirky behaviour that can happen in a real game play setting without it, I don't think this will be addressed.

The thing to remember is notarget is only taking the player off of normal sight and sound checks. It does not prevent the player from flood-filling sectors with their sound pointer by firing their weapon, and some creatures will respond accordingly to that if other conditional checks suggest for them to do so.
I would disagree. I was only using notarget to make it easier to reproduce. It can also be produced using this test map viewtopic.php?t=57221

To my knowledge "flood-filling sectors with their sound pointer" is not a standard feature of doom. In fact, it was not like this as far back as gzdoom 4.13.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Rachael » Fri Jan 31, 2025 6:48 am

Ultimately this is a cheat, so unless it reveals any quirky behaviour that can happen in a real game play setting without it, I don't think this will be addressed.

The thing to remember is notarget is only taking the player off of normal sight and sound checks. It does not prevent the player from flood-filling sectors with their sound pointer by firing their weapon, and some creatures will respond accordingly to that if other conditional checks suggest for them to do so.

The only thing I can suggest is looking at p_enemy.cpp for "P_LookForPlayers" and "P_NoiseAlert", it gives a lot of clues how visual and sound cues are handled by monsters in Doom.

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Xtyfe » Thu Jan 30, 2025 12:01 pm

phantombeta wrote: Wed Jan 29, 2025 10:52 pm This sounds like you have the "Use original sound target handling" compat flag enabled, which works exactly as described.
Basically, in vanilla Doom, monster "hearing" works by the player's weapons setting a pointer in the sector's data to point to the player, and "sleeping" monsters check that pointer and target the actor it's set to.
ZDoom changed this so the player's weapons set a pointer stored in the monsters instead. (this does lead to a similar quirk where, if you resurrect, any monsters that ever heard you will instantly wake up, but ones that only saw you won't)

(Note that compat flags stay set even after you close the game, unlike gameplay flags)
I looked at my compact flags and they are set to 0. I even went as far as to check the sound target one and it was set to off.

Rachael wrote: Wed Jan 29, 2025 9:22 pm This does not appear to be a bug to me, but rather a quirk of the ambush mechanic.

When a monster has the ambush flag, they will stay in the Spawn state even when they acquire the target player. The only time they move in to attack is once the player has LOS to them. This can happen even if the monster is not facing them - all that is required is the monster gets pulled into the "ambush" state, which is what likely happened when you shot and killed the first monster, and then the player has to have a direct line of sight to the monster, which will cause them to go to the See state as normal.

Monsters without the ambush flag will start engaging the player as soon as they get the player as a target, which is what the player firing their weapon causes. Monsters with the ambush flag will still acquire the player target but stay in the idle state until the player has LOS to them which is when they think they can "surprise" the player.

-

However, even discounting all that, notarget is ultimately a cheat, and it's merely a flag, at that. It's possible that your actions are causing the monsters' soundtargets to be triggered but the monsters can't attack, so that might be inadvertently causing the ambush mechanic even with normal monsters.
'
I understand that would be how it would work for a monster in isolation. But why would it stick for the whole level for any other summoned monster after the first?

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by phantombeta » Wed Jan 29, 2025 10:52 pm

This sounds like you have the "Use original sound target handling" compat flag enabled, which works exactly as described.
Basically, in vanilla Doom, monster "hearing" works by the player's weapons setting a pointer in the sector's data to point to the player, and "sleeping" monsters check that pointer and target the actor it's set to.
ZDoom changed this so the player's weapons set a pointer stored in the monsters instead. (this does lead to a similar quirk where, if you resurrect, any monsters that ever heard you will instantly wake up, but ones that only saw you won't)

(Note that compat flags stay set even after you close the game, unlike gameplay flags)

Re: [g4.15pre-45-g162ab3c4e] Player detection issue

by Rachael » Wed Jan 29, 2025 9:22 pm

This does not appear to be a bug to me, but rather a quirk of the ambush mechanic.

When a monster has the ambush flag, they will stay in the Spawn state even when they acquire the target player. The only time they move in to attack is once the player has LOS to them. This can happen even if the monster is not facing them - all that is required is the monster gets pulled into the "ambush" state, which is what likely happened when you shot and killed the first monster, and then the player has to have a direct line of sight to the monster, which will cause them to go to the See state as normal.

Monsters without the ambush flag will start engaging the player as soon as they get the player as a target, which is what the player firing their weapon causes. Monsters with the ambush flag will still acquire the player target but stay in the idle state until the player has LOS to them which is when they think they can "surprise" the player.

-

However, even discounting all that, notarget is ultimately a cheat, and it's merely a flag, at that. It's possible that your actions are causing the monsters' soundtargets to be triggered but the monsters can't attack, so that might be inadvertently causing the ambush mechanic even with normal monsters.

[g4.15pre-45-g162ab3c4e] Player detection issue

by Xtyfe » Wed Jan 29, 2025 6:19 pm

I've noticed an issue with player detection in certain circumstances. Below are the steps to reproduce this issue.
  • 1. set notarget on.
    2. summon a monster and make sure its back is turned away from the player. then back up so it won't wake up from you touching it.
    3. set notarget off and shoot and kill the monster.
    4. set notarget on again and summon another monster then back up again.
    5. set notarget off.
The monster will now wake up as if its look fov was 360. This will happen with any summoned monsters for the rest of the level. It seems to happen with all monsters, summoned or placed another way.

Top