This comment has been minimized.

Do we really want the hitanim block into this if? I'd presume this block should be only ran in the first tick and not in all damaging ticks OR we want new hitanims played in all damaging ticks. This doesn't cover either.

This comment has been minimized.

This doesn't seem to match the [Desc()] above: if DamageInterval is 5 and DamageDuration is 2 then I would expect ticks 0, 1 to deal damage, then ticks 5, 6, and so on. This looks like it will disable all damage after the first DamageDuration ticks.

This comment has been minimized.

Why do you need to duplicate? Unless I'm overlooking something, we don't have a case where the initial facing should be still used after firing, so the Facing alone should be enough for being used for this.

This comment has been minimized.

This comment has been minimized.

Wait a moment... why Facing() takes the firer's facing? That sounds wrong. It should always be used for the projectile's facing and lasers/waves/bolts/instahits can still get facings from the movement vector.

This comment has been minimized.

We need to be careful here, because this is changing semantics. Consider the case where a slow moving projectile is fired from an actor, which then turns after it has fired. It would be reasonable to expect args.Facing to not change in this case, because the facing of the projectile doesn't depend on that of the firing actor once it has been launched.

It might be clearer if we could instead expose this as a CurrentMuzzleFacing or similar to avoid confusion?

This comment has been minimized.

We can't trust posFunc to not do something arbitrarily weird between invocations. It would be safer to evaluate this in Tick and then save the result in a variable for use in the ScreenMap update and in rendering.

This comment has been minimized.

I still don't understand the purpose of these two fields - it doesn't make sense to me why you would want to repeatedly spawn the same effect for only part of a weapon's firing duration. If this is to implement a warmup-loop-cooldown cycle (like fire-start and fire-loop on the oil pump destruction) then that would be cleaner and certainly better for performance to define these explicitly in the LaunchEffect.

A demonstration/testcase for this would help a lot.

This comment has been minimized.

I could do that, but - apart from not being easy to set up (don't have any suitable example in shp(td) or shp(ts) format) - by now I suspect it would get rejected anyway, for being aimed at a too specific scenario.

The use-case in my mod is that the laser muzzle effect is too "weak" with higher translucency, and still so-so (and too pixelated/aliased!) with very low or disabled translucency, so just prolonging the sequence doesn't cut it.
I tried all kinds of blend-modes, but using higher translucency + spawning another muzzle every tick for the LaunchEffectDuration is still by far producing the best-looking result (I even use a LaunchEffectIntensity that allows to spawn more than one effect per tick, which I didn't bother submitting as it's even more limited-scope).

I admit I can't think of any real uses outside that very specific use-case, it was more a case of "might as well submit them upstream along with the generally useful stuff, to reduce my local diff and in case anyone else has a use for this".
It's probably better to just drop them from this PR (I have to use a custom engine anyway, due to other changes).

This comment has been minimized.

Ah, I see. So you're relying on stacking many overlapping sprites in order to build up the strength of the effect?
We had the same problem in D2K, which I worked around by adding the PaletteFromScaledPalette trait to increase the contrast in the palette itself - mimicking the effect of stacking multiple sprites but without the stacking.

This comment has been minimized.

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.