soooo can you list out what support_preferences can't do then?
considering we can add to it
Yup. It was designed as an open standard after all.
Alright, considering you're double teaming me now...
Support_Prefs uses eval to get and set values. Not necessarily a problem if you're the trusting type, but not really something I like doing either because if someone runs this:
function BlocklandPrefSO::getValue(%this) {
return eval("return " @ %this.variable @ ";");
}With the variable registered as something like
"crash()" // extreme example, I know"You're screwed. Eval is never a good idea. You use it in several other places too but at least there you add mild security by expanding your escape characters.
Take a look at "support/variables.cs" for my special method for getting around this. You'll find it interesting, I'm sure.
Also, there's the fact that Support_Prefs uses nonstandard seperator characters rather than torque's words and fields.
while(strLen(%params)) {
%pos = stripos(%params, "|");
%row = getSubStr(%params, 0, %pos);
%pref.rowName[%count] = getSubStr(%row, 0, stripos(%row, "**"));
%pref.rowValue[%count] = getSubStr(%row, stripos(%row, "**")+2, strLen(%row));
%pref.valueName[%pref.rowValue[%count]] = %pref.rowName[%count];
%count++;
if(stripos(%params, "|") != -1) {
%params = getSubStr(%params, stripos(%params, "|")+1, strLen(%params));
} else {
%params = "";
}
}
%pref.listCount = %count;Which goes against my personal preference simply because a) there's no point and b) you're forcing a new format on everyone. Just use getWord/Words and getField/Fields, it would've been much easier for you to code and wouldn't cause this problem.
Keep in mind that sometimes list names will contain spaces. I have no doubt that this was your motive for doing it this way but there's really no point if the only word you need from each field is the first one. Or, do what I'm doing and extend the old RTB method (which JUST used words) by replacing underscores with spaces.
%optionCount = (getWordCount(%type) - 1) / 2;
for(%i = 0; %i < %optionCount; %i++) {
%first = (%i * 2) + 1;
%name = getWord(%type, %first);
%value = getWord(%type, %first+1);
%name = strreplace(%name, "_", " ");
%input.add(%name, %value);
}Because if you do it my way not only will old pref registrations work (lists limited to single word entries) but new ones will translate easily to the old system as well. I like the idea of this. Backwards compatibility is part of every good standard.
case "string" or "password":"password" doesn't need to be a default type. In fact, type is a bad place for declaring that certain prefs are private because now I can't add private values that are numbers or selection list. Think those won't be needed? Sure they'll be needed. What if I don't want to show everyone what AI mode a monster is set to? What if I don't want people to know what my lucky number is set to?
It needs its own value on the pref object.
case "slider":That's good. I don't have those yet.
function BlocklandPrefSO::findByVariable(%var) { // there's gotta be a better way to do thisThere is, if any of my guesses at what you're trying to do here are right.
If you're attaching variables to large tree structures instead of the prefs themselves (icons, for example) you should use global caches instead.
If the prefs are stored in the tree structure, use Badspot's NTObject optimization and list all their ids in a global array. My system uses "category" and "name" as a composite key for this since no two prefs can have the exact same category and name. Getting to them would be as simple as "$Pref[%cat @ "_" @ %name]" and checking they exist would be as simple as "$Pref[%cat @ "_" @ %name] !$= "" ".
$BLPrefs::Init should exist, because it's a standardized way of checking that a pref system is available.
-removed-
// the groups made things SO MUCH SIMPLER
for(%i=0;%i<%group.getCount();%i++) {
%row = %group.getObject(%i);
if($Pref::BLPrefs::ServerDebug) {
echo("\c4Sending" SPC %row.category @ "...");
}
commandToClient(%client, 'addCategory', %row.category, %row.icon);
}Liking this. I only have two layers of iteration, but your prefs can go as deep as you want.
But do they really need to? What would a sub-sub-category even look like? Think about it.
// because oRBs is the same thing at this point -_-
// so much for "innovation", amirite?Lol.
I never actually understood the point of renaming all of the oRBs functions. I assume it's so RTB won't have a naming conflict... with itself? I don't know.
That's pretty much it. If it's an open standard, fix some of this stuff. Copy paste some of my code if you like, I'm happy to help.
