Ideas for Major Changes
This is a page to list ideas for changes we want to make to Overviewer, but may be very large or may break backwards compatibility with old maps.
Note: Breaking backwards compatibility could either mean the configuration file format or interface breaks in a backwards incompatible way, or that the render algorithm changes and existing maps need to be completely rerendered.
A GUI would be nice for those less enlightened CLI-capable, or on Windows. Rymate has a good start for a Windows GUI, so we'll see how that turns out.
For those with very large maps, or someone looking to setup a general map rendering service, it would be very cool to be able to distribute the rendering work load to multi machines. This could tie into the continuous update/render idea below.
We have done a few preliminary tests with this idea, but ran into issues with the shared filesystem and caching problems. Specifically, when a worker goes to read in a tile, if that tile was just recently written out by a worker on a different node, the first may not get the updated version.
Our thinking is that a shared filesystem may not work and we will need to explicitly pass the data between nodes. This would be more work, but still possible.
Making additions to Overviewer is fairly awkward currently, it would be nice to streamline this for the end users. Note that there are a couple of different areas plugins could affect and a good plugin support system should account for these. Such as a pure JS plugin that only affects rendered maps, a plugin that has both Python and JS components and so needs to hook into overviewer_core.
There's a lot of functionality that probably does not belong in the core, so a good API is the first step to adding a lot of features.
We should strive to make overviewer as fast as possible. Pigmap produces very similar output, but runs much quicker. We should try to achieve pigmap-like speeds (even if this means re-writing some code in C/C++)
The easiest low-hanging-fruit here is to move the nbt parsing code to a C module. Doing a profile shows that is the current most expensive part of the python code.