-
Notifications
You must be signed in to change notification settings - Fork 481
TODO List
This is a list of ideas, things that we're not sure should be done, and need more investigation and/or discussion.
-
Allow renders to specify a list of rendermodes and north directions, and have the code automatically enumerate them. The downside is we'd have to generate a unique title for the user, but that would be their choice to make that tradeoff. Specifying north directions this way could invoke a special UI with rotate buttons.
-
Serial renders instead of interleaved ones. This may seem simple but there's a few details that make it tricky. Also I'm not sure the advantages make it worth it.
-
A more comprehensive mode to fix any inconsistencies in the output directory.
-
Better error handling and error messages all around. In my opinion, a traceback should never reach the user, we should be catching all typical errors (e.g. syntax errors in the config file) and providing a nice error message to the user that doesn't involve a traceback unless it's relevant.
-
Detect a change in the parameters for a render and trigger an appropriate fix. Similar to how a change in the number of zoom levels triggers some custom code to fix the output directory, a change in some other option could trigger some custom code where appropriate. None of our current options may be able to support this kind of automatic fix though.
-
Better logging all around. I would like to have named logging categories that can be turned on and off, similar to how e.g. gcc does things. Aside from that, there are a lot of debug log messages that aren't relevant but debug is still a useful mode. We should re-think what log messages are appropriate at each level.
-
Change the check modes to named parameters of e.g. a --mode option, instead of what we have now with --no-tile-checks, --check-tiles, and --forcerender. Instead it should be something like --mode=all --mode=check --mode=update. Along with this idea is a re-thinking of what modes are appropriate to expose to the user. the current --check-tiles isn't too relevant to any situation right now except an interrupted render, and now has this tile prune feature stuck in.
-
Along with the above bullet, we've been mulling keeping some kind of additional metadata for tile -> chunk timestamp mappings, so that we can have more information on which tiles need updating in certain situations such as an interrupted render or parts of the map get deleted. We're thinking along the lines of an sqlite database. If there is nontrivial overhead this could be an optional feature, with the sqlite file named explicitly in the config file.
-
In order to optimize the chunk->tile mapping in determining which tiles need updating, we could keep metadata on each chunk in easy/fast access. The problem is that chunks are so tall now that a single chunk update will trigger a large number of tiles to update. If we knew during chunk scan how tall a chunk really was (most chunks are filled mostly with air) then we could tighten the to-update tileset. During the rendering, the chunk height data would get updated. This means building in an area that was previously air may result in two renders for it to show up on the map. IMO an acceptable trade-off for this optimization.
-
Generalize the optimizeimg option: make it e.g. a list of optimizations to apply to each tile, or even call an arbitrary function.
- Along with that, add an optimization routine to check for blank tiles and omit them from being written out.
Things that we do want to do, but haven't yet.
-
Cobblestone Fences look lame - may be the fault of the texture, nothing we can do.
I'm going to do these items.
- Configurable logging and change default log output to stdout not stderr
- Finish regions