The MMM (Triple M)

[SpiritTree]

Can you implement private storage? So you can't accidentally overwrite someone else's data.

Yes, now that you have mentioned it, I will. It should not be too difficult.

Just gonna throw this in here.... another cross plot like network won't be approved. Small scale implementation where ppl can move there plots near u if they want to participate, or we work out something to give the project a group of plots. But a server wide network won't be approved. Far to many issues come up with it, and the very rare times ppl will use it (so far... like 4 networks made.. ppl get excited say they will build... no one does) it will lag and cause chunk loading issues... 
If 1 person does a WE goof and doesn't catch that it messed up a network wire.. shit could be down for ages till u find that 1 block of dust. 

I like the idea, but keep it local. (Btw every single stack of memory this large I have seen.... drops everyone's FPS to about 2, and kills the server in lag... while it's.. off)

Also... 600+ ticks for 16kB is a lot of time.. I can stack my memory in my GPU and get 16kB in well under 100 ticks (guessed time, scaled up from my last timing count when I estimated 4kB time) and it's not destructive

Alright, I am totally fine with a local implementation. I can understand why a large scale network would not work. If someone does happen to make a W/E mistake it should be fairly simple to locate as I'm separating the memory into blocks. Chunk loading will not be a large problem. If I remember correctly, you can do it with hoppers chained into another chunk.

I'll have to see what I can do about the lag. I am currently building a model, but obviously the FPS and TPS is not affected until the large scale. My estimate of 600 ticks was a complete guess, I'm going to be doing actual calculations of it once I finish the model.

16kB............   ok... i'll believe it when i see it. Unless you're doing item based that's not possible... and if you are doing item based you will never get that fast a read. (unless you do a really fast encoding/decoding setup that sacrifices size/compression, but in that case it would also lag to much) so like yeah... 16kB @600ticks isn't happening lol your a few thousand ticks off xD Best i could get was 540 bytes per chest with a read of like 10 mins. not to mention bussing from mem to the destination lol if you drop down to 20 bytes per chest you could get 9 min read times lol. On a real note, being realistic id try 4-8kB of serial hex. The read/write would be less than 150 ticks and the lag may possible be bearable. 4kB of that would tots work, idk about the 8 though. Anyways have fun.   also yeah have private storage, use an xor cipher, that'd be neat af

Oh ye of little faith, this memory will take up a large area, which will make it totally possible . As for speed, as I mentioned above, I've completely guessed as I'm still working on the small scale model. I've chosen not to use hex because of much, much larger access times and bussing delay/syncing issues. I am implementing private storage.

Isn't this type of memory sort of not working 'cause of the weird way redstone signals spread? Or having a redstone wire between the repeaters fixes it?

The way I belive it can be solved is by having a subtract comparator between the repeaters side powered by a repeater. That system can achieve 10 blocks per bit if the control line is shared.
Also, isnt that 12 blocks per bit, if I see correctly each cell is 2x3x2?

To my knowledge, chunk loaders can fix any problems associated with redstone not being handled correctly in unloaded chunks. I'm not sure your system will work, but I will definitely try it.

You are correct, it is 12 blocks per bit. Derp. Actually less than that now. Here is a picture of my progress on the small scale model.

http://imgur.com/a/bpvIP

If I haven't derped out on the math a second time, each bit takes around 24 blocks.

Did I mention I'm aiming for it to be completely torchless / pistonless?