Author Topic: Nesting FlxSprites  (Read 3819 times)

Gilda

  • Active Member
  • ***
  • Posts: 123
  • Karma: +0/-0
    • View Profile
Nesting FlxSprites
« on: Tue, Oct 30, 2012 »
Is not possible, I've always found this really weird, I don't understand it.

Let's say I want to this, make a enemy that's a circle, then attach to it a gun that's a different sprite.

I'd either have to add all the enemy parts to the state which would be really unorganized, or I can do the much more sensible thing and make an Enemy class that extends FlxGroup and add them all to that, but then I lose properties like even the most basic x and y. I can't move, toggle visibility, transform or anything of this new object.

It just seems really broken to me, does anyone have any incite into this?

Gama11

  • Contributor
  • ****
  • Posts: 390
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #1 on: Tue, Oct 30, 2012 »
I do that sort of stuff with a FlxGroup - which is flawed, I agree. I am absolutely clueless why they removed x and y properties for those - but you can easily hack them in again by adding some getter and setter functions - that's what I did. Same works for everything else, like alpha values. Visibility can already be toggled.

Code: [Select]

private var _alpha:Number = 1;

public function set alpha(n:Number):void
{
_alpha = n;
if (_alpha > 1) _alpha = 1;
else if (_alpha < 0) _alpha = 0;

for each (var i:* in members) {
i.alpha = alpha;
}
}

public function get alpha():Number { return _alpha }

private var _x:int = 0
private var _y:int = 0

public function set x(nx:int):void
{
var offset:int = nx - _x;

for each (var object:* in members) {
object.x += offset;
}

_x = nx;
}

public function get x():int {return _x}

public function set y(ny:int):void
{
var offset:int = ny - _y;

for each (var object:* in members) {
object.y += offset;
}

_y = ny;
}

public function get y():int {return _y}

Now you can move the group just like any other FlxSprite, you could say x = 300 or x -= 100.
« Last Edit: Tue, Oct 30, 2012 by Gama11 »

mightiest_hero

  • Member
  • **
  • Posts: 51
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #2 on: Wed, Oct 31, 2012 »
i think you can use setAll function

Gama11

  • Contributor
  • ****
  • Posts: 390
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #3 on: Wed, Oct 31, 2012 »
i think you can use setAll function

Yeah, that's yet another option. Still, it's so much handier the way I described it, because you can basically treat the group just like a sprite and do stuff like x += 100.

Gilda

  • Active Member
  • ***
  • Posts: 123
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #4 on: Wed, Oct 31, 2012 »
Yeah, I was afraid of that, I guess I'll make a class that extends FlxGroup but adds a tonne of properties, has anyone already done this?

Gama11

  • Contributor
  • ****
  • Posts: 390
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #5 on: Wed, Oct 31, 2012 »
Yeah, I was afraid of that, I guess I'll make a class that extends FlxGroup but adds a tonne of properties, has anyone already done this?

"Afraid"? Why?

Also, you don't necessarily need to create a class that extends FlxGroup.. Could also just add the code I posted at the end of the original FlxGroup. I don't really see any reason not to.

Alex

  • Active Member
  • ***
  • Posts: 102
  • Karma: +0/-0
    • View Profile
    • Levelism
Re: Nesting FlxSprites
« Reply #6 on: Wed, Oct 31, 2012 »
Why not extend FlxSprite and override the update and render methods to have the children update and render? Then you can pick and choose what the children inherit.

So on update you can do something like

child.x = this.x + childOffset;
Level designer/Programmer
portfolio/blog http://www.levelism.com

Gilda

  • Active Member
  • ***
  • Posts: 123
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #7 on: Wed, Oct 31, 2012 »
Ok, so I've started creating my groups like this, and I noticed a problem. I have no way to figure out the width of the group, any ideas?

mightiest_hero

  • Member
  • **
  • Posts: 51
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #8 on: Wed, Oct 31, 2012 »
if you extends FlxGroup. you can use length

Gilda

  • Active Member
  • ***
  • Posts: 123
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #9 on: Wed, Oct 31, 2012 »
if you extends FlxGroup. you can use length

That just tells me the amount of objects in the group. . .
I need to know the size in pixels. :/

wg/funstorm

  • Global Moderator
  • Key Contributor
  • *****
  • Posts: 596
  • Karma: +0/-0
    • View Profile
    • Funstorm
Re: Nesting FlxSprites
« Reply #10 on: Wed, Oct 31, 2012 »
Loop through the group's members.
For each member, check the value of x. Store the smallest x value in a variable called min.
For each member, check the value of x + width. Store the largest x + width value in a variable called max.
Width = max - min.

