"Shane P. Lee" wrote:
>
> Now from a code point of view, I realize that it is
> virtually impossible to use an int or even a long int
On most common platforms those would be the same, GNU also has a long
long type which is 64 bits wide. I would recommend an unsigned long for
most flexibility.
> to hold infinite values, but from a hacker's point of
> view, anything is possible.
> Here's what I proposed to my admin:
> Defining a max_mort_level,
You could also define a lvl_immort which would be more consistent with
the way the current code is. I would suggest giving its default value
in config.c
> which is set to the value
> of the highest mortal's level.
> LVL_IMMORT would = max_mortal_level +1.
Try this:
#define LVL_IMMORT (lvl_immort)
#define LVL_GOD (LVL_IMMORT + 1)
#define LVL_GRGOD (LVL_GOD + 1)
#define LVL_IMPL (LVL_GRGOD + 1)
> The Master Command List would have to be re-written
> since LVL_IMMORT is no longer static.
Nope the master command list should be just fine with it.
> Now the command
> list would have to search for flags. Anyone over
> max_mortal_level would be flagged with an IS_IMM flag
> which the command list would read and process the
> commands accordingly.
Nope, like I said, the command list will work fine with this as-is.
> The immortal levels would have to be read and
> dynamically upgraded each time max_mortal_level
> changes.
Yeah, this would have to be done, in the entire pfile. Another way
would be to define a pflag for PLR_IMMORT then start the immort levels
over at 1 again, then you don't have to worry about updating them.
Okay, now that would work up to the highest unsigned long, but if you
want a truely infinite number of levels...
You have to create a new data type to hold infinite values, I would
recommend an array of unsigned longs which is dynamically allocated with
CREATE and resized (when necessary) with RECREATE. Use 31 bits of each
value in the array to hold that part of the number and the 32nd bit will
be an indicator of weather or not that is the last number in the array.
Then you will have to write your own functions to add, subtract, do
comparisions, etc. and replace all the operators in the entire src that
act on levels with these functions (you'll probably want to put all this
stuff in its own file instead of cluttering some other file with these
functions).
Off the top of my head, I can't think of anything else that would need
to be done for this. If this were C++ you could go a step further and
make up your own class for the new data type and overload all the
default operators. That way you don't have to go through the source and
change all the operators to thier corresponding functions. Come to
think of it, you might be able to get away with writing it in C++ in its
own file, compiling it seperately (in the Makefile) and just linking it
right in with the C source, I have never tried to mix C and C++ this
way, though so I'm not sure how well it would work. Any comments?
Regards, Peter
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT