recognizing mvps

Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=3131

The eAthena mobdb contains a column called 'MEXP', which indicates the value of the mvp exp reward, if nonzero. This is a somewhat custom feature, and for some reason, there's a huge amount of code that examines this value to see if a mob is a mvp or not.


However... just who thought that this might be a good idea? Deriving secondary information from data is never a good idea, especially when it's not guaranteed to be 100% correct. What this thing needs is a more straightforward approach.

On aegis, mvps have a special join table that contains the mvp reward value and the mvp drops. Here, the 'mvp' flag is implied by existence of a row in the table - if a mob's id is there, the mob is a mvp. What I don't understand is why they chose to use 'putboss' - perhaps to have precise control over which mobs can be shown and which can't?

Anyways, back to eathena. This whole thing started by bugreport #2653: Boss Radar (Convex Mirror) where a person complained he can't radar one particular mob - not mentioning there are several others that also cannot be seen. This got 'fixed' today in r13813 by rewriting 30+ spawn files to use a new static spawn type 'boss_monster'.

So let's think about this a bit shall we? What was the true purpose of this update? Was it to
1. Make every mvp mob visible using convex radar? Well then you missed all the scripted mvps that require a script function to spawn. Also, this 'boss_monster' command does not enforce any relationship with the mob's actual 'mvp-ness' - you can just as well make a poring visible this way.
2. Make a very specific list of mobs visible using convex radar? I know it looks like Gravity decided to do it this way, but why? If you already know exactly which mobs are mvps, why add another flag like this? Is there some very significant idea behind this?

In the meantime, here's a suggestion. From what I know, all mvps give a fixed 50% mvp exp reward - so this mobdb column could theoretically be removed, and replaced with a simple yes/no mvp flag. There might be better solutions though.