I was fumbling through updating the Bell 407 audio for an upcoming 3rd party addon and found, first of all, that I need to submit a bug report for non-functional sounds in the 407. All of the buttons, switches, and interactive controls (aside from simvar activated controls) are not functional.
I found that Nemeth actually used Animation based sounds, so they are relying on their animations to playback the audio. So did we, since their behaviour files are set up so strangely. No matter…
The issue with the 2024 model seems to be that there is a missing element with the 407’s animation sounds in the XML. I had to dig into Asobo’s 737 Max Sound.XML to understand what is missing, and I found that an entry “SimAttachmentAlias” is needed for every animation sound in place of the old nomenclature “Model”.
Can you please elaborate on its use in regards to audio, and how do we make sure they are set up correctly in our projects?
Bump.. .interested in this since we are about to prepare sounds for our 1st full modular MSFS 2024 exclusive aircraft.
In MSFS 2020, we love doing 3D surround sounds, where sounds are attached to nodes to ensure users perceive the sounds coming from the correct source, etc.
We need to understand how to achieve the same things in MSFS 2024 when we split the airplane in over 30 parts to comply with the new standards, etc.
@Boris Any help with this will be appreciated to avoid delays with our project development.
@EPellissier It would be great to get some documentation or even a simple explanation of the intended use case for SimAttachmentAlias here. I’m very curious to learn what it’s for, as I’m finding splitting up my sound.xml into an individual file per attachment a bit tough to maintain, especially when attempting to support both 2020 and 2024 simultaneously. I was hoping SimAttachmentAlias would let me specify what attachment a sound is intended for (so I can just use a master sound.xml in common), however I haven’t gotten it to work.
That’s not the same function as what’s needed for the actual attachment. The sim pulls (for whatever reason) a separate sound XML for interior parts. Has nothing to do with the SimAttachmentAlias function.
That is pretty much, from my understanding, just a nomenclature adjustment. There’s no way around having multiple sound XMLs at this time, unless I missed something.
Having a barricade of sounds.xml across a modular aircraft is indeed a drawback IMO, I would love to see a way to keep “optional” the need to split your sounds across multiple .xml, for example, I understand if you are going to re-use a “part” that the sound should be split.
However you always need the base .PCK anyway, so the argument is flaky at that stage for 3rd party devs, the reality is, we only splitting the planes to hit the requirements for performance and LODs, not because we are going to re-use a wing, a engine, a gear, etc. with another aircraft, most aircraft we 3rd party devs work on cannot allow such thing, the interiors and cabins are also different most of the time, the reality is, very little we are going to re-use for another project, quite frankly pretty much nothing.
So it would be much easier and simple if we could have 1 single sound.xml with the .PCK, etc, as tweaking sounds and events for these is way easier when inspecting a single file.
With the current solution / layout, if you need to adjust a sound, you have to hunt down across up to 30 to 40 sound.xml files (on a large plane number of parts go easily this big) to find out where is the things you trying to tweak. I know L:VAR sounds can be on the master, but, if you want to attach to nodes to provide a true 3D sound experience, you end up splitting to crazy amount of sound.xml
It is a pain, agreed, there has gotta be a better way around it. Maybe a similar adjustment can be made to the XML code to allow for #includes so it pulls from the master sound XML without needing to manage several dozen of them.
