Problem with mob resets

[Ylang]

I'm posting this here, rather than in the forum for my area, because I suspect other area writers (particularly Wish) might know something about this...

I'm having a curious problem with mob resets. I have nearly 100 mobs at the moment. There are more than 200 individual mob resets, to account for multiple instances. To control exactly where they're placed (which is moderately important for several mobs in the zone), I typically have X resets for a mob with limit X.

However, at or about 200 resets, I get a problem with the muditor. It appears to lose track of the last reset, and when trying to edit them, it loses track of everything else. If I load the .ARE file into the muditor, and don't edit mob resets, it handles the walkthrough just fine, however, which suggests it is a problem with the actual editing code. If I remove the most recent reset, all returns to normal.

It this a problem with the muditor, not being able to handle more than 200 mob resets? Or is this a strict limit on the number of resets allowed? I might be able to work around it by sacrificing some control over mob distribution, not making all the resets happen at the same time, and letting the mob limit control them instead, but that'll take a fair bit of work at this stage.

Any ideas?

Ylang Ylang

[Tokugawa]

I've never heard of this happening. However, that is a lot of mob resets, ;)

If needed, we can put the area file on the test port and see if the area file loads.

-Tokugawa

[Ylang]

I've never heard of this happening. However, that is a lot of mob resets, ;)

Hehe. True. It's a big area, with many mobs, and I tried from the outset to make the area interesting and useful to all levels, and all kinds of players, so there's something for everyone.

It's not that many, when you think about it. I keep doing walkthroughs to see that it isn't too crowded, but 100 mobs and 100 rooms quickly leads to 200 resets, because of multiple instances of some of the mobs.


If needed, we can put the area file on the test port and see if the area file loads.

I've removed some resets that aren't critical, so I can get the area wrapped up (I have just the last few key rooms, mobs and narrative items to finish), but I'll manually create a version as originally intended, so we can see if it works. I suspect it will, if the muditor walkthrough is any indication.

There's time to tune it anyway, since the connector needs to be written before installation anyway, and it will be fairly substantial itself, both for geographical and continuity reasons (about the size of the Forest of Fear, I expect).

Thanks,
Ylang Ylang

[Ylang]

BTW, the reason I thought Wish might have come across the problem is because I think I've seen the symptoms of the workaround in his Barbegazi masterwork.

Here's a theoretical example of the problem:

You have six guard posts. Each is supposed to contain two guards. So you make a sentinel guard, and make 12 resets with limit 12 on the mob. You /could/ do this with only 6 resets, still with limit 12 on the mob, and let the mob limit control what pops where, but this would not enforce the two-each distribution in the rooms.

This appears to happen in Barbegazi, where there are several rooms that are supposed to have four sentinel guards each. Sometimes, however, if only some of the rooms get cleaned out, one room's mobs repop in another, making eight mobs (and zero in the other room). If you kill all of them before a repop, they pop as intended, four to a room. This looks like a case of letting mob limits, rather than explicit resets, control where mobs appear.

I can't be sure, however. It might be that the Barbegazi case actually does have explicit resets for each mob, and in fact demonstrates that even this doesn't solve the original problem. It might be that you'd need multiple (identical) mobs (one per room) to make such scenarios fully consistent and fully controllable, and that is not really an option in a big zone.

Anyway, enough speculating, back to writing. :)

[boromir]

Hi,

Part of what I have had to do is create specific resets for mobs so that they appear in certain rooms. And as Ylang has stated, to keep the distribution even across multiple rooms. I probably dont have as many mobs/location combos as Ylang (and given the size of the area, probably a good thing !) but its still a a technique I have used.::lol::

Is there a way to update the reset process to allow for an even distrubution of mobs across rooms with the same specific mob resets? ::cool::

[Ylang]

Bump. Boromir's question is a good one, which has come up again in my connector zone.

This example is as follows: The zone is split into three or four regions, separated by no-mob rooms to control mobs that should stick to only one region. Some mobs appear throughout the zone, however. They have three or four resets, one for each region. If you kill one, however, only the first reset in the area file will kick in the next time the zone repops. The result is that the pan-regional mobs will in time bunch up in one region, corresponding to their first reset. This is not what was intended. Only killing all the relevant mobs, or a reboot, restores the intended distribution.

Is there a way for the mud to cycle through the mob's X resets as new mobs are needed? If this is too hard to keep track of across zone repops, an alternative might be for the mud to pick one of a mob's X resets at random to execute whenever that mob is needed.

Whether either solution is possible would depend on how the mud implements resets, I guess. If (as I suspect) it is a simple sequential read, with conditional execution depending on how many mobs with that vnum already exist, modifying the reset behaviour might be more tricky than one might want... It would, however, significantly increase an area writer's control over their mobs.

If anyone has figured out a solution to the problem that doesn't involve coding, I'd love to hear it.

[Ylang]

Now that I think about it, there's a workaround that might solve the problem. Add a sort of super-repop, which kicks in periodically (provided nobody is in the zone, and perhaps after the zone has been deserted for a given time period). This super-repop would not merely reset missing mobs and objects, but purge all zone rooms before beginning the reset cycle.

[Tamar]

This example is as follows: The zone is split into three or four regions, separated by no-mob rooms to control mobs that should stick to only one region. Some mobs appear throughout the zone, however. They have three or four resets, one for each region. If you kill one, however, only the first reset in the area file will kick in the next time the zone repops. The result is that the pan-regional mobs will in time bunch up in one region, corresponding to their first reset. This is not what was intended. Only killing all the relevant mobs, or a reboot, restores the intended distribution.

I don't know for sure how this works, but the solution that comes to mind if you have spare vnums is to just make the same mob under 4 different vnums, and then put each group of the separately-vnumed mobs into a region.

[Tokugawa]

I don't know for sure how this works, but the solution that comes to mind if you have spare vnums is to just make the same mob under 4 different vnums, and then put each group of the separately-vnumed mobs into a region.

Tamar is correct. If you really want to control how mobs are reset, you need to have specific vnums for each set of mobs/resets.

For example, if you have eight mobs you want to pop in two different rooms, lets say room A and room B. The way the code works now, is you would specify a mob count of eight for two different resets. Then when the mud starts 1 mob each is put in room A and room B. Then when the zone resets 1 more mob is put in room A and B. This continues until the mob count equals eight. Later, if one mob is killed in either room, the mud pops another mob until the count is eight again.