Large maps = No game

ID:263634
 
Jun 22 2007, 9:30 pm
Problem description:
Well I'm not really sure if this classifies as a code problem or not, but I hit a neat little wall.

I just designed one single map with a 500w x400h dimension, and when I went to load my game I find that I get this runtime error.


BYOND(355.914) ERROR: maximum number of lists exceeded (65535)!
runtime error: Cannot execute null.Add().

I'm not really sure why it fails to create new lists, but from what I understand there are already way too many created within the turfs. I went through all of my source and checked, and no turfs have any lists defined for them.

Is there some way around this? Or am I severely limited on creating maps for my game?
Jun 22 2007, 9:44 pm
You're creating (and saving) a list for each turf, somewhere. Check under datum or atom, too.
Jun 22 2007, 10:32 pm
no, theres no limit to how many turfs you can have. Plus DBOII has much larger maps than 500x400. So its definetly some sort of crazy loop or array parsing mechanism you need to look into.
Jun 22 2007, 10:39 pm
In response to Masterdan
There is a limit - it's just much, much larger. Additionally, turfs that are the same - all variables the same, type the same - count as just 1 turf towards the turf limit.
Jun 23 2007, 5:22 am
In response to Garthor
The only way I have lists defined is for either Movable ATOMs or by defining it as
var/list/players=list("me","you","that guy")


There are no area or datum list definitions, actually I'm not really sure how to even approach a datum or why I'd use it, I've never really had a reason.

I'm not sure if those kind of lists would cause this problem, but from my understanding defining them like that only creates one global list.
Jun 23 2007, 5:35 am
You have turf/var/something = list() defined SOMEWHERE in your code. Either that or something in the startup process is setting a turf variable to = list(). That's the only way you can get that error, unless you've got over 65535 mobs/mobs in your game, each with a var defined as = list().

If you didn't put it in your code, maybe a library or something you're using did. Make a small map and make a verb that'll list all the turf variables, then find one that says /list (besides verbs, vars and contents, underlays, overlays, etc... because they don't count)

turf/verb/ShowVars()
    for(var/v in src.vars)
        usr << "[src].vars\[[v]\] = [src.vars[v]]"
Jun 23 2007, 5:35 am
In response to The Naked Ninja
Uhh... What?
Jun 23 2007, 6:25 am
In response to The Naked Ninja
The turf lists may come from a library you've included, or the error may even happen because you have too many movable atoms in your world if they each have multiple lists.

I've written a little snippet to help you find the culprit.
mob/verb/check_lists()
    // Displays all non-standard lists in the world.
    usr << "Displaying all non-standard lists"
    var/count = 0
    for(var/atom/A in world)
        var/list/var_names = A.vars - "contents" - "overlays" - "underlays" - "vars" - "verbs" 
        // all vars except the built in ones that won't cause a problem.
        if(ismob(A)) var_names -= "group"   // mobs also have a built in group var
        for(var/var_name in var_names)
            if(istype(A.vars[var_name], /list))
                count++
                usr << "[A] ([A.type]) at ([A.x], [A.y], [A.z]) has a list called [var_name]."
        sleep()
    usr << "[count] non-standard lists found."

Enter that debug verb in your project. Then uncheck your large map in the file tab in Dream Maker so that it will not be included. Make a new smaller map with a couple turfs. Run the project and execute the check_lists verb. Any variables displayed are lists that could be causing the error, especially if the list belongs to a turf type.

If it doesn't find any, then the list may only belong to a specific turf type or it could belong to a mob or obj that you have placed on the map enough times to trigger the error. Make another map with every area, turf, obj, and mob type in your game and retry the check_lists verb.

The "List Husbandry" section of Lummox JR's Dream Tutor: Green Programming article explains how to avoid this sort of list explosion. You should be able to locate the errant lists by searching your code files for the var names that the verb produced.