rheo reports: default chest duplication glit ... #5068
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/petz
3. source/testserver
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/QA main
4. step/QA NOK
4. step/QA OK
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
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#5068
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?
rheo reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
this is much easier in a "vanilla" world, because we've made open chests MVPS stoppers.
however i can still trigger it on YL, by opening and closing the chest rapidly when the piston is extended:
at least the new chests don't have duplicated contents - their node metadata doesn't get initialized.
proposed solution: any chest w/ an "open" variant should be an MVPS stopper.
oh right, the reason the open chests are already MVPS stoppers: #1905
but the problem persists w/ closed chests too, in some edge case
fixing this via something other than MVPS stoppers would be very tricky.
How about we add everything that has meta to mvps stoppers and replacer blacklist?
There is no way that this doesn't mess with some sort of mesecons build, I am all for replacer blacklisting them but making everything that has meta a mvps stopper is taking away one of the nicer features of mesecons, couldn't you just remove chest open entirely? I don't think many would care if a random animation disappeared, I haven't seen anyone complain about shared chests not opening. Honestly I think open chests are more trouble than they are worth.
Anyway that is my 2 cents
this is probably a good first step - this will prevent exploits.
true. this will 100% break things. but probably these mechanics need to be whitelisted and possibly have special logic to handle the interactions, which we intentionally add when requested.
another option: get rid of the "open" chest variants, and have these chests work like e.g. the shared chest.
I'm not that big into machines, sorry. What examples or usecases would break by adding add blocks with inv to mvps stoppers?
If for some reason we cannot "tame" open chests, we can remove them. Especially since not all chests display the same behaviour.
We can add back that mechanic when we unify chests and we found a generic solution.
the problem is not items with metadata being mvps stoppers it is with open chests, see #5085 just kill 2 birds with 1 stone and get rid of them now before there is another way to destroy open chests
all nodes w/ mutable metadata or special construction actions are now MVPS stoppers:
fbcc8cfe51
i got rid of open chests:
34fe76ee92
QA:
Open chests are still in due to #5085 (comment)
However, the issue was solved, I can't reproduce it.
this is live