ACC: Too many map Variables

[skadoomer]

This is mostly a question aimed at developers. I have a pretty massive Library system. When trying to compile code that was working before, I'm now getting the following error:

Code: Select all

 statdraw.acs.1229:Too Many map Variables.
 >HudTrackerMid

Removing some functionality (ie, other imported scripts that do statistic work) for this particulair library makes it work, but as it stands I've never hit this error message, nor do I know what it means. Have I reached the limit of acs, or has importing too many libraries into another library caused an overflow of sorts?

Offending Scripts will be provided upon request.

[Apothem]

I think this was one of those things that randy wouldn't expand on until someone hit the limit. Apparently you have! Perhaps we may get an expansion on the use of global variables and arrays as well?

[XutaWoo]

How did you-I mean, jesus christ, are you defining an entire RPG system per map?!

[Macil]

I thought the limit was several thousand? (oh guess I'm completely off on this then - guess I was thinking the script limit) I'm probably wrong on that, but if you're using more than a few hundred map-scope variables, you're either doing something wrong and some need to be script-local variables, or porting an entire game into ACS with hudmessages and... I don't think that would hit the limit if done right, especially since I've seen that done before. Can you show some or most of the code?

[skadoomer]

This is weird, it seems to be very picky at this stage about what libraries can be included in other libraries. I have some functions that require a single function from another library, so I may be getting caught in a complex web of import loops.

[randi]

The limit is 128, actually. It used to be 32 in Hexen.

[skadoomer]

Any chance it can be expanded to 65536 like everything else?

[Graf Zahl]

Can't you use global arrays instead of a shitload of single variables?

[skadoomer]

Well, kind of. It's not like I'm using a shitload of map variables, I've just got a lot of systems at work. Below are the scripts I'm using. I have two files setup to handle the quantity of #define values alone, and each library uses a few map variables here and there. Upon further examination, most of the map variables i've used are arrays. The offending file in the bunch is statdraw.acs. When removing the functions that are dependent on itemdrop.acs and weapon.acs (they are only used once), the library compiles without a problem. Keep the three lines and two libraries included and then there is a problem. Again, its this library specifically and none others.

Every piece of code is included, but i must warn I have minimal documentation in there, so good luck figuring out what something does.
edit
Download

[TheDarkArchon]

I thought the limit was several thousand? (oh guess I'm completely off on this then - guess I was thinking the script limit)

Script limit is 1000 (0-999)

[skadoomer]

Weird, I hit the problem again in a different library, though it is part of the stat**** end of things. I worked on one of the imported files (didn't even add in any values outside of the script scope) and I got the error again. Removing a library that i could easily substitute other functions fixed the problem. This leads me to think how i've got everything setup is causing the problem. Now here are my questions:
1) Do script scope variables count toward the count of map values?
2)If a library(1) contain map values is included in library A, and library A is imported into Library B along with the same library of map values(1), is the count of map variables essentially doubled because by inheritance, the library is effectively being added twice? I know #import is not the same thing as #include, but i think this might give me a better understanding of how I'm messing things up in my setup.

[Zippy]

I thought the limit was several thousand? (oh guess I'm completely off on this then - guess I was thinking the script limit)

Script limit is 1000 (0-999)

999. If I recall, script 0 is special and reserved by ZDoom; hence it should not be used by map authors.

[TheDarkArchon]

999. If I recall, script 0 is special and reserved by ZDoom; hence it should not be used by map authors.

It still counts,

(Script 0 is used for some of Strifes linetypes and has a special syntax in it's definition to prevent people accidentally breaking it)

[skadoomer]

I'm stumped. I did some math involving the two files that define all my map variables (f_array.acs and statdata.acs if you care to follow along in the download provided above). Between map arrays, string arrays and int/bool values, the total comes to 144, 16 over the limit. The weird part is all the libraries are still compiling as they should be. So I guess the fundamental question is how does ACS tally the map values between libraries? Does it follow the tree of imports and includes to build a sum that way, or is it local, specific to the file its-self (meaning it doesn't care what the total is in another library that is imported)?

[randi]

When you #import a library, you gain access to any map variables it declares, and they count toward your limit. It's been a while since I worked on the system, but I don't believe larger degrees of separation count. That is, a library imported by a library you import does not count toward your limit unless you directly import it as well.

Are there any places where you could substitute arrays in place of multiple variables? There is no limit on the length of an array, so you could pack multiple variables in them and use #define to give them symbolic names so the code is still readable. e.g.

Code: Select all

int myvars[2];
#define FOOD 0
#define DRINK 1

script 1 (void)
{
    // More food than drink?
    if (myvars[FOOD] < myvars[DRINK])
    {
        // Time to down a glass!
        myvars[DRINK]--;
    }
} 

(As an aside, map arrays do count toward your map variable limit. Technically, there's no reason why they can't have their own limit separate from normal map variables, except for some foolishness when I designed them. Unfortunately, it's too late to change them now, but I learned my lesson when I added world and global variables, as they are completely separate from their normal counterparts.)

Any chance it can be expanded to 65536 like everything else?

Actually, nothing has such a large limit.