Array in Permanent Char var?

[nanakiwurtz]

Is there any chance to upgrade the script engine to support arrays on permanent character variable? (and also maybe in permanent local account too)?

 

I'm sorry if this sounds like a support post, please move this to a proper section if I'm wrong.

Thanks! 

[Emistry]

i think the reason they never tried to add it because the array will be stored permanently...and longer and longer...more and more variable is stored...your server will having lag problems and etc...

basically i believe it's just same to what annie explain when ppl stored / abused these kind of variable wrongly...

[nanakiwurtz]

I assume that people has read Annie's post regarding that issue, and still chooses to ignore the warning.

For example, they would use a 'set var1,1;' up to 'set var10,1;', then it'll be easier to do with arrays.

Yes, I agree with your reply Emistry, people do horrific things to their database, they let their data to stack and becoming too much to handle.

 

What I have in mind is that I might could make a pseudo-array using a permanent character string variable, by using a delimiter string to parse each data into smaller chunks, and I believe by doing so, I don't need to make unnecessary additional permanent char variables.

But currently I have no idea about the max limit of the permanent character string variable...

[Emistry]

trunk/src/common/mmo.h

#define GLOBAL_REG_NUM 256   // max permanent character variables per char
#define ACCOUNT_REG_NUM 64   // max permanent local account variables per account
#define ACCOUNT_REG2_NUM 16  // max permanent global account variables per account

[nanakiwurtz]

Thanks Emistry for your reply

And what about the limit of permanent character string variable, I mean how many letters can it hold in a single variable?

[Stolao]

max string is 255

[xazax]

A better practice to store pernament data in SQL tables.

[nanakiwurtz]

But all permanent vars are already stored in SQL too, isn't it?

"global_reg_value"?

[Euphy]

Yes, but character data is mass-saved into the database in regular intervals; using a separate database would avoid this.

The only real benefit I see to this is having 'getarraysize' for permanent character variables; but at the same time, we don't want to encourage users to use large character arrays. ._.

[nanakiwurtz]

Oh it's the 'autosave_time' config on map_athena.conf? It makes sense now, just like what xazax has said and Euphy has confirm this too.

From my understanding, a single long var is still counted as a single variable isn't it? Or does the length of it's value will affect the performance in the long run?

[AnnieRuru]

a single long var is still counted as a single variable isn't it?

yes

Or does the length of it's value will affect the performance in the long run?

no it wont

the string length doesn't affect performance

its just like counting 10 cars (small) or counting 10 trucks (big)

size doesn't matter, only numbers

by analysing the way *athena parse mapreg table, array is treated the same as variables

I rather don't like getting this implemented

[Euphy]

We won't be implementing this; it really would not do much good. Thanks for the idea.