Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=279
Currently, the only ways a mob can be marked as 'belonging to a guild' (for ally/enemy checks during WoE) are
- being a mob with special ai and having a master who's a PC (alchemist mobs)
- having guardian_data
I dug up some old revisions that updated the mob guild id thing -
r3051.
Basically, Skotlex removed the generic guild_id variable that each mob had, and added a guardian_data structure that stored both the guild id, and cached the guild's emblem. I think the rationale was "to minimize resource consumption when handling guardians".
But why the hell? By 'resource consumption' I assume he meant time spent doing guild emblem lookups when a guild-affiliated mob appears inSight. But isn't it a bit brainless to optimize out a few mobs that you'll only see from time to time, when you've got 100+ players running around you to worry about?
Anyways, this wouldn't be so bad, if the whole mob guild affiliation thing wasn't changed to depend on the concept of guardian_data. As it is now, you have to dynamically allocate a guardian_data object and fill it with dummy values if you want to prevent the owning guild from damaging it. Plus, all the data in the structure can actually be retrieved by looking up the guld data - so it's just a cache that needs extra management code to keep it updated.
Where am I going with this? Well, did you know that Emperium is a guardian too? Its guardian no. is MAX_GUARDIANS+1.
Now enter WoE:SE, where you need to have barriers and gateway stones behaving like that. Get my point? There needs to be a better way than hacking it...
PS: in function mob_guardian_guildchange(), no client update packet is sent; flaviojs said there's a packet for that.
This post has been edited by flaviojs: Oct 24 2007, 07:05 AM