MAX_STATIC_DATA maximum reached

I have reached the max_static_data limits (which are 180000) and I have changed tham to 990000.

What are these limits for?

I mean, I have created 8 or 10 tables with 5 to 10 rows and maybe a dozen columns each or a little more.
I will need to create a lot more tables but I already reached a limit.
I don’t get the meaning since we use now pretty much powerful computers with a whole lot of memory available, and considering I am writing a text game I see no reason why some memory limit should be reached so fast.

These limits serve no current purpose. However, the I6 compiler is built on the model of pre-allocating all memory, and redesigning it will be a lot of work.

Until somebody does that work, the static limits will remain. They will probably be bumped up occasionally, but this is a somewhat reactive process.

Seems like something else is going on. Given what you’re saying, you shouldn’t be maxed out on anything…?

I have exactly 14 tables. 2 of them have 2 columns, most of them have 24 columns. None have more than 15 rows.
btw I have 2 or 3 tables of lists (small lists, but lists).
Well, after have changed the limit everything looked fine.

FWIW, even very small lists are tremendous memory hogs. There’s some discussion of it here; as zarf says:

I made a game that basically had nothing in it but tables of lists (one room, eight objects I think, a couple of relations, 52 lists) and it blew right past the z-machine memory limits. (Don’t worry if that doesn’t mean anything to you – what I mean is, it ate up a lot of memory.)

Are you compiling as Glulx? And maybe find a way to handle your mechanic other than lists?

I compile as glulx.
Since I knew lists eat a lot of memory, I have very few lists. And each have just a few items in it.

As others have mentioned before, it doesn’t matter how small your lists are, they still munch memory. Also, having just one list requires quite a bit more memory than having none at all. Not that there’s anything to worry about with Glulx, but if you’re using lists anyway, there’s no need to be stingy with them.

I wouldn’t worry about the memory consumption if you’re compiling to Glulx. “Lots” is a relative term, and while it certainly applies to lists when you’re compiling to the tiny Z-machine, it isn’t the appropriate descriptor when you’re compiling to the Glulx VM. Even lists with several thousand entries won’t cause you any problems with Glulx.


Okay thank you.
I bumped into another limitation yesterday, not about lists but the number of temporary variables allowed (it is said the limit is 15).
I created several subfunctions to solve the problem.
I haven written 5% of the game and already hitting so many limitation I am wondering if Inform 7 was the right choice (lol)

This is not a problem that people report frequently. I suspect there’s something about the way you’re writing the game that is taking up more resources than you really need. You might want to find a friendly programmer to look at your entire source in detail and see if there are any red flags.

You mean “Too many local variables for a routine”? I am curious how you hit that in I7.

In Glulx this limit is raised to 119.

The I7 compiler has a limit of 15 temporary variables in a single rule. I suspect that this is the limit referred to. It shouldn’t affect most authors, but I’ve run into while having to do a lot of math…


Yes this is it.
You can hit it easily.
Try to create more than 15 variables with
let X be a number
let Y be a text

If they deal with tables it may be limited to 7.

I have a strong feeling you are treating I7 like some other programming language, and not taking advantage of the power that it does have. You could take a step back, and look for things that you could do in a more “Informish” way, or you could look around for a language that fits your style better. TADS 3 is more like traditional object-oriented languages, for example. So is Inform 6.

I’m definitely curious now. Would you mind posting the full text of a rule or phrase you’ve written that contains more than 15 variables?

This has been bothering me since your first post. I’d like to take a look at your code. Or your pseudo code. Or whatever you’d like to provide. You shouldn’t be hitting this many memory limitations.

I haven’t run into this I7 limit before. I suspect that most game authors haven’t.

It’s worth filing a feature request to raise it (for Glulx games). It’s probably easy enough, and it just hasn’t been looked at, simply because most game authors don’t run into it.

On the flip side, as capmikee was saying – most authors don’t run into it because there are often ways to do things that don’t require temporary variables.

since I corrected the problem I am not sure if seeing the code would help (anyway I post from my phone right now so I can’t past it).
This is a code for a punching action which checks in order the potential damage done to a body part, the potential damage done to its bone(s) the potential damage done to the internal organs, and that calculatel also the critical hits. The relative size of the persons is also taken in account. The progression of the damages and their probabilities are define for each bodypart, bone and organ in tables.

I couls have done it more informishly but I am not familiar with rulebooks and activities yet. I would’t know how to code an in depth fighting system with them…

Oh, you’re the one doing the complex RPG/simulation. Let me guess, every person has a collection of body parts, every body part has a collection of tissues, every tissue has a collection of statistics, and you end up with a really big amount of data because of that.

I think it could be done in I7, but it might be a good idea to get more familiar with the language first, perhaps with a simpler project. Or you could use a language that’s better adapted to detailed simulations. Inform was originally created for more descriptive games, where the world model has only enough detail to represent it as prose.

I still think this could be done more simply with properties.


Curious to see what the end result looks like, though.