You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The system for this should ideally be implemented upstream. SS14's current talk sound system should be refactored slightly, with SpeechComponent's speechsounds being shunted into a separate component, the actual sound-playing being moved clientside, and the server triggering the sounds by sending an event to the client. Additionally, barks should be introduced as their own separate component that can be present alongside the current speechsounds, with barks also being played clientside, and being triggered through the same event. To allow these two forms of speech noises to coexist, a clientside CVar should be added that allows clients to set their preferred speech noises (either barks or bytes), and even disable speech noises entirely. If the client's preferred speech noise type isn't present, then the SpeechComponent should fall back to whatever speech noise is present (for instance, if only a bark is present, then that should play. Otherwise, the speechsound should play instead. If there's neither, then no sound should play, but there should be a warning if a speechcomponent exists without either form of speech noise). Additionally, there could probably be some bonus code cleanup while all that's being done, such as making speechsounds use SoundSpecifiers.
The existing speechsounds should, from the player's perspective, remain exactly the same. The only player-facing difference should be that they can be disabled entirely, something that currently can't be done.
Bark components should ideally be implemented with parity in mind. If the exact same values are used for a given set of bark properties between Main and the SS14 implementation, then messages with the same length and ending should produce the exact same bark sounds and patterns. Additionally, since barks will be handled largely clientside, client CVars should be added to allow the player to determine the maximum amount of time a series of barks can continue for, and the maximum number of barks that can play within that time period (some folks might prefer that barks be restricted to a shorter time period! While others might want to embrace the chaos of getting barks for the entirety of the bee movie script. Player choice, woo!).
Making barks be used upstream is entirely optional, however. Folks upstream might like them, as they are quite cute compared to the current speech soundbytes! It'd likely be fairly acceptable to integrate barks into character customization with the same level of granular customization seen on Main, complete with ports of bark sounds from Main. However, care should probably be taken to vet the license validity of individual bark sounds, as SS13 has historically had a fairly rocky history when it comes to complying with sound licenses (currently, most barks in Main are pre-existing samples taken from sounds inherited from TGstation).
The text was updated successfully, but these errors were encountered:
Barks should be brought over from Citadel Main. The relevant PRs for implementation reference can be found at Citadel-Station-13/Citadel-Station-13#15677 and Citadel-Station-13/Citadel-Station-13#15684
Brief discussion about this on the Discord can be found here (In Citadel's Discord): https://discord.com/channels/161574200581029888/961021752656416799/1055714068335431700
The system for this should ideally be implemented upstream. SS14's current talk sound system should be refactored slightly, with SpeechComponent's speechsounds being shunted into a separate component, the actual sound-playing being moved clientside, and the server triggering the sounds by sending an event to the client. Additionally, barks should be introduced as their own separate component that can be present alongside the current speechsounds, with barks also being played clientside, and being triggered through the same event. To allow these two forms of speech noises to coexist, a clientside CVar should be added that allows clients to set their preferred speech noises (either barks or bytes), and even disable speech noises entirely. If the client's preferred speech noise type isn't present, then the SpeechComponent should fall back to whatever speech noise is present (for instance, if only a bark is present, then that should play. Otherwise, the speechsound should play instead. If there's neither, then no sound should play, but there should be a warning if a speechcomponent exists without either form of speech noise). Additionally, there could probably be some bonus code cleanup while all that's being done, such as making speechsounds use SoundSpecifiers.
The existing speechsounds should, from the player's perspective, remain exactly the same. The only player-facing difference should be that they can be disabled entirely, something that currently can't be done.
Bark components should ideally be implemented with parity in mind. If the exact same values are used for a given set of bark properties between Main and the SS14 implementation, then messages with the same length and ending should produce the exact same bark sounds and patterns. Additionally, since barks will be handled largely clientside, client CVars should be added to allow the player to determine the maximum amount of time a series of barks can continue for, and the maximum number of barks that can play within that time period (some folks might prefer that barks be restricted to a shorter time period! While others might want to embrace the chaos of getting barks for the entirety of the bee movie script. Player choice, woo!).
Making barks be used upstream is entirely optional, however. Folks upstream might like them, as they are quite cute compared to the current speech soundbytes! It'd likely be fairly acceptable to integrate barks into character customization with the same level of granular customization seen on Main, complete with ports of bark sounds from Main. However, care should probably be taken to vet the license validity of individual bark sounds, as SS13 has historically had a fairly rocky history when it comes to complying with sound licenses (currently, most barks in Main are pre-existing samples taken from sounds inherited from TGstation).
The text was updated successfully, but these errors were encountered: