Ineva reports: white Pixel again, maybe from ... #1416
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#1416
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?
Ineva reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
Almost a duplicate of #1412 and that in turn must be a duplicate of an older issue
...but in a different place, so not closing.
See also #1315.
I verified on the test server that these "loose pixels" are indeed part of a sign entity. I'm not sure what the conditions are that result in them generating.
I'm not going to remove these pixels until we figure out how to stop them from occurring, and automate removal of existing ones, but if it becomes urgent, the following commands can get rid of them:
I'm fairly certain these are due to signs disappearing due to worldedit shenanigans, though I'm not totally clear on the trigger.
The fix is probably to have the sign entity check to make sure it's actually still attached to a sign in the
on_activate
callback, which ideally would be fixed upstream, but could be done via an override.Steps to reproduce:
//s air
)upstream issue: https://github.com/mt-mods/signs_lib/issues/8
upstream PR: https://github.com/mt-mods/signs_lib/pull/9