So, here's the deal.

I have a completely modular ship system in the works, but I've hit a small snag. By completely modular, I mean, you buy a Chassis, then you buy/build parts and install them on the Chassis until you have a flyable ship. Anyway.

So I've reached a point in the construction of this system where I need to come up with a way to store a layout for rooms inside the ships. Basically, I would like to be able to have some way to efficiently store data on the rooms in the ship, their layout, and how they connect, without storing any vnum information or the like. I'm also thinking an easy way to plan them out without actually building rooms and then copying them into some kind of layout data structure would be nice, but I'm drawing a blank on how exactly to accomplish this.

Anyone have any ideas?

Any progress on this Kayle?

I've been giving it some thought as well and the best I can come up with is some sort of database. But your still going to need identifiers of some sort to link a b and c together. The quickest identifier in the game happens to be vnums. You could go by each ship having it's own vnum.are file assigned instead of carving out a chunk of the swfote style shipvnum.are file. Really, clueless here, tossing out sayings that might spark something in your mind!!

As to an easy way of layout, how about a hacked up version of overland? Have a player start in the center a giant overland map with nothing defined. From there, they can define the area. Create each room and have it update in real time to their design. Have the overland data saved to their pfile, or perhaps their clan data (if they are in a clan). I'd think from that you could export the overland data to a whatever file and then they could have the 'frame work' if you will for the ship. From there, all they'd have to do is add descriptions. (I've no experience with overland so this could be REALLY hard to do.) Also, with the overland, can't you color code specific tiles? Blue could be weapon ports, Red could be engines, yellow could be cockpit, dark green could be whatever. Default there is 15 (i think) standard color's defined. You might run into limitations, but I really doubt it. Fote uses 22 rooms, and most of those are tied up for turbolaser turrets. Another way, and I've seen this on a few game is a system like overland, but an actual room map: something like this:

                                           [ ]   [ ]
                                            |   /
                                            | /
                                     [ ]---[#]
                                           -

If your wondering about having a ship 'added on to' with extra rooms, once the area file is defined you could say, for a medium sized ship have up to 10 free rooms, for a large ship up to 40 free rooms, and for a capital and super capital up to 100. Granted, that is a lot of rooms for an area very few people might see, but it would allow for player customization. Actually, I'd likely make it less, as well sometimes players get carried away.

Anyhow, that's about all I have to say on the subject. Hopefully I at least gave you a few decent ideas.
ayuri

Some progress, not much.

Basically I've gone a route similar to FotE's. I've created minimalist copies of the Room and Exit classes, and store them inside a Layout class which acts sort of like an Area. Still working on the details of creating a layout, but I assume the easiest way to do so would be to manually create the area for the ship, and then have some kind of command to convert the area to a layout and then save the layout.

Hmmm, I sent you a tell, but not sure if you got it.

My idea was using a string to represent your connections, assuming your room templates have fixed and well-known names.

small cargo ship : {
   airlock : {
        east : hanger
    },
    hanger : {
        west : airlock,
        north : mess hall,
        south : engineering,
        up : central hallway
    },
    central hallway : {
        north : bridge,
        south : crew quarters
    }
}

If you have all exits two-directional, you can even shrink that to make it more nested to avoid duplicaiton. But that's my idea anyways. You have templates for each room type, and then just plug in exits to room templates. Your virtual room system just has to assign vnums to each as you walk the tree and actually create the rooms.

I can tell you how I solved this. May not be practical for you, but anyway.

First some background. My mud uses a vnum scheme where each area has its own private range, which eliminates conflicting numbers between areas. For instance, a vnum can be 4:56 where 4 is the area's id number, and 56 is the room's id within that area. Thus you can also have 6:56, 2:56, etc. All area data is stored in an SQL database.

When I create a new ship layout I build it like any other area with standard OLC tools. This area serves as the template for this type of ship. When I want to create an instance because someone buys it I make a deep copy of the entire area. Because of how the vnums work I simply have to alter the area id. All internal references to room numbers remains unchanged. The advantage of this approach is that it's easy to build ship layouts and you can use all the features you have for regular areas such as exits, doors, turbolifts, script triggers, mobile/object resets, whatnot, etc.

The area copy process is very easy because I use SQL so that the database itself does the hard work. Then I load this new area and associate it with the new ship instance.

I'd actually be very interested to see both how you've approached revising vnums (it's been something I've wanted to do for a while both personally, and for the FUSS Project), and your ship layouts.

I'm not sure exactly what you're asking. It's easier if you ask some specific questions to get things started. At any rate I'll try writing up a rough overview of what I've done tomorrow.

As far as the vnums are concerned, I believe Kayle is referring to the colon (:) inside the vnum scheme which you have created. In the current FUSS project that's released, the colon is not used. So, when we look at your vnum scheme, I don't see what the difference between 456 and 4:56 might be, aside from the addition of the colon.

The difference is that the 4 is the area's ID number, that is, the primary key in the database. The 56 is the room's database ID. A vnum is a class containing a pointer to the area and an unsigned integer with the room's ID within the area. Several rooms may have the same ID as long as the area is different. So each area has its own private range of possible rooms, potentially 4 billion each. While this number is huge, it does allow an area to expand gradually without ever crashing with another area's vnum range.

It also makes it easy to create instanced zones such as ships, assault courses, quest areas, etc. The reason it's easy is because you don't need to renumber the rooms, exits, resets, etc. Just a matter of copying all the data from the template area and alter their vnum with the new area ID.

Here's an example of how all the rooms in an area is copied to a new area using only SQL:

query << "INSERT INTO room( area_id, room_id, room_name, description, night_description, room_flags, sector, max_persons ) "
            << " SELECT " << GetId() << ", room_id, room_name, description, night_description, room_flags, sector, max_persons "
            << "  FROM room "
            << "   WHERE area_id = " << source->GetId() << ";";

Notice how the room table contains both an area_id and a room_id. Together these serve as the primary key. This is one query even though it uses both INSERT and SELECT. The results of the SELECT (which fetches the data of the old rooms) is fed into the INSERT while altering the area_id (with the GetId() function) resulting in a range of new rooms which are identical to the original in every way except the area it belongs to has changed. The "original" would be the ship template area as described in my first post, and the new data would be the new instanced ship.

The colon serves to distinguish the area ID from the room ID when using in-game commands. Nothing else. The implementation is the Vnum class as mentioned above.

I hope this clarifies things.

Something just occurred to me that I haven't considered before. First, let's look at how SWFotE handles this. That codebase uses a special area for instanced ships. Most people will probably give it a very large range of vnums so they won't run out as players buy ships. Let's say it's called playerships.are and runs from vnums one million to one billion. No way you'll run out, right?

But then one day you get this idea that wouldn't it be cool if players can buy new rooms in their ship? This is no simple task because if the first ship has 5 rooms with vnums 1.000.001 to 1.000.005, and there's another ship at 1.000.006 to 1.000.010 then the first ship has no room to grow.

In my system this is no problem because the first ship may run from 40:1 to 40:5 (40 is area ID and generated when the ship is instanced), and the second ship might be 65:1 to 65:5. The first ship can grow without conflict because there will never, ever be another ship at 40:6. Each ship has its own area and can theoretically have four billion rooms. New rooms can be added whenever you like.

This opens some cool possibilities. You can have a shipwright profession for players and they can build custom ships for themselves and other players. Not only that, but you could even use the shipwright's newly built layout as a template so that it will essentially be a new ship model that can be instanced N number of times as players buy them. The admins can go to the pub and get blasted while the players create new content for the mud!

Ahh Caius,
I completely forgot about how you were setting up your area files that way. I must say, that is a most elegant solution. I'll admit, at first took me a bit to wrap my head around it, but it allows for so much with out having to shift vnums about, have any of you tried that? Quite fun!!

Side note, I can't log into any of my IM clients (been so damn long forgot the passwords heh) so drop me a line here via pm or my email. Would love to get back in touch with you.

Also nice to see my rather incoherent ramblings has sparked some discussion!!

ayuri

Probably because the concept is actually simpler than you expected

A little late on the discussion here, but I thought I'd add what I did within the standard (extended) vnum functionality of SWR:

I had template rooms built, mostly generic. I used one area to create them all with a predefined vnum range. So I used about 500 rooms to build generic templates for rooms ( 10 different cockpits for different needs, etc ). They were within the standard OLC ranges.

I then used a string to build each ship's template, similar to this: 2)23,6:24;24,1:23. Where 2) is the number of rooms, 23 is the template room, 6 is the south two-way exit, 24 is another template room and 1 is the north exit. The second part wasn't required with the two-way exit number (there was higher numbers for one way). So cut down '2)23,6:24' worked fine.

When the ships were built, the ship's rooms were built dynamically on startup (I wanted to use lazy loading here where it would only load when the ship was entered, but I'm not sure I ever got around to implementing it). The vnums were unique and based on the ship's serial ID plus a static starting number. So the starting vnum was 4,000,000 and the ship'd ID was 230 then the first vnum of the ship was 4,023,001. This gave me 100 vnums to work with within a ship, which was just fine for anything short of capships (which were hard-built and unique, not purchasable through the virtual ship system). Bigger ships would have been a beast for the template string anyway - I created two 20 room ships but mostly confined myself to 10-15 rooms for the biggest medium ships.

It was a bit of a waste of vnums, but with 2 billion I had plenty to burn.

Darrik Vequir
SWRIP

Hmm area based vnums sounds interesting. Been looking into adding it in lop, looks like it will be quite a job and then havent decided on the best way to handle it all easily. Any pointers you willing to share on it?

I think the first thing you should do is to consider the consequences for existing areas, especially when it comes to "foreign" references (ie, references to rooms, mobs and objects that belongs to another area) in places like resets and scripts. Since I have a vnum as an area:room combo I decided to interpret a partial vnum as being within the current area. This is fine for the future, but will probably cause problems with existing content. For instance, let's say a script loads up object 12345. The script is attached to a mobile in area X. But maybe object 12345 is really in area Y. Before you started using this vnum scheme it didn't matter, but now you need to decide how to handle such "partial" vnums. In my case I say that since the mobile with the script is in area X, I automatically expand the vnum to X:12345. But in this example it was supposed to be Y:12345. In future scripts you can write a full vnum to be explicit, but you have a challenge with existing content. This is just one of the issues you'll need to address.

Nod, thats one ive been considering as well as the best way to deal with the get_room_index etc... Haven't figured out the best way to address everything yet which is why I was asking

I know this thread is old, but I reallylike the area:vnum idea

it would solve many problems

like player city building and as yall have touched onship building

Is there a snippet of this conversion thati have missed or is it too big a job for that?

wow yea old post lol. Well I still haven't done it and I've not seen any for it.