[Feature Request] Creative Item to copy Pocket and contents

[NPException]

User Azu on IRC suggested this.

The Item has to be obtainable and usable in Creative only, and only if it's use is enabled via config. (Since hard copying blocks/chunks might break the world)

[Jezza]

One thing I want to make happen, which I'll throw on the list of crap I want to do when I return is have be able to link multiple pockets.
I think it would be awesome. :D

[Jezza]

Also, yes, hard copying chunks is going to be funky...

[NPException]

Though the idea of linking pockets sounds nice, it is a bad thing.

For one it is a pain to implement (ask @thraaawn about his entangled machines), and other than that it would break the idea of a DP just being a block that you can enter.

[Jezza]

Well, even still I'd like to have a look at it.

[NPException]

Different problems would arise, I just list the 3 that imediately come to my mind when you have 2 DPs linked to the same room:

1. The current saving format and chunk loading needs to be rewritten to handle multiple source blocks for a single room
2. When exiting the pocket, to which DP do you teleport?
3. RF Transfer would break entirely as it is. Right now it's beauty lies in the fact that it simply forwards the RF method calls to the adjacent blocks on the DP and the Connector, thus eliminating the need for seperate states for input and output. For example: you have a simple energy conduit/pipe on the Connector inside, and then on one DP Something that is pushing energy and on the other one something that is receiving energy. I expect this to break.

The "forward method calls" behaviour is something I will also use for fluids and items, since it makes things extremely simple and elegant for us.

And because of this: As long as a pocket should be able to transfer stuff through it's walls, it must always be a one-to-one relation between DP face and connector.

[Jezza]

I was thinking about using a auxiliary pocket. The master pocket, which is actually the main pocket, and you have "sub" pocket blocks, which just connect to it and use it for various things.
I'll flesh this out as I think about it more and more.

[NPException]

Just gimme a complete plan before you start coding your crazy things. :)

[Jezza]

I haven't coded for 2-3 weeks, I'm going crazy just from that. O_O

[davenonymous]

Entangled machines was a exhilarating and very tempting idea and I started implementing without thinking too much about the implications. From a players point of view it's ridiculously overpowered, someone called it a "tesseract on steroids" once and that's a very fair assessment. And the implementation required a lot of thought and fixes afterwards. You might be able to learn a thing or two from my hiccups, here's the tldr for it:

• What happens when you break one of the linked pockets? What happens to connected pipes etc?
• What kind of transfer system do you want to support in the future? Can all of them be used "directly", i.e. without a buffer (maybe pipes won't connect etc)? Or do you need to keep that in mind and make feasible later on?
• Are you storing any NBT data in your pockets that is necessary for the pocket to work? How will you handle it across multiple pocket blocks?
• If you go for a master/slave approach, how will you handle the master not being loaded? What happens to the slaves if the master is being broken?
• Or do you go for a registry approach?
• Do you plan on adding automatic output/input of RF, Fluid etc, i.e. automatically push to adjacent machines? How does that work with linked pockets?

These are some of the questions I wish I had asked myself before I started implementing, I hope it helps.

[Jezza]

The first one would probably be the hardest to decide...
The way I've got it laid out in my head should work for the most part with all of those questions. Hmm. I'll have to write them down before I inevitably forget it.

[NPException]

okay. copying with an item: No. there will be a command to make kind of a template for premade pockets though -> #92