mrminer reports: suggestion for 1.4: builder's ... #5063
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
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#5063
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?
mrminer reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
Not in favour.
Remote access to chests means the area needs to be loaded, which has a couple of other sideeffects and could be abused to run machines.
Well what do you suggest? I often find it a pain when building "far from home" when I realize "I need this!", and have to go to storage, then back to build site.
i'm not in favor of this either, but technically you don't need to forceload the area (which would make it "active").
minetest.load_area()
only makes sure the mapblock is loaded in memory, it doesn't activate it (or trigger lbms).I think that an alternative to this could be a new mod to implement something like Shulker Boxes in Minecraft. That is: a type of chest where all of a player's owned instances of it point to the same inventory.
The inventory data itself could be saved/loaded via the StorageRef API. This means that no forceloading happens ever.
Potentially: each player could have multiple remote inventories, where each corresponds to a different dye color of this Shulker Box.
Given the value of such a tool, I think it would make sense for it to have a very high crafting cost in YL. e.g. aybe something involving nether ingots.
shulker boxes were not really part of minecraft when i played it, so i had to look it up: https://minecraft.fandom.com/wiki/Shulker_Box
it seems like are more like chests that can be picked up, not nodes that share an inventory? do you mean an ender chest?
lmao, probably. i haven't played actual minecraft in nearly a decade, I think. the idea I mentioned is more what matters lol.
As far as I can tell those work like a placeable fifth backpack?
Shulker boxes are basically portable chests that yo ucan place in your inventory, so yeah like placeable backpacks (but you cannot acccess the materials in a shulker box without placing the shulker box first)
Personally while I'm not against the idea of shulker boxes, I do think that if they were to be implemented they need nether-exclusive materials in their making. In the base minecraft game you can only get these things from naturally generated structures after killing the ender dragon (so they're like an endgame item).
I meant Ender Chest, not Shulker Box.
I gave it some thought and now I am fairly certain I do not want remote access to chests, neither via machines nor magic.
Enderchests, shulkderboxes already have their own or should have their own issues.
For the initial request: No, sorry, wontfix.