Difficulties with sound in GECK

[EPDGaffney]

That's the most current list of functions, whilst most other lists are unfortunately outdated or otherwise incomplete. I know this because that's my page and I have JIP LN tracked in order to add the new functions as Jazz releases them.

 

On the NIF level, if you knew what to do, it's possible you'd be editing the sound files for the footsteps or scripting an automated process via the NIF functions added by JIP, or that the sounds are attached to the animations and not the skeleton, or if they are attached to the skeleton, that they're attached to the main skeleton file and not the individual armours. I've made armours and have never touched anything like this or seen it suggested, so I have a feeling that's not where any audio information is located. I think it's in the animation files.

 

I think that if the player can be a radio, that's your best choice. I know it sounds weird, but I can see that going extremely well. An IsSoundPlaying script could work, but may be more performance-intensive than a radio station. Though it shouldn't be that bad if it's just checking for a sound every .2 seconds or whatever it would be.

 

I see a ToolCabinetMetal base form with an ID of 35EA, not 35AE. But it has no sound attached to it, so I'm not sure how you found the one that it plays.

 

However, I looked at the NIF and there is indeed a sound there:

https://prnt.sc/kk4vx5

 

I need to head out now, but maybe that can help you to find something. If not, PixelHate probably knows more.

[Asterra]

I see a ToolCabinetMetal base form with an ID of 35EA, not 35AE. But it has no sound attached to it, so I'm not sure how you found the one that it plays.

 

By guessing and then listening to make sure.

 

However, I looked at the NIF and there is indeed a sound there:

https://prnt.sc/kk4vx5

 

There it is. Good.

 

I've fiddled with it now. The problem is either fundamental to the game engine, or a flaw in the NIF format itself. Any sound tied to the first animation sequence gets double-played in-game if the same container is re-opened. Every single time. This does not happen to the closing sound. The only thing that differentiates the two is that in the NIF's controller sequence, the "Open" sequence is first, meaning it is the thing that gets played after the entire set loops. It could be the flaw is specifically tied to the sequence loop, which would explain why the opening sound doesn't double-play the first time one opens the container.

 

I believe that's as far as I can take this one. I'll see if PixelHate might have some insight. Thanks.

[EPDGaffney]

I take it deleting the sound entirely yields complete silence? indicating it is indeed doubling that sound entry, and that the sound is not selected in two places.

 

It could be in the NIF flags, or it could have something to do with the fact that the engine is entering menu mode for the opening sound, whilst for the closing sound, it's going into game mode. You can test this by making a door form using that model, rather than a container form.

 

PixelHate is to my knowledge the most likely source of further information on this forum. However, there are a lot of people that may be able to help if you asked on the NifSkope forum or Discord. Forgot about that. The developers of the software may even drop by to answer your question.

 

Obviously, if it's more to do with the engine than the NIF, then someone like Roy Batterian is more likely to know what's going on than a NIF expert. You could try posting in the YUP comments as those are frequented by Roy, Sandbox, and a few other people that may know what to do about this if it's an engine peculiarity.

[Asterra]

I take it deleting the sound entirely yields complete silence? indicating it is indeed doubling that sound entry, and that the sound is not selected in two places.

 

Yes indeed, and the sound does vanish outright. Though I'll point out once again that there are a few open/close sounds in the game (ammo boxes and doors) that also have GECK entries and so have their very own (but at least fixable) double-sound playing problem.

 

You can test this by making a door form using that model, rather than a container form.

 

No need. As mentioned before, doors that animate have the same problem.

 

Obviously, if it's more to do with the engine than the NIF, then someone like Roy Batterian is more likely to know what's going on than a NIF expert.

 

My best guess is that this is an engine problem, but also that someone with adequate Nifskope expertise could soup up a workaround. Perhaps by somehow finding a way to keep the animation from reaching the end (and thus looping) during the close sequence.

 

Edit: A really awful workaround that would probably get the job done would be to eliminate the open sound from the NIF, and then just play the sound on activate. Would have to drop an emitter each time.

Edited August 20, 2018 by Asterra

[Deleted1205226User]

You seem to be right with your best guest.
My experience is with FO3 mainly but I suspect the problem hasn't been solved in NV.

Containers and doors with animations will have a doubled sounds when opened while static ones don't.
The double sound isn't occurring at the first activation, that's why it isn't noticeable in game (you often activate these only once).
When the door or container is activated several times, the doubling sound occur.

