Instead of reading all Players and especially Entities and TileEntities
into RAM and than applying the filter functions onto them, filter
functions are used after each parsed chunk to get only the markers of
this chunk and not all Entities.
This reduced the RAM usage dramatically:
On a 233 MB map over 200 MB of RAM was used before.
Using these changes (and only having two filter functions for signs) not
more than 36 MB of RAM was used.
Since all the POIs are created from different lists, multiple for loops
were used. With itertools.chain these lists can be looped over with only
one for loop thus removing doubled code.
The code creating the actual marker dict out of the entity and the
result of the filter function was almost the same for every set of
entities. Thus it is now a function.
Instead of doing the UUID->name resolution for all players in every
case, only do it when EntityId is accessed and the name hasn't been
retrieved this run already. This makes genPOI usable for people who
have many players on their servers but don't wish to use player POI
while still using other genPOI features.
To do this, a PlayerDict has been created, which contains a dirty
hack to see if the requested item is EntityId and whether it hasn't
been set already.
Added support for filter functions to return dicts.
Added support for filter functions to return a list of coordinates to
draw lines between when shown.
If the returned type is a tuple, it will be interpreted as first the
title (i.e. hovertext), then the content of the infowindow. If the
returned type is a string, it will be used as both the title and
infowindow content (the old behaviour). This means that older configs
are still compatible and need no changes.
Here's how to use it:
have a list called "manualpois" in your config filled with objects that contain
the attributes id, x, y and z. Feel free to add more attributes as you need them.
Then, write filter functions to filter for your custom POIs (hint: use the id).
