Flatulenator reports: Sometimes when the inventory d ... #1819
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
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#1819
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?
Flatulenator reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
There is something at work that removes the items regardless of the 15 minute rule of dropped items. The stuff is a maximum of 16 so it can't run into the "can't store more than 128 entities".
I refunded the items because Flatulenator could prove he was at the very drop location 10 minutes after at most.
It absolutely can if there's already 128 entities in the area, e.g. too many shops/signs/scouts etc.
Only that there were next to no entities around. Is there a way to capture the on_despawn of dropped items?
I think by overriding the
get_staticdata
callback, e.g.Though that only captures when the item is going to be unloaded. If you want to log when it's going to be removed, you have to do
I might as well add that code to yl_commons
Added logging code in
e31543758b
logging is live, items dropping will not happen once the bones update is live.
fix is live