I know we plan to eliminate most boundaries and limitations in the editor, and allow for values to be input into it that RMXP does not permit. Obviously, these values are need to have SOME type of limitation though, however crazy high/low it may be.
This can really be broken into a few categories.
String Length: Max number of characters for names, descriptions, ect.
Parameters: ATK, PDEF, etc. I was thinking using -65535..65535
Percentages: Currently its 0..200. We can obviously bump the max for this up to something more like 1000 ro 10000 at least.
"The skies the limit" values": Things like price, level, gold, experience, etc. We can allow for these to be obsenely high. I suggest the max value of a Ruby Fixnum on an x86 system (2147483647)(I think, I have x64, but did the math...). I would have no argument applying this cap to the parameters category I listed above either. Keeping it a Fixnum will maintain performance and precision.
I understand that in many cases values these high would be ludicrous, but somebody, at some point, is going to want to use them, and since ARC is all about removing the limitations, we should allow for them through the front-end GUI instead of via a custom script, as I am sure you would all agree.
Thoughts or ideas?
there is actually a limit imposed by the data format we created for ARC Data serialization. specifically in the fact that it limits all numbers to the size of a 32 bit unsigned integer: 0-4,294,967,295
that's Zero to four billion two hundred ninety four million nine hundred sixty seven thousand two hundred ninety five.
it's a ridiculously large limit now that I think about it.
Also Blizz, I just realized. shouldn't we allow the storage of signed integers?
as it is all numbers are converted to an unsigned int when dumped unless they are floats which are stored differently
The only possible problem I see would be exceeding Ruby's Fixnum value, which is half that. I am unsure of the performance difference between Bignum and Fixnum, nor the conversion process between the two, but I personally think that 2,147,483,647 is sufficient for anybody for any type of editor-based setting. This conversion is automatic, so it really won't cause any issues allowing for Bignum, since it will only be used in the rare cases that someone defines it them values, it will normally be Fixnum by default.
[sarcasm]I do see one fatal flaw in your dump method. What if someone plays the game for over 19,884 hours (a mere 828 days of solid gameplay)? The Graphics.frame_count will not dump correctly. I would have expected better of you, Ryex....[/sarcasm]
String Length: There will be no real string length as they will be stored in a localization file. I guess we *can* put up a limitation of 500 or 1,000 characters or something.
Parameters: Screw negatives. We will use 0 - 99,999. I talked with Ryex about that already.
Percentages: We will use 0 - 100,000 because some percentage values can be negative. This is yet again the limit of 100,000, similar to attributes.
"The skies the limit" values": Values like that will have 999,999,999 as limit. Only level will have 999. This is basically there just to have a limit and satisfy all needs. If somebody needs high than that, then obviously they are doing something wrong.
I suggest that we put these settings into a configuration file for the editor. If somebody wants to change the limits, they can edit that file instead of having to make a script.
Limits are always reasonable. The problem with RMXP was that the limits were way too low. The imposed limit on HP to 99,999 is just wrong.
All these limits are arbitrary limits for the editor, but the user will be able to specify a game limit as well. This should be a special script that is generated internally and added to the game before running or something like that. You know, if you go over 9999 HP, that it limits the HP to 9999.
@Ryex: If you cast a signed integer into an unsigned integer, store it, load it and cast it back, everything will be fine. Unsigned and signed integers differ only in their logical ranges, the data is exactly the same. Besides that, we can always change the format and allow 64 bit integers to be stored if we need. In fact, for integers that require more than 32 bits I suggest that we use an additional type that stores the number of bytes used and then stores the value byte by byte. This makes a lot more sense to me. But generally I think we should disallow that somebody exceeds 32 bits in the editor.
[sarcasm-counter]Savegames are still stored in Marshal format. :V:[/sarcasm-counter]
That sounds good, but how can we not have negative values for parameters? That's a fairly common thing to set values for that to negative. You know, equip an accessory that increases magic power dramatically, but penalizes physical power.
Modifiers, yes, but not base values. There's no point in a STR value of less than 0. There is a point of a STR bonus for a weapon of less than 0, but not for the actual base value.
Okay, that makes sense. I was thinking you were referring to both. :P
Alrighty, I made a quick .ini file so that the database limits can be altered externally by the user. I left out minimums, since anything that is allowed to be negative can simply be the negative value of the maximum. I made the preset configuration of the limits what Blizz posted above, which should be more than enough for 99% of everyone, but if they need more, they can easily alter it themselves.
* Ninja Bump * :ninja:
So, as I said before, I made an .ini file that allows for the user to set the limits in values in the database. I have discovered we are bound to keep values under 2147483647, which is the maximum value of a C long (x86). wx is interfaced to C libraries which are expecting a number within that limit, so it looks like thats it. I see no problem with this at all, that should be well over anything anybody needs, but I might implement a quick check to ensure the values are within range before passing on.