Song 'N' AssumedPseudonym's Superior Sounds

[Song]

SNAPSS is currently not compatible with 1.7a2. George changed something that broke missile sounds entirely and while AP seems to know what's going on, he doesn't yet know how it can be fixed. A new release will be made when the issue is worked out. This will probably also include a steam release via workshop.

[TheLoneWolf]

great

[AssumedPseudonym]

 Basically, what I need is a way to access the launcher item in events. aWeaponUNID returns the ammo fired rather than the launcher, and it’s usually the launcher that has the sound effect defined. Getting the launcher type from the ammo fired won’t cut it because some ammo can be fired from multiple launcher types.
 What I really need to get SNAPSS working well, though, is for the caching issues to be fixed in the engine and for sysPlaySound to accept a repeat value.

[NMS]

It would be even better if repeating weapons triggered Events with each shot. But in the mean time, you could get the sound to repeat with something like this:

Code: Select all

(setq theStation (sysCreateStation &stSoundEmitter; nil))
(objSetData theStation 'sound theSound)
(objSetObjRefData theStation 'shooter theFiringShip)
(for i 1 (add repeatCount 1)
	(sysAddObjTimerEvent i theStation 'PlaySound)
)
(sysAddObjTimerEvent (add repeatCount 1) theStation 'DeleteMe)

where stSoundEmitter is a virtual station with this event:

Code: Select all

<PlaySound>
	(block (theShip)
		(if (setq theShip (objGetObjRefData gSource 'shooter))
			(sysPlaySound (objGetData gSource 'sound) theShip)
		)
	)
</PlaySound>

[AssumedPseudonym]

 I had considered something along those lines, myself, albeit using a more kludgetastic implementation. I mostly hadn’t started on it because bluh. ¬.¬;
 I might yoink that code and tweak it as necessary. You’ll get a “special thanks” in the credits if I do.

[NMS]

So it turns out the problem with ammo weapons playing the wrong sound was not due to a change in aWeaponUNID, but a bug introduced in typGetProperty.

Hopefully it will be fixed soon, but in the mean time, you can avoid it by using itmGetProperty instead.

[AssumedPseudonym]

...Really, now! If that's the case, I just might be able to patch SNAPSS up when I get back home after the weekend. It'll be a good excuse to test coding in something for repeating weapons, too, since I still need to do that. Thanks muchly. ^.^

[NMS]

I had this email exchange with George before discovering the new info:

From: Nathaniel Stalberg
Sent: Wednesday, October 5, 2016 1:11 PM
To: George Moromisato
Subject: A couple questions

Hi, George. I noticed that you fixed one of the issues related to SNAPSS. I was wondering if the others are high on your todo list. I have some ideas for how to partially work around some of the issues, but they're a bit complicated and hack-ish, so I don't want to get into it if you're likely to resolve the underlying engine problems/missing features soon. Also, If you're likely to make the game save the XML when using typCreate, I'd probably redo it using that instead.

Secondly, is there any problem (such as memory leaks) associated with repeatedly creating and destroying virtual stations (e.g. every time a repeating weapon fires)? If there is, I could probably save them to a list and reuse them, but it would be more complicated.

Thanks!

Nathaniel

George Moromisato Oct 5 (3 days ago)

The bugs on your master list that I’m very likely to fix for the next release (ETA one/two weeks) are:

Variable to get launcher UNID: http://ministry.kronosaur.com/record.hexm?id=57968
Projectile data: http://ministry.kronosaur.com/record.hexm?id=56192 (at least owner, target).
Repeating fire triggers: http://ministry.kronosaur.com/record.hexm?id=56596

I probably won’t get to the XML save in this release—I’m always wary of touching that code because it affects lots of things.

There should be no problem with creating/destroying virtual stations. Destroyed stations may hang around for a tick (until we’re sure no one is referencing them) but then get de-allocated at the beginning of the following tick. But you might not need it if you get repeating fire triggers.

-- George

So if you feel like it, go for it, but the virtual station workaround for repeating sounds should be unnecessary soon. The incorrect sound bug can be fixed with a simple find/replace: typGetProperty -> itmGetProperty

[AssumedPseudonym]

Groovy. I'll just chill until the end of his next Ministry run and see what needs patched up after that. Thanks again. You definitely get a special thanks reference on SNAPSS. ^.^

[AssumedPseudonym]

 Okay. Apparently George fixed the whole weapon-sounds-only-fire-once bug — which is awesome, one less thing for me to fix; thanks, Boss — but yeah, there’s still the whole thing with launchers. I’m finally getting enough of a break with assorted RL that I should be able to dig into that and do something about it. If I’m really lucky, I’ll even be able to toss George a PM advising him to download an updated version before his stream this Thursday.

[NMS]

That should be fixed, too. This was the problem: http://ministry.kronosaur.com/record.hexm?id=59632

I tested the DK10 and NAMI and Makayev launchers, and they all work for me. Although, I guess I'm still using a modified version of SNAPSS with all the typGetProperty calls replaced with itmGetProperty. That shouldn't matter anymore, but if it isn't fixed for you, I'll reopen the ticket.

[AssumedPseudonym]

 Meanwhile, weeks of RL later, I finally got around to testing things. The off-the-shelf version of SNAPSS seems to work just fine in the latest beta. Just for good measure, I even tested it with the latest SM&M++ to see if it behaved with the Minotaur. It does.
 …And that, ladies and gentlemen and other assorted individuals, is how you write a mod: Don’t rework valid code on your end to work around engine bugs, bother the developer until he fixes the bugs in his code. ^.~ …Seriously though, thanks, Boss. Now that sounds are firing properly, we might actually be close to calling this a beta instead of an alpha. And thanks to NMS, while I’m thinking about it. He’s the one who was finding the bugs in the engine to point George at. I have no idea how long it would have taken to find the whole typGetProperty/itmGetProperty issue without him.
 On that note, most of my work on this is probably going to be fairly minimal from here on out. Unless we follow though on a few ideas we had about possibly redoing shield and armor hit sounds in a similar manner to the weapon sounds, the coding on this should pretty much stand as-is. Shrike, you’re in charge of the audio side of things; this is pretty much in your hands at this point.

…Oh. Right. PM, anything of yours that uses sysPlaySound (like your zapsats, for instance) to manually fire &snLaserCannon; is probably working properly, the real issue is that the WAV file it points to now is a silent WAV. If you want compatibility with SNAPSS, you can probably get around it with something like:

Code: Select all

(sysPlaySound (if (typGetProperty soundHexUNIDfromSNAPSS 'unid) soundHexUNIDfromSNAPSS &snLaserCannon;) sourceObj)

 It would just be a matter if sifting through the sounds, finding the appropriate one, and digging its hex UNID out of the source code. We won’t be changing those unless this winds up getting made into an official expansion on Multiverse, anyway, at which point we’d need to update the prefixes, so using them shouldn’t break anything. Also, if anyone else is using sysPlaySound to play one of the vanilla weapon sounds, take notes; you’ll run into the same thing if you try to run SNAPSS. Compatibility issues is the number one reason I hate doing overwrites in mods.

[Song]

Alas, overwrites are the only way to do this right now. Personally I'd prefer convincing George to update the sounds in the game using these over making SNAPSS registered...it's a clever solution to a problem (bad sounds) that has far easier ways of fixing it.....for the developer who can just alter things in Core.


I'll start mixing new sounds, see what I can come up with, and then bug AP about what might need adding. Then we can go to Alpha 2 (we're still adding things, therefore it's an alpha).

[digdug]

So, if I want compatibility with snapps, I simply have to not sysplaysound with a vanilla sound unid ?
In that case modders can simply add the vanilla sounds with another unid to not break their mod ?
I would like we6 new sounds to be fully compatible with snapps if possible.

[AssumedPseudonym]

So, if I want compatibility with snapps, I simply have to not sysplaysound with a vanilla sound unid ?
In that case modders can simply add the vanilla sounds with another unid to not break their mod ?

 …That’s actually a good idea, too, yeah. That would work; I hadn’t thought of that. I suppose that’s what I get for typing up a post at stupid-o’clock-in-the-morning, heh.

I would like we6 new sounds to be fully compatible with snapps if possible. :)

 They should be. I have SNAPSS coded so that it only plays SNAPSS sounds for weapons that use vanilla sounds. This has been tested and verified with TSB, TBR, Cabbage Corp, and Foomerians, all of which have non-vanilla-sound-using weapons. So yeah, WE6 should be fine.