Now we know what you're trying to achieve, we can ask even deeper:
Would it be acceptable to have some kind of instance marker you could share? For instance, the questgiver (or whatever means we are using to distribute the quest) give a "token" of a sort that has an internal code?
Think of something like this:
Code:
The questmaster gives you a key to the dungeons.
> examine key
This is a key to the dungeons, given to playername. You can use it to enter your own dungeon.
If you need help, you can give a copy of the key to another player. They can then enter the same
dungeon. To do this, use the command: copy key to playername
The key has an ephemeral feeling.
The key seems to be fading from existence. It will be completely gone in 105 hours.
Here, the "ephemeral" would mean it persisted after death and that it disappears in a cloud of smoke if it is ever intentionally dropped or attempted rented. Attempts to give it away/steal it should fail.
I'm introducing some new concepts here - persistence across death, timed objects, a "copy" (and corresponding "accept") command.
All this to avoid assigning a specific id to a group and preventing changes to a group (or joining a group half-way through) from causing trouble. For instance, say I'm part of one group when I accept the quest, but join another before going into the instance - who should have access?
Also, having objects with a set timeout will help us in deciding whether a zone can be safely unloaded - no more access keys == no more zone. It could even go as far as when the zone has been "defeated", the key is removed from everyone, so the zone is no longer accessible. And once everyone has left, it is removed.
About the actual implementation: There are some limits that need to be addressed for this to work.
github.com/tbamud/tbamud/blob/master/src/structs.h#L24
:
Code:
/* preamble */
/** As of bpl20, it should be safe to use unsigned data types for the various
* virtual and real number data types. There really isn't a reason to use
* signed anymore so use the unsigned types and get 65,535 objects instead of
* 32,768. NOTE: This will likely be unconditionally unsigned later.
* 0 = use signed indexes; 1 = use unsigned indexes */
#define CIRCLE_UNSIGNED_INDEX 1
#if CIRCLE_UNSIGNED_INDEX
# define IDXTYPE ush_int /**< Index types are unsigned short ints */
# define IDXTYPE_MAX USHRT_MAX /**< Used for compatibility checks. */
# define IDXTYPE_MIN 0 /**< Used for compatibility checks. */
# define NOWHERE ((IDXTYPE)~0) /**< Sets to ush_int_MAX, or 65,535 */
# define NOTHING ((IDXTYPE)~0) /**< Sets to ush_int_MAX, or 65,535 */
# define NOBODY ((IDXTYPE)~0) /**< Sets to ush_int_MAX, or 65,535 */
# define NOFLAG ((IDXTYPE)~0) /**< Sets to ush_int_MAX, or 65,535 */
#else
# define IDXTYPE sh_int /**< Index types are unsigned short ints */
# define IDXTYPE_MAX SHRT_MAX /**< Used for compatibility checks. */
# define IDXTYPE_MIN SHRT_MIN /**< Used for compatibility checks. */
# define NOWHERE ((IDXTYPE)-1) /**< nil reference for rooms */
# define NOTHING ((IDXTYPE)-1) /**< nil reference for objects */
# define NOBODY ((IDXTYPE)-1) /**< nil reference for mobiles */
# define NOFLAG ((IDXTYPE)-1) /**< nil reference for flags */
#endif
The limit is currently
65535 rooms in the world. In all zones, regardless of whether they're loaded dynamically. This makes it slightly more trouble to do this. For us to actually do this, we'll need a somewhat larger addressable scope, at least an uint32. i haven't tested tbamud with this, but it might be simple:
os.mbed.com/handbook/C-Data-Types
Upping it to an uint32_t would let us use 4 million room, though this would potentially have an impact on the performance of other aspects of the mud. I think we can safely say that we need to look into this before just changing the limit (we're looping over "all rooms" and "all items" quite often).
