[Feature] New map rendering method.

[Nima304]

Right now, the only two ways the map renders a tile for the first time is when a block is modified in an unrendered tile, or one does a full render command. A much-needed feature in Dynmap is to have Dynmap render an area for the first time when a player walks into the unrendered tile. This way, people can't run for days on the map, then start building in a completely black area, because they'd leave a fresh path along the map. Also, it would be great if Dynmap searched in the background for unrendered chunks and rendered them, without taking up much resources.

[FrozenCow]

The problem with this approach is that Dynmap needs to check whether the tile-file exists every player-move (this is somewhere around 30 times per second). When the world is already fully generated, this 'tile-checking' would be all for nothing and will only cost diskio. I could add this as an option in configuration.txt, but I won't enable it by default.

The plan I had was to support CHUNK_GENERATE event from Bukkit. This makes it possible for Dynmap to render chunks that were just generated in the world. After a full-render with Dynmap, all generated chunks are rendered. When a player walks to a new area, new chunks will be generated and thereby will also be rendered.

[boblehest]

So Bukkit has a CHUCK_GENERATE event? Problem solved then? :)
What (I think) Nima304 meant was of course to render chunks when they are created, not necessarily when you touch them for the first time.

Edit: And sorry for the -1 vote, that's a github bug :)

[Nima304]

Frozen, what about searching in the background for unrendered chunks? Is there any way to be able to do that? I tried a full render a few days ago, and I found that although it did render large parts of the map, a few parts were left unrendered.

[FrozenCow]

Well, I could also hook CHUNK_LOADED or something. That's being called when a chunk is loaded (or loaded after being generated). Maybe just make a list of hooks in the configuration where you can enable/disable all the different hooks. When you have no hooks enabled in the list, you have disabled runtime-rendering altogether.

[Nima304]

That would be great, actually. Making it more configurable is always better. Probably better to have them disabled on default, though, unless you're going to change the priority of the processes to low.

[pwood]

I upvoted but not sure GitHub took it. But I too would love this, rendering on load or generation seems to fit the bill.

[boblehest]

Nima304: That would be a waste of resources imo. If you just render chunks the first time they're created, and then update them whenever they're changed, it shouldn't be necessary to keep searching for unrendered chunks.

[FrozenCow]

Yes, for most things it is a waste of resources once CHUNK_GENERATED is implemented. Though there are some cases where you want to have the option. When there is a forest fire, some people want to keep that up-to-date all the time. Others don't want to overload their server for things like that. That's why I'm still allowing people to choose their render-triggers... (it's also handy for me, because PLAYER_MOVE trigger is a nice way to test heavy rendering).

[mikeprimm]

We've finally gotten a good CHUNK_GENERATED hook from Bukkit, and we've provided the corresponding render triggers, as of 0.19 (along with optional triggers for other block-altering events, like leaves fading, snow/ice forming, and the like). The new default triggers should do a good job of organically growing a map, without requiring fullrenders for maintenance.

[mikeprimm]

This is completed, per our intentions - please reopen if there are more comments or items to discuss