19 Sep, 2008, Fizban wrote in the 41st comment:
Votes: 0
Sandi said:
As a builder, I can tell you that being able to search and replace bits in .are files by their flag names would be heavenly.


Agreed. I've always felt a XML-esque format for area files would be ideal compared to the format used currently in most DIKU- derivatives. Perhaps like:

#0
<Name>: The Quiet Forest
<Description>: The description goes here.
<Flags>: DARK !RECALL !MAGIC
<North>: 500
<South>: 400 Open
<East>: 350 Closed Locked
19 Sep, 2008, David Haley wrote in the 42nd comment:
Votes: 0
Well, you could still do it in C, it'd just be less nice… pseudo-code:

bool is_room_dark(Room* r) {
return is_bit_set(r->bits, ISDARK_FLAG);
}

EDIT: didn't see Fizban's post. I don't understand why you would change the format to that? It seems that Quix's suggestion is enough. If you want XML, you should just go with XML, so that you can use existing parsing libraries instead of having to roll your own for this format. I'm wary of adding in extra brackets just for the sake of it.
19 Sep, 2008, Hades_Kane wrote in the 43rd comment:
Votes: 0
Well, if the general consensus is to go with option 2 without being overly concerned about the areas from the new base being compatible back and forth between Stock ROM, then I suppose discussing actual specific changes we would like to see would be good.

I think we're already on that track with the talk of bits and such, and of course material has already been mentioned (we've addressed this, and what we've done might be a good thing to consider, but I digress…)

Perhaps what might be beneficial is for us to try to compile a list of weak points we think could be improved with the codebase (while maintaining the "feel" of ROM, that I agree with), and once we have a list of things we would like to accomplish, start talking about -how- we would like to solve the issues. I'm sure for every issue with ROM we'd like to see fixed, there are numerous ways we could go about fixing said things.

As far as a name for the project… Rivers of Mudbytes? :p
19 Sep, 2008, Darva wrote in the 44th comment:
Votes: 0
Changing the area file format by a large amount seems like a bad idea. I really think that, as much as possible, it should be attempted to maintain compatability with the rom format. After all, the thing that sparked this was the idea of putting together an area repository for rom muds.

I guess i just fail to see the problem with using is_bit_set(target->act, ACT_WHATEVER) when you need to know if a bit is set. Moving a check for each bit into a function of it's own seems pointless. Yes, that sort of thing would make sense if you were working in an OO environment, but rom isn't.

For a name, i suggest RoMP. RoM Project.
19 Sep, 2008, David Haley wrote in the 45th comment:
Votes: 0
Darva said:
Moving a check for each bit into a function of it's own seems pointless.

The idea was to preserve the efficiency of bits over unsigned chars, while allowing easy and short access to fields.

Darva said:
Yes, that sort of thing would make sense if you were working in an OO environment, but rom isn't.

Well, actually, it might not have explicit classes and so forth, but most MUDs are more object oriented than people think… it's just not enforced, which creates trouble sometimes. Many functions that take a structure as a first argument can be thought of as methods on that structure.

And frankly, FWIW and IMHO, MUD codebases would be much cleaner if stricter design standards were applied, including enforcing some degree of object orientation. You don't need C++ to do OOP.
19 Sep, 2008, Kayle wrote in the 46th comment:
Votes: 0
You could change the area format and make it easier to use and still maintain compatibility. You have one function that saves the areas. This command saves to the new easier to read and understand format. (SmaugFUSS 1.8+ has one of these formats, as does AFKMud 2.0+)

And then you write an areaexport command, that would write the area, sans new additions to the build structure in the original format. It never made sense to me why people would want to write those god awful area files where you had no idea wtf each number was without looking at the code. Having it output like:

Quote
#FUSSAREA
#AREADATA
Version 3
Name The Astral Plane~
Author Andi~
WeatherX 1
WeatherY 2
Ranges 15 35 0 60
Economy 0 2064393
ResetMsg The astral field glitters with a thousand points of light for a moment…~
#ENDAREADATA

#MOBILE
Vnum 800
Keywords astral guardian figure~
Short the astral guardian~
Long A shimmering grey figure stands vigil before the pearly gate.
~
Desc You see a shimmering grey figure, vaguely humanoid in shape. Its sole
striking feature is the item it wields: a pearl wand. The astral
guardian seems to notice your attention and shifts uneasily.
~
Race (null)~
Class warrior~
Position standing~
DefPos standing~
Gender neuter~
Actflags npc sentinel~
Affected detect_invis detect_hidden sanctuary truesight~

Makes so much more sense…
19 Sep, 2008, David Haley wrote in the 47th comment:
Votes: 0
Kayle said:
It never made sense to me why people would want to write those god awful area files where you had no idea wtf each number was without looking at the code.

