(7:23:39 PM) El Havard: vnums will be used again. (7:24:33 PM) El Havard: just thought of a great way to implement loading and unloading chunks of areas. (7:25:02 PM) El Havard: As you're probably well aware, arrays in ada look very much like functions or procedures (7:25:33 PM) El Havard: basically, instead of referencing room_array(vnum), we use a function room(vnum) (7:26:45 PM) El Havard: there's a fixed-sized array of loaded rooms. There's also a mapping table of real vnums to the loaded room array (7:28:26 PM) El Havard: the room function looks up vnum in the loaded_rooms array, if it's found, it returns a pointer to the room, otherwise it clears out unused rooms from the loaded_rooms array, loads the room from the area file, stuffs it into loaded_rooms array, and then returns the pointer as appropriate. (7:28:54 PM) El Havard: It's essentially a specialized userland virtual memory system. (7:30:42 PM) El Havard: As we have a cap on the number of simultaneous connection, the loaded_rooms array would be something like (MAX_USERS * 6 (for each direction))^3 (7:31:04 PM) El Havard: basically enough to have the player's room, and the next two connected rooms. (7:31:10 PM) El Havard: in each direciton. (7:33:31 PM) El Havard: Naturally, certain special rooms would be pegged (newbie room, major cemeteries , The Void, etc.) and actually kept outside the array. Each room in the array would have a "used X ticks ago" when it reaches some limit, the room is unloaded. (7:35:15 PM) El Havard: hrm, that's actually over 7 million rooms assuming we limit it to 32 players. so that array will be a good bit smaller. (7:37:02 PM) El Havard: anyways, we limit the max number of rooms loaded at once. Ultimately we need no more than MAX_USERS if we have several thousand players. Ooh. Even have a room "swap" file that keeps the state of recently visited rooms until it comes time for reset.