> > Hi Jazz fans! > > I just sought the place in code where there is considered whether to > load a mobile or an object into given room or not. There is a check > if mob_index[x].number is lower than the arg2 in reset command. > What makes me amazed is that the number is increased whereever a mobile > is been loaded and it's pretty horrible to calculate the max number in > zone reset. > Has anyone dealt with the problem already? I thought of changing > the max number to depend on zone, not considering the whole universe. > So we have to count the mobs in the current zone first to know the max number > available. Has the mob_index[].number any sense then at all? > anyone? What that max number is is it controlls how many mobs of that type will load. If you load a mob and the max number is 1, if that mob existas anywhere in the mud, it will not load when the zone resets. Asa far as making it check only that zone.... consider this. You have a badass mob, we'll call him 'Bad assd unique mob'. Now for some reason he gets out of the zone, wether he's been sumoned, wanders out or hunted someone out of the zone. Now the zone repops. He's not in there to be counted, hence he loads again. Now you have *2* 'Bad assed unique mob's running around. The max_existing works pretty well IMHO, and if you are worried about it counting ALL the mobs in the game when a zone resets (thus lagging the mud and creating undue cpu useage) it doesnt. It runs through the mobile_index, which basically holds this info: The mob PROTOTYPE's vnum (or rnum, I forget), the # existing, and if it has a special procedure. Thus, it runs through a much smaller list, just checking the PROTOTYPES of mobs, and when they mtch up, it checks the number that exist in that index data. The index is increased or decreased by load_mobile or extract_char. Got it? IMHO this code needs no tinkering whatsoever.
This archive was generated by hypermail 2b30 : 12/07/00 PST