serveroption : disableRCsetattrs = bool
 

disableRCsetattrs = true/false

Disables the ability for external RC's(not scripted) to set player attributes. Why? So servers can implement their own custom(or use scripted RC) attribute editors without the worry of someone unknowingly using RC and clipping player's flags with the 255 char limit. Now, a nice solution would be just to not give anyone the right, but sometimes you'll have someone above you, like an owner, who is not a developer and thus may not understand the severity of such a bug.

The problem is external RC is going to be around for a long time, and so will the bug. As long as the bug is there this is a big worry for me, even if we take the proper measures to avoid it, it's just too much of a risk if you store important data in flags. I think the ability to disable external RC's from setting attributes would ease the worry for me, personally.

/signed

I don't think I would ever use this, but I can see how it would be very helpful if you used attributes for storing important things (e.g. items).

In fact, it's probably better in some cases to store items and such in player flags as opposed to text files or SQL.

Strings should never have to exceed the limit, and if they do, you should consider rewriting whatever does exceed it. That, or simply change to a TStaticVar.

The "limit" is not a limit, but rather a bug. You can easily exceed 255 characters in player flags. External RC just fails to save those after the 255 mark when editing player attributes.

Not that hard to exceed 256 characters if you're storing things like item descriptions and such. The limit includes everything that you see in the flag's(the name, the = and everything). It is a bug and a serious one at that, and unless Stefan updates the RC, I think this is a fair compromise.

If possible avoid such long strings, item descriptions could be stored separately, e.g. only loaded from server when needed (when viewing the item).

Really? Why do we always have to compensate for bugs instead of at least doing a bandaid fix like this?

Because large strings really shouldn't be stored on the player anyways, it can lead some problems because more data has to be stored & accessed. It's much better to only access it when you need it due to the fact that strings are stored in memory.

Yes, but in some circumstances you're going to have more data... I'd just rather compress it all into one string rather than having tons of single flags.

Well, I agree, it would be nice; for example, for UN's hat system, I had to store peoples' hats in text files on the server and then load them into the person's string on login (due to the fact that some people had so many hats); but for most circumstances, it's inappropriate to have a string attached to the player that's > 255 characters in length.

Well my point is sometimes you're going to just have a lot of data. For example, if you used a simple switch/flag system that Classic used to use, where you set a flag when an event happened to make sure it didn't happen again, add up a lot of those and you're going to end up with a lot of event flags. What's the difference between having 20 strings or having one string with 20 values? Even if I save them in a file, they're going to have to be loaded and stored somewhere in memory anyways, no?

I just don't understand why such a simple change would be dismissed. As far as I know, Stefan can update the serveroptions and RC commands from the gserver and do an update that wouldn't require any updates to RC at all. I may be wrong, but that was my impression. I know even if it's not wise to use large strings, servers do and it's stupid to lose important player data just because of an outdated RC tool.

I'm not saying we should all start using huge client strings and all, but when the occasion arises that a string does get long we shouldn't lose it to a bug. Especially when sometimes you might not even be aware!

It's just easier to use client flags instead of having file i/o or DBs for things like saving outfits, and other things like that.

Eventually such option could be added, but specifying what kind of strings should be protected (like clientr.mud_ or so), so that it's still possible for staff to change other variables.

Well the idea is that if they were to use this option, they'd have an alternative way to change variables... either with the scripted RC that doesn't have the bug, or a scripted weapon with the proper security. The only thing this would do is disable the external RC from saving attributes.