The "mudlib" obsession
 

1. It seems that the average forum user/scripter on Graal has no real concept as to what a "mudlib" really is.
   
   Quote:

   Originally Posted by Wikipedia A mudlib is a library of interpreted code used to create a MUD. It is interpreted code usually written in the LPC language. The code is interpreted on the fly by a driver.

   Quote:

   Originally Posted by Wikipedia In computer gaming, a MUD (Multi-User Dungeon, Domain or Dimension) is a multi-player computer game that combines elements of role-playing games, hack and slash style computer games and social chat rooms.

   So, please can we stop using the term "mudlib" to describe your scripts?
   
   
2. Can someone please explain to me what advantages a system that reads and writes from text files for all player or item data really has? I find it difficult to believe that, whatever it is, it justifies the:
   
   
   • More CPU cycles going to loss to read and write text files when the gserver is already doing this for Database NPC flags or player attributes;
   • Greater memory usage in caching both player flags and even more text data;
   • Files filling up file manager which are just going to turn into a disorganised mess;
   • More layers of scripting that could potentially go wrong and may need debugging, or more things to confuse someone else who has to work with your systems.

This GST doesn't approve.

I use clientr. strings for most of my item systems because I find that they're more efficient than loading from text files all the time, I normally frown upon the use of text databases unless they actually plan on having multiple characters, similar to how Zodiac allows you to select which character you'd like to use.

I find clientr strings extremely messy, and, given the RC bug which crops them to 256 characters, a mess waiting to happen.

It strikes me that you might be saving too much superfluous data, then.

It depends on what you want to save, honestly.
My system involved items having unique statistics, so it all had to be saved individually for each weapon.

Well, even in that case, how were you saving each individual statistic? In strings like "str+1,dex+2"?

Regardless of what you call them, I like them because they allow custom items, as does everyone else. Strings are rather messy and a pain to deal with in my opinion.

Strikes me that you might not be organising your strings in the best fashion, then. I've never found myself needing a text file for something that I couldn't do using existing engine stuff. :/

;O

I only use text files for items, item templates and players..
I usually cache them in forms of objects though :o

I could probably use a DB, but meh.. I like textfiles more, since then I don't need to give NC to people who make items :o

The problem is that would have quite a big memory footprint (not to mention the overhead of instantiating new objects for, well, everything) when the engine is already caching built-in flags. I still don't see the advantage.

No, I saved them just as numbers. I actually tried to keep it under 256 characters, but that doesn't account for future additions/long names, any other number of variables introduced by other staff. And anyways, when all done, all I had was a huge mess of numbers and quotes because graal turns {}'s into ""s, which is makes it even harder to read.

You could just use a single integer with bit flags for true or false values, and providing you don't go into too many dimensions, the quotemark conversion shouldn't become a problem.

So use more then one variable, then it won't overflow. Crazy pills?

If you want people to use client variables more often fix the stupid 255 character limit or its not happening.

Using more than one variable works but it shouldn't be necessary in the first place.

That's even worse.