Difficulties with sound in GECK

[EPDGaffney]

I think you had one approach in mind and I had a different one, which is why the things I mentioned don't make sense in the context of the method you were considering. The method I suggested off the top of my head posed potential problems with mod compatibility. GetActivatorSoundActivate and similar functions would have been run on everything mod-added that could have used the sounds you were muting, not just doors or containers, in order to eliminate that problem. But again, it's a completely different method to the one you were considering.

 

I have a feeling the function (SetSoundTraitNumeric?) works but isn't working here because it potentially fires too late or is possibly being intercepted by changing between game mode and menu mode. I've had this problem in the past where you expect your event handler to work right before the event but it doesn't work in time. Which should never happen, was my understanding, but apparently some of them work that way (sometimes it's that the function called by the handler is too slow to work before the event, even if it gets called when it should). I'm almost certain one of my scripts in my quest mod uses it to mute sounds temporarily.

 

I had no idea the GECK's use info could be off like that. Kind of scary if you rely on it a lot, which I do. The method I suggested would still work regardless of that, though. At least, if I understand what you want to do, which maybe I don't. To me personally, this bug is so minor compared to some of the fundamental problems with this game that I don't really think it's worth your time unless you really want to fix it.

 

The JIP LN page would be a good place to try as well. Maybe Jazz can take care of it.

[Asterra]

I have a feeling the function (SetSoundTraitNumeric?) works but isn't working here because it potentially fires too late or is possibly being intercepted by changing between game mode and menu mode.

 

No, it turns out that it just wasn't documented well enough to account for its peculiarities, and parameter 3 in particular, for which a faulty example syntax is provided, is highly misleading. The Get for that parameter only returns a 0 to -100 integer, which turns out not to be what the Set will accept, in addition to being too inaccurate to revert the setting to default without guessing. (-6 vs. -6.17, for example.) If it gets changed to be more accurate in the future, that would actually potentially break my mod as I am currently coordinating it.

 

To me personally, this bug is so minor compared to some of the fundamental problems with this game that I don't really think it's worth your time unless you really want to fix it.

 

There's almost nothing left in the game that bugs me to the point that I wonder why nobody has tried fixing it. This genuinely is one. It may help to remember that there are two different kinds of double-audio bugs happening, one of which occurs even upon the first opening of a given container/door. So that affects everyone no matter how inattentive they may be. It would be laziness to fix one and leave the other broken.

 

For grins, I'll spend a moment trying to think of other things that bug me that nobody has tried (or succeeded at) fixing. 1) Sometimes when you draw a weapon, the draw animation gets interrupted and ends up playing twice in a row. Obviously this means it took that much longer to draw the weapon, which stinks if you like playing a speedy character with the relevant perks. 2) The Bright followers (83824 etc) almost always get stuck outside of door 840ac on the way down to the basement (happened both of my last playthroughs). That's really about it off the top of my head.

 

Edit: Fun fun. Latest stumbling block: Figuring out how to differentiate between a container/door that is and isn't already animating. Right now the activation works as fast as one cares to spam it, which obviously isn't going to fly.

Edited August 21, 2018 by Asterra

[EPDGaffney]

It only returns an integer? That's really weird. Is it possible that the list is wrong and parameter 3 is the frequency one and perhaps static attenuation is 2? Everything in the sound form looks like an integer except static attenuation, and the documentation does say it returns a float. That's a shame if it returns an integer there. That would definitely be something to mention on the JIP page.

 

Do you play this game in third-person? If you do, there's a world of problems. Aiming is somewhat impossible. Your character's feet move independently of their position on the ground, as if everything were a conveyor belt or ice or something. 'Grabbing' something means it hangs near you from a magic spirit thread until you press the button again. Your cursor is always a little off and you kind of need to use first-person to pick up items when there's a lot of them in the area (especially if you don't want them all). Besides that, in general, VATS can sometimes glitch horribly and get you killed for no reason, or just take ages between when you press the button and when it loads the shaders and information. Then there's among the worst optimisation in the history of games, the fact that it's not 64-bit, the issues with LOD, the pretty much broken lighting (much improved in several mods, but never to the standards that games had by that time), the rare bug I have where post-mortem dismemberment clones dismembered limbs each time the actor is loaded, and I could probably go on but I'm realising this is already really long. Apart from 'errors' like the above, there are many questionable design choices, whether a result of the rushed development or just questionable, but I don't think there's much reason to go into those.

 

