I would say that if you really need the answer to any of those questions, you're probably doing something wrong.
That's a terribly foolish attitude. Documenting this type of thing, is not only useful in general, but it's important, so that future developers know what limits are in place, and how anything works.
Actually, saying that needing to know the technical specifications for something implies that 'I'm doing something wrong', is downright rude. It should show that I'm doing something properly, by using all of the available information, to plan ahead.
Constants are constant. They don't need to occupy memory, as they can be swapped with raw values at compile-time, so that's why there is no limit on the number of constants. Functions are also constant. The limit for these should be the same as the total amount of memory you have to run the program. (Which can be arbitrary, depending on your machine setup.)
A global variable is simply one that isn't declared in a function body, so it will never fall out of scope.
A function takes arguments, and must have parenthesis after it's name.
int variable;
int function();
Curly braces define the function body, they don't really signify that you have a function.
Constants do use space on disc, in the save file, though; unless that's bad information that i was given in the past.
Right, so it's parens, in theory, that signify that it's a function. I assume that this always holds true with the ZC compiler?
There's nothing that documents limits on global functions. I would have thought that functions, constants, and arrays, were all constrained by max int. I know that Saffith wrote previously that the maximum number of elements in an array was 214,748, so I assumed that was the de-facto standard.
Yet, ZC doesn;t believe in standards, which is why I'm requesting these values... I'm hoping to put together something that people can use as a reference resource.
Can we at least have a list of the maximum numbers for the following:
- Verification that the maximum number of global variables is 256, and not 256 per type.
- Global script variables (per global script, and in total; if the cap is calculated across all global scripts).
- Item script variables.
- Item script args (assuming it's possible to pass values beyond the eight that can be used in the editor, to the script).
- FFC script variables.
- FFC script args (assuming it's possible to pass values beyond the eight that can be used in the editor, to the script).
- Function arguments (by type, if they aren't all identical)
- Array elements.
- Total declared arrays.
- Total arrays in use at one time.
- Total array elements in use at one time.
- Concurrently running scripts.
- Variables used by concurrently running scripts.
- Functions, in use at one time.
- FFC scripts, in use at one time.
- Maximum field size for an embedded string (array/float)
A definitive list of what necessitates a new .sav file would also be fantastic.
I've probably wasted about 15% of my time working with ZQ, making new .sav files, because I don't know if changes that I make in a game file, require me to do thus.
Perhaps, time allowing, the devs could try to answer the questions as provided above, assuming they have the information, rather than providing minimalistic or fragmented responses... ZC is sorely lacking a technical FAQ. (I formatted it as a FAQ, so that it could be assembled as a FAQ, and pinned somewhere.)
Whether anyone actually has a use for the knowledge, is entirely hypothetical. Clearly though, there's a conflicting amount of information on caps, and many unknowns, even to the current developers. That's what lack of documentation nets.
There isn't even a basic FAQ that states that constants are unlimited. I've been designing a game with the idea in mind that I can't use constants to define things, because they'd use valuable space; and I was wondering how many functions I could have that weren't of the type (void), because I didn't know if an int function (as an example), would consume a global register.
If I'd know this from the onset, I could have saved a lot of time, and made a lot of code more user-friendly. The documentation only states something generic, about 'globals', not even bothering to separate that in fact from local variables that are part of global scripts.
When you use two similar terms, you need to define any limitations thereof, with considerable finesse.
I think this was addressed, but the reason why constants have no limit is because they don't need to be in kept memory. They are kept in a table in the binary, or something like that, similar to function definitions (also unlimited).
The limits on globals ought to be expanded to arbitrary limits. I see no reason for them to be restricted for the user.
Is it truly no limit, or just a limit so high, that 'no-one cares about it'? That's not the same, as 'no limit'. How 'unlimited', is 'unlimited'? If you exceed 214748 constants, or functions (or a combination of both), what would be the result?
Are the values of constants contained in .sav files? If so, then surely that would mean that a .sav file should be of any size that a filesystem will accept; so why put such a low cap on other values?
...'or something like that', is the problem. We have only partial information, on a rather intricate, quirky compiler, with a variety of restrictions, and a lot of inconsistency.
std_constants.zh alone has well over 256 constants. Constants are simply substituted by their values during compilation, so the values aren't saved.
If you do this, for instance:
const int CONSTANT=6;
ffc script Test1
{
void run()
{
Trace(6);
}
}
ffc script Test2
{
void run()
{
Trace(CONSTANT);
}
}The ASM from the two is identical.
What is the maximum field size of a constant? Can a string be declared as a constant? Can an array of any kind, and the values therein, be declared as a constant? if the answer to these two is no, then the maximum field size would be ten decimal places, or a value of 2147483647. Correct?
There's a limit of 4096 arrays at once, in total.
Is that in operation at once, total; or declared, in total?
There's also a limit of 256 local variables at once; that's per script, I believe. It's not likely to be an issue.
Really? I was told that the maximum number of variables defined in scopes other than global was 214,748. That's going to make hard-coding strings very painful, as I was expecting to be able to have thousands of hard-coded strings available in the scope of single scripts. Before people ask why I'd need so many strings, please remember that what I'm making is as much an interactive novel, as anything else.
(That another reason that it takes so bleedin' long to produce story elements, and why I was waiting for the new Tango release.)
Actually, strings aren't variables anyway... I'm not sure what the 'type' is for a string, other than a string; but the compiler considers them floats. What is the limit (maximum total number of, and maximum length of each) of embedded strings, per script, and the type assigned to them?
It's still going to make flow control of them more tedious, as I'm going to need to make arrays to handle all the strings in a script, so I'll need to verify the maximum number of array elements, so that I don't exceed the 4,096 array cap.
See? I actually do have a use for this datum.
Technical Question: What is the reason for such a low cap on local variables? I can't imagine people trying to run 2.50 on a 386 with 16MB of RAM... a full page of ASCII text is usually ~<4KB.
Assuming that every value was 4KB in size, and you used 214,748 values, that would be around 850MB of memory space. Most values will be measured in bytes, so the cap seems to be entirely arbitrary.
As this has nothing to do with .sav files, because the values are local, is this a restriction that you think you could lift to max? I don't know what's limiting this, but it seems silly.
Is that a different limit on how many variables (or strings, or elements, or arrays, or functions) you can declare, versus how many you can have active, at one time?
What is the maximum number of variables that can be active at one time, from any/all sources?
If you max out your global arrays, yes, you can make the save file quite large, but it shouldn't get too big for the system to handle. The max is roughly 30MB per save.
Is that set by limiting field sizes for these data registers, or is is an arbitrary, fixed size of the file?
I don't believe there's any limit on functions. I certainly haven't run into one. There is technically a limit on the size of a compiled script, 2^32-1 instructions. You're not going to hit that.
No, I don't think any of us will ever reach that mark, but it's prudent, if naught else, to list all the technical specifications, restrictions, and related information. You never know though.
If you have the time, I'd appreciate if you, Gleeok, or anyone else involved could provide detailed answers to the questions above (in the FAQ format), to the extent of your knowledge.
DarkDragon and jman would know more about this stuff than I do, but they haven't been around for a while.
I don't know if DarkDragon would be willing to fill in the gaps, or would even recall the answers; and therein lies the problem. If this was documented, you'd know the answers, and so would I.
It would certainly be nice to have all of this information in one place.