Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=3968
This is a very old issue, first reported in
Crystal Mobs, amotion 0 adelay 0. It involves a mob with 0 adelay (say, CRYSTAL_1) attacking a player. When that happens, the server freezes, and exits after running out of memory shortly afterwards.
(the part with the server freezing is covered in a separate bugreport,
#3967)
The reason why these mobs' aspd does not get clamped to 199, as per the monster_max_aspd battle config setting, is because this limit is only applied in status_calc_bl_main(SCB_ASPD). In particular, it is not applied at the point where the mob spawns, and there is no status calc (ALL) activation. Therefore, the mob exists with its default, mobdb-specified, uncalculated values.
I have tested the spawn procedure for various units:
BL_PC: in pc_regs_received() at login time
BL_PET: in pet_data_init()
BL_HOM: in merc_hom_alloc() and various other places
BL_MER: in merc_data_received()
BL_MOB: nothing at all
Also, one more potential issue. In status_calc_bl_main, we have
CODE
if((!(bl->type&BL_REGEN)) && (!sc || !sc->count)) { //No difference.
status_cpy(status, b_status);
return;
}
For units that don't regen (I guess npcs and pets, also others if someone decides to change the define), this will let them completely bypass status calc even if it's invoked. This may be undesirable.