RipSound

[Zippy]

One also presumes that if the other primary developer were to find some interest in this, he could easily chime in. Even if the thread were, you know, locked. So, Graf expressing an opinion as a senior developer hardly seems like a problematic thing precisely because it fails to prevent Randy from acting if he wanted to.

With regards to ripping projectiles it is pretty clear that there are arguments for the sound being tied to either actor. You'd expect robots and demons to make different noises when being torn apart. You'd also expect a chainsaw missile and a laser weapon to make different noises tearing through flesh. But I agree that complex solutions seem a little overblown for something that probably won't see much use. A simpler solution of maybe just having a priority (e.g. projectile's RipSound takes priority over an actor's RipSound or vice versa, just a defined behavior) would probably cover most needs.

[NeuralStunner]

I actually had this same essential idea a while back, I was considering lightning bolts that "zap", fireballs that sizzle, etc. I was thinking of it originally as missile outranks actor, so to speak. (Though I guess if you work off of the assumption that actors are fleshy by default, it is not as big a deal.)

I wouldn't expect more than one "rip" sound would be needed for each actor. And failing either having their own, it would use the default common rip sound anyhow.

Hopefully this would not be too much of a pain to implement.

[Graf Zahl]

No, that wouldn't be too hard. But seeing some people starting to make suggestions to blow this out of proportion instead of trying to find a solution that works for everyone was not a good sign.

[Kinsie]

Graf, is this YOUR goddamn source port?!

Yes in part, actually.

[Snarboo]

Tying it to the actor being ripped makes sense but so does using it on a projectile. How about any RipSound property works like it does for other sound effects: it can be defined for both actor types but it has different effects. If a monster/player/what have you has a RipSound, that is the sound played when the actor is ripped. If the projectile has a RipSound, that takes priority and is played instead of a monster's rip sound.

This way you could define two rippers that make different sounds depending on what they are, say a needle or lightning bolt. It would be inappropriate if the lightning bolt sounded like it was tearing through flesh or the needle sounded like it was electrocuting something. You can still use inheritance with this method if you want all monsters to make the same sound when ripped.

[Cutmanmike]

This may not be desirable but isn't there a way to give custom blood types depending on what damage is done? Off the top of my head I can't remember if that's possible but if you could you could give the ripping projectile a separate damage type and have a new blood make sounds and do whatever the fudge you please. You could make as many ripping projectiles all making different noises as you please OR define what blood to spawn to make the sound in the actor. If not then maybe it would be worth requesting that, as it would solve this little issue.

Edit: Okay it looks like you can't and bloodtype also has a few other parameters I wasn't aware of. Not sure if it's worth adding an extra damagetype parameter to that or making a new property altogether to deal with this.

[Graf Zahl]

Forget it. This is so rarely used that so much customization would be overkill.

[Ichor]

Heh, I don't blame you. This was not one of my better ideas. Besides, I think I know of a way around this: a projectile that uses A_LookEx with a range that extends only as far as its radius, and "attacks" by playing the sound as long as the target is within range (i.e. while it's ripping through the target).

It still needs testing though, but I think this could work.

[Cutmanmike]

It could but a monster's sight is not limited to what's near it, i.e if you shot that ripping projectile above a monster it would still "see" the monster and make a noise. I've played with this kind of crap before

[Major Cooke]

Heh, I don't blame you. This was not one of my better ideas. Besides, I think I know of a way around this: a projectile that uses A_LookEx with a range that extends only as far as its radius, and "attacks" by playing the sound as long as the target is within range (i.e. while it's ripping through the target).

It still needs testing though, but I think this could work.

If not, just have something kinda like one of the weapons I did. Have it constantly shooting a projectile that upon contact with an enemy, it goes to the death state and emits it's death sound. If it touches nothing, then it stops on it's own and just disappears. Yes, this has one flaw, that being hitting walls/floors will make it go off but it's the easiest one.

[wildweasel]

If not, just have something kinda like one of the weapons I did. Have it constantly shooting a projectile that upon contact with an enemy, it goes to the death state and emits it's death sound. If it touches nothing, then it stops on it's own and just disappears. Yes, this has one flaw, that being hitting walls/floors will make it go off but it's the easiest one.

Hmm, actually, can't you use the Crash and Death states to determine whether the projectile hits a wall or a monster? I know puffs work like this...

[Graf Zahl]

Yes, something like that is implemented.