Does GetOpenState not check what you need with the animation?

[Asterra]

That's a shame if it returns an integer there.

 

Well that wasn't even what had me scratching my head for hours. Take the SetSoundTraitNumeric example provided in the wiki. Set it to -4.85? If you try that, it will set it to 0. Why? Because it turns out it only accepts positive integers.

 

So now we enter off-topic territory:

 

Do you play this game in third-person? If you do, there's a world of problems.

 

Nothing patently intolerable, in my opinion. Unlike with Fallout 4. (Which mercifully isn't a game worth returning to.)

 

Aiming is somewhat impossible.

 

Not untrue, but I don't consider this dealbreaking. I don't expect the game to point my gun directly at something just because the camera situated behind me to my right is pointed that way; how is it supposed to know if I mean 5 feet away or 500? Basically what I'm saying is that I understand the concessions made to the vanity camera, and when it's time to aim, I go to first person. I swap back and forth all the time. I'm pretty sure there's even a mod that will do this automatically.

 

Your character's feet move independently of their position on the ground, as if everything were a conveyor belt or ice or something

 

I have almost never seen a game that took a solid stab at animating ground collision properly, and I don't think I've ever seen one succeed in the sense that it wasn't basically more awkward than the conveyor belt approach. Although now that you bring it up, I do have another for the pile: The character's feet don't animate when rotating in place in third person. They do when in first, so there was no need for this oversight.

 

'Grabbing' something means it hangs near you from a magic spirit thread until you press the button again.

 

So that's not realistic. I'd probably still take it over whatever mechanic they might have invented in order to legitimately wrap the player character's arms around something. (Let alone a modder's efforts at said.)

 

Your cursor is always a little off and you kind of need to use first-person to pick up items when there's a lot of them in the area (especially if you don't want them all).

 

Okay, yeah, this one. I don't see how hard it could be to make it so whatever pixel the cursor is aiming at is the item you're wanting to pick up. And fair's fair: I bet some modder could make this happen.

 

Besides that, in general, VATS can sometimes glitch horribly and get you killed for no reason, or just take ages between when you press the button and when it loads the shaders and information.

 

Yeah, VATS. I think it's actually only New Vegas (not FO3) that does that thing where VATS thinks about it for about 8 seconds before finally giving you a body part. Other complaints: 1) No solid pattern of control for moving from one body part to the next -- especially confounding on arthropods for some reason. 2) Targets that are too close will not get hit at all. 3) Cannot interrupt VATS once committed, so if you hit an invisible wall, too bad. Last one is less a complaint about committing to VATS and more one about hitting invisible walls.

 

Then there's among the worst optimisation in the history of games, the fact that it's not 64-bit, the issues with LOD

 

Ultimately, most of your issues don't, to me, fall nicely into what I would call the "open to improvement" category. Not without DLL-level shenanigans. I was really only referring to things that I imagine I or someone else could mod. As it happens, I think all three of the things I mentioned about VATS could probably be corrected by some clever modder. But they're each the kind of mod I'd personally have no solid footing with if I tried myself, so I don't think about it.

 

Does GetOpenState not check what you need with the animation?

 

That should do nicely (knock on wood). I was just taking advantage of your knowledge so I didn't have to personally hunt for it.

 

Edit: Maybe I am a glutton for punishment, but now that I have this in hypothetical working order... I am thinking about forcing weapon arm/disarm/wield/unwield/reload/etc. sounds to be positional in third person. As it is, they originate as mono 2D, which is irksome.

Edited August 21, 2018 by Asterra

