16 Jul, 2011, arholly wrote in the 1st comment:
Votes: 0
Hello:
I want to work on revising the area format so I break up the credit string to levels, creator, and name (I need to figure out something besides area name). That would allow me to redo the area command to not use the credit string. I'd also like to add versioning to the files.

What are the perils of doing so? What do I need to look out for? Has anyone done something similar and have any advice?

Best Regards,
Arholly
17 Jul, 2011, melopene wrote in the 2nd comment:
Votes: 0
Assuming you're using merc, rom, etc:

You will need to add the data fields to the directory structure in merc.h and update olc_save.c as well as add the fields to load_area. You'll then want to boot the changes in separately - first load in the olc_save.c and merc.h changes. Then go save each area, then boot in the load_area changes. Alternatively, if you want to be able to boot in files from other sources, you may want to take a versioning approach.

Hope that helps.

-Mel

Edit: Note to self, notice which board you're posting on before you add the 'Assuming you're using' line.

*snicker*
17 Jul, 2011, Omega wrote in the 3rd comment:
Votes: 0
In the past I've written the area files into sql databases. And that was a fun endevour, another method was to make them more like playerfiles and have them 'KEYd' properly, for all things room related.

Which is a great way. However, my suggestion to you is to straight out replace the load/save routines with brand-new ones using XML. There are many open-source XML interpreters out there, tinyXML is my personal favorite and I use it in my new mud.

That is my personal opinion on the matter. XML is fast, and so long as you take the time to read the API for an interpreter (such as tinyXML) you should have no problem in converting your existing area files into a whole new entity.

Fun note: my abandoned system ROCS used XML area files for a cross mud interface wrt conversion/saving/loading. Anything in your XML that isn't read in by your calls, is simply dropped. (xml is easy to retain compatability to your older xml formats without much, if any stress on the system)

Anyways, just my two cents. Thats what I would run with.


Edit : Figured I would give an example : this is from my account loader (not sure if it compiles as this system is in the works, but it gives a good example of what to expect)

bool Account::load(void) {
try
{
char filebuf[200];

// account name is set on Account::new(name) so we have our name here, so we attempt loading
// as the account name is already set!
snprintf(filebuf, 200, "../Libs/Accounts/%c/%s.acc", tolower(mAccountName[0]), mAccountName.c_str());

// declare the document for the phone book
ticpp::Document book(filebuf);

// actually load the information
book.LoadFile();

// retrieve our actual account data first action.
ticpp::Element *bookObj = book.FirstChildElement("Account");

// read in our password
bookObj->GetAttribute("password", &mPassword); // assign password to our account
// saved in the clear until we can find a
// safe way to encrypt it

bookObj->GetAttribute("level", &mAccountLevel); // assign our account level (staff or not)
// staff commands are assigned by account - not by player
// so staff can safely co-exist as regular players if they
// want to play the game.

bookObj->GetAttribute("email", &mEmailAddress); // Email address used for the retrieve password
// option that is slated to come into the mud
// so that players can at-least get a new
// password should they forget.


// our iterated elements (things that have multiple childs to them)
ticpp::Iterator<ticpp::Element>entry(bookObj->FirstChildElement("Player"), "Player");
// add our players!
while ( entry != entry.end() )
{
char *stringData;
int intData = 0;

PlayerData *p = new Player();

entry->GetAttribute("name", &stringData);
p->setName(stringData);

entry->GetAttribute("level", &intData);
p->setLevel(intData);

entry->GetAttribute("x", &intData);
p->setX(intData);

entry->GetAttribute("y", &intData);
p->setY(intData);

entry->GetAttribute("roomname", &stringData);
p->setRoomName(stringData);

// advance to next item
++entry;

mPlayerList.push_back(p);

} // end of our entry loop

return true;
} catch (ticpp:Exception &e) {
// report our exception from ticpp!
Log::instance().exception(e.what());
} catch ( … ) {
Log::instance().exception(UNKNOWN_EXCEPTION);
}
// return false if the account does not exist!
return false;
}
0.0/3