BYOND ERROR: maximum number of appearances exceeded (65535)!
I got this during another one of my stress tests, letting the game run on autopilot overnight. I don't ever expect to hit such a limit in real world play, but I'm curious nonetheless.
So what exactly does this mean? Anything I should look out for to avoid it, or does it just mean I've been mucking with things in a way they weren't designed to be mucked? ;-)
ID:259303
 Apr 8 2001, 3:56 pm
|
|
On 4/9/01 3:18 pm Dan wrote:
On 4/8/01 7:56 pm Air Mapster wrote: Just curious; the object table (i.e. the objs and mobs) also have a limit of 65535 occurrences throughout the world, right? If so, how big of a map would we be considering here to exceed that limit? If I'm not mistaken, some people are thinking about making massively multiplayer MUDs here, and you can't have massively-multiplayer MUDs without at least a semi-hefty amount of space. Basically, I'm assuming that designers could stick some 20000 random monsters throughout the globe, and then if players decided to purchase a lot of equipment... well, things could easily get overblown. Not to mention the various objs throughout the world. If objs and mobs are on a separate table, though, there'd be no need for concern. Like I said, just curious. | |
On 4/9/01 3:18 pm Dan wrote:
On 4/8/01 7:56 pm Air Mapster wrote: Yes, every turn, the player whose turn it is gets an overlay indicating that fact. And of course that overlay goes away at the end of the turn. There are also overlays indicating various other states that happen less often - player called Una, player is a PC in automatic mode, player has been forced to quit the hand. Occasionally an NPC will have its name and icon changed. In my test, there were: 48211 turns 186 quit player overlays added and removed 225 name/icon changes 871 Una overlays added and removed Obviously I don't expect a real world game to ever come close to these numbers, especially the turns! One thing that comes to mind is that instead of maintaining flags to keep track of what mobs have what overlays, I just do a <nobr>"mob.overlays -= 'icons/overlay.dmi'"</nobr> any time I need to make sure that mob has no overlays. Is it possible this could be a problem when the mob doesn't actually have that overlay? Other than that, it's pretty much standard <nobr>"mob.overlays += 'icons/overlay.dmi'"</nobr> and vice versa at the appropriate points in the game. Related to this, is there a better way to know if a mob (or whatever) has a particular overlay (other than keeping state flags to track the overlays)? I'm thinking adding the ability to have "mob.overlays.Find(overlay)" at least return true or false might help. But again, if the <nobr>"mob.overlays -= overlay"</nobr> is harmless, there's probably not much point. I suppose I could also do "mob.overlays.Cut()" to clear it, correct? Hmmm... something else - do icon_state changes apply to this as well? Each time a card is played, the icon states of four objects change. In the test, there were 38366 cards played. Also, direction and color indicators may change icon_state when necessary. There were 6496 direction changes and 10067 color changes. Hmm, how about visibility? Card visibility changes depending on whether it's in a player's hand or being played, etc. I think I don't need to touch visibility anymore, but I still have the changes in from older versions of the code. Of course this is all wild speculation on my part, but I hope it helps! | |
On 4/9/01 6:33 pm Spuzzum wrote:
Just curious; the object table (i.e. the objs and mobs) also have a limit of 65535 occurrences throughout the world, right? I hope that's not the case...it wouldn't be hard at all for a MUD to have this many active objects, even without a huge map. | |
The current limit is 65535 objs and 65535 mobs but also 65535 unique object "appearances", which is shared between the two. It is not a major change for me to up this to a much bigger number, but it will require a backwards incompatible change to the networking protocol, requiring everyone to upgrade their software. I'm not prepared to do that right now, but I'll definitely do it before it becomes an annoying limitation. In the mean time, it is helpful for me to have the lower limits, because it brings to light potential problems in the algorithms, such as the one Airmapster just found. --Dan | |
In my test, there were: I just do a <nobr>"mob.overlays -= 'icons/overlay.dmi'"</nobr> any time I need to make sure that mob has no overlays. That should be fine. Hmmm... something else - do icon_state changes apply to this as well? Yes. But as long as the number of unique object appearances (combination of icon, icon_state, overlays, name, visibility, etc.) does not grow indefinitely, this shouldn't be a problem. Is there anything in your game that would have caused it to grow indefinitely? For example, if object names kept getting longer and longer or something, that could keep generating new "appearance" entries. Unused ones get removed, but if there were a bug in that, then it would all depend on whether your game cycles through a finite (less than 65535) set of object appearances, or whether it is unbound (greater than 65535). I am conducting some tests now to see if I can uncover any problems in a simple case. | |
On 4/10/01 9:20 am Dan wrote:
Is there anything in your game that would have caused it to grow indefinitely? For example, if object names kept getting longer and longer or something, that could keep generating new "appearance" entries. Hmm, how about mob.suffix? If that affects appearances, I'll bet that's it. Suffix is always set to a combination of the player's current score and current number of cards in his hand, so that information can be displayed in a statpanel. In such a long game, there could be many (65535) combinations of this. I'm conducting a little test as I type this and I suspect it will confirm the culprit: mob/verb/test(n=32768 as num) src << "Will try [n] times..." for (var/i = 1; i <= n; i++) var/rn = rand(1, 1000000) overlays += 'icons/curplayer.dmi' suffix = "[src] is testing [i] times! (random: [rn])" overlays -= 'icons/curplayer.dmi' src << "Done." Yep. I get the maximum number of appearances exceeded. Also, testing without the overlay changes, I got a maximum number of strings exceeded instead (using n=65536). As you said, though, unused ones should get removed... does that apply in this case, or does BYOND keep the old ones around in case they're used again? In my case it would be more useful to simply trash the old appearances, but maybe you have reasons for keeping them? Again, I don't ever expect to hit these limits in real games, so it's not urgent for me... but perhaps in the future people will have games that are large enough to easily hit them. | |
Hmm. It maxxed out on the number of unique instances of an internal data structure I use to store the appearance of an object. (This is data shared between client and server.)
I can increase the limit, but I am concerned that in your case it should not have been happening in the first place. Is there anything that would progressively be generating new object appearances (combination of icon, overlays, name, etc.)? Even if you do so, unused ones should get garbage-collected. Perhaps there is a leak in that process.
--Dan