[EPDGaffney]

So it doesn't accept negative numbers. Well, that really needs to be mentioned.

 

I found Fallout 4's third-person mode much more natural. It was absolutely the only thing I liked about the game. And it still wasn't up to the standard of other games with a third-person camera.

 

Third-person OTS aiming has been functional in games for ages now, and it's probably my biggest problem with this game. Games like Resident Evil 4 and Mass Effect and gears of War managed it with no problem. But you're right, there is a mod that goes into first-person when you aim. And I made it. Still, I'd prefer a mod that could make it so that aiming in third-person were possible. I may try my hand at that one day. I know I could make a RE4-style laser mod if I really wanted to. I just kind of don't think it fits with the game lore- and æsthetic-wise. The other approach would be to adjust the camera for aiming based on a lot of factors. It's certainly possible, and I may do it one day, but it would just be an absolutely immense amount of work.

 

Games that use root motion look better and most of them feel better. Even the '90s-era Resident Evil and Metal Gear Solid games have better-looking foot placement.

 

I was really only referring to things that I imagine I or someone else could mod.

Ah. I thought you were saying this sound thing was the last thing that really bothered you, whilst to me all these things are much bigger problems, not to mention the design choices I didn't go into. Fortunately, Unofficial Patch Plus does include a VATS cancel button. I forgot about that actually, where you can just waste all your AP on an invisible wall despite having a 95% hit chance. I mod more than I play now, and I barely use VATS at this point, but when I do, I keep that cancel key handy. I use VATS to have the game draw enemies in the distance so that I don't walk into a raider swarm during mod testing. So it would be nice if it didn't take 8 seconds to load a body part. If it wasn't like that in Fallout 3, I hope someone can eventually take care of it in New Vegas. I think I seen Axonis theorising about how to do it.

 

The 2D sounds you mentioned are just one more way this game was not intended for third-person, and that's a huge over-arching problem I have with it. Fortunately, I play with the camera zoomed in really close, so I get the same illusion they intended for first-person. But it would be a nice thing to fix.

[Asterra]

I found Fallout 4's third-person mode much more natural. It was absolutely the only thing I liked about the game.

 

Fallout's third-person is an exceptional failure because under many circumstances (technically most), mobility is slower in third-person than in first-person. I put together a mod at some point that addresses this. I discovered that some aspects couldn't be fixed whatsoever. Good example: Power armor has a hard cap on mobility that cannot be exceeded in third-person, which ends up causing a certain upgrade (grease?) to have absolutely no effect. Basically, with an essentially new engine, Bethesda allowed a ton of third-person flaws to go unnoticed and certainly uncorrected. I 99% guarantee you they'll still be there in Fallout 76, too.

 

That said, they got the camera right. No more arbitrarily forcing the character to rotate forwards the moment one stops moving.

 

I use VATS to have the game draw enemies in the distance so that I don't walk into a raider swarm during mod testing.

 

I was just thinking, a few hours ago, about a mod I'm confident nobody would ever download, but one which I could still envision making for myself. It would limit VATS to work only on targets that are both in radar range and in one's field of view. The point would be to eliminate the temptation to abuse the VATS mechanic to make travel risk-free and destroy the purpose behind Perception. Along the same lines, I had plans to make it to where you had to have, like, 5 Perception in Fallout 4 if you wanted VATS to automatically pick up on land mines, since I felt that was a completely unnecessary addition to the VATS system. But yeah, I don't look at FO4 anymore.

 

If it wasn't like that in Fallout 3, I hope someone can eventually take care of it in New Vegas.

 

I tend to go back and forth between the two games so I'm pretty sure it's a NV thing only.

 

Fortunately, I play with the camera zoomed in really close, so I get the same illusion they intended for first-person. But it would be a nice thing to fix.

 

