Added several variables to make ClumsyComponent more modular for developers.

[widgetbeck]

About the PR

Added nine new variables to ClumsyComponent and its system to allow developers to specify that certain clumsy events should not be applied to a given entity, and to allow developers to have custom per-entity "failed" popup message.

Why / Balance

ClumsyComponent does a lot of different things, and sometimes you only want it to do a few of those things. For example, I was developing a species that is incapable of using guns on my server - I added these variables so that I could disable the hypospray, defibrilator, and table bonk events on those entities.
In short, these changes allow developers to find more creative uses for this component, without the hassle that would be separating each event into its own system.

Technical details

Very simple. Added a check to each event that, if that event's boolean is false, skips the event, and changed the hardcoded strings in ClumsySystem to public LocIds that are read from ClumsyComponent.

Media

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

[slarticodefast]

I noticed another thing, please use spaces instead of tabs everywhere:


I recommend using an IDE instead of a text editor. That way you will be corrected if you do things conflicting with our code conventions defined in the .editorconfig file.

[widgetbeck]

Ahh, I see. I'll fix that. Out of curiosity, is there a reason that this matters functionally? I've been using tabs on all my custom content for our server.

[slarticodefast]

Consistency reasons mostly, functionally all whitespace should be the same afaik. If you would be using an IDE the tabs would get automatically converted into spaces, so it wouldn't even be possible to mix both. But if you do it in a texteditor and open it in an IDE afterwards the IDE will scream in pain and throw yellow squiggly lines at you :)

Also git sees the tabs and spaces as different code, so if someone would change a few lines including whitespace then it would mess up the diff.

[slarticodefast]

Looks good to me, thank you for your first contribution!

[beck-thompson]

us becks like the clumsy system I guess 😆!

[chromiumboy]

Honestly, I feel like this approach of having a separate bool for every possible clumsy event is something that could get out of hand. If someone wants to add clumsiness to a specific tool in the future, for example, that's another bool to add to the list

I'd prefer a system in which clumsy people have a list of clumsiness rules (i.e. prototypes), which get checked against when a potentially clumsy event occurs. If a match is found, the event occurs; any required data regarding the event (e.g., the message to display to the player) can just be stored in the rule prototype

[slarticodefast]

I'd prefer a system in which clumsy people have a list of clumsiness rules (i.e. prototypes), which get checked against when a potentially clumsy event occurs. If a match is found, the event occurs; any required data regarding the event (e.g., the message to display to the player) can just be stored in the rule prototype

I think that would probably make things unnecessarily complicated in this case. Another approach would be to split the component up into a separate one for each effect, so that you could use composition to select the effects you want. But that again is not really needed in upstream at the moment. A boolean is simple to use and easily adjustable using VV.