Reset Residence(With a temporary vault)?

When residences are copied by a Senior Staff, somtimes they forget to omit air in the copy, and it’s extremely laggy. I belive this is the same, as the server may have to check every block? 60x60x255 is 918000 blocks. That’s nearly one million blocks that the server has to check!

I can see this as an SS service actually... “Clear a 30x30x30 section of your residence, getting every block and item back” no clue how much it would cost though.

I'm going to try and explain this to you (even though others have tried, I'll try as well).

So, when you normally place a block, or remove a block, the Processor of EMC changes a data value, the data-value that you updated with placing or removing that object. The same goes for when you put something in a chest. A single, somethimes maybe a couple data-values get changed at a time. All these data-values are saved at a hard drive, which obviously has alot of space.

Here is the difference though: that what is stored at that hard-drive (so, all these resses for instance) have been stored there by one value at a time, which the processor does. Having stuff stored, is not a big problem and doesn't cause any lag.
BUT: When you change a value, the processor has to update all the data at the hard-drive. So when you reset a res, there are already about 900000 values changed. That could already cause a little lag.

Currently, the system doesn't need to check what is all placed and can just change all this data to a set value (air and dirt). When you would want to somehow save all stuff on your residence, the system would also have to copy all these values of the stuff that was at your res and allocate new space on the hard-drive to sore this data. This can create alot of lag because that takes alot more processing power. Especially if you are someone like tomvanwijnen and you have thousands of chests set up, there could be millions and millions of values that need to be saved after just executing one command. Result: Alot of lag on EMC when there is a person resetting their res.

I hope this explaination helped . My terminologie might not be totally correct though .

I know haastregt just posted as well, but I want my shot at this too

As you know a residence is basically a dedicated area for one (or more) players to do what they like. Playing there basically means following default Minecraft behavior. Everything you do there (building, planting, storing items, etc.) gets handled by the game engine itself, no problems here.

This game engine (= the thing which makes Minecraft work) stores everything it needs to know about your residence in a database (imagine that to be a storage system on the server which only gets used by Minecraft). Because Minecraft needs a lot of stuff to store (and retrieve) it does this in the most optimal way possible. So... It doesn't keep track of what you place, only that you placed it. After that it somewhat forgets about it.

Meaning: Minecraft itself doesn't know that a residence contains (for example) 8 DC's of items. What it does know is that location 23,21,19 contains a block of type chest. And associated ("linked") with that block is some extra data which describes its contents. It doesn't even realize that this is a double chest, but it would know that the block next to it (at location 24,21,19) is also a chest block.

That is basically the problem here. For this system to work the residence would need to get examined block by block to determine what is actually on there. Once it found a chest it would then need to perform a new examination to determine all the items which are inside.

It is for this reason why there is a /testforblock command; this command checks a specific location to see if it contains a certain block, but why /testforblocks doesn't really exist. That is: the command exists but it doesn't actually do what its name implies: it doesn't check an area for certain blocks, but it can only compare 2 areas to see if they're equal.

Note: /testforblock 23 21 19 minecraft:chest is how to use that command, this would tell me if there is (or isn't) a chest at that location. But I can't use this the other way around: I can't ask Minecraft "tell me what kind of block is at this location", because the commands don't provide that functionality. That's because Minecraft doesn't keep track of what you placed.

That's why this would become a lot more bothersome than it's worth right now, because having to check every single block would require a lot of work. Too much to be used casually by regular players.

This was much more informational than most who have tried to be honest. What I gather from what you are saying is if a PLAYER sets a block it's one and done-the server has time to recuperate after a minimal task.

When the SERVER has to compile and/retrieve the data on a residence, it has to compile/retrieve not only the residence, but the entirety of a map(Town)?

In this case, that makes sense. Maybe it's the same thing but, could the server be set to slowly deconstruct and compile this date just as a player would if they were harvesting the materials up for themselves?(Perhaps at a slightly faster pace). As to not overburden the server with an instantaneous hit all at once? Or is going to perform in the same manner?

Thank you.

To give you a perspective from the programming side, here is what goes through my head in the first couple of minutes after I read the suggestion...

What is necessary for this feature?

Seal the res to prevent changes -- kick everyone off, prevent any block breaks while saving it off, pause any water updates, disable fireworks, animal movement, physics etc. Prevent unclaiming of the res, or changing ownership of the res, etc.

Convert the contents from blocks to items -- egg the animals? discard the water and lava or produce buckets? discard or harvest crops? iterate over the rest and convert from placed block to item in hand.

Deliver the blocks to the player -- If we're filling vault pages, do we scan pages for potential item stacks? Each time we place a stone into the vault do we check previous pages or just keep going forward? In either case, there is very real potential the player will run out of vault storage. Do we mail blocks then? Do we need to stack the blocks before mailing to reduce the amount of mail?

What happens if a reboot is scheduled, or if the server crashes, while the server is doing this? Don't want to lose any special items of course. Does that mean we're creating escrow storage?

Is there anything I missed? What else might go wrong? How bad is it if something goes wrong?

Something like this is a very large project and has to be implemented precisely and tested thoroughly. It's an interesting idea, but the risk and complexity are pretty high. So then I'd start brainstorming ways to reduce the risk. And those become little projects of their own.

Anyhow, I think you get the picture. None of what I wrote above was meant to be critical of the idea at all. I just typed it out in the same dry way I internally ponder over programming tasks.

Perfect wording, my friend

Yeah, a great addition, that was actually interesting and fun to read!

Yes, I'm late, but wow. lots of debate on this suggestion

So here's what I think:
This would be heavy on system resources, but how much depends on how it is implemented. If it's just checking containers, it would have to (at minimum):

• Scan all 918000 blocks of the residence
• For each block, check if it's a container
• If it's a container with items in it, append the items to wherever it's stored
• Other logic, such as checking if it will actually fit in whatever end container; if not, split the items

Now, yes, people aren't clearing their res all of the time. I think if this would be implemented, there would be some kind of payment. But that's a lot of checks. As JP mentioned, it would definitely be more complicated than what I mentioned above. There would be more involved.
If you've ever tried clearing out a large area with WorldEdit, you probably know how much it lags. I'm sure this would be worse, and wouldn't be very good on a server. Keep in mind one server machine on EMC runs 3 SMPs.

I'm not sure if I understood your response right, but it doesn't actually change the 900,000 values each individually. The way it would work is: (sorry, this is pretty technical)

• Save the residence into memory
• The processor would perform an operation
• After each operation, save the value into memory (which is millions of times faster than a hard disk drive)
• Depending on how the program is setup, it may use the processor's cache (which also has much lower access times than DRAM)
• Perform one or more operations to save it back onto the hard drive

If it changed all 900,000 individually, that would not be plausible. Hard drive access times are usually in the neighborhood of 10-40 MS. That means it would take hours or more. Since read/write operations are asynchronous, the more things that are trying to access the hard drive at once, the more the access time would go up.

I may be wrong. Overall, I think this is not going to be implemented any time in the near future.