I use headphones, and furthermore have started using the 3D positional mod which exacerbates the problem. That's probably why I finally noticed that armor rustling sounds play in mono. But yeah, weapon sounds, armor sounds, standing and ducking... Basically if it isn't feet hitting dirt, it's most likely dead-center, and that incongruity between footsteps and everything else is annoying enough that I have to seriously consider trying to fix it all, even though there's plenty of reason to suspect it will be too much work. Sure would be nice, just as an example, if I could set up event registration for something like standing/ducking.

[EPDGaffney]

I don't think I played Fallout 4 long enough to realise most of that, but I'm not surprised. And I never use power armour anyway. I want to do it in NV at some point, but I've never done a playthrough with it in any Fallout game.

 

I think the Game Setting variable fVATSMaxEngageDistance is what governs how far away VATS works. You can alter that via script based on Perception (or whatever else you want). Just remember that those don't save with the save data and will need to be reconfirmed every time a game is loaded. Sounds like a mod I would like. I mostly use VATS as I do now because I'm testing my work, but I'm making an anti-HUD mod right now, which ideally will make things like binoculars more important. Also, the compass is going to be an AP-draining item that you turn on and off. Most of the mod will be modular and optional in case you don't like that concept, but so far I've really enjoyed the tension of having no compass.

 

Another idea I've had is to make simply going into VATS drain AP. Coupled with a mod that increases AP drain per use, that could make things much more interesting. Another one was to make AP function like HP, and not refill unless you take something like Jet, which would in this circumstance restore your AP by 15 or 30 and never take it away unless you use your AP for something.

 

Ah, see, my girlfriend and I usually play New Vegas together on a big television, or I'm mod-testing with barely any volume, so these things don't actually bother me much. I kind of gave up on New Vegas years ago regarding sound. I just chalk it up to the game having a gigantic number of quirks that I ignore if i don't want to go mad. The game's good points are worth that for me. If you fix it, though, I'm sure I'd be glad to use said fix.

 

Could you not just use SetOnControlDownEventHandler with crouching and an IsSneaking check to confirm the player is actually crouched?

[Asterra]

I don't think I played Fallout 4 long enough to realise most of that, but I'm not surprised. And I never use power armour anyway. I want to do it in NV at some point, but I've never done a playthrough with it in any Fallout game.

 

This goes for me as well, truth be told. But fair enough. The same exact bug limits the mobility of unholstered sneaking. The limit is the speed at which you move without any mobility mods. Meaning mobility mods don't make you sneak any faster unless you've also drawn your weapon. And this is a bit ironic since there are armor mods specifically intended to speed up sneaking.

 

Could you not just use SetOnControlDownEventHandler with crouching and an IsSneaking check to confirm the player is actually crouched?

 

Seems like a good start. But I assume I would then need to watch for confirmation that sneak/stand has begun, and then hastily play the sound. Same deal with the multitude of weapon sounds. A year ago I'd probably do it. I have less time now.

[EPDGaffney]

You'd just need to set the event handler in a pre-load script, and then in the UDF for the handler, have something like

If player.IsSneaking
    player.PlaySound3d <Sound>
Else
    player.PlaySound3d <Other Sound>
EndIf

With OnControlDown/Up, it seems to account for menu mode as well, but you should test that to make sure. Of course, if you want to support controllers, this ruins everything. OnControlDown/Up don't detect controllers. Download my Aim View Switcher mod and look at the code that accounts for that disastrous void. It's disgusting. I may have thought of a workaround using SUActn however. I recall SUActn returning gamepad buttons, and if it does, I'm going to test with that. But it still won't automate accounting for several things OnControlDown does, even if I don't need to make players synchronise my mod with their game settings manually (which is extremely annoying for me to code and probably not too thrilling for them to be subjected to, either).

 

There are animation event handlers as well, but I didn't have great luck when I tested them briefly. They probably work fine if you know what checks to use, but i opted for something else at the time and had no need to test further. The advantage would be, obviously, that controllers and keyboards could all use the same scripts and it would work for everything without much extra work on your part.

[Asterra]

OnControlDown/Up don't detect controllers.

 

Ugh. Sounds like a job for a very low quest delay.