Setting UserEmotesEnabled to false should disable default chatted emotes

Feature Requests Engine Features
#1

The name, UserEmotesEnabled, implies it should disable all possible player-initiated emotes. This includes things such as chatted emote commands - but it does not.

For example, if UserEmotesEnabled is set to false and you chat “/e laugh” - you’ll still laugh. This has the potential of breaking functionalities or for allowing emote clips. It is not intuitive behavior given the name of the property.

It may make sense to split “UserEmotesEnabled” into one property to disable the emote wheel and a separate property to disable the emote chat commands - either work for this use case. The main desired feature is the ability to disable chatted emotes without having to fork chat scripts.

Current Behavior:

  • UserEmotesEnabled is set to false
  • The player character who used the chat command still emotes

Desired Behavior:

  • UserEmotesEnabled is set to false
  • On chatting an emote command, a user should receive a reply in chat explaining emotes are disabled and the player character should not emote.
7 Likes
UserEmotesEnabled does not disable default chatted emotes
#2

I think this was maybe a badly named property, we probably should have called it CustomUserEmotesEnabled or something like that. The idea was that the property would disable the per-user customizable emotes that users could add to the emotes wheel, but not change anything related to the default emotes which are managed by the Animate script.

Currently the best way to disable the default emotes is to fork the Animate script and make a small code change to remove Emotes support, but we could make the script read from this property and do this automatically. Not sure what the intended use of the property is by developers currently using this, so it might just make sense to add a way to more easily disable the default emotes.

7 Likes
#3

Agreed. That’s why I had proposed potentially splitting the functionality into a new property (with an implied rename of the existing one). The current verbiage is confusing and the current way to disable chat emotes is not ideal.

I don’t think it would be too hard to implement, but the real question is the desired use case. Is the ability to disable chat emotes + menu emotes separately overkill? Probably not, but definitely something to consider for the future of these properties. Especially depending on whether or not the chat/animate scripts will continue to support forking.