Question Room creation/Deletion

Hey fellas, I've decided I no longer like the way that CWG handles vehicles. Yes its set up well, however if more than 1 vehicle type are being used at the same time, you can see the other guys using the vehicle as well. Now I could always make a tiny mod to hide people from seeing each other, however it still doesn't fix the issue of where the vehicle is going. Is it going to players A destination, or players B destination. Anywho having said that, I'm going to redevelop the vehicles code so that everyone in the mud can take advantage of it on their own. My question is: Has anyone ever released a snippet or written one, that will add a room to the top of the index and populate it with blank members? I figured i'd ask before i wrote an entirely new function for it. After the first couple of attempts i've done some hard core crashing. Anyone wanna share thoughts?

- Gahan

The functions add_room() and delete_room() are already present in the stock code in genwld.c . That said, DIKU was not designed to be used in the way you are suggesting. That doesn't mean it can't be done, but because it uses a numerical array to keep track of rooms, it means overhauling the entire world each time a new room is added or removed. (Look in the functions to see what I mean)

If I were attempting to redesign a vehicle system similar to that of CWG, I think I'd probably use a hybrid of the CWG design idea and yours. Perhaps creating a new 100 room zone called "Vehicles", and filling it with template based data. When a player buys a vehicle, I'd assign the first vehicle room vnum to it that is currently free. When the player logs off, clear the room data and allow someone else to use it. Simple, Quick, Works within the current system, and on the odd chance I happen to be nearing 100+ players on-line at a time, I'll just open up some more vnums.

Thanks for the response Vatiken, I appreciate you taking the time to give me insight. Basically what i've decided to do was, have 10 rooms dedicated to the descriptions and names of each vehicle (10 vehicles in total) and reserve a 500 room block for vehicles/alternate start rooms/whatever else i might need dynamic rooms for, and started off basically like this:

I'll let you know how this goes, however I'm slightly worried about the end result.

What do you think? Is there a more efficient way of doing it? I'm scratching my head here a bit.

What I'd REALLY like to do is convert tbamud to a vnumless system, however time is getting more sparse as I age.

Keep in mind this is just a rough hack attempted pseudo code, i do understand that if i check for object value 0 it will produce undesireable results

Keeping in mind that my memory of the CWG vehicle system is a little rusty at best, if I do remember correctly, the system worked by having an OBJ, that had a vnum set to it that allowed someone to use it as a door to the vehicle room. From there, you'd use a WINDOW object, or a CONTROL type object to navigate the vehicle around the world.

My suggestion was far simpler then what you have scribed up. Essentially what would happen is when a vehicle object is loaded into the MUD, we'll call on a function like find_available_vehicle_room(), and change the vehicle object's vnum to that room. You could also then flag the room ROOM_OCCUPIED or something so we know it's in use. If you wanted to go further, you could keep some data stored on the player which you could use to alter the room name, description etc.. When the player quits, remove his vehicle (or decommission it), and unOCCUPY the room.

From your example, you have a few issues. This implies that you are storing the room RNUM in OBJ_VAL(), which SHOULD be incorrect as RNUM change as new rooms are added/removed. There really is no need for any of this as the room is already created, it's just a matter of placing in it the player, and other necessary objects, and renaming/re-describing it (if neccessary).

What I'd REALLY like to do is convert tbamud to a vnumless system, however time is getting more sparse as I age.

This would be like trying to turn a printer into a toaster... it could be done but there are MUCH easier ways to make a toaster. Switching to a non-vnum system in tbaMUD would require re-doing a (!EPIC!) SIGNIFICANT (!EPIC!) percentage of the code, as so much is tied into vnums and rnums.