[REL] Settings Manager v1.6.0 [67342]

This framework allowed other mods to easily add new settings to the settings screen. As Uber have modified the settings system to allow it to be more easily extended though, this mod is now deprecated.

Only the DropDown and Slider option types are functional, and these map to the new method of adding settings. This is for compatibility purposes to allow old mods to continue to function; new mods should not use this framework any more.

Usage
In the settings screen, use one of the following to add a new setting:
model.addSetting_DropDown(displayName, id, tab, optionsArray, defaultIndex, group);

model.addSetting_MultiSelect(displayName, id, tab, optionsArray, defaultOptionsArray, size, group);

model.addSetting_Text(displayName, id, tab, type, defaultValue, group);

model.addSetting_Button(displayName, buttonText, tab, callback, group);

model.addSetting_Slider(displayName, id, tab, min, max, defaultValue, group);

• displayName is the caption that is displayed in the settings menu
• ID is a unique identifier for the setting
• tab is the name of the settings tab the setting appears in (ie. 'Graphics', 'Audio', 'UI' etc.)
• type is the type of textbox - "Text" or "Number"
  
• optionsArray is the list of menu items that appears in the drop-down menu
  
• defaultIndex is the index of the value in optionsArray that is the default.
• defaultValue is the default value of the textbox
• defaultOptionsArray is the default values selected in a MultiSelect listbox
• size is how many items are shown in the multi-select
• buttonText is the text to display on the button itself
  
• callback should be a string that will be executed when the button is clicked
• group is the name of a group which this setting will be added to.
• min, max are the range of values allowed for a slider.

You will also need to make one additional function call before using the new setting, which will ensure the setting is populated if it is not already (as the above code only applies to the settings screen, so if a player doesn't open that screen your new setting won't have a value). This will not change the setting if it has already been set.
initialSettingValue(id, value);

You can then access the value like any other setting:

var settings = decode(localStorage.settings);
var value = settings[id];
or
var value = settings.id;

There is also one other method available:
model.addSettingGroup(tab, group);

Normally, new groups are created as needed, however this can be used to create a blank group (sometimes needed to maintain the ordering of groups, as they appear in the order they are created). In general, you shouldn't need this.

Installation
Current build: 67342 (version 1.6.0)

Step 1:
Install the PA Mod Manager: https://forums.uberent.com/threads/rel-ui-mod-manager-v1-2.50726/

Step 2:
Launch the Mod Manager and click Install next to "Settings Manager" on the "Available Mods" page.

Step 3:
Tick the box for "Settings Manager" in the Installed Mods list to enable to mod.

Great, this will unify things a bit
Let me know when you got a release.
I will update hotbuild2 to use the framework then.
We should be able to set dependencies in the ini file or something so it downloads the framework files or links them online.

PAMM ini files already support dependency declaration

But the file needs to be packaged with the mod right ? Or are you going to make a common ui mod framework folder that's packaged with PAMM itself ?
Anyhow eager to try out your 2 frameworks. So let me know if you need a tester

I'll release these two frameworks as mods, then you can specify them as dependencies within your mod's ini file, for example:

Code:

[PAMM]
Name=Commander Health Display
Author=raevn, danzel, burntcustard
Link=https://forums.uberent.com/threads/rel-commander-health-display-v2.50584/
Description=Adds a display to the UI that tracks your commander's health
Category=In-Game
Folder=PA\media\ui\mods\rCommanderHP
live_game='../../mods/rCommanderHP/rCommanderHP.css','../../mods/rCommanderHP/rCommanderHP.js'
settings='../../mods/rCommanderHP/rCommanderHP_settings.js'
Version=2.6
Build=57703
Requires=rSettingsManager

That's Perfect

Just to check, by 'dependency declaration' you mean that the mod declares that it is dependent on another mod being installed/active to function?

Apologies, I'm obviously incredibly interested in the modding scene but I'm by no means a programmer (yet).

Yes that's what he means. If I understand correctly pamm allows a mod to declare that and pamm will take care of the rest?

That's awesome.

Somewhat Off-topic, my apologies

Another nooby question - is the following scenario theoretically possible?

• One mod, which adds new units, edits a core unit file, adjusting its HP to 360 instead of 300
• A second mod, which also adds new units, edits the same file to 330.
• Because of the nature of the units added by the two mods, the unit is deemed to require 400 HP if both mods are installed

So, you'd end up with:

• NO mods installed: 300 HP
• ONLY Mod #1 installed: 360 HP
• ONLY Mod #2 installed: 330 HP
• BOTH Mod #1 & #2 installed: 400 HP

Is this all possible using checks within the mods themselves?

You could probably somehow write 2 mods that interact like that, but it is not the usual scenario. If 2 mods conflict like that it is much more likely that whatever mod was loaded last will dictate it's value.
So the first mod says:
hp = 330
and the next one says
hp = 360

Than you get 360 hp.

But that's all speculation, as the server side modding has not been described by uber.

EDIT:
Even if the mods would be based on delta values, +30 and +60 dont sum up to +100

I'm thinking something like

In mod 1:

IF Mod 2 installed, HP = 400
ELSE HP = 330

In Mod 2:

IF Mod 1 is installed, HP = 400
ELSE HP = 360

Then you could use nested ELSE IFs for more complicated relationships.

I'm sorry, let's return to the actual topic of this thread. I'll pick people's brains elsewhere

Not every option will be an Array.
Make sure we can just add normal textboxes + for normal textboxes , some validition rules would be handy parseInt ...

I chose drop-down lists first as they are both the easiest (validation not needed) and most useful (most other types, such as checkboxes, can be represented as a drop-down list).

But what a bout my reset time box

I think these frameworks are really going to be helpful and needed.
We should maybe also set up some coding guidelines.
Like naming conventions. Cause everytime I declare a var I hope I don't break another mod

It'll be there eventually, not to worry! Also, depending on how your mod is set up, this hooks the existing settings in a non-destructive fashion, so your mod should still work if this is released before text boxes are implemented.

That's not a bad idea. Also, if someone has time, an index of declared variables in mods for each screen would be handy.

Actually, that gives me an idea.

We should be declaring our mods in anonymous closures so they don't pollute the global namespace unless desired.
https://developer.mozilla.org/en-US...sures#Emulating_private_methods_with_closures

Then you don't need to worry

That is what I was already doing with hotbuild2

raevn

https://forums.uberent.com/threads/rel-hotbuild2-57703.54561/page-2#post-835576

We have conflict issues with settings standalone it works fine.
Ideas ?

Released!

Small update that sets the mod's priority to 10 so it loads before others.