Bitttymacod
Elweit --
This time I'm going to say that you have a good idea.
=:O *faints*
Bitttymacod
It's not for everyone, but it doesn't unbalance anything in terms of gameplay since the rest of us who deal well with text don't have to use it and don't lose.
Things can be coded to have flags as default (mainly for historycal reasons, as the new code should be very similar to the old one and not heavier), which can be substituted (one by one) by a user-selectable icon, choosing from an icon-pool (maybe suggesting a standard one, following BM de facto standard) while configuring.
As a matter of fact, the client-side "running" code (e.g. when you're around and look at the map) should change only in the "pointer" of the "icon" used: the flag or the icon(s) (plus the config part).
I bet the definitions file, now can contain a list like this one:
Item ____ icon ___ color
fauna ___ 0 _____ #00a000
named __ 0 _____ #ffa000
boss ____0 _____ #ff0000
portal ___0 _____ #a0a0a0
teleport _ 0 _____ #f0f0f0
(etc.)
New list could be:
Item ____ icon ___ color
fauna ___ 1 _____ #00a000
named __ 10 ____ #ffa000
boss ____11 ____ #ff0000
portal ___0 _____ #a0a0a0 <-- user didn't select a different icon here: will get a (gray) flag
teleport _ 2 _____ #f0f0f0
(etc.)
Thus, maybe, "flag" is the icon #0 (flag_icon) default one, so if you like to see your current setup, just avoid to tell the (ingame) configurator "named_mob -> named_icon" (where, named_icon is icon #10) and your map will show a flag even for "named_mob" spot (like now).
But, as *I* change the association from named_mob -> flag_icon (color #ffa000) to named_mob -> named_mob_icon (with or without color), I'll automagically see the new icons in the map where I previously see an orange flag.
If colors can't be implemented on pre-colored icons, I suggest to insert TWO sets of icons: a "white" one (black contours, white area), which should be colorable (AKA substituting white with defined color) exactly the same way flags are now, and a (pre)"colored" one, where the icon is only selectable but not colorable (AKA the ones we can see on BM site). Icons from the two sets should be selectable one-by-one (e.g. I can have a colorable one for OPs and a pre-colored one for TPs).
Bitttymacod
Config file should not increase a lot as (I bet) nowadays there should be a 1-1 association from a category to a flag color (didn't found the right config file): maybe the flag icon is an (undefined) default. Just add an icon's index there (one byte = 256 icons available, where icon #0 is the flag one).It will increase the size of the cfg file and will need some pretty careful coding to make sure it works. (All flag positions and colors are client-side, not server-side, and we only got colors a couple of years ago.) Since it IS client-side, it would be a good project for open-ryzom, however.
Being client-side means it won't impair the server in any way... so, maybe, we can have an higher landmark's number available (which, at the moment, I've been told is 127 Atyswide) with the improvement: nowadays computers 're far more powerful than 2004's ones and should handle more than 127 map icons/flags... maybe they'll handle an unsigned-int (65536) or even a signed-int (32768) instead of a signed short-int (127). ;)))
P.S.
I just don't know if I can "expand" the present suggestion to include the ability to even create new user-defined categories of landmarks: just new entries in the table with their own name (color if flag/colorable icons) and/or icon assiciation from the icon-pool.
___