The server sends a ridiculous amount of network traffic to burning players #137
Labels
No Label
blocker
bug
code quality
confirmed
critical
discussion
high priority
incompatibility
incomplete feature
invalid
low priority
missing feauture
needs testing
packet spam
performance
project
regression
translations
unconfirmed
in review
ready for review
No Milestone
No project
No Assignees
4 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Mineclonia/Mineclonia#137
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?
How to reproduce / test:
minetest --info >log.txt 2>&1
tail -f log.txt |grep TOCLIENT_HUD
this is analogous to the other already fixed hudspam issues #111 and #90
EDIT: adapted packet count to later results, added grep to the tail line to make it less spammy
TOCLIENT_HUD_SET_FLAGS might be an issue here as well:
EDIT: HUD_SET_FLAGS is (was) unrelated - minimap privs ( #146 )
In
mods/ENTITIES/mcl_burning/init.lua
, there exists a globalstep:In
mods/ENTITIES/mcl_burning/api.lua
:This issue may cause about 100 packets/s:
I wonder if fixing this also fixes burning in general causing performance problems.
In
mods/ENTITIES/mcl_burning/api.lua
,mcl_burning.catch_fire_tick()
is called unconditionally frommcl_burning.tick()
:In
mods/ENTITIES/mcl_burning/api.lua
:Could
obj:hud_add()
inmcl_burning.set_on_fire()
be the smoking (hahaha) gun?Turns out
fire_basic_flame.png
is not even an animation. Why is it added so often?@EliasFleckenstein03 as the author of the mcl_burning mod, would you help us investigate the issue?
Maybe because fire_basic_flame.png isn't the issue here. mcl_burning_hud_flame_animated.png is where the party is at ^^.
Upon further investigation i would say setting the update frequency to lower (a lot lower, rn it's every 0.015 seconds from what i understand [which is even faster than globalstep frequency is in the first place right ? ] ).
I would set it to something like 0.2 for at least for multiplayer if we can differentiate that - i tried it and i think it looks ok.
the "limiting" logic is at
the offending function that calls the hud_change and is called too often is at (update_animation_frame)
However in my opinion this whole thing shouldnt be an animation if it needs to send every f. frame over the net. Something like animated png is off the table right ?
APNG does not seem to be supported by the engine :/
Moving gif doesnt seem to work either. I personally would be in favor to have it not be animated at all to be honest - it's not like this is super fun too look at - the idea is to block the players view a bit right ? let's just use one of those animation frames imo.
I would be honestly interested though, what is the point of this "limiting"?
mods/ENTITIES/mcl_burning/api.lua:288
a wait of 0.015 translates to 66 2/3 times a second right ? Isnt that significantly faster than globalstep even is ? Where does this number come from? @EliasFleckenstein03
Note this mcl2 commit which relies on having the animation done client side (i.e. you need a csm).
27e4bd6d09
MineClone2/MineClone2#1864
since they don't even seem to bother to fix this mess i propose just throttling it severely. To like 0.2 (wait) or sth.
oof. I'm just finished making it a setting but it seems you can be on fire multiple times !?
try throttling the fps to like 1 or 2 with this commit:
be8b35df43
you will still be able to trigger the packet spam by catching fire multiple times :/
People will need to adapt to having to use client side code.
And Minetest will have to fix their rendering code.
I will do adjustments to my implementation however.
well i dont want to break backwards compatibility for this hence the setting to jus throttle it.
Another big problem is that you can get the animation multiple times. This commit fixes that:
bf8577f860
this code prevented it.
and your fix does not update other burning related values, like the reason.
o thats a good point, looks like that can be fixed easily though. but to be fair anything is better than having that traffic generator run mulitple times ^^ - yes this has been an actual problem.
Fixed by merge of this PR: #149