The "mudlib" obsession

[Skyld]

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

   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.

   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.

[Tigairius]

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.

[DustyPorViva]

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

[Skyld]

Originally Posted by DustyPorViva

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.

[DustyPorViva]

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.

[Skyld]

Originally Posted by DustyPorViva

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"?

[DustyPorViva]

Originally Posted by Skyld

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

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.

[Skyld]

Originally Posted by DustyPorViva

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.

[Kristi]

Originally Posted by DustyPorViva

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.

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

[DustyPorViva]

Originally Posted by Kristi

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

That's even worse.

[Chompy]

Originally Posted by Kristi

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

I had to do that just for the item's description.. >_>

I say fix the 255 char limit as Inverness said

[cbk1994]

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.

[Skyld]

Originally Posted by cbk1994

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. :/

[cbk1994]

Originally Posted by Skyld

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. :/

I find it easier to load from text files than loading from a database of strings ... I'm not talking about how you store the strings in a player.

However, I usually use text files for that so that I can have multiple characters.

But, it's much easier for incompetent staff to edit some text files than strings in a database NPC without messing **** up.

[Chompy]

;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