Add more easily tweakable offsets to FlxTrail

[ninjamuffin99]

In FlxTrail by default it creates a trail behind the target FlxSprite using it's x/y position, along with its offset.x/offset.y value, to get the general positioning.

This PR adds an additional variable to FlxTrail, effectOffset which is a FlxPoint to add additional position offsetting to the trail effect.

This came about in FNF when we changed the way we did animation offset stuff, where we no longer use offset to reposition sprites, so the FlxTrail would be in an incorrect position. We fix this by changing the effectOffset each frame with our internal offset values.

However I believe this extra variable would be useful otherwise for additional effects, if you want a specific trail sprite to be exaggerated, you can change the offset value every update for example.

[Geokureli]

can i get a sample usage?

[ninjamuffin99]

apologies for .mov file

lil squiggling trail effect, without affecting or changing the players offset or x/y

var trail:FlxTrail = new FlxTrail(_player, null, 10, 1, 0.4, 0.05);
trail.effectOffset.y = -5;
FlxTween.tween(trail.effectOffset, {y: 5}, 0.3, {type: PINGPONG, ease: FlxEase.quadInOut});
add(trail);

Screen.Recording.2024-09-24.at.1.30.07.PM.mov

[Geokureli]

Unrelated: I noticed your .mov showed up this time, it looks like it's because you added an empty line before, I tested this same change in your Debug Watch resizing issue and it worked

[Geokureli]

in my test this seems to have the same effect as:

var trail:FlxTrail = new FlxTrail(_player, null, 10, 1, 0.4, 0.05);
trail.offset.y = -5;
FlxTween.tween(trail.offset, {y: 5}, 0.3, {type: PINGPONG, ease: FlxEase.quadInOut});
add(trail);

Am I missing something?

_trail.effectOffset.y = -50:

_trail.effectOffset.y = -50:

[ninjamuffin99]

VERY subtle, but offset moves the entire FlxTrail group/object
In this first video, you can see every trail snap behind once I set offset.x = 0

Screen.Recording.2024-09-24.at.3.50.50.PM.mov

effectOffset doesn't affect any previously created sprite, they retain their original positions/offsets.
In this video, you can see that when effectOffset.x = 0 that previously created trails still retain positions and fade away, opposed to snapping back with the rest of the group. (might be hard to notice at this framerate/recording/example)

Basically

• offset if you want to shift/move the whole FlxTrail group
• effectOffset if you want to shift/move the upcoming created trails without affecting previously created trails

Screen.Recording.2024-09-24.at.3.52.09.PM.mov

[Vortex2Oblivion]

This would be very cool to have ngl
I could probably do some funky shit with it

[Geokureli]

I feel like this is where people tend to get mad or frustrated at me, but I'm really hesitant about adding ad-hoc stuff like this, especially when a simple extension can do this pretty easily.

class OffsetTrail extends FlxTrail
{
	/**
	 * An offset applied to the target position whenever a new frame is saved.
	 */
	public final frameOffset:FlxPoint = FlxPoint.get();
	
	override function update(elapsed:Float)
	{
		final oldX = target.offset.x;
		final oldY = target.offset.y;
		target.offset.copyFrom(frameOffset);
		super.update(elapsed);
		target.offset.set(oldX, oldY);
	}
	
	override function destroy()
	{
		super.destroy();
		
		frameOffset.put();
	}
}

Admittedly, this way may seem a little hacky (though, there's many other ways to accomplish this, too), it's still a simple enough solution that works for most cases. I fear that officially adding every single ad-hoc feature like this will cause bloat and confusion. Truthfully, the name and doc comment you provided are not the most informative, where, even if someone was looking for this specific feature I think they wouldn't intuitively think that this field is the answer. For cases like this rather than really nailing the field name and documentation, creating a cool demo showcasing each feature, battle-testing it against edge cases and maintaining it when newer features are added, I think you're better off just making a little extending class above that does exactly what you need for your specific usage.

That said, I do think FlxTrail could have it's code broken up into separate functions, so it's easier to extend and modify specific parts without copying the entire update. I also think it's probably not uncommon for people to want to modify the position, angle or size of newly saved frames for some kind of dramatic effect, and the current system makes that kinda hard to do, and restructuring FlxTrail could make extensions like this easier to make, and I think that would be cool. I imagine taking the giant if in update and moving it to addNewFrame or something would allow you to extend that and modify _recentPositions[0], and viola! This would work for all other properties, too

Lastly, there's a lot of things I don't like about FlxTrail, and I think there's easier, more performant ways to do this, but that's fine, these little out-of box features are meant to serve as toys and blueprints for people learning haxeflixel or learning gamedev. Not end-all beat-all features that do it all.

Thoughts?

[ninjamuffin99]

I think I agree on making sure things don't get too bloated or confusing, and I think the changes made in PR #447 would work in the use case I'd need! I'll close this issue, I'll end up using this method for trail stuff heheh