Totally makes sense, thanks!

Hi Daniela,
1. When the aircraft is a _user_ aircraft, yes, by design. With the Cessna this didn’t require inside-ratio attenuation; the combination of the fall-off ratio on the sounds and the engine noise was enough. Technically if your’e outside your aircraft with the door open and the engine off, I’d expect you might here a sound in the cockpit if it’s loud enough.

2. You cannot use more than one start/end condition. The dataref logic is limited – if you really need something complex you can use a script-driven dataref. Most of our newer aircraft have XLua embedded so we can get simple derived logic easily.

PS I think Tyler may have finished and Chris is testing it now.

1. Is it possible that sounds that are routed into the `Interior` bus are nevertheless heard from the outside of the aircraft? Is that an intended behavior? That would mean that in order to hear those exclusively on the interior, we’ll have to add a snapshot to isolate them using `inside_ratio`.

2. The docs don’t specify if you can use more than one EVENT_START_COND or EVENT_END_COND. If that’s legal, what’s the logic? (and/or).

PS: Insert here obligatory nag about the starter project 🙂

Okay, I get it now. I was thinking that you had to name it with the dataref followed by the range (all in the name). It makes sense that it uses the range from the properties.

Thanks!

It’s not syntax. When you edit a parameter in FMOD, the numeric range are fields you fill in in the properties dialog box for the parameter. The only “text” you have to type in is the dataref name itself, similar to what you might have in an OBJ file or in some of the lighting fields in Plane-Maker.

This may sound stupid, but better to ask than to guess. What exactly is the syntax for this as far as adding the range?

Loading two Cessnas is not a problem. The sim recognizes the _same_ plane twice and avoids the double-load. It’s when you _copy_ that bank file that you get hosed.

Ben,
I’m not a developer but just curious about something from your post.
Does this mean that FMOD will stop me loading 2 copies of the C172 as AI planes? This seems it would duplicate those master buses.

Appreciate the lecture material, Mario, RE pro development.

However, for the FMOD aspect of X-Plane for *hobbyists,* payware sounds or recording same can be a burden too far.

Glad to hear at least the stock aircraft will eventually be updated to FMOD specs. I do hope that will be the case relatively early in the XP11 run.

Stock sounds can always be tweaked with the likes of Goldwave or Audacity to suit the tastes of a hobbyist or freeware developer, which is where my posts in this regard come from. Then again, how would I record XB-70 sounds if I ever wanted to release a payware XB-70?

FMOD Studio uses GUIDs to refer to all of its internal objects, including banks and all sound objects (events, buses, etc.). The GUIDs allow you to put a sound in two banks and not have it be loaded twice.

The uniqueness has to be handled differently in two cases:
– The buses in your master bank MUST match ours, so that they are not loaded a second time; if the master bus were to be loaded a second time, FMOD would fail internally because it can support only one master bus per program. If the various sub-buses were loaded a second time, your sounds wouldn’t be piped into our buses and the sound volume sliders wouldn’t work.

So the buses have to all match GUIDs. Buuuuuuuut…

– The master bank must be unique – otherwise when we load two planes, we get a failure to load the bank due to a duplicate GUID! This is why people cloning the C172 sound into other aircraft get a hard crash if the C172 becomes an AI for their aircraft.

Since some GUIDs must match and some must be different, we’re automating the edit process of producing correct banks..this should prevent user error, some of which can be hard to detect until it’s too late.