In these nif there's a sound referenced, the same sound is also referenced in the GECK Edit window.

If you remove one of these reference, the sound isn't playing. At least, that's how it reacts in FO3.

The workaround is, indeed, to play the sound via script OnActivate.
For some reason, in my experience, the sound isn't playing at the first activation but play fine after that.

So it's one annoyance or the other ... (and not the only one sound related)
I can't wait for a Wizard to fix it.

Maybe in JIP there's is a function that could help, but that's not my field.

[Asterra]

The workaround is, indeed, to play the sound via script OnActivate.

 

After quite a bit more fiddling with the sound data in some meshes, I regretfully came to this conclusion myself, though I really didn't want to get on with it because I remembered from an earlier mod of mine (Empty or Not Empty) that it would be an almighty pain. There are 700 individual container entries affected by one or another flavor of this bug, depending on their meshes and their sound data, and I would need to figure out what sounds go to which, for all of them. A gargantuan workload.

[EPDGaffney]

There probably aren't that many opening and closing sounds, so if you really wanted to do this, you could move them all to a different folder so that the models can't access them, replace them with mute files, then at game launch script all affected containers (I believe it's anything with an open/close animation?) to become part of a form list (or several form lists broken down by model) and then set an OnActivate event handler for that form list. Your OnActivate event can use a new sound form that points to the new location of the sound files. Any mod-added forms that use the sounds (which all have 0 uses in the vanilla game according to the GECK) can be accounted for using the relevant JIP functions, added to an array, and then looped through to point them to your new sound form.

 

There could be a cleaner way if you refine what I said there, but the general concept would work and would not involve changing everything by hand. JIP LN added RunBatchScript, but it doesn't look like what I would expect. If it did, I'd suggest asking for some NIF scripting help that you could use to do a batch script for New Vegas to run at launch. Other ideas could include turning NIFs into text files and grabbing strings from them, but whilst it sounds plausible, I don't know how to do it. Someone at the forums or Discord may, though.

 

Oh, you're the Empty or Not Empty author! I actually did some work on that mod for someone. Quite honestly, I believe it was something with their load order, as opposed to anything your mod should have affected (I couldn't reproduce the problem myself). But I'm not sure what part of it caused you to have to do anything by hand. To fix his problem, I just remade the mod from scratch. I added an item to every actor and container base form at game launch, then took it away with an OnActivate event handler using the player as a filter. The complication there was the item was appearing in barter menus, which I solved by turning it unplayable in that situation. None of it really took much time to do (well, besides the bit where I had no idea that a merchant's owned items will always appear in their inventory if the references are in the loaded cell).

[Asterra]