I'm willing to bet that somebody was trying to save disk space without actually going through the numbers on how much it would in fact save. In fairness, it is possible that in the earliest days, a few MB of disk might have actually mattered. And then by the time it didn't matter, most people didn't get around to fixing it.
19 Sep, 2008, Kayle wrote in the 48th comment:
Votes: 0
That does make sense. But still, there had to have been better ways to do it..
19 Sep, 2008, David Haley wrote in the 49th comment:
Votes: 0
I dunno, if you really really want to save space, saving a number is a lot shorter than saving a whole string. So in some sense what they did isn't bad if your goal is to save space. Be thankful that they left it as text, instead of saving it in binary – if they'd really wanted to save space, they'd have saved numbers in binary, so that the number "100" would take one byte instead of three. :wink:
19 Sep, 2008, Kayle wrote in the 50th comment:
Votes: 0
Oh good god, I'd have never become a developer if I'd have had to screw with binary files..
19 Sep, 2008, Lobotomy wrote in the 51st comment:
Votes: 0
While I haven't tested it out yet myself, apparently it is possible to read and write files directly as gzipped files; another route for saving more space. Compared to just regular binary files, it would still be possible to modify the files from the shell as regular text files but with the added steps of decompressing the file, editing it, and recompressing it again.

Until I get around to implementing such a setup (which would then make saving bitvectors directly as text strings more viable), the current method I've come up with for getting a compromise between the two methods of storage (i.e, storing as a number to save space verus storing as text to achieve flexibility - such as if your vector flags change order, it doesn't corrupt the values on load) is to create a key table of sorts that turns a particular flag into a specified 2 digit alphanumeric value (kinda like a hex pair, but extending all the way through Z instead of F). It provides compressed storage along with load flexibility, but it still has the downside of needing to look at the code to see what value equals what flag if you want to edit the file directly. Once I get the setup going to save and load as gzip/tar files (might even do that right now, since I'm reminded of it again), I'm planning on doing away with that system; unless anyone has thoughts otherwise?
19 Sep, 2008, David Haley wrote in the 52nd comment:
Votes: 0
Lobotomy said:
(which would then make saving bitvectors directly as text strings more viable)

Let me throw out there that it is already quite viable. Some analysis:

- assumption: total of 20,000 things being saved with bitvectors.
- assumption: on average, 10 flags set per thing.
- assumption: on average, flag name is 10 characters long.

With these assumptions:

- Saving flag as number: about 5 bytes per thing.
- Saving flag as a list: about 10*10 bytes for the flags. The whitespace can be factored into the flag name assumption anyhow.

So, the space increase is about 95 bytes per "thing". That translates to 1,900,000 more bytes given that you have 20,000 "things".

Therefore, unless you really can't afford two extra megabytes, it is entirely viable to store the bit vector as a list of flag names.

Lobotomy said:
Compared to just regular binary files, it would still be possible to modify the files from the shell as regular text files but with the added steps of decompressing the file, editing it, and recompressing it again.

vim is smart enough to let you edit a .gz file directly: it decompresses it on the fly. So you wouldn't even have the added steps (assuming you use vi).

Ideally the MUD would first look for a compressed version, and then upon failing to find it, it would look for an uncompressed version. That way, if you needed to decompress things e.g. because you're working on them a lot, you wouldn't have to keep going through the hoops.
19 Sep, 2008, Lobotomy wrote in the 53rd comment:
Votes: 0
DavidHaley said:
Therefore, unless you really can't afford two extra megabytes, it is entirely viable to store the bit vector as a list of flag names.

I'm just trying to keep things as compact and efficient as possible over the long run. For a single bitvector of that size (or of similarly large sizes) the change is not necessarily that much; it's when you get many more iterations of such sizes that it becomes an issue, as far as I see it. Aside from the sort of setup I plan to go with eventually, I.e a high emphasis on (near-unlimited) dynamic content creation, there's the matter of my currently working on a shell environment where my space limitation is a mere 100 mb. I feel it's far more than enough, provided that data is handled efficiently. However, if files are constantly exploding into the megabyte range that will then become a serious problem for me.

DavidHaley said:
vim is smart enough to let you edit a .gz file directly: it decompresses it on the fly. So you wouldn't even have the added steps (assuming you use vi).

I've always used pico/nano (and still currently do), so vim/vi is actually news to me. :thinking:
19 Sep, 2008, David Haley wrote in the 54th comment:
Votes: 0
Well, go through the math above, but with bigger numbers. It doesn't make a huge difference. Double the amount of content: go to 40,000 total "things" (rooms+objects+mobs), and you increase your space by only 4mb vs. the number scheme.

IMHO the gains vastly outweigh the cost of using a few more megabytes of disk space. It is much better to have a format that is sane, easily extensible, robust to changes in the code, and for which it is easy to make the code robust to changes in the format, than it is to have a format that is compact merely in the name of saving a few MB. Even when you only have 100 MB, you're just talking about 2%.
19 Sep, 2008, Lobotomy wrote in the 55th comment:
Votes: 0
Well, I suppose it helps that I was misreading your figures to confuse how the math was playing out in my mind, however I still don't see the fault in making use of compression methods (or how they are not "sane") to drop unnecessary extra file space usage.
19 Sep, 2008, Darva wrote in the 56th comment:
Votes: 0
*laughs* So from the discussion i'm guessing named flags in area files is one thing we need to put on the list.

So the current list goes:

Hunt and squash bugs (obviously)
Unlimited bit system.
Named flags in area files.
Finishing the Material system.

What else should we be looking at? Most of the things that I keep thinking of are relativly minor changes: Centralize the channel system, change the affect structure to have a dispellable boolean so you can remove the long list of spell checks in spell_dispel_magic and new affects work automatically.
19 Sep, 2008, quixadhal wrote in the 57th comment:
Votes: 0
DavidHaley said:
I dunno, if you really really want to save space, saving a number is a lot shorter than saving a whole string. So in some sense what they did isn't bad if your goal is to save space. Be thankful that they left it as text, instead of saving it in binary – if they'd really wanted to save space, they'd have saved numbers in binary, so that the number "100" would take one byte instead of three. :wink:


LOL, they did! The original DIKU used text format for the area file (singular… tinymud.wld for rooms, tinymud.mob for mobiles, etc…), but the numbers were meant to be directly read (via fscanf) into the data structures. The player files were binary.

Back then, people didn't think twice about doing bit-wise math, and you'll find old bits of code that did things like if(room->flags & 37) blah(); because it was more efficient in CPU cycles to do one and rather than check each bit individually.

I build areas back before OLC, and you kept a printout of the various flag values right next to your coffee/coke while you were typing the areas in.

Let's get a long ways away from that. :)
19 Sep, 2008, quixadhal wrote in the 58th comment:
Votes: 0
You could easily use gzip (or bzip2) by just adding the gzip library to your dependancies (-lz), and then using gzopen/gzclose instead of fopen/fclose. The price you pay is more CPU use when accessing files, and you lose the ability to randomly seek in your files, but that ability hasn't been used since we went away from indexing directly.

Personally, I'd like a file format (well, if you must use files) which is 100% self documenting so you never have to look anything up in the code. I'd also like the ability to nest things. By that, I mean if I want to load an orc with leather armor and a bone sword, it would be nice to have that dependancy explicit somewhere. My choice would be a seperate reset section, because I don't want every orc to have the same gear…. but somewhere I should be able to see something like:

BEGIN RESET #2001
Load MOB #4672(orc) TO ROOM #7261(nursery)
Equip OBJ #6001(bone sword) PrimaryWeapon
Equip OBJ #5900(leather armor) Torso
END


That's not a format I'm seriously suggesting… just a quick idea to show what's possible. Again, there's NO reason to stick to the standard format as the NATIVE format, as long as you provide ways to import stock files. I really don't see exporting as being so important, because if the codebase does evolve, there will be things that you just can't DO in stock ROM.

For a clever format someone else did with an ENVY derivative, check out DalekenMUD.

Mobile {
Vnum 12700;
Name "Vorlin priest";
Short "Vorlin";
Long "Vorlin, the high-priest of Zoth, sits here smiling absently.\n";
Desc "This tall elven man sits here looking around at all the souls he has\n
helped with a contented look upon his face. His far-away look gives you the\n
impression that he is thinking of a time long past when he helped many more\n
than just these few people, possibly he was even a healer during the Great\n
Rending.\n";
Level 100;
Align 1000;
Class (Cleric);
Act (npc sentinel);
Affected (detect-invis detect-hidden sanctuary infrared);
Sex (male);
Race (Elf);
Specfun "spec_cast_adept";
MudProg {
Type (greet_prog);
Args "100";
Comlist "if isgood($n)\n
say Welcome my friend. Please rest awhile and tell me of your adventures.\n
smile $n\n
else\n
glare $n\n
say If your intentions be good, please, I welcome you. If your intentions\n
be foul, I warn you now, I do not house rabble in my temple.\n
endif\n";
};
};
20 Sep, 2008, David Haley wrote in the 59th comment:
Votes: 0
Lobotomy said:
however I still don't see the fault in making use of compression methods (or how they are not "sane") to drop unnecessary extra file space usage.

There's a big difference between (a) using compression and (b) making the format itself terse. I have no problem with (a), it is (b) that I am railing against for various reasons. Using compression is perfectly sane. :smile:
20 Sep, 2008, Lobotomy wrote in the 60th comment:
Votes: 0
DavidHaley said:
Lobotomy said:
however I still don't see the fault in making use of compression methods (or how they are not "sane") to drop unnecessary extra file space usage.

There's a big difference between (a) using compression and (b) making the format itself terse. I have no problem with (a), it is (b) that I am railing against for various reasons. Using compression is perfectly sane. :smile:

I see, but now I'm semi-lost as I'm not sure what format it is that you're speaking of as being terse?
40.0/71