Need help with a persistent bug I'm having with emitted sprites

I’ve been having a persistent and hard-to-squash bug regarding certain sprites when they are spawned from an Emitter block. Here is the game I’m working on; to see the problem in action, go to Level 3, move the player character to the lowest floor of the level, and press Z to have the Hero character emit a Pickaxe sprite. You’ll notice that the Pickaxe sprite doesn’t actually travel any distance. It just self-destructs right after spawning.

The strange thing I’ve noticed about this bug is that if I use a sprite that has at least four pixels of empty space between the bottom of the Sprite Editor palette and the bottom of the sprite, then the bug doesn’t appear. Take a look at this Fireball sprite I’ve tested this bug with before:

The area outlined in red shows how the Fireball sprite has an empty space between its bottom and the bottom of the Sprite Editor palette. If I have the Hero character emit this Fireball sprite, this bug does not appear. But if I use the Pickaxe sprite, then the bug does appear. Take a look at the stock Pickaxe sprite from the collection of Flowlab sprites:

Notice how the Pickaxe sprite has just two pixels worth of clearance between the bottom of the sprite and the bottom of the palette. It doesn’t seem to matter if the sprite in question has animation or not; the only thing that reliably triggers this bug as far as I can determine is if there is less than four pixels between the bottom of the initial sprite and the bottom of the Sprite Editor palette.

I don’t know why this bug is appearing or why it seems to be so persistent, but I’d like some help in clearing this up. Is this a problem with my coding? Or is it a problem with Flowlab itself? Any help regarding this bug would be much appreciated.

Your pickaxe is hitting this star, triggering the collision.
image

Pardon me, I specifically mentioned that you should load up Level 3 in that game where the bottom floor is bare of objects and reliably triggers this bug. The bug doesn’t reliably trigger if the player character is on an upper floor, but going to the lowest floor in Level 3 does reliably trigger it.

My guess is that if an emitted sprite is too large (i.e., its bottom protrudes within four pixels of the Sprite Editor palette’s bottom), it collides with the floor that the player character is standing on and is destroyed if the Collision block is set to “Any”. Is this intentional on Flowlab’s part?

3 Likes

Why not just make the object’s collision shape a Capsule?

1 Like

Oh, sorry. I didn’t even think of it.

1 Like

Good idea!

Or make the emit point up a little bit… making use of the update. But that my cause it to hit a roof later.

It worked when I changed the players to capsule… but not the pickaxe. Interesting.

1 Like

Tried making the Pickaxe’s collision shape a capsule, and it didn’t work. Emitting the Pickaxe sprite from the player character while it is standing on the lowest floor of the third level still causes it to instantly self-destruct after being emitted.

2 Likes

Do you want it to be destroyed after touching the wall sprite?

Try changing the players to a capsule?

Yes, I would like the emitted Pickaxe sprite to be destroyed when it hits a wall sprite, just not the floor if the player character is standing on it.

2 Likes

Ok, so here’s how you do that:


Put this code in the player object, both messages go to the pickaxe.

This code should go in the pickaxe.

1 Like

If you want to fix the problem without using extra code, here are two options:
Use invisible pixels with 0 alpha at the top of the sprite, to change the centroid of the sprite, which is where the hit boxes are positioned.

Test if this by turning show hit boxes in the settings.

Second option is to make another object with whatever hitbox you want, don’t mind the sprite, emit that object instead. Make that object emitted 0 alpha and attach the real sprite you want (pickaxes)

3 Likes

Sorry, but I’m rather new to Flowlab. I’m not getting the flow of your logic here, as I haven’t used RayCast blocks nor am I familiar with Mailbox blocks. Are you saying that in the player object, the Raycast checks if there’s a Wall Block, then if the projected ray from the player object hits a Wall Block, the Ray turns off and the emitted Pickaxe is destroyed? I’m probably getting this all wrong, but I would like a full explanation if possible of how this actually works.

1 Like

Ouch. I guess that means there’s no real fixing this bug without code I currently don’t understand, is there? I guess I’m limited to just using smaller emitted sprites that don’t have pixels that cross the invisible four-pixel boundary I mentioned earlier then.

1 Like

Yes. There actually is a pretty easy solution. Here are the steps explained in greater detail:

Create a new object. Set the collision shape to circle, the edit the sprite and change it to a sprite that works (collison wise, don’t care about how it looks at all)

Go into the behaviors of the object. Add a “once”, connected to the “on” of an “attacher”. (Attachers are in the component section). They attach the sprite selected to this one, without changing the hitbox or anything. This will change how the thing looks.

Then, to make the hitbox invisible, add a once connected to a number 0 and connected to an alpha block. This will make this block invisible.

Add all the extra code currently in the pic axe object into this new object.

Now, select this new object in the “emit” in the player. It will be emiting the new object now, however the sprite is attached and it looks like the pickaxe you wanted originally.