LeetPeet reports: Two death messages for jike at ... #3017
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#3017
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
LeetPeet reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
possibly a regression of #1015
so this is definitely happening, but it's not a regression of #1015, which was due to the game predicting the player would die, and the armor heal factor negating it.
this feels more like multiple mobs are attacking the player, and one kills the player, but the attacks from the others still land.
after testing, this seems to be caused when the player is getting attacked by multiple mobs and they're wearing armor w/ "heal".
verified that "on_dieplayer" is called again if the player is killed while dead. which sounds like a glitch, but consider the case that the player is "dead" but didn't get the "death formspec" e.g. https://github.com/minetest/minetest/issues/11523
question is, can we detect that and ignore it...
i was able to reliably cause the issue for a while, then it stopped happening. possibly this fixes it, but the problem wasn't occurring when i was testing it:
fb0200b640
Why did it happen just now? We (more likely: 3d_armor?) must have changed something in some on_death (or on_hp_change) callback?
very good questions that i don't have good theories about. let's wait and see if it happens more, it doesn't seem to happen often?
Current rotation of the log started on 2022-11-13 10:46:17
Today is 2022-11-24 16:23:58
In this period 2376 death were recorded, of which 455 seem "duplicate death", measured by "death in the same second"
One example:
2022-11-24 19:21:48: ACTION[Server]: [yl_commons] Spectro is not immune to fall damage
2022-11-24 19:21:48: ACTION[Server]: [bones] Spectro added default:pick_stone 1 38071 to bones @ (2211,-913,582)
2022-11-24 19:21:48: ACTION[Server]: [bones] Spectro added default:iron_lump 4 to bones @ (2211,-913,582)
2022-11-24 19:21:48: ACTION[Server]: [bones] Spectro added default:tree to bones @ (2211,-913,582)
..
2022-11-24 19:21:48: ACTION[Server]: [bones] Spectro dies at (2211,-913,582) and their inventory goes to bones.
2022-11-24 19:21:48: ACTION[Server]: [MOD] xp_redo: Spectro lost 37 XP!
2022-11-24 19:21:48: ACTION[Server]: [MOD] xp_redo: Reason of death of Spectro: return {["from"] = "engine", ["type"] = "punch", ["object"] = nil}
2022-11-24 19:21:48: ACTION[Server]: LuaEntitySAO "mobs_monster:oerkki" at (2211,-912,584) (id=42074, hp=38) punched player Spectro (id=29162, hp=0), damage=4
2022-11-24 19:21:48: ACTION[Server]: Server: Spectro tried to interact while dead; ignoring.
2022-11-24 19:21:48: ACTION[Server]: [yl_commons] Spectro tried to interacted_while_dead while dead; killing again
2022-11-24 19:21:48: ACTION[Server]: [yl_commons] Spectro is not immune to fall damage
2022-11-24 19:21:48: ACTION[Server]: Sandra places node ethereal:glostone at (1642,-881,623)
2022-11-24 19:21:48: ACTION[Server]: [yl_commons] Spectro is not immune to fall damage
2022-11-24 19:21:48: ACTION[Server]: [bones] Spectro dies at (2211,-913,582) and doesn't have any inventory to be dropped.
2022-11-24 19:21:48: ACTION[Server]: Server: Spectro tried to interact while dead; ignoring.
2022-11-24 19:21:48: ACTION[Server]: [yl_commons] Spectro tried to interacted_while_dead while dead; killing again
2022-11-24 19:21:48: ACTION[Server]: [yl_commons] Spectro is not immune to fall damage
2022-11-24 19:21:48: ACTION[Server]: [yl_commons] Spectro is not immune to fall damage
2022-11-24 19:21:48: ACTION[Server]: [bones] Spectro dies at (2211,-913,582) and doesn't have any inventory to be dropped.
Sometimes they are not just sent twice but four or five times. Generally I have seen this happen quite often now.
i bet that's the issue - i'm not sure why it's getting triggered, but it seems due to the solution to #478.
when a player is dead, further death messages should be ignored until they respawn.
fixed in
502b5a7706
I still get more than one staff message when aplayer dies and the death portal points to a wrong location?
ah, that's handled by entirely different code, isn't it.
fixed in
ba092b8075
wait really? i didn't think players could meaningfully move while dead, at least as far as the server was concerned.
There must be something that kills the player over and over and even affects dead players. We should go through all register_on_dieplayer and see if there's some death loop there? Could also happen in some register_on_respawnplayer or register_on_player_hpchange or any other that affects the hp0-death-respawn order.
Lag may cause a player to "keep on dieing" at the spawnpoint, effectively setting the death portal to the spawnpoint.
lag. i see a race condition in my "kill on dead" code, that's almost certainly the cause.
fixed in
8b3a832f86
still testing it, but i think this works ....
this is live and appears to solve the problem - i don't see any more repeated death messages.