Considering starting on a general enhancement suite

[TheBlackParrot]

I'm just going to copy-paste the notes I was taking on potential things to add. I haven't decided on a name, "BLES" is just there to be a thing (Blockland Enhancement Suite is what it stands for).

This wouldn't be another Blota or w/e the older heavy theme rewrites are, it'll look very default and just add on to currently existing things.

EDIT 10/28: Preference backend has been detached from the enhancement suite idea into its own project. I will however create a frontend for it in the suite, and as an example frontend for reference purposes.
EDIT: 10/29: https://github.com/TheBlackParrot/blockland-preferences and https://github.com/TheBlackParrot/blockland-preferences-client


- prefs manager
   - be compatible with RTB, oRBs, etc.
      - make my own system too??
      - wrap RTB and oRBs into my system??
      - just take things from RTB?? (pls no)
   - give everything their own section
      - e.g., for categories:
         - General
         - Duplicator
         - Fillcan
         - Slayer (does it have RTB prefs? idk, 2lazy)
      - each addon registering a pref gets their own section

========================

- client sided chat logger
   - ez
   - pay attention to newChatSO::addLine for special things??

e.g., in config/client/BLES/chat/10.25.15.log:
==== CONNECTED TO TheBlackParrot's Falling Platforms ====
23:14:27   18701   TheBlackParrot   hi
23:14:29   173214   Blockhead173215   hi
23:14:48   173214   Blockhead173215   gotta go cya
!! Blockhead 173215 (173214) DISCONNECTED !!
23:14:52   18701   TheBlackParrot   ok b- oh

========================

- ID tracker
   - keep track of previous aliases
   - last seen (and where)

e.g., in config/client/BLES/whois/18701.log:
NAME         LAST SEEN      WHERE
TheBlackParrot      10/25/15 02:33:35   Cavik's CityRPG
TheWhiteParrot      04/01/15 14:57:23   TheBlackParrot's Falling Platforms

========================

- server playtime tracker
   - IP/port based
   - split into server name in files
   - take out words that start with "(" or "[" or etc.???
   - when clicking a server in the list, display total playtime somewhere

e.g., in config/client/BLES/playtime/127.0.0.1_28000.log:
TITLE               TIME (seconds)
TheBlackParrot's Falling Platforms   3742
TheBlackParrot's Brickochet      1243
TOTAL               4985

========================

etc. stuff:
- additional option to the saving menu to only save your bricks
   - ...is this even possible? (probably another server sided thing i bet)
- additional buttons to the regular admin menu to admin/deadmin players
   - and mute
- combine Client_CustomChat with this too?

========================

server-sided stuff:
- (maybe) find some way to get a player list on the server chooser?
   - ofc you'd have to have the system enabled/running on the server, so
   - maybe something similar to how RTB saw whether a server had RTB?
- mute commands
- moderator ranks
   - kick/mute only
- bring the colorset chooser back
- load a save on a custom gamemode