Gama11

  • Contributor
  • ****
  • Posts: 390
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #11 on: Thu, Nov 1, 2012 »
Loop through the group's members.
For each member, check the value of x. Store the smallest x value in a variable called min.
For each member, check the value of x + width. Store the largest x + width value in a variable called max.
Width = max - min.

To add on that - this could be done with getters as well - but in fact, I just tried it, and it's a bit of a pain. There are some classes that extend FlxGroup and have width and height vars. (FlxEmitter in the original flixel library, as well as FlxButtonPlus from the Power Tools and even my custom class FlxSlider >.>). You can't really use any other name than "width" and "height", though. Maybe it'd make sense to bring this up regarding the community flixel verson some ppl from this forums are currently working on - having these values for FlxGroups is something that should be there from the get-go, not missing until you chose to implement it on your own.

Gilda

  • Active Member
  • ***
  • Posts: 123
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #12 on: Thu, Nov 1, 2012 »
Ok, now all this creates a deeper and more serious issue, when using FlxG.overlap() you don't get the original Enemy class, you get one of the inner objects. This is infuriating, I have to put it all on the main state.
« Last Edit: Thu, Nov 1, 2012 by Gilda »

Alex

  • Active Member
  • ***
  • Posts: 102
  • Karma: +0/-0
    • View Profile
    • Levelism
Re: Nesting FlxSprites
« Reply #13 on: Thu, Nov 1, 2012 »
That's another thing that would be solved by extending FlxSprite instead of FlxGroup. Am I missing something here?
Level designer/Programmer
portfolio/blog http://www.levelism.com

auriplane

  • Snails!!
  • Contributor
  • ****
  • Posts: 497
  • Karma: +1/-0
  • Snails!!
    • View Profile
Re: Nesting FlxSprites
« Reply #14 on: Thu, Nov 1, 2012 »
There's more than one possible behavior for "nested FlxSprites".  These range from very simple to full physics interactions between pieces.

Since the behaviors for my complex objects differ significantly, I didn't create a special type for them.  Instead, I decided to code them on a one-off basis.

(Sorry, this post probably wasn't very helpful :-)

Gama11

  • Contributor
  • ****
  • Posts: 390
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #15 on: Fri, Nov 2, 2012 »
Ok, now all this creates a deeper and more serious issue, when using FlxG.overlap() you don't get the original Enemy class, you get one of the inner objects. This is infuriating, I have to put it all on the main state.

"All this?" What exactly caused this behaviour? Adding the x/y getters and setters? Either way, I suggest using adding one single hitbox-sprite for colissions. That should work fine - unless the "Nested sprite's" dimensions change a lot over time.

Gilda

  • Active Member
  • ***
  • Posts: 123
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #16 on: Fri, Nov 2, 2012 »
"All this?" What exactly caused this behaviour? Adding the x/y getters and setters? Either way, I suggest using adding one single hitbox-sprite for colissions. That should work fine - unless the "Nested sprite's" dimensions change a lot over time.

Well I wanted to do FlxG.overlap(_bullets, _enemies, bulletVenemy);

But when we get to the bulletVenemy function the two params are not a bullet and an enemy, it's a bullet and a subpart of an enemy because it's a group and testing overlaps within the groups.

Gama11

  • Contributor
  • ****
  • Posts: 390
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #17 on: Fri, Nov 2, 2012 »
Well I wanted to do FlxG.overlap(_bullets, _enemies, bulletVenemy);

But when we get to the bulletVenemy function the two params are not a bullet and an enemy, it's a bullet and a subpart of an enemy because it's a group and testing overlaps within the groups.

Just create a group called enemyHitboxes or something then and add all enemy hitboxes to it. No need to add that group to the screen, btw.

Gilda

  • Active Member
  • ***
  • Posts: 123
  • Karma: +0/-0
    • View Profile
Re: Nesting FlxSprites
« Reply #18 on: Fri, Nov 2, 2012 »
Just create a group called enemyHitboxes or something then and add all enemy hitboxes to it. No need to add that group to the screen, btw.

Yeah, that would work, that's what I mean by just adding everything to the state. There's more parts than that though, there's like, the base, rotating top, gun, and health bar.

auriplane

  • Snails!!
  • Contributor
  • ****
  • Posts: 497
  • Karma: +1/-0
  • Snails!!
    • View Profile
Re: Nesting FlxSprites
« Reply #19 on: Fri, Nov 2, 2012 »
That's what I do.  All the parts of an enemy are enemies themselves (generally), so they all get added just like any normal enemy.

I either add them in the constructor, or in a deferred construction function, which is run on the first call to update().  Doing the latter allows you to add them to the enemies list *after* the object itself is added, rather than before.

Of course, if you make the parent object invisible/intangible, and put all the visible bits in other objects, then you can avoid the deferred construction pattern :-)