Menu
▾
▴
#2883 Multiplayer remote sound is broken
Fixed
Medium
2024-12-23
2024-04-20
No
Hi,
while adding engine sound to remote 172's and 182's I noticed the feature got broken in 2020.4/next.
In 2020.3.19 the feature still works!
But in next, no sound from the remote airplane can be heard (with same plane version).
The 777 (777-200) from FGAddon was the sample I peeked at when implementing, and there its also working in 2020.3 but not in 2020.4.
Nothing suspicious in the logs, especially no errors to be seen.
References:
No idea why this broke, it's not an area of the code I know at all so hoping someone who knows the Ai/MP stuff will comment.
Hi Bene,
Just wanting to rule out that this is related to multithreaded loading of models, but is this with a single loading thread ?
-Stuart
If you mean the OSG pager threads option property (
/sim/rendering/database-pager/threads), then yes...Benedikt, would the following setup be om to reproduce this:
This should be enough hear eg flap movements or engine noise from the MP aircraft, agreed?
Okay tried to reproduce this with the 777, and it's not possible, becuase the loaded model is the FGData/AI/Aircraft/777/ model - none of which specify any sounds in their XML.
The code is present to load a sound/path file from ModelData at a /ai/<type><nn>/sim/sound/path I thnik, but I need to figure out a better way to test it.</nn></type>
Testing this, with both the 777 and 182 I'm noting that the fallback model in FGData/AI/Aircraft is always used, and not the full model. The fallback models typically do not specify a sound configuation.
@stuartbuchanan - how does the 'real model' vs 'fallback model' selection work these days? Is it possible this bug here is caused by it not working the same as previously?
Actually, what I think that happened is that the fallback models have been added after 2020.3 so before that it would use the full model (with sound) instead.
Oh yeah, that could do it. So ... how do we fix this? I'd assumed the fallback models were, well, a fallback when the full model is not present?
The fallback models are there especially for AI. So they are lower polygon count and use less texture memory. To get sound back they need to define a sound file per (base) aircraft.
I think we go down the wrong rabbit hole.
When I found the issue, I was seeing the correct complex model, which had no sound in the newer, but had sound in the older version I tried.
In no instance I was testing against to a low-poly fallback model!
Ok, at least for I didn't manage to trigger the high detail model to load, yet.
Still working my way through this: the '3D model finding' code in AIMultiplayer / AIBase finds both paths correctly: the low-res fallback path and the high-rest one in my aircraft path. The ordering is that the low-res (fallbacl) path is first (index 0) and the high-res model is second (index 1)
When the AIModeData modelLoaded callbakc fires' its the fallback model it reports, which of course, has no sounds : so the AIModelData fxpath is set to empty.
This means on the next AIBase::update we hit needInitialization .. find an empty FXPath ... and don't load any sounds.
I am guessing that based on LOD settings, we at some point load the high-LOD version.. but at that point we don't check needsInitialization again, so we don't pick up the now-present sound XML?
Okay, I had some dumb LOD ranges due to testing a different bug. With a slightly more plausible High-detail LOD range, when the high-detail model loads, for me, the sound works.
There's logic in AIModelData to trigger a re-initialization, and we re-create the FGFX and I hear sounds. I did just make some fixes to FGFX around reloading, and I think that may have helped this.
Suggestion here: when we have a high detail model, I can imagine we might want to use its FX.xml even when loading the lower detail 3D model? This would mean loud jet noises etc would be audible (potentially at least) for quite disant MP models
Just reading this thread now. You'll have noticed already that I refactored the LOD code for AI models in 4cfa707f419ca9161d0549c41d911e4d6f0a064d, but it sounds that wasn't a factor here in the end.
I agree that loading the high detailed FX even when the lower detailed 3D model is loaded makes sense.
I've made a note about improving the low/high FX XML selection, but could use some other folks re-testing 2024.1 with my latest fixes, to see if the main issue here is fixed or not. For me I think it is, but I'm not certain yet.
The latest 2024.1 build on GitLab shoulds contain my changes: can some folks please test and see if there's any improvement here?
Hopefuly fixed, waiting on a bit more feedback before marking as verified.