# GetParameterDescription called in Construction Script (Or OnConstruction in C++) returns empty array when running in a packaged build

**URL:** https://qa.fmod.com/t/getparameterdescription-called-in-construction-script-or-onconstruction-in-c-returns-empty-array-when-running-in-a-packaged-build/15300
**Category:** Unreal Engine
**Created:** [December 9, 2019, 8:14pm UTC](https://qa.fmod.com/t/getparameterdescription-called-in-construction-script-or-onconstruction-in-c-returns-empty-array-when-running-in-a-packaged-build/15300 "2019-12-09T20:14:42Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![paras238](https://avatars.discourse-cdn.com/v4/letter/p/5f8ce5/32.png) [@paras238](https://qa.fmod.com/u/paras238)
#### Post date: [December 9, 2019, 8:14pm UTC](https://qa.fmod.com/t/getparameterdescription-called-in-construction-script-or-onconstruction-in-c-returns-empty-array-when-running-in-a-packaged-build/15300/1 "2019-12-09T20:14:42Z")

</div>

Hi  
I’ve been struggling with this for a while now.  
The GetParameterDescriptions function in UFMODEvent is supposed to return an array of type FMOD\_STUDIO\_PARAMETER\_DESCRIPTION.  
I’m trying to get FMOD parameter names in the construction script. When I call GetParameterDescriptions in the construction script, it populates the array fine and the values stick when playing in the editor. However, when playing in Standalone or in a packaged build, the array comes out to be empty.

Is there something I’m missing here?

---

<div class="post-metadata">

### Author: ![cameron-fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/cameron-fmod/32/261_2.png) [@cameron-fmod](https://qa.fmod.com/u/cameron-fmod)
#### Post date: [December 16, 2019, 10:44pm UTC](https://qa.fmod.com/t/getparameterdescription-called-in-construction-script-or-onconstruction-in-c-returns-empty-array-when-running-in-a-packaged-build/15300/2 "2019-12-16T22:44:08Z")

</div>

It looks like `GetParameterDescriptions` was not intended to be used outside of the editor, which is why it does not work in Standalone or a packaged build.

The issue is the `EFMODSystemContext` in this line of `UFMODEvent::GetParameterDescriptions`:

```
FMOD::Studio::EventDescription *EventDesc = IFMODStudioModule::Get().GetEventDescription(this, EFMODSystemContext::Auditioning);

```

The fix should be as simple as changing it to `EFMODSystemContext::Max`, this will then use a valid FMOD System at runtime.

I have added a task to implement this fix for an upcoming release.

---

<div class="post-metadata">

### Author: ![DenizSelim](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/denizselim/32/9822_2.png) [@DenizSelim](https://qa.fmod.com/u/DenizSelim)
#### Post date: [April 22, 2026, 1:40pm UTC](https://qa.fmod.com/t/getparameterdescription-called-in-construction-script-or-onconstruction-in-c-returns-empty-array-when-running-in-a-packaged-build/15300/3 "2026-04-22T13:40:01Z")

</div>

Hi,  
I am facing the same problem, I can’t get event parameter descriptions in packaged build, before I go ahead and modify the function from the plugin in my project, is this the only solution there is? is there a good reason for keeping the EFMODSystemContext as Auditioning?  
I need the event parameter descriptions so I can check if an event accepts a specific parameter before trying to use SetParameter. If there is a good reason for hiding these descriptions in Packaged builds maybe I should find a different solution to my problem

---

<div class="post-metadata">

### Author: ![cameron-fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/cameron-fmod/32/261_2.png) [@cameron-fmod](https://qa.fmod.com/u/cameron-fmod)
#### Post date: [May 3, 2026, 5:23am UTC](https://qa.fmod.com/t/getparameterdescription-called-in-construction-script-or-onconstruction-in-c-returns-empty-array-when-running-in-a-packaged-build/15300/4 "2026-05-03T05:23:12Z")

</div>

I don’t think there is a good reason to exclude this from a packaged build, we will have to investigate to make sure there isn’t a reason for it. This task is still in the backlog but I will give it a bump to see if we can get it changed sooner.
