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.

I still don't see why you need to be storing that much data, when there are methods to store the same detail of information in less space.
It may encourage more human-friendly flag arrangements.

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.

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

I say fix the 255 char limit as Inverness said

It doesn't matter if you see the reason or not. The point is that the character limit is a problem that needs to be fixed.

Of course there are ways to store large data in less space but I'd rather do that on my own and not be forced by some silly character limit that just breaks scripts.

Until the player gains a lot of items... then you have a huge mess of flags. I honestly hate looking through the flags of players on systems that used clientr's for item databasing.

Zodiac also has a problem with the 255 character limit, and they decided to remove every staff's "set attributes" right..

That was my intention when I was working on my system. Remove all rights to set attributes and then create my own debugging system that allows you to change/add/remove weapons that way.

And here we have a good example of why bugs should be fixed instead of avoided like the GST are saying.

I do not endorse that we avoid fixing bugs, but a bug like that is hardly reason enough to completely abandon client flags when straight-forward optimisations that I would like to hope you are using anyway would provide a suitable workaround.

if done correctly, you generally only need to load the item once it's been changed and then storing the data in a global flag, how is that causing lag?

fix the 255 character limit and i might just actually use the clientr flags

opening era's item database causes lagg [items 900+], why use a database??

your reasons for not using a mudlib are void, why should we use clientr.flags?
why does GK use a mudlib is clientr flags are available??

My idea(well really Zero's) was to load the item upon login, and then store them in objects. Only need to save them was upon any sort of change. I don't find that too demanding, really.

I would love to use clientr flags as it's really the least amount of hassle, but I'd really, really hate to see random glitches appear because item data is getting cropped.

In this instance, loading things from text files is more CPU cycles and memory overhead than is required than directly accessing a flag would produce.
How are they void? You are clearly not focusing enough here on performance.
Because GK actually has a proper mudlib library available in the NPC-Server which means that script CPU cycles are not being used instead.

That bug has been around for years and I highly doubt it would be difficult to fix.

If Stefan would just put a bit of time into looking at it and fixing it we wouldn't have this problem. That or pass on the RC code to someone else who can do it.

People have been complaining about it for forever can someone just effing fix it already.

not really, no.
your loading a file as you are loading a flag, sure it'll take a little more CPU but not a substantial amount though.

please try to create a system that has alot of information in each flag
currently, my item system contains the following flags, make try make them into a flag with less than 255 chars.
didn't know this, release to servers that want a mudlib to solve the CPU issue? :)

False
He was implying it used exactly what he was saying everyone else should (flags and such)

prove it.

don't get your reply at all, so why not release the gk method?

What, that the gserver is optimized to handle flags over loading data from a textfile? That is just a fact, simply true.
It's simply scripted without reading textfiles, the same point skyld was making.

i didn't say that loading a text file was faster than loading data from a flag. it's not a substantial difference from loading a flag than a text file.

explain how gks system works please

I really would like to be able to use client flags for a system but its simply not happening until I can be assured that they wont get cut off without having to take set attributes away from all the staff.

I'm using a DB NPC as cache for all items on Mythic, and simply only update the required flags if the file that the data is stored in is changed. Yes, there is a function to check if a file is updated in folders, quite useful too.

Then I just have item system related script's grab the string from the database, and it'll be guaranteed to be the same as the data in the file.

Item archetype data on a normal day should only be read from, not written to unless there is an update to the server (which should be in the form of server updating, patching, etc; not this mess of small updates every 5 minutes like most Graal servers do).

As for the item data of a player inventory:
It's not exactly black and white, only the inexperienced scripters see it that way. There are many ways which you can make a hybrid system that both uses text files optimally as well as built-in features for speed and performance.

You may not see any advantages to text files but I have already seen a ton named in this thread so let me spell them out to you (plus a few more):

• 255 Character Bug - I'll start with this one since it seems to be the most commonly named here. RC messes up client., clientr. and other player. strings that are saved to the player. Now this isn't really a viable reason as it isn't that hard to create a player editor in-which you can edit players and avoid having to modify them while they are playing (causes them to "jump back in time", unprofessional, etc).
• Organization - You can't expect to be the scripter on a server forever. When I first took a look at Maloria's player attributes and then a few years later, Zodiacs, I was searching for a needle in a haystack. Not the mention the amount of time it took to load an experienced player's attributes. To put it simply, text files allow you to place the data in what ever form you see fit. Again though, you can always build an editor that can interpret the player attributes and organize it for you, but you still are just leaving a robot to search through your messy room, that's all.
• Security - Probably one of the most important reasons; by saving data to a text file, you are increasing security both with the leaking of information and the modifying of information. Any kid and his dog knows how to /open a given player, and either find out everything about that player or make some kind of modification that will be forever lost in the mess that is rclog.txt. Yes, text files are logged even worse but if no one has rights to those text files, the only modification possible would be through scripts; this can't be used as a counter arguement though as a scripter could much more easily modify a variable on a player then loadlines, modify, savelines, etc. By separating data into text files, you can allocate who can read and modify what.
• Stability - Also could be classified under security, file data stability. Data stored in player attributes isn't really safe data. Anyone who works on a classic server for just a little while know how much your player data just sits on a thin thread. Some idiot with /reset rights could "accidentally" reset a player and all the data that could have taken months to acquire goes down the drain.
  On Zodiac, some scripter was making something inside a database npc and forgot some syntax in his with () block. You know what happened? The whole database was deleted along with a few others. I know that was an error on his part but it doesn't change the fact that it was so easy to do (by accident as well). Text files can't be "destroy()ed".

I know that Graal will automatically sync client. and clientr. variables but if you don't have any client. or clientr. variables, it doesn't matter now does it?

Anyways, I didn't put to much effort into that list but there are a few clear cut reasons why text files can be useful. Again, text files can be more performance intensive that's why in most cases, hybrid systems are best.

I have actually just made an item system that only uses one flag [the amount of the item] but it's not a proper mudlib :[

I'm sticking with it though, doesn't cause any lagg at all =D

Mine doesn't use any flags other then a clientsided this.data that is updated upon login/weapon update ^^

i just transfer all item data and don't even store them on the client, they are global clientside vars containing the data ^^

If they are clientside variables, you are storing them on the client o.O


Also, why no reply to my long explanation, people?