Changes to HitDef Sound and Spark Parameters

[Kokorz]

Is your feature request related to a problem? Please describe.

I personally don't like how HitDef gives you no control over how you want your sparks and sounds to spawn. And there's no alternative either unless you don't want it to spawn on time. But even that is ineffective for multi-hits.

Because of this, I have a few solutions to suggest.

Describe the solution you'd like

Add the following parameters that act essentially act the same as their original counterparts (from Explod and PlaySnd):

spark.angle = int
spark.bindtime = int
spark.vel = int, int
spark.accel = int, int
spark.random = int, int
spark.scale = int, int
spark.remappal = int, int
spark.ownpal = int

sound.volumescale = int
sound.channel = int
sound.freqmul = float

(side note: sound.channel and spark.angle are already implemented)

Additionally, add the following (and these are quintessential):

spark(x)no = int

• This acts the same as sparkno, but this is to allow you to spawn multiple hitsparks.
• This also means that each and every spark parameter i suggested above would be different based on the number.
• Assume x, without the brackets, can be substituted with a number. like spark2no.

spark.postype = string,string

• Allows you to specify the way you want to align the hitspark. Takes the same parameters as an Explod in both string positions.
• By default, this will match MUGEN behaviour. (x = P2, y = P1).

(hit/guard)sound(x) = (string)int,int

• Acts the same as hitsound/guardsound, but allows you to spawn multiple hit/guard sounds.
• Assume x, without the brackets, can be substituted with a number. like guardsound2.
• Allows you to layer multiple sounds without the use of audio editing and adding a new file, which could take up more space, especially if a sound is going to be used with other sounds.

Additional context

No response

Search terms

hitspark hitsound guardsound sound snd explod visual spark guardspark trigger parameter hitdef

[potsmugen]

I think making Hitdefs pretty much incorporate Explod and PlaySnd as you said is a bit of a feature bloat. Bang for the buck, the most useful parameters are sound channels and rotating sparks, as they are very common in commercial games, and those are already implemented.

The trigger you suggested earlier that detects the exact frame a move connected would be useful, however, as I've used workarounds for that for a long time.

Incidentally, I named "sparkangle" without punctuation for consistency with "sparkno" and "sparkxy", but if someone were to add that many spark parameters I think it could be "spark.angle" indeed.