gmlaxfanatic / Contraptions

Emergent machine creation through fuctionalized minecraft blocks
MIT License
3 stars 6 forks source link

Implement Structure Gadget #10

Closed gmlaxfanatic closed 9 years ago

gmlaxfanatic commented 9 years ago

The structure gadget should require that a functional block exists in a three dimensional configuration of specific minecraft blocks. The code to do this is mostly already written in the schematics branch of gmlaxfanatic's factorymod repo.

gmlaxfanatic commented 9 years ago

The biggest issue I have had to think about here is how to listen for block break efficiently, since they occur so frequently. If large structures are support I don't think we can any longer rely on a Map to store all of the contraption associated locations in the world, since if contraptions are 5x5x5 blocks that multiples the size of the map by 125, which if we shoot for 100,000 contraptions could have 10 million entries.

Here are options I have:

  1. Continue using a Map to store locations, restrict large structures to uncommon factories, so even if there are 50,000 piping contraptions, they all are 1 block, where as there are only a few 5x5x5 structures which don't effect the total number of locations representing contraptions by that much. O(1) on block break, O(n*j) on storage
  2. When a block is broken first check if it is part of a structure that could belong to a contraption, therefor this block check scales with types of contraptions and not number of contraptions. This would allow many large contraptions to be built. O(m) for block break, O(n) for storage
  3. Implement a quadtree storage structure for locations, this would mean search do not scale with structure size by they do scale with Contraption number. O(log(n)) on block break, O(n) on storage size.

(n is contraption number, m is total structure size, j is weighted average structure size)

Right now I am leaning towards option one actually, however methods should be designed such that another method could be adopted in the future if storage size becomes an issue.

ProgrammerDan commented 9 years ago

Just crazy idea, but how feasible would adapting something like PostGIS be for this context? Location queries in general aren't "fast", but a better database engine would make it seem fast, especially compared to the orders you're proposing. Might not be understanding completely the problem, but thought I'd toss it at the wall.

gmlaxfanatic commented 9 years ago

That looks like a great solution, if we wanted to do things perfectly. Right now I'm leaning towards just using a Map (option 1), mostly cause I have never worked with databases, and I think that a Map will be completely sufficient for the medium term. However this'll be a good reference if we do end up having to optimize around large contraption numbers each with their own bounding boxes in the future.

ProgrammerDan commented 9 years ago

Tell you what. If you leverage a DAO or other legit access pattern in the middle term, I'll scrounge up motivation to leverage a geographic information system database as a alteration to the backing implementation. That way you aren't blocked by learning new tech, but the structure can incorporate it in the near/mid term.

gmlaxfanatic commented 9 years ago

A DAO sounds like a great plan, and I think there is a good chance that we never need anything more than a map, but then we'll have that option.

gmlaxfanatic commented 9 years ago

Implemented in 8a2c797cb813823abfd0ec5404f160e45b6b65a8 among other commits.

There is a DAO to manage storage now, its just using maps for now, but that could be switched up if needed in the future.