The "mudlib" obsession

[Skyld]

Originally Posted by Inverness

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

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.

Originally Posted by Inverness

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

It may encourage more human-friendly flag arrangements.

[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]

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

[Inverness]

Originally Posted by Skyld

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

[DustyPorViva]

Originally Posted by Skyld

It may encourage more human-friendly flag arrangements.

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.

[Chompy]

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

[DustyPorViva]

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.

[Inverness]

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

[Skyld]

Originally Posted by Inverness

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.

[[email protected]]

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

[DustyPorViva]

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.

[Skyld]

Originally Posted by [email protected]

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?

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

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.

Originally Posted by [email protected]

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

How are they void? You are clearly not focusing enough here on performance.

Originally Posted by [email protected]

why does GK use a mudlib is clientr flags are available??

Because GK actually has a proper mudlib library available in the NPC-Server which means that script CPU cycles are not being used instead.

[Inverness]

Originally Posted by Skyld

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.

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.

[[email protected]]

Originally Posted by Skyld

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.

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.

Originally Posted by Skyld

How are they void? You are clearly not focusing enough here on performance.

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.

#The archetype name
realname=Fung Si Yan

#The file location
archetype=equipment/shields/

#The Display Name
displayname=Fung-Si-Yan Shield

#The Display Icon
itemimage=Shield-FungSiYan

#Item Description
itemdescription=Forged by the almight Stefan at birth!

#The Weight [kg]
weight=10

#The Value [Rupees]
value=5

#Can Be Traded
candrop=true

#base, agility, magic, mental, personality, physique, wisdom
reqlevels={0, 0, 0, 0, 0, 0, 0}

#strength, dexterity, vitality, intelligence, wisdom, power, charm 
reqstats={0, 0, 0, 0, 0, 0, 0}
basestats={3, 3, 3, 0, 0, 0, 0}

#Item Data [+Melee weapon functions]
itemname=+Shields
itemequip=true
itemganis=fungsiyan

#Can The Shield Break
canbreak=true
#Amount Of Hits Taken Then It Breaks
breakamount=750

Because GK actually has a proper mudlib library available in the NPC-Server which means that script CPU cycles are not being used instead.

didn't know this, release to servers that want a mudlib to solve the CPU issue?

[Kristi]

Originally Posted by [email protected]

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.

False

Originally Posted by [email protected]

didn't know this, release to servers that want a mudlib to solve the CPU issue?

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