46 replies to this topic

[Timelord]

I know that true global variables, have a cap of 256 in ZScript.

 

I wanted to check a few facts, and clarify some things:

 

1. Do global functions, that are ints, bools, or floats, count as variables?
2. If not, what is the maximum for global int, bool, and float functions?
3. What is the maximum number of global (void type) functions?
4. Do global constants count against the maximum number of global variables?
5. Do variables defined in the scope of a global script, count as local variables to that script, as global variables, or both, (with regard only to the limits on maximum global vars, not their intended scope)?

 

Example:

int globalThis;
int globalThat;
 
global script active{
    void run(){
         int LocalThis;
         int LocalTthat;
}
 
global script onContinue{
      void run(){
         int LocalThis;
         int LocalTthat;
}
 

 

The variables globalThis, and globalThat, are by definition, global variables, but are LocalThis, and LocalThat, considered global variables (with regard to the maximum allocation, not with regard to their actual scope)?

 

[LinktheMaster]

I don't think global functions count against your list of variables, and I don't think there's an effective maximum number of functions.  There may be one, but I don't think there's one specified by the devs.  Nick and I haven't hit that wall, and we have a ton of functions that come from either std.zh, libraries, or are custom written.  If there is one, I'd expect it to be a pretty high number.  However, this is just speculation.

 

For numbers 4 and 5, I do know the answers.  Global constants do not count against the maximum number of global variables, and variables that are defined in the scope of a global script don't count either.  Those are separate.

[Timelord]

I don't think global functions count against your list of variables, and I don't think there's an effective maximum number of functions.  There may be one, but I don't think there's one specified by the devs.  Nick and I haven't hit that wall, and we have a ton of functions that come from either std.zh, libraries, or are custom written.  If there is one, I'd expect it to be a pretty high number.  However, this is just speculation.

 

For numbers 4 and 5, I do know the answers.  Global constants do not count against the maximum number of global variables, and variables that are defined in the scope of a global script don't count either.  Those are separate.

 

Oh my... You don't know how much trouble that's going to save me. I've been avoiding the use of constants, because I didn't want to max out on global vars. That's why I didn't understand the reason that people would assign constants to elements of small arrays, if the idea is to conserve space, and why people are willing to make anything a constant.

 

I expect, that if global constants don;t have the same limit as vars, that they use MAXINT as their limit.

 

There's no straightforward list of limits anywhere, or anything that separates different types, and lists the limits of each. We could really use a definitive list of each type, and its limits in global, and local scope, with clarifications like these.

 

How does the compiler differentiate between a global int/float/bool function, and a global int/bool/float variable, when determining the number of each in operation?

[LinktheMaster]

See, the thing is, if it's something that's static and unchanging, the data can merely be stored in the quest file itself.  For example, an actual function is not going to be changing at all, so until it needs to be accessed and put into memory, it can just stay on the hard drive.  It's the same thing with a constant.  Since it's unchanging, there's no reason for it to always be in the memory.

 

However, variables, which constantly change, have to always be in memory to make sure that their values are not lost.  If these weren't capped, quests could theoretically use a crazy amount of memory which could break the quest (or perhaps worse) on older machines that don't have much memory at their disposal.

 

This is pretty much what I'm guessing and understanding.  I could be wrong, but it's what makes the most sense in regards to why constants don't go toward the limit on global variables.

[Timelord]

See, the thing is, if it's something that's static and unchanging, the data can merely be stored in the quest file itself.  For example, an actual function is not going to be changing at all, so until it needs to be accessed and put into memory, it can just stay on the hard drive.  It's the same thing with a constant.  Since it's unchanging, there's no reason for it to always be in the memory.
 
However, variables, which constantly change, have to always be in memory to make sure that their values are not lost.  If these weren't capped, quests could theoretically use a crazy amount of memory which could break the quest (or perhaps worse) on older machines that don't have much memory at their disposal.
 
This is pretty much what I'm guessing and understanding.  I could be wrong, but it's what makes the most sense in regards to why constants don't go toward the limit on global variables.

 
That's actually not likely, from what I understand of how the .sav files work, and why there is a cap on global vars. My thinking was, that if global constants are stored in the .sav file, with variables, that they must not exceed the 256, let's say registers here, although I don't know exactly how the values are stored.

 
For the record, according to Saffith and Gleeok, local variables have a standard, 32-bit cap, 2,147,483,647, floored to 214,748. That's a ZC limit, by the by, because of internal float handling oddities. If ZC used floating point operations properly, we could use all 2.14-Million values, at any given time. (A 32-bit system couldn't handle more simultaneous values/operations than that, without bankswitching them, or otherwise remapping them.)

Thus, anything that creates variables that aren't global, can have 214,748 maximum components, be they arrays, variables, functions, etc.. Only truly global values have a cap, and thus, I'm always concerned on what I'm using; and there's no reporting function available (to my knowledge) that will tell me how many I'm using.
 
Global variables, on the other hand, need to be saved between sessions. A local variable is not saved to the hard disc, and thus, not part of a .sav file; but a global variable, is stored in the .sav file, between games. The reason for the cap, is because the ..sav file only allocates space for 256 values. That's what I understand, from my conversations in the past; however the developers may fee free to slap me on the wrist, and correct that, if I'm wrong.

 

Values stored in memory, in any event, aren't a problem here. It's the pre-allocated size of 'slots' in .sav files, and the 'register' space available in each, to store the values of global variables, that were in RAM, on re-starting, continuing, saving, etc.. The .sav file allocates 256 registers (or something of similar nature) to store these values, whatever size they may be, in the .sav file, per game save instance.

 

The size of the file itself, and the length, or size of a value, is probably not limited by anything; save local filesystem handling, unless there is some internal, forced limitation. (A single global array with 214,748 elements, would be stored in a single register, in the .sav file, however I'm not sure of the .sav file has any kind of field length restrictions for this kind of consideration, nor do I know how it handles mapping the data registers, or data fields, to prevent overlays.)

That's why I expected that constants were restricted too: I recall that constants were stored in sav files, and when changing constants, your old .sav file may be incompatible with a new game. (That may not be correct, and that may only apply to global variables.)
 
There are ways to cheat this system too. Assuming that constants aren't limited to 256, and are instead limited to 214,748 values, you could make 256 arrays, with 839 elements each; assign a constant to each element, and use those elements via the constants as independent global variables. That would give you an effective limit of 214,748 global variables, although it's not practical, or necessary. (It would also slow down the reading of stored values.)
 
You'd also always need space for other things. I'm assuming that if any function counts against a single main cap, that variables, arrays, constants, and functions combined, have a cap of 214,748 components (of any combination of types). You could still cheat the system to a large degree though, but I don't have a factual answer as to the actual maximum numbers of any of these components, in any instance.
 
(I'd really appreciate some confirmation fro the developers, as well as some kind of data sheet, or other reference, on limits of this sort.)
 
I think I'm going to need a response from the developers on how the compiler differentiates between a declaration of a variable, such as:

int value;

 
...the declaration of an operation,  such as:
 

int rand10 = Rand(1,10);

 
... and the declaration of a function, such as:
 

int produceValue(int a, int b){
int value = Rand(a,b);
return value;
}

 
...to decide what is, and is not counted as a value to store in the .sav file, and thus, a value with a relatively low cap.
 
(I'm assuming that if the compiler encounters a curly brace, that it knows that the int above is a function, and not a variable...)
 
I also wouldn't mind some clarification on if constants are saved in the .sav file, and in any case, a definitive value if the cap on maximum constants is other than 214,748.

Edited by ZoriaRPG, 02 June 2014 - 09:21 AM.

[LinktheMaster]

Ah, that's a good point.  I hadn't thought about the .sav aspect of it.  That would be another good reason for capping the number of global variables.  If you had a bunch of quests and all of them had a ton of global variables, that could stack up to making the sav file really big.

 

But, yeah. Saffith or Gleeok will have to jump in and answer.

[Timelord]

Ah, that's a good point.  I hadn't thought about the .sav aspect of it.  That would be another good reason for capping the number of global variables.  If you had a bunch of quests and all of them had a ton of global variables, that could stack up to making the sav file really big.
 
But, yeah. Saffith or Gleeok will have to jump in and answer.

 


Here's my problem, or point with that: Assuming that the .sav file has 256 fields, for variables, and must read them by field identification, the fields may not themselves have a limited size. If you follow the path that I outlined above, using arrays entirely, you could have 256 field entries, of arrays, with a total data space that occupies up to a 32-bit file size; that, depending on your filesystem, may exceed the capability of your filesystem to read, or to store... 
 
The size of any single array element is probably restricted by something, in terms of its data size, to prevent that, but the only thing that I know about that is limiting the file size, is the number of fields, not the amount of datum stored in a single, given field. I'm not sure what the capacity of any single field/register is in a .sav file, but unless it;s intentionally constrained, the 256 value limit doesn't prevent the file from becoming a gigantic monstrosity.
 
I'm not sure how soon to expect any kind of in-depth technical explanation,that defines all of these things, but if we ever have one, please add it to a pinned FAQ.
 
I would consider all of the following, important technical questions:
 
(Q) What is the largest value in ZC/ZQ
(A) 214,748.3647 (floating point), or 214,748 (integer).
 
(Q) What is the cap (maximum number of) global variables?
(A) 256
 
(Q) Exactly what constitutes a global variable?
(A) --Speculative--A developer would need to explain this, and determine what does, and what does not count as a global variable, and how to easily determine what shall, and shan't be treated as such.
 
(Q) Are depreciated uses of declaration still accepted by the compiler?
(A) Unknown.
 
(Q) Do global arrays count as single, or multiple global variables.
(A) Each array counts as a single global variable.
 
(Q) What is the maximum number of elements per array?
(A) The largest technical number of elements, per array, is 214,748. The largest usable (safe) number is --speculative; unknown--, based on other variables in memory.
 
(Q) How is the data size of an array element defined, and by what means is is constrained (if any)?
(A) Unknown.
 
(Q) Do concurrent running variables, from more than one source, count cumulatively against a total ceiling?
(A) --Unknown: Do vars, and values from multiple functions each have a maximum of 214,748 components, or is that a maximum for any and all running processes? If so, what is the total maximum ceiling?
 
(Q) Do global constants count as global variables.
(A) No.
 
(Q) What is the maximum number of global constants?
(A) Unknown; further, is the maximum constrained by extant variables, and functions?
 
(Q) Is the maximum number of variables and functions running at one time, a single value, or are they segregated into their own memory pages?
(A) Unknown.
 
(Q) What is the maximum number of functions in any single scope?
(A) Unknown; assumed to be 214,748.
 
(Q) What is the maximum number of functions, that can be compiled?
(A) Unknown.
 
(Q) What differentiates a function, from a variable, to the compiler?
(A) Unknown; assumed to be a curly brace.
 
(Q) Precisely what values are stored in the .sav file?
(A) Unknown.
 
(Q) Are values stored in the sav file limited to a specific field size, and if so, what is that size?
(A) Unknown.

Edited by ZoriaRPG, 02 June 2014 - 10:58 AM.

[RetraRoyale]

I would say that if you really need the answer to any of those questions, you're probably doing something wrong.

 

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.

 

 

(Q) What differentiates a function, from a variable, to the compiler?

 

 

(A) Unknown; assumed to be a curly brace.

 

 

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.

[anikom15]

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.

[Saffith]

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.

There's a limit of 4096 arrays at once, 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.

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.

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.

DarkDragon and jman would know more about this stuff than I do, but they haven't been around for a while.

[Timelord]

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.

[Saffith]

What is the maximum field size of a constant?

I'm assuming you mean the maximum value. It's 214747.9999, the largest numeric literal the compiler accepts.
 

Can a string be declared as a constant? Can an array of any kind, and the values therein, be declared as a constant?

No and no.
 

if the answer to these two is no, then the maximum field size would be ten decimal places, or a value of 2147483647. Correct?

It's a little less because of some weirdness in parsing.
 

Is that in operation at once, total; or declared, in total?

In operation. Valid array pointers are 1-4096. One is selected when the array is allocated, and they can be reused.

 

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.

No, it's that many in the script's stack at once. As long as they're not all in the same scope or something, you should be fine.
 

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?

A string is a numeric array. A pointer to an an array is the same type as the elements of the array. There's no limit on the number of strings in a script, only the number in use at once.
 

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.

4,096 at once, not total. Shouldn't be an issue.
 

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.

Partly that the stack is so small... Other than that, I don't know.
 

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?

There's no limit on how many you can declare.
 

What is the maximum number of variables that can be active at one time, from any/all sources?

There's only a per-script limit.
 

Is that set by limiting field sizes for these data registers, or is is an arbitrary, fixed size of the file?

I don't know.

[RetraRoyale]

My point was that anything you are doing to bump up against hard limits on such things is not the proper way to write scripts. Many of those questions are unreasonably obscure, and asking them directly is the wrong way to approach the problem.

 

It's like asking where every transistor is in your CPU. Not even the CPU designer cares about it because it's far too low-level for any reasonable problem. Or how many times the letter 'e' is used in War and Peace. Yes, the information technically exists. But it doesn't matter, and asking about it is not how you want to learn to solve programming problems.

 

Don't ask what the limit of the number of functions is. Ask why such a limit does or doesn't exist.

 

(If you are concerned about hitting hard limits on arrays, then you are probably using the wrong tool for the job. Personally, I won't be asking about using hard-coded arrays to represent strings, but about why I couldn't simply read strings from a text file.)

 

Constants do use space on disc, in the save file, though; unless that's bad information that i was given in the past.

 

When I said 'memory', I was talking about primary memory, not secondary storage. Programs don't really use the hard drive, they use memory allocated by the OS, which can be anything; RAM, HD, cache, network, etc.. The OS can even use your hard drive as RAM, if it wants.

Edited by RetraRoyale, 02 June 2014 - 03:28 PM.

[Timelord]

My point was that anything you are doing to bump up against hard limits on such things is not the proper way to write scripts. Many of those questions are unreasonably obscure, and asking them directly is the wrong way to approach the problem.
 
It's like asking where every transistor is in your CPU. Not even the CPU designer cares about it because it's far too low-level for any reasonable problem. Or how many times the letter 'e' is used in War and Peace. Yes, the information technically exists. But it doesn't matter, and asking about it is not how you want to learn to solve programming problems.
 
Don't ask what the limit of the number of functions is. Ask why such a limit does or doesn't exist.
 
(If you are concerned about hitting hard limits on arrays, then you are probably using the wrong tool for the job.)

 
Sorry, I'm never going to agree with you on that, so please drop it. If it doesn't interest you, leave it be; as it does interest me, exactly as I'd asked.
 
I am an engineer sir: I used to design logic devices (CMOS), and I do want, and need to know how many gates are in a logic device, and how each one operates.
 
Why the limit exists, in this case, is arbitrary allocation, that has never been updated. that doesn't tell me what the limits are, so that I can account for all of them. I find these values, extremely important, for what i plan to do, and I'm going to move on to another important question, and probably move this topic to a PM thread, to stop this banter, because telling me not to ask a question, is essentially commanding me to be ignorant.
 
I would never do that, to anyone on this, or any other forum. I answer all questions that I can, in as much detail as I can, as I believe that there is no such thing as too much information, too much knowledge, or too many facts; only too much ignorance, or lack of information. Please show me at least the same level of respect that i would do for you, in turn.

 

I always believe that information should be available, to whomever needs it; rather than having a third-party decide what someone else needs to know. (I also come from an era, where applied chemistry, and calculus, were required learning.) The idea that you only need basic, minimal information, doesn't pass with me.
 
 

I'm assuming you mean the maximum value. It's 214747.9999, the largest numeric literal the compiler accepts.

That was my fault, for being non-specific: The total number of values is 214,748, including 0, and I forgot to mention that; for 00000.0000 is a logical value, unless ZC hndles this inappropriately.
 

In operation. Valid array pointers are 1-4096. One is selected when the array is allocated, and they can be reused.
 
A string is a numeric array. A pointer to an an array is the same type as the elements of the array. There's no limit on the number of strings in a script, only the number in use at once.
 
4,096 at once, not total. Shouldn't be an issue.

Right'o. The compiler declares it as a float, and i assume that;s true. I'm not sure how translation if ASCII to numeric values happens, if it's on a byte, or bit level, but that particular aspect isn't crucial. (I'm assuming that the compiler converts the ascii chars into numeric values, and doesn't store the text here.)
 
Partly that the stack is so small... Other than that, I don't know.


I want to clarify something else now:
 

In operation. Valid array pointers are 1-4096. One is selected when the array is allocated, and they can be reused.

Please tell me which among any of these these statements is true:

1. I can use 4,096 array pointers that can be in memory at one time, in total, regardless of their source.
2. I can use 4,096 array pointers per script.
3. I can have more than 4,096 arrays in use, as long as each is from a different source. (I expect not true here).
4. When a string array is read into memory, it can be replaced.

What actions cause the array to flush, and is there a specific way to force flush arrays, so that I can have 10,000 arrays in a script, and use only those that I need, clearing them, once they've been used, assuming that script continues to run?

This is important, to allow text flowcharts, for branching story paths. What I'm figuring, is that I'll need some master arrays to control the flow of a storyline, with individual characters, that activate if/else/do statements, and read string arrays into memory to play them.

Once I display a string, what action(s) cause(s) it to flush, reallocating its pointer, and can I do it by some manual means?

I still need verification on the maximum number of elements in an array. I think, because no-one has ever attempted anything like this in ZC, that the problems I face are pretty alien, but imaging one of those choose your path novels; and then imagine that every character is one of those. Player actions, choices, and story paths set a base attribute, for each NPC, and the actions of the player with that NPC influence not only future relations with that NPC, but also with others: It's a living world, of consequences, and will take years to complete.

I'm hoping that in a future release, we can lift most of these caps. They made sense in 1999-2001, but today, there's no reason that we can't raise them, but that would necessitate a change in the save file architecture. I think I'm slowly proving what it is possible to do with ZC, and the scope of my production, is rather gigantic. The sheer focus on story and detail, as planned, will likely surpass most commercial RPGs.

 

That's why i need to resort to tricks, to achieve my goals; and I need to know as much as I can, about the limits, so that i can play ahead, and build structures that allow me to control the flow of information.

 

I think that I can use a series of master arrays to help with this:

 

1. Primary (global) array, that stores main path values for the story.

2. Local arrays, in the tango scripts, to set the if/else path, to choose the correct string arrays.

3. Load only those arrays, selected with if/else statements.

4. Ensure that no more than 4,043 string arrays are in memory at one time (reserving at least fifty for other things).

 

Knowing as much as I may, will allow me to make a better product, and really push ZC as far as I can in the process.



 
 
 
 
v

Edited by ZoriaRPG, 02 June 2014 - 04:32 PM.

[Saffith]

(I'm assuming that the compiler converts the ascii chars into numeric values, and doesn't store the text here.)

Yes.
 

I can use 4,096 array pointers that can be in memory at one time, in total, regardless of their source.

Yes.
Edit: Actually, looks like it's really 4,095.
 

I can use 4,096 array pointers per script.

That many or more. There's no limit on how many can be in a single script.
 

I can have more than 4,096 arrays in use, as long as each is from a different source. (I expect not true here).

No.
 

When a string array is read into memory, it can be replaced.

Yes.

 

What actions cause the array to flush, and is there a specific way to force flush arrays, so that I can have 10,000 arrays in a script, and use only those that I need, clearing them, once they've been used, assuming that script continues to run?

An array is freed when the scope in which it was declared is exited or when the script that declared it stops running.
 

Once I display a string, what action(s) cause(s) it to flush, reallocating its pointer, and can I do it by some manual means?

Only leaving the scope or quitting the script. There's nothing like malloc or free, unfortunately.
 

I still need verification on the maximum number of elements in an array.

214747, only because that's the largest integer literal the compiler will recognize.