There probably aren't that many opening and closing sounds, so if you really wanted to do this, you could move them all to a different folder so that the models can't access them, replace them with mute files, then at game launch script all affected containers (I believe it's anything with an open/close animation?) to become part of a form list (or several form lists broken down by model) and then set an OnActivate event handler for that form list.

 

I am leaning towards muting the sounds, yes. It depends. I still need to analyze each of the 700 containers to ensure that either their associated sounds are never referenced by GECK (not a safe assumption), or that any references I do find won't prove too much of a complication. That is basically step #2 and it is a big one. Not going to do multiple lists since it would introduce unneeded extra steps, and also since I already have the necessary list from my past mod.

 

There are always complications. The very first entry in the list, for example. It points to an oven. When you open this particular container, you actually get two sounds: One that comes from the mesh, and one that is tied to the container form. Now, this phenomenon is normally what is responsible for one of the sound-doubling problems on certain containers and doors. But in the case of this oven, its effect is intended: The two sounds are actually different, and it makes a certain sense that you'd hear one from the 3D object and the other as a 2D menu sound. I didn't anticipate this and will need to bear it in mind going forward. Just an example of complications.

 

Your OnActivate event can use a new sound form that points to the new location of the sound files. Any mod-added forms that use the sounds (which all have 0 uses in the vanilla game according to the GECK) can be accounted for using the relevant JIP functions, added to an array, and then looped through to point them to your new sound form.

 

This part sounds interesting but I don't immediately know which functions would accomplish it. Nor how this wouldn't bring me back to square one, since after all the meshes provide the names of the sound forms and if those forms suddenly point to real audio files again, the meshes will again be able to play them. I was more or less just going to ignore the possibility of other mods using the sounds, or, at most, make a compatibility patch, since the likelihood was extremely low.

 

I added an item to every actor and container base form at game launch, then took it away with an OnActivate event handler using the player as a filter. The complication there was the item was appearing in barter menus, which I solved by turning it unplayable in that situation. None of it really took much time to do (well, besides the bit where I had no idea that a merchant's owned items will always appear in their inventory if the references are in the loaded cell).

 

This approach would have saved me a lot of headache, and in hindsight I probably would have done it that way if it had occurred to me, but what I eventually put together is, to me, the more idealized result, since it avoids directly tinkering with fundamental components of the game (running the risk of confusing another mod), along with the need to add to the JIP glut when starting a game.

[EPDGaffney]

Well, you can see what's referenced by GECK with Use Info, and you can use the Find Text feature from the Edit button menu on the top toolbar, so I don't think that should be a problem. I wouldn't really expect any mishaps there, save for mod-added items, which is why I mentioned looping through those. I suggested multiple lists organised by model because you want each model to have a different sound and the GECK can't see which mesh uses which sound but it can see which form uses which model. But I suppose you can just do a bit of If and ElseIf and work it out in the script instead of the form lists. Shouldn't be much worse for performance.

 

The functions I was talking about for looping through mod-added items are things like GetActivatorSoundActivate, which checks whether that sound is one of the ones you've muted, and then you point it to a new copy if it is, using the Set counterpart. This is done at the game level rather than the mesh level, so it wouldn't pick up anything used only by a mesh. If you know how to use string variables and arrays, this doesn't have to be a gigantic performance issue, though it would still only be for a moment at game launch, not during actual gameplay.

 

I do actually use sounds like these in my mods, as I initially had assumed nothing was using them, so my quest mod has a lot of instances where sounds like these were selected for certain events. Maybe that was a mistake, but if I were going to make a mod like this, I'd try to account for it.

[Asterra]

I suggested multiple lists organised by model because you want each model to have a different sound and the GECK can't see which mesh uses which sound but it can see which form uses which model. But I suppose you can just do a bit of If and ElseIf and work it out in the script instead of the form lists. Shouldn't be much worse for performance.

 

Going to use separate form lists and use the key from one to dictate the key from the other. I've done this in past mods. I already know there is no issue with huge form lists; they are parsed instantly.

 

 

The functions I was talking about for looping through mod-added items are things like GetActivatorSoundActivate, which checks whether that sound is one of the ones you've muted

 

Still not quite following this. For starters, I haven't established how I will be muting the sounds. I thought I had hit upon the perfect solution: Use the JIP function to tweak static attenuation to -100 at the moment when the container is opened. Unfortunately, the JIP function in question seems to not work at all, at least for that parameter. If I edit the sound entry in GECK, it gets muted as expected. Anyway, I don't get how checking GetActivatorSoundActivate has anything to do with sound forms (or container forms for that matter). Seems to be something used to investigate activators, such as broc flowers.

 

I do actually use sounds like these in my mods, as I initially had assumed nothing was using them, so my quest mod has a lot of instances where sounds like these were selected for certain events. Maybe that was a mistake, but if I were going to make a mod like this, I'd try to account for it.

 

Okay well, just as an example of open/close sounds being referenced in GECK despite what GECK insists about use count: Take a look at OffDoorSmL01 159A6. It uses sounds DRSWoodOfficeDouble01Open 1EA6A and DRSWoodOfficeDouble02Close 1EA69. But neither of those sounds have any use info. So that data cannot be trusted in these cases.

 

Incidentally, that door is a good example of one of the variants of the double sound problem. The door's mesh uses sounds DRSWoodOfficeSingle01Open 1E995 and DRSWoodOfficeSingle01Close 1E994. Note the difference. What happens is the mesh-specified sounds play in 3D space while the GECK-specified sounds play simultaneously (and redundantly) in 2D. In cases like these, the GECK entries will need to be modified, on top of whatever is ultimately done with the mesh's opening sound.

 

Edit: I've decided my best bet is to pursue the apparent bug in JIP and hope it gets looked into. I'll be making a post in its thread.

 

Edit2: I figured out how to make the function happy. It will work, but for example the wiki is patently wrong on how to use it, and also the value retrieved with Get has to be essentially translated into something usable.

Edited August 21, 2018 by Asterra