Work on OctoberPeaks 1.2 is progressing but is pointing out some design questions.

For example, I think that tracking multi-block structures may require some new aspects: 1 for block orientation and 1 for multi-block root block location. These would be combined to allow multiple blocks to function as one since they could check each other when something breaks or is placed to make sure that there is always consistency. The question is how this should work within existing blocks.

An example of what I mean is a hopper. Hoppers currently have 5 "orientations" (each cardinal direction and down) but there is currently no generalized concept of orientation within the system. This means that they are represented as 5 distinct block types, which is kind of strange. The obvious solution is to convert this to use the new orientation aspect. However, this data conversion is rather complicated and I am not sure if it is really worth it, given that version 2.0 will allow a clean break on the data level.

There is a similar matter for fire where I think it might make more sense as some kind of special block flag, as opposed to its own block type (since then a wood log could be "burning" instead of just having a fire block on top of it which somehow applies to it). If I am going to add a special flag, should I also add other flags for things like "activated" or "open" (think of switches, lamps, and doors)? Should these also be re-written even though it would now mean needing to provide multiple sorts of data when checking how to interpret a block?

These questions are leading me to suspect that it might make sense to leave the current system alone and just build the new mechanics on top, only where they are required. This would avoid front-loading new complexities onto the system before they can be more freely implemented and avoids a very complicated data migration design (although I did some up with a mostly-sane way to do this). Further, it would mean no work on OctoberPlains to transition to this support in what is otherwise an end-of-life project.

Still to be considered but I think that leaving the broader refactoring of the internals to the 2.0 release is probably a sane approach.

Jeff.