-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify Usage of Settings #203
Comments
I guess I am not fully understanding the context as to what you are requesting. I don't think modifying a player's settings should really happen in a plugin, it should be up to the player themselves to modify their own settings. Also, in case you are unaware, outside of using the SP player settings menu on each server, users can also add things like the following to cfg files on their client:
For instance, in my MostDamage plugin, I add PlayerSettings with the So now, clients can now use the following in any of their cfg files:
That value is always checked first. If it is found that the client does not have that convar set locally, we then grab the value from the server. So, if a client goes onto a lot of servers that have MostDamage installed, and they always want to have the same setting, they can simply add that to their I realize the documentation is lacking, and that is something I have planned to work on but just haven't. I also definitely need to add in functionality for users to dump all SP player settings on a server, so that they have access to all of these client convars. Though, the plugins that utilize this functionality themselves should also add them as a part of their documentation. If I have failed miserably at this response, please just clarify what you are intending to want added (and why) with further context. |
I tried to give it a chance, next to my 'clientprefs' version from sourcemod to source.python. (Which simply let the plugin easily save the players choice for the named setting). So, I was usually having my own chat commands, or my own settings menu (Toggle, with custom ON/OFF Outputs, sometimes even more than that with cycling). After building it up, theres only few ways to set it, with that built in menu (for one setting?) or that console command. It would be pretty nice to just use a my own command like !hudoff which disables 3 player settings at once, or making my own toggle commands. Its hard to explain, but If its still not understandable Im trying it another way. Thanks |
Well, again, player settings aren't really meant to be set by plugins themselves. Typically, the user should do as I stated above, and if they want to toggle their settings, they could run a client command to execute the appropriate cfg file. However, if you wish to circumvent this, you could always use something like the following: from players.entity import Player
from settings.player import PlayerSettings
from settings.storage import _player_settings_storage
plugin_player_settings = PlayerSettings('My Plugin Name', 'prefix')
setting_one = plugin_player_settings.add_bool_setting(
name='Setting One',
default=True,
)
setting_two = plugin_player_settings.add_bool_setting(
name='Setting Two',
default=True,
)
setting_three = plugin_player_settings.add_bool_setting(
name='Setting Three',
default=True,
)
def some_function(user_index):
player = Player(user_index)
for setting in (setting_one, setting_two, setting_three):
_player_settings_storage[player.uniqueid][setting.convar] = not setting.get_setting(user_index) |
I remember talking with Frag on this matter. As for me, the key thing is: If I understoood Frag correctly, he builds up a custom settings menu JUST because of how inconvenient current implementation is. Indeed, to toggle a boolean setting, you have to click on the corresponding setting, and that opens another submenu. While Frag's own implementation just switches (toggles) the setting upon "clicking" on it, without entering a submenu. For a bunch of boolean settings that really simplifies the usage, IMO. Then to extend this further, Frag wanted to be able to cycle through possible setting values the same way as with boolean "toggling". E.g. click - I think that this can be implemented as a keyword (like I'd also throw my two cents in here. I think that some sort of EnumSetting would be more pythonic than the current StringSetting. Really, you can't set StringSetting to arbitrary values via chat nor via convar anyways (and from its name, I'd say that you could), so it's bound to a set of values. Why not just bind it to an if quake_sound_volume.get_setting(player.index) == "loud":
... is less pythonic than if quake_sound_volume.get_setting(player.index) == SoundVolume.LOUD:
... Actual text shown in the menu for each value can be either set as a class SoundVolume(Enum):
NORMAL = strings['sound_volume normal']
LOUD = strings['sound_volume loud'] But in this case I don't see the benefits of the Or it can be supplied some other way, say, via a separate mapping: plugin_settings.add_enum_setting(
name="quake_sound_volume",
enum=SoundVolume,
default=SoundVolume.LOUD,
text=plugin_strings['settings volume'],
value_translations={
SoundVolume.LOUD: plugin_strings['settings value loud'],
SoundVolume.NORMAL: plugin_settings['settings value normal']
}
) This allows to use an # `value` is SoundVolume.LOUD
value.name.title() # 'Loud' |
Hey,
I was trying to use the Player.settings module and thought, if it would be easier to use it than via the menu.
How about if we just simply could use:
Player.settings.get_string_setting('test_bool')
or
Player.settings.save_string_setting('test_bool', True)
This would allow us much more ways to modify player settings, such as in commands, in a all in one settings menu or anything else.
The text was updated successfully, but these errors were encountered: