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)