Support_Prefs v3.1 - now with keybind

[chrisbot6]

v2.2 to v2.3

Code: [Select]

- Fixed issue with disconnectCleanup.

[Ad Bot]

[chrisbot6]

v2.3 to v2.4

Code: [Select]

- Fixed issue where dedicated servers wouldn't load the mod in time
Thanks, Kenko!

[HALO3cheif]

Still seems to be an issue with Preferences not appearing, such as server_WeaponShopSystem, tool_Banhammer and server_AFKkicker

[The Lawyer]

Chris, could you add a mirror for the download? Mediafire is not working.

[The Lawyer]

Nvm, just got it to work. Wonder what the problem was...

[The Lawyer]

I can't see how to use Server Prefs. I've downloaded them and enabled them on my server, but how do I access the GUI?

[Maui69]

the edit button is a handy tool
i'm only mentioning this because your posts were basically only like 1-10 minutes apart

I can't see how to use Server Prefs. I've downloaded them and enabled them on my server, but how do I access the GUI?

Description
Server_Prefs replaces the default server settings GUI with this extensible one:

[chrisbot6]

Still seems to be an issue with Preferences not appearing, such as server_WeaponShopSystem, tool_Banhammer and server_AFKkicker

Those mods use the isFile method of checking if RTB is present. Not much I can do.

[jes00]

Those mods use the isFile method of checking if RTB is present. Not much I can do.

You could create fake files.

[chrisbot6]

You could create fake files.

Not a good idea.

- How do I confirm whether fake files need to be created?
- How do I prevent the user from seeing or enabling fake server.cs/module files?
- How do I cover every possible filecheck? (Support_ReturnToBlockland, Support_ReturnToBlockland/server.cs, Support_ReturnToBlockland/modules etc)

Packaging isFile has its own flaws:
- Should certain file paths really always return 1?
- How do I prevent modders from causing console error spam because they think a mod that isn't enabled is enabled.

Also, there's
- Why should I make my system work for people who don't make their mods properly?

Which is pretty important to me.

[Zeblote]

You can't package isfile.

Just make a copy of rtb with empty cs files, problem solved. Don't add description.txt, then it won't show up in add-on list. Don't do it if an rtb zip exists.

[chrisbot6]

You can't package isfile.

Just make a copy of rtb with empty cs files, problem solved. Don't add description.txt, then it won't show up in add-on list. Don't do it if an rtb zip exists.

Alright.

[chrisbot6]

Server_Prefs v2.4 to Support_Prefs v3:

Code: [Select]

- Now using TheBlackParrot's Support_Preferences as a base.
- Numerous bugfixes.
- Legacy pref categories that contain certain separator characters are now auto-subcategorized (i.e. Zeblote's duplicator)
- File name was changed to better reflect the mod's type and intentions. Delete the old file before updating.

[Scout31]

So, doing what you've done, Glass and Support_Prefs now break each other. You've rewritten a majority of Support_Preferences, and then implemented the newer version. Anyone running both will end up with one of them being broken because of the sweeping changes you've made.

When developing an API, you can't just change function names and protocol of an already adopted system. That defeats the entire purpose of having an API.

Also, Support_Preferences should be a stand-alone add-on, not the base of yours. That way, standardized updates can actually be released together. This shouldn't be an issue, since the API should be static. A script to download it if it's not installed isn't hard to write.

The officially released version of Support_Preferences can always be found here. I'll be updating it when the next Glass milestone comes because I don't have the time to just rewrite half of my end of things or work on the old branch anymore. In the future, please take more consideration when working with libraries and APIs.

[HALO3cheif]

So, doing what you've done, Glass and Support_Prefs now break each other. You've rewritten a majority of Support_Preferences, and then implemented the newer version. Anyone running both will end up with one of them being broken because of the sweeping changes you've made.

When developing an API, you can't just change function names and protocol of an already adopted system. That defeats the entire purpose of having an API.

Also, Support_Preferences should be a stand-alone add-on, not the base of yours. That way, standardized updates can actually be released together. This shouldn't be an issue, since the API should be static. A script to download it if it's not installed isn't hard to write.

The officially released version of Support_Preferences can always be found here. I'll be updating it when the next Glass milestone comes because I don't have the time to just rewrite half of my end of things or work on the old branch anymore. In the future, please take more consideration when working with libraries and APIs.

This

Having both run at the same time makes no prefs show up at all and breaks Glass or support_prefs