AliasAlreadyTaken reports: Overwrite minetest.show_formsp ... #4628
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
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#4628
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?
AliasAlreadyTaken reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
interesting proposal. note that this will necessarily not be complete, as it won't know anything about client-generated formspecs, e.g. inventory, death, and the "escape" menu, as well as node metadata formspecs.
Grrr, you're right. Imagine minetest engine was a real game engine where you could build anything, not only minecraft-not-minecraft.
Death and inventory both can be intercepted, right? The Death formspec at least can be assumed active between death and respawn. The Inventory formspec ... how does it open at all?
the real solution probably involves SSCSM. this is not an easy problem to solve.
all formspecs can be "intercepted". bug me to fill this in tomorrow, i'm falling asleep.
i'm not sure what i meant by this. the server gets info about what a player does in the inventory formspec, and sets the formspec itself, but there's no way to see what the player does with the death formspec or the escape menu formspec.
Even if implemented, such a method might be quite inaccurate due to client-server desync:
I tried something like that in my chat_formspec mod, assuming that the fs would be closed as soon as the player submits my fs with a
quit
field. (to delete some context data I would no longer need if the player stops interacting with the mod)This is what happend: #6300
now I remember #4640 (comment), so I searched for these lines...
It seems like the server already does caching like that:
658bc9fcc8/src/network/serverpackethandler.cpp (L1458)
I guess logs could reveal how often even the server fails with that task.
I currently try myself in formspec modding - I would be really interested how often these mismatches happen (memory vs. user experience tradeoff: can I afford asking the user to start again or do I have to store my data forever in case the formspec I expect to be closed isn't).
Another interesting thing to investigate:
There was a code in yl_speak_up that did basically:
i.e. showing same formspec as soon as you close it.
But it is still possible to just hold down
esc
button and break from this loop after some time.I always wondered what exactly happens and what state is assumed after...