Spritegroup single collider

[Geokureli]

allows FlxSpriteGroups to be treated as a single colliding object rather than a group of colliders when passed into FlxG.collide or FlxG.overlap

[Geokureli]

I'm not entirely happy with this concept, currently setting a FlxSpriteGroup's collision bounds via width, height and offset, is possible but setting offset sets the offset of every child sprite. maybe that's fine? maybe I should avoid FlxSpriteGroup being used like this and just make a FlxSprite extender with a simple group and call update and draw on it?

[Geokureli]

Closing this, will revisit the idea when new collider components are created

[47rooks]

I've been looking at this a bit. I didn't fully understand your concern about offset here but there are really issues with correctly setting the hitbox after a FlxSpriteGroup (hereafter fsg) is scaled. The problem is that the hitboxes have to move - or rather the relative x,y placements have to be scaled also because it's different from the origin. And then the offset cannot just be copyed from the parent to the children either. The other thing I noticed is that even with a normal sprite when you scale and then updateHitbox() is called it doesn't move the position, so the net visual effect is that the sprite actual moves - by the offset amount. I was trying to fix that while adding updateHitbox() to fsg, but that seems wrong. If the paradigm is that the x,y doesn't move but the displayed image does then I guess I need to updateHitbox on fsgs the same way. The other things that's funny is that if you add a sprite to a fsg with negative relative position the hitbox of the fsg doesn't include part of the added sprite, but the hitbox is the right size. I think this is all fixable. And then finally you need what you added in this PR to choose how to collide. That said I am wondering how you think the new collider model would impact this. I'm going to take a crack at fixing this as I need a single collider for fsg now.

[Geokureli]

Part of why i closed this is because sprite groups don't really have colliders to begin with, they're width and height is determined by their children. My goal here was to allow a a group of sprites that all move together to have a single collider, and FlxSpriteGroups just aren't a valid option IMO.

@47rooks If you need a single collider for sprite groups than i recommend the method I explain above:

import flixel.FlxSprite;
import flixel.groups.FlxGroup;

class SingleColliderGroup<T:FlxBasic> extends FlxObject
{
    public var group:FlxTypedGroup<T>;
    
    public var length(get, never):Int;
    inline function get_length() { return group.length; }
    
    public function new (x = 0.0, y = 0.0, width = 0.0, height = 0.0)
    {
        group = new FlxTypedGroup();
        super(x, y, width, height);
    }
    
    override function update(elapsed:Float)
    {
        super.update(elapsed);
        group.update(elapsed);
    }
    
    override function draw()
    {
        super.draw();
        group.draw();
    }
}

and implement ONLY the specific overrides you need, like set_x/set_y. or alternatively, don't implement any of the overrides that sprite groups use to transform member, and instead treat members position as a "local" position and apply it in draw()

[47rooks]

I've mostly been taking my lead from the class hierarchy and the intent expressed in the docs "FlxSpriteGroup is a special FlxSprite that can be treated like a single sprite even if it's made up of several member sprites. It shares the FlxTypedGroup API, but it doesn't inherit from it.".

So I've been working on the principle that this is a composite sprite with as many features of a sprite as can be intuitively supported - so a single collider makes sense to me. But the group collider seems to give precedence to the group nature over the sprite nature.

So @Geokureli, is a FlxSpriteGroup a composite sprite, or a group of them with some utility methods to set sprite properties ? I'd like to understand why you think a FlxSpriteGroup is not a good fit for a single collider ? Is it because objects have all the flixel collision at the moment and you'd rather retain the physics vs images separation between objects and sprites ?