Service reports: Unlag spawn. Reduce signposts ... #5234
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
source/testserver
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#5234
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
Service reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
Investigate whosit's solution of caching signposts
I like this idea
one thing i've wanted to try for a long time is to despawn the entities for small signs (not banners) if there's no player within, say, 8 nodes of the sign (they're usually illegible from any farther away). it'd be tricky to create a cheap mechanism to get them to spawn in properly though. probably a once-a-second globalstep which calls
minetest.find_node_near
for each player.All we can do (as players) to reduce fps lag in Haven is to lower the view range.
Minetest 5.8.0 has a new feature which allows the Server to set players view range.
Maybe one could write a mod that (if the player enables that feature) will automatically reduce the view range on /spawn and reset it when the player leaves Haven.
It would at least improve my gaming experience if I won't have to do it manually every time I come to Haven.
Sure, automaticly reducing view range in Haven to 20 - and when leaving it back to 400 - would help me. Typing /spawn with a view range of 400 is an extremly bad idea.
Sadly even view range 20 is too much.
We need to get those packages down to something manageable. Everyone is suffering from it. Even if the computer is fast enough and the line likewise fast it's still a huge waste of ressources.
i VERY MUCH think that we should move the post office to somewhere much farther from /spawn, and we should also declare and enforce an entity limit on all the plots in haven. my haven shops are important, but i also very much try to limit them because of client-side rendering issues that make playing the game unpleasnt.
moving the post-office shouldn't be too hard to do. when doing the last move, i made sure to keep the process extensible. i support keeping the current post-office's design, but moving it somewhere less harmful to brand new players with low-power CPUs.
I support moving post office away, but it's current placement is very convenient... Maybe we can have Virgillio's brother near spawn that will teleport you to the post office at least?
Things certainly got worse with the post office. It got better at the old place near the harbour when the post office was removed there. It got way worse on the way from spawn to airship at the new place. That path used to have way less loading problems and was less laggy.
But the post office is not the only issue. Walking from spawn to the sailship - is no fun. At the time I managed to get through that lag hell smaller Voice attacks are over.
If Alias might get comftable with at least some more teleport options - like one to the post office - that might help a lot of players a lot. But we also need some teleport to a chest storage so that all that chest content doesn't have to be transferred all the time.
NPC as traders might be able to replace some smart shops. They can offer a lot of deals in one go. Admittedly their inventory is a bit small. But they can restock from chests and also put things into chests.
The entity limit per plot might be a very good idea.
Because they are hard to search for, linking this issue here "Client lag (mostly in Haven plot area)": #5005
Basically FPS drops issue, which is partially caused by signs too.
flux's ideas on how to reduce lag spikes:
#2416 (comment)
node_entity_queue
is used only for smartshops still, could try it for signs too...node_entity_queue is more of a way of avoiding server-side lag when generating a bunch of entities. we need a way to make the entities just not exist if players are standing more than e.g. 8 nodes away from them, and if they're not visible.
Another related issue:
your-land/administration#152
Seems like at some point enchanting tables and item frames were creating new entities without deleting old ones? (my plot had maybe a couple of item frames and a single enchanting table, but flux found hundred entities for each?)
Is this still a thing?
Probably no - maybe old entities are not cleaned up. Do /count_entities and guess whether there may be really 200 enchantment tables loaded right now.
That's how we can check entities are not all on the same place. Maybe could be added to debuggery or yl_commons:
After checking visually some plots, town tall and tutorials with my
find_entities
command, I didn't find any duplicate entities.Good to know that those fixes mentioned in that admin issue seem to actually work :p
yeah i fixed those. see #2234 and #2235.
i did notice that the total count of itemframe entities on the server is often huge, but i haven't found any duplicates. i think some players just use them to label their storage areas.
What values of FPS are we talking about?
I seldom reduce range at spawn below 200 and have between 10 (on very bad days) to 25 (on very good days) FPS directly at spawn, getting better values when running towards public farm or harbor.
it's not just FPS "lag" - all of the entities loading causes a noticeable hiccup that can make the entire game freeze for a second or more. for players with low-powered hardware, it can be way worse than that.
Today (uptime 5d 4h) we had a maximum of 22 k entities on the server, 18k of which were itemframes. I used the updated logpos script to print them to a file. Many of them were duplicate positions:
44 of them led to an itemframe in Ernesto's plot. This itemframe hadn't been touched forever.
2075;23;1172
Do we not clean up itemframe entities for some reason, but only generate new?
Turns out a row of itemframes at Ravise's had 7 entities of each itemframe in one mapblock, but only 3 in another. Itemframes without item do not create an entity.
Updated logpos:
I can reproduce the issue on the testserver. The bad news is, the entities persist and accumulate over server restarts.
Repro:
=> There is no entity at this position: OK
=> There is one entity at this position: OK
server_unload_unused_data_timeout
. On YL, that is 900 seconds = 15 minutes=> The entity is unloaded, there are no entities at this position: OK
=> There are now two itemframe entities at this position: NOK
=> There are still two itemframe entities at this position: NOK
so a regression of #2235.
too bad tenplus1 deleted the old repos, i can't see what the fix was.
this was the original fix:
ee24a223c9
this is what tenplus1 committed:
156c229ce4
the LBM, at least, seems to still exist, though the entities now static_save...
the LBM never actually culled duplicated entities, we relied on the fact that they didn't static_save.
static_save = false
was removed in the latest commit for no obvious reason8f39564306
and that commit happened after i said we'd fixed the proliferation of itemframe entities, so it was true at that time...
created a new issue for tracking an upstream PR to itemframes: #6638
i wrote a snippet so we can periodically cull the itemframe entities until upstream gets fixed and live