Open bchantech opened 1 year ago
I will consider this during the sound event overhaul (#95). This might make resource handling more complicated though (passing sound files directly instead of sound events means that all class configs will have to check whether it's a sound or an event; on the other hand, specifying deliberately nonexistent sound event files might be too unintuitive).
ResourceManagers may be able to create sound events on the fly when a path to the sound file is passed in a :getSoundEvent()
call, though.
I'm closing this since with ff71f34 sounds can be placed in any directory so we can't assume that they will be present in the /sounds folder.
Reopening since providing a path to a sound file whenever a Sound Event is expected should generate an implicit Sound Event to avoid creating unnecessary boilerplate Sound Event files of which the only purpose is to exist - as a QoL for modders so that they need to change/create one file less. This part has nothing to do with the resource placement, as you need to provide a full path to any resource anyways.
Also, relates to #123 and is a part of a bigger plan to iron out all inconsistencies in the way expressions are defined, resources are referred (#103), etc. that will be carried out throughout the rest of the Beta 4.x cycle.
Currently, sounds are specified via
sound_event
, however, most if not all of the time it only containspath
containing the sound file of the same name.When the game plays a sound event that is not defined, it should try to play the sound file of the same name using the default parameters.
Example:
/sound_events/sound1.json
is specified in UIIf
sound_events/sound1.json
is not present, it should create a newsound_event
with the following info:If the game cannot find the sound, then path will not be included. If the game can find the sound, and detects it is stereo,
flat
will be set to true.