- 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.
[g4.15pre-45-g162ab3c4e] Player detection issue
Moderator: GZDoom Developers
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!
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!
-
- Posts: 1490
- Joined: Fri Dec 14, 2007 6:29 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
[g4.15pre-45-g162ab3c4e] Player detection issue
I've noticed an issue with player detection in certain circumstances. Below are the steps to reproduce this issue.
-
- Posts: 13884
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.
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.
-
- Posts: 2147
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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)
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)
-
- Posts: 1490
- Joined: Fri Dec 14, 2007 6:29 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.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)
'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?
-
- Posts: 13884
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.
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.
-
- Posts: 1490
- Joined: Fri Dec 14, 2007 6:29 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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=57221Rachael 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.
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.
-
-
- Posts: 26835
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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?
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?
-
- Posts: 1490
- Joined: Fri Dec 14, 2007 6:29 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.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?
The "Use original sound target handling" thing is turned off for me. Unless this option is now suddenly being ignored.
-
-
- Posts: 26835
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.
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.
-
- Posts: 13884
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.
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).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?
-
-
- Posts: 26835
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.
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.
-
- Posts: 1490
- Joined: Fri Dec 14, 2007 6:29 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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?
Last edited by Xtyfe on Sat Feb 01, 2025 8:47 am, edited 1 time in total.
-
-
- Posts: 26835
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.
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.
-
- Posts: 1490
- Joined: Fri Dec 14, 2007 6:29 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
This is very strange then. Thank you for testing this out. It must be something on my end somehow.
-
-
- Posts: 26835
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: [g4.15pre-45-g162ab3c4e] Player detection issue
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.
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.