I haven't started on this at all, I'm still brainstorming. This is something I definitely want to do though, and I figured I could get feedback on ideas, and maybe get some ideas from you guys (as long as they're possible, that is).

Or I can just leave this up as a list in case BLG or oRBs need ideas, but I'm rather certain I want to go through with this.

[Ad Bot]

[elm]

Don't we have all of this stuff already though?

[jes00]

         - Slayer (does it have RTB prefs? idk, 2lazy)

Nope.

- additional option to the saving menu to only save your bricks
   - ...is this even possible? (probably another server sided thing i bet)

If it is, it's only possible to just take your bricks that are touching the ground and save everything on top of them(even bricks planted by people that have your trust).

[Scout31]

I have started working on a prefs replacement. I figured that it would be a good idea to ship the mod manager and preference system together, just so if you have one, you'll have the other.

If you want to contribute though, that'd be absolutely fantastic.

Edit: honestly the reason I wanted to keep BLG as an open project is so that, together, the community could make a fix-all solution instead of having a whole bunch of separate competing mods. If everyone has the same community-made enhancement suite installed, anyone is free to come in and make the changes they want to see and have them immediately distributed, instead of waiting for competing/cross functionality.

[TheBlackParrot]

I have started working on a prefs replacement. I figured that it would be a good idea to ship the mod manager and preference system together, just so if you have one, you'll have the other.

If you want to contribute though, that'd be absolutely fantastic.

Edit: honestly the reason I wanted to keep BLG as an open project is so that, together, the community could make a fix-all solution instead of having a whole bunch of separate competing mods. If everyone has the same community-made enhancement suite installed, anyone is free to come in and make the changes they want to see and have them immediately distributed, instead of waiting for competing/cross functionality.

I really only wanted the prefs manager after RTB died off, tbh. Mod managers and preference managers (in my opinion) shouldn't be in the same system, let people pick what systems they want to use.
I'd even go as far as saying "develop a standard for a pref backend," but I can't see that happening in BL.

Plus I wouldn't want this to just be a prefs manager lol.

If it is, it's only possible to just take your bricks that are touching the ground and save everything on top of them(even bricks planted by people that have your trust).

that sounds better actually

[K3k0m@n]

to be honest most of these things are already in development already

[Greek2me]

I'd be all for developing a standard preference system API, and I'll help with it.

It should be something similar to the Slayer 4 system, where the user creates a ScriptObject of a certain class with specific fields.

[TheBlackParrot]

I'd be all for developing a standard preference system API, and I'll help with it.

It should be something similar to the Slayer 4 system, where the user creates a ScriptObject of a certain class with specific fields.

something like this then?

Code: [Select]

function registerBlocklandPref(%name, %type, %parameters, %object, %variable) {
// ... i'm tempted to add in %callback via eval, but it just sounds like a bad idea

%sets = BLPrefSet;

%set = %name @ "PrefSet";
if(!isObject(%set)) {
%setObj = new ScriptGroup(%set) {
class = "PreferenceGroup";
};
%sets.add(%setObj);
}

%pref = %name @ "Pref";
if(!isObject(%pref)) {
%prefObj = new ScriptObject(%pref) {
class = "Preference";
}
%set.add(%prefObj);
}

// use $Pref::xxxxx::variable in place of defaults, and %variable
// (let blockland handle pref saving, it already has a functioning system for that)
// maybe just combine the two?
switch$(%type) {
case "integer":
%pref.def = getField(%parameters, 0);
%pref.min = getField(%parameters, 1);
%pref.max = getField(%parameters, 2);

// with the way blockland loads things, i doubt this can actually be a thing
// ...well it could if you registered everything after the initial save loads, in case it's a brick
// would be a bit delayed? but not too delayed? idk
if(%object !$= "") {
if(isObject(%object)) {
%pref.object = %object;
%pref.variable = %variable;
} else {
warn(%object SPC "does not exist! Can't assign this object to a preference; not registering it to avoid issues.");
}
} else {
%pref.variable = %variable;
}
case "string":
%pref.def = getField(%parameters, 3);

// repeat from integer

case "slider":
%pref.def = getField(%parameters, 0);
%pref.min = getField(%parameters, 1);
%pref.max = getField(%parameters, 2);
%pref.step = getField(%parameters, 3);
%pref.snap = getField(%parameters, 4);

// "

case "boolean":
%pref.def = getField(%parameters, 0);
if(%pref.def > 1) {
%pref.def = 1;
}
if(%pref.def < 0) {
%pref.def = 0;
}

// "

case "list":
%pref.def = getField(%parameters, 0);
%list = getField(%parameters, 1);

// "Host**4|Super Admin**3|Admin**2|All**1"

// string nonsense to separate the list
// "**" denotes the separation of the visible part and the value of the variable
// "|" denotes a new choice

// "

default:
warn("Invalid pref type, not registering" SPC %name);
}
}
(this was a quick example, can't really test while i'm on campus)

[Scout31]

If an open standard is being developed, I'd be happy to adopt and contribute to it. Personally I think callbacks are necessary.

[TheBlackParrot]

I'll probably end up creating a repository solely for the preference manager later tonight, although...
Do we want only the backend to be the standard? We still need a frontend regardless to show as an example, and other things, but if that's not a part, should that be in its own repository?

Make 1 repository for the entire pref system
or
Make 1 repository for the backend, and 1 for the frontend?

[Scout31]

If you want the backend to be adopted universally, I feel like your project to adopt it should be structured like any other; so, keep the manager and backend separate.

[jes00]

something like this then?

Code: [Select]

-Snip-
(this was a quick example, can't really test while i'm on campus)

Not what Greek2Me is talking about.

Something like this:

Code: [Select]

new scriptObject(BlocklandPrefSO)
{
class = "Preference";

category = "Some Mod";
title = "Money Limit";
defaultValue = 500;
variable = "$SomeVariable";
type = "int";
int_minValue = 1;
int_maxValue = 1000;
callback = "doStuff();";
};

function BlocklandPrefSO::onAdd(%obj)
{
%obj.setName("");

PreferenceContainerGroup.add(%obj);
}
Have every new pref registered named BlocklandPrefSO.

[TheBlackParrot]

started the repository
https://github.com/TheBlackParrot/blockland-preferences

and the client:
https://github.com/TheBlackParrot/blockland-preferences-client

[Greek2me]

Yep, like Jes said.

[Scout31]

I feel like it would make more sense to have the base functionality of both the server and client included in a single add-on, and then have your implementation as the separate repository. Like, keep both the server and client of the handshake and everything as part of, say, Support_Preferences, while keeping your example client as Client_Preferences or something. You can do something like Greek2Me has done with his Support_Updater migration, where Client_Preferences automatically downloads all the underlying base in Support_Preferences. It's what I'm planning on doing with Glass, at least.