Considering starting on a general enhancement suite

[TheBlackParrot]

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.

I can't wrap my head around what you mean. I'm assuming you're talking about interaction functions, which is in interaction.cs on the server-side. I'd assume anyone working on clients would start from scratch or use the default/example client as a base.
I could always add a button to download the server-sided part if someone hosts a server, though. I don't want to make that a requirement.

I could also just let the handshake (GameConnection::setConnectArgs on the client and GameConnection::onConnectRequest on the server) reside in Support_BlocklandPreferences (or Support_Preferences, idk), and just pass off the "handshake is valid" to a client-sided function to use. (is that what you meant?)

[Ad Bot]

[TheBlackParrot]

(the pref manager will split into its own topic once it gets a bit more done)

Progress so far:

The client doesn't show every pref yet as I'm still adding the types for it, but anyways

• Can generate categories based on what's given for the %addon argument
• Can generate prefs on its own using pref types of number, string, slider, boolean, list, password
  
  • I plan on adding types for colors (via colorset) and time
    
    • Time prefs will be in (#)h, (#)m, (#)s format, 3 text edit fields on the example client
    • The value will be calculated out to seconds by the pref system
• RTB prefs are automatically converted to the new system, they're set with a legacy flag (clients can do what they wish with this info)
  
  • The example/default client will use the "bricks" icon from the famfamfam silk icon package (the old RTB logo), and will mark the title with "(Legacy)"

Current syntax for registering a preference:
registerBlocklandPref(%addon, %title, %type, %variable, %default, %params, %callback, %icon, %legacy)

• %addon: Addon name or category name
• %title: Preference name
• %type: Type of preference (can currently choose from number, string, slider, boolean, list, password)
• %variable: Variable on the server-side to be modified
• %default: Default value for the variable (or the current value, see the example below)
• %params: Extra parameters (can be viewed in server.cs for reference (as of right now))
• %callback: Command to call once the variable is updated on the server-side
• %icon: Icon to use for clients (clients can choose to ignore this, it's merely a string)
• %legacy: Flag to signal this is registering through an older method (e.g. RTB)

Example of registering a preference for the server's Welcome Message:

Code: [Select]

if($BLPrefs::Init) {
%cat = "Server";
%icon = "server_edit";

registerBlocklandPref(%cat, "Welcome Message", "string", "$Pref::Server::WelcomeMessage", $Pref::Server::WelcomeMessage, "512 0", "eval(\"$Server::WelcomeMessage = $Pref::Server::WelcomeMessage;\");", %icon, 0);
}
(more can be viewed at https://github.com/TheBlackParrot/blockland-preferences/blob/master/prefs/general.cs)

The code's public for both the example/default client and server backend if anyone wants to contribute.


On the client, should I line up the pref fields, or leave them to the right of the label like they are now? (minus the checkboxes)

[Scout31]

I could also just let the handshake (GameConnection::setConnectArgs on the client and GameConnection::onConnectRequest on the server) reside in Support_BlocklandPreferences (or Support_Preferences, idk), and just pass off the "handshake is valid" to a client-sided function to use. (is that what you meant?)

Yeah, this is what I meant. Sorry, I typed all that on my phone in the airport, it wasn't very concise.

[Zeblote]

Regarding prefs, I always thought RTB was missing these:

- Large text areas
- Resizing the prefs window to fit larger texts
- Subtitles or mouse over hints for prefs to tell new users what each prefs does in detail
- Adding seperators between prefs of the same add-on

You could also add a few more cool features that a few add-ons could make good use of:

- Support for adding custom buttons in the prefs section that execute a callback function, for example an add-on could register a button "Clear Stats"
- Dynamically adding/removing prefs or updating values while the gui is open

[TheBlackParrot]

Large text areas should be doable if there's a way to wrap a text edit control.
Manual resizing of the window instead, maybe?
Mouseover hints can be done so long as there's some mouse-over trigger or something.
I want to add separators, for sure.

Custom buttons sound like a good idea, although this actually makes me consider more things as well, e.g. live updates of specific variables, just more things to interface with.

Prefs can be added dynamically very easily just be running the registerBlocklandPref function at any point, I just need to add a function to send a signal to clients when that happens. The current GUI is too dynamic right now as it fetches everything every time a category is clicked. This is technically already there, but I'm going to rewrite how it creates rows/etc.

I'd like/am coding the system to be designed to allow for custom clients as well. (I can see Blockland Glass potentially making their own)

Yeah, this is what I meant. Sorry, I typed all that on my phone in the airport, it wasn't very concise.

ah that's fine