Added ability to hide POI/change icon for entity types #662

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
Contributor

redorkulated commented Mar 25, 2012

Allows different entity types to have a different icon or be hidden based on entity ID. As the markers py filter in the settings allow for any entity to slip through this could be used to mark mobs,chests etc..

Added ability to hide POI for entity types based on entity ID. It als…
…o allows different entity types to have a different icon. As the markers py filter in the settings allow for any entity to slip through this could be used to mark mobs,chests etc..
Contributor

redorkulated commented Apr 1, 2012

hey, is it possible for this to be included? I feel this would be quite useful for more then the overviewer generated POI. It could also be used to mark any form of ID. It could also make a standard way of selecting the icon, this could help the pull requrest #669.

Owner

eminence commented Apr 10, 2012

hey, sorry for letting this sit for so long. i (and the rest of the overviewer devs) have been busy. i still want to get to this, so please hang tight for another few days

Contributor

redorkulated commented Apr 10, 2012

that's cool I don't mind after all its your project :)

});
}});
}
- iconURL = overviewerConfig.CONST.image.signMarker;
+ var ShowEntity= {"Sign":true};
+ var IconEntity= {"Sign": overviewerConfig.CONST.image.signMarker};
@tswsl1989

tswsl1989 Apr 10, 2012

Contributor

Personally, I'd rather include this information as something like entity['icon'].
As I understand it, the information for each entity is generated in the genPOI script, which means the icon URI could be set in the main config file.

@redorkulated

redorkulated Apr 12, 2012

Contributor

the reasoning behind having the Icons defined here is if there is not a handler to deal with the entity (currently only signs are handled) then this will act as on / off. The icon for the signs is set in the main config file under "overviewerConfig.CONST.image.signMarker" which is referenced above. Do you mean that the icon / show entity objects above should be pre-set in the overviewer main config and then overridden (like regions used to work) by the user defined settings.py ?

+ 'position': overviewer.util.fromWorldToLatLng(entity.x,
+ entity.y, entity.z, overviewer.mapView.options.currentTileSet),
+ 'map': overviewer.map,
+ 'title': jQuery.trim(entity.Text1 + "\n" + entity.Text2 + "\n" + entity.Text3 + "\n" + entity.Text4),
@tswsl1989

tswsl1989 Apr 10, 2012

Contributor

For the same sort of reasoning as above, this could be changed to entity.text, with the line breaks being dealt with in the python code.

@redorkulated

redorkulated Apr 12, 2012

Contributor

I think that storing the text like this is perfectly fine, for example if we replaced the text1-text4 with text then what if i only wanted to show the text1 line (unlikely but possible)? I think keeping it the same as the output from the NBT code makes it more standard and flexible when more entities get added.

@tswsl1989

tswsl1989 Apr 12, 2012

Contributor

If you only want to show text1 then in the filter defined in config.py you set text=text1 rather than text=text1+"\n"+text2+"\n"+text3+"\n"+text4
This then means that other entities can be supported by setting entity.text with line breaks where appropriate in the genPOI rather than setting 4 separate text variables

Owner

eminence commented Apr 14, 2012

again, sorry for letting this sit for so long. i have a few thoughts:

i agree with what you're trying to do, but i'm not sure about the approach. so a few questions:

  1. What's the pint of var ShowEntity= {"Sign":true};? I assume this is here so you can set "Sign":false, which would hide all signs. Why if you want signs hidden, why don't you just exclude signs via the filter functions in your overviewer config.py file?

  2. Having something like var IconEntity= {"Sign": overviewerConfig.CONST.image.signMarker}; is good, we need this type of configuration. But I'd rather have this configured in the python config file, instead of the JS file (which isn't supposed to be customized by end-users).

In fact, I'd rather be even more flexible with how icons are specified. I am to support a syntax something like this in a config file:

renders['render'] = {
    # ...
    "markers": [dict(filterFunction=FF1, icon="foo.png", name="foos"), 
                dict(filterFunction=FF2, icon="bar.png" ,name="bars")]
}

let me know what you think

Contributor

redorkulated commented Apr 14, 2012

really this thinking behind this was having this Is be the fail safe defaults which are then overridden by a config, for example if the entitie Poi of mobspawner is enabled in a dodgy config but no handler is in the is to deal with such a type then it will silently hide them. I am all for configuring them in the py scripts and this being the fail safe default setup.

Owner

eminence commented Apr 14, 2012

fail safe against what? the user? what if the user wants to show mobspawners? they have to both edit their overviewer config file and views.js? we don't want the user to have to deal with both. in fact, we don't want the user touching views.js at all

Contributor

redorkulated commented Apr 14, 2012

no i agree with you the user should not be changing the view.js, what i mean is lets saythe overviewer core has not setup an icon for the mobspawer or an info box for a mobspawner (like it is setup for sign) then, in my setup, it would not (by default) want to show the mobspawner. currenty if i changed my config to show all entities they would all show as signs,

I believe it should work like this:
User has defined an icon for mobspawners in settings [ use this icon }
User has not defined an icon in settings
[
is it defined in view.js as as a display able icon? [ show as default icon } else { hide silently }

as i didn't know how you were going to do the config for these i made a stab in the dark aproche, what my script now needs i to reads the config and override the "defaults" in ShowEntity and IconEntity after they are defined and before the icons are generated. Ho thisp makese some more sense?

Owner

eminence commented Apr 15, 2012

Can you all take a look at 2a6769c and let me know what you think? It enables usage like in my example above. The docs also help explain the new mechanism: http://docs.overviewer.org/en/devel/signs/

Contributor

JonnyJD commented Apr 15, 2012

2a6769c:

'markers': dict(name="Chests", filterFunction=chestFilter, icon="chest.png")]

If you use chestFilter in 5 renders, you would have to specify the name and icon 5 times. That would be redundant.

I would prefer setting
entity["icon"] in chestFilter().

That means the icon location will be redundant in markersDB.js, but that is generated automatically. The config is generated manually.
You could also strip the icon out in genPOI.py and save this in markers.js.

Contributor

JonnyJD commented Apr 15, 2012

However, I like using the return value as the marker text.

Contributor

redorkulated commented Apr 15, 2012

Now so much for POI has been done I can see that this is not a needed solution, I do like the idea of customised icons in the markersdb, but to cut down on file size I agree that each POI could have a group which defines icon etc if none are given

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment