[PENNMUSH-ANNOUNCE] Heads-up: Flag changes
Alan Schwartz
dunemush at pennmush.org
Sat Jan 11 15:43:58 CST 2003
Greetings, my friends,
This message is a heads-up for people who:
* Are using PennMUSH 1.7.7 (or planning to soon), and
* Have added their own flags via the hardcode
If you use vanilla PennMUSH without any local changes to the source code,
this message is probably only of academic interest. :)
As you know if you hang out at M*U*S*H, the long-awaited "flag rewrite"
has been completed and is in testing (and working out very nicely so far).
It may well appear in the next 1.7.7 patchlevel.
The key features are a removal of the limitation of number of
flags/toggles in the game; you can now have effectively unlimited numbers
of flags (and we don't use the concept of 'toggle' any more, as a flag can
be limited in what object types it applies to.) In addition, flags that
don't need to have hardcoded effects (e.g., most "IC" flags and the like
that just need to be set/cleared/tested by softcode) can now be added by
God on the MUSH using the @flag command, removing the need to touch the
hardcode for this. Of course, people who write things like space systems
can have their system add its own flags from within the hardcode if they
want to save God the trouble. Internally and in the db on disk, flags are
now referred to by name, and definitions of flag names, characters, types,
permissions, and aliases get stored at the top of the db when it's dumped.
The rewrite does not, at this time, affect the @power system.
This patch is going to require some special attention for people who
have already hacked new flags into their hardcode, and I wanted to
provide this notice to let you know something about how the process
of conversion works so you can get your code prepared to make
the transition as smooth as possible.
WHAT YOU DON'T HAVE TO CHANGE
You will not need to change the entry for your flag in the flag_table
in src/flags.c, or any aliases in the alias_table (or anything in the
hack_table). These will be used when your db is first loaded in order
to convert existing objects with those flags to the new system.
These tables are not used at all once a db has been converted to the
new system, so to add future flags, you'll need to use @flag or
the hardcode flag_add() call (probably from the new src/flaglocal.c
file).
WHAT YOU WILL HAVE TO CHANGE
The definition of your flag's bit in hdrs/flags.h will have to
move to a new file, hdrs/oldflags.h, that will be distributed
with the new code (or will appear when you patch up). You may wish
to get a clean copy of your version's flags.h and add all of
your defines back in at the very end of the file, to minimize failed
hunks in hdrs/flags.h when the patch is applied.
If you wrote a macro (usually in hdrs/dbdefs.h) for testing your
flag in hardcode, this macro will change. For example, the
LinkOk() macro has changed from:
#define LinkOk(x) (Flags(x) & LINK_OK)
to:
#define LinkOk(x) (has_flag_by_name(x, "LINK_OK", NOTYPE))
Again, if you move all your custom macrosto the end of this file,
you'll minimize failed patch hunks and make it much easier for you
to make these changes.
Finally, if your flag gets set or cleared somewhere in the hardcode
other than via the standard flag.c functions (that is, if you added
you own code that does things like: Flags(thing) |= MYFLAG), you can
expect to have to change those to new function calls provided in
flags.c (e.g.: set_flag_internal(thing, "MYFLAG"))
That's all for now. If you have questions or want to see the system
in action (which hopefully, to ordinary players, looks exactly the
same as the original system!), feel free to catch me on M*U*S*H.
- Javelin
P.S. Now that the limit on flags is gone, I'm very likely to start
adding several new flags, including BLIND, DEAF, DUMB, and NO_MOVE,
but not for a few patchlevels. On the other hand, if you end up
hacking in one of these flags under the new flag system, do send
me a patch and save me the effort! :)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Javelin at MS*H (mush.pennmush.org 4201) | Alan Schwartz
| dunemush at pennmush.orgPaul at DuneMUSHnd Javelin elsewhere | PennMUSH Server Maintainer
=-------------------------------------------------------------------------=
PennMUSH God's Guide: http://www.pennmush.org/~alansz/guide.html
PennMUSH Source: http://ftp.pennmush.org/Source
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
More information about the Pennmush-announce
mailing list