Player attack interfering with enemy bullet's lifespan? (SOLVED)

[Shadowbonnie7]

Greetings,

In my game, I have a group that contains everything that hurts players and enemies, with checks to see which one hurts which for convenience sake.

Each thing has a damage value, from the player’s attack projectile to enemy bullets.

In this example, the bullets do 2 damage, and the player’s attack does 3 damage. I even have a mechanic that let’s me stall the attack on an enemy.

However, something really strange happens:

If you look closely, when I stall my attack on an enemy (3 damage), the bullets (2 damage) will also do 3 damage to the enemies behind…???
They aren’t supposed to share damage, so I have no idea what’s causing this…

In my code, I have it set up so that everything in the group pulls from a damage variable to deal it’s own damage (Using the new group variable feature):

The player attack damage is calculated like this:

Bullets are spawned from a temporary bullet spawner, which sets the values of the spawned bullets like so:

This has left me scratching my head. How can I fix this bug and make it so that the player’s attack doesn’t interfere with the enemy bullet’s damage value?

EDIT: I’ve decided to use a ForEach group and it seems to work, although, now there’s an even crazier issue present:

At appears that when I throw my attack out, the lifespan of the bullets drastically reduce? Why??

On top of that, when I tab out, the bullet’s lifespan is too long???

Here’s the code that spawns a bulletSpawner object to shoot a bullet:

I was trying to ball everything up for convenience sake, but is it a bad idea?

EDIT 2: I’ve added lifespan checkers to each bullet, which determines the lifespan when each bullet “dies,” and uh…

(1 and 2 pinpoints where the bullets were deleted, basically their destination points)

So yeah, how can I make it so that the lifespan stays consistent every time? I’m totally lost for clues at this point…

[MrMen]

@Shadowbonnie7

image1412×506 42 KB

The issue will be here. You have multiple HarmfulThings colliding with entities, and GDevelop will have a list of each HarmfulThing that is colliding. I understand it that the first object created is the first one on the candidate list. In the case of this example, your attack is first, then the bullets. When you apply damage from a list of multiple objects, GDevelop will use the first one on the list. In this case, it’ll use the damage amount from your attack.

The best way around this is to use a “Foreach HarmfulThing” subevent, and then apply the damage. In this foreach subevent, repeat the “HarmfulThings is in collision with Entities” condition so that you get the correct entity collision to apply the harmfulthing damage to (otherwise it may apply multiple damage values to each entity).

[Shadowbonnie7]

Ahhh yes, that was it, it appears to be working as intended now. Thanks!

Although, I do still have this problem that supposedly arose from this fix as well:

@Shadowbonnie7

EDIT: I’ve decided to use a ForEach group and it seems to work, although, now there’s an even crazier issue present:

Aside from the assistance, do you think it’s a good idea to clump all damage types up like I’m doing?

[Cangethelpy]

you must calculate the position = and estimate its coordinates. once you think you have the up yourself with the x and y position, thy that with enemy and youll be zooming :]

[MrMen]

@Shadowbonnie7

Aside from the assistance, do you think it’s a good idea to clump all damage types up like I’m doing?

If all you’re doing is applying a different damage for each attack type, then yes, it’s fine to clump the damages together.

[Shadowbonnie7]

I can see where you’re coming from, but in my game, the bullet system gets a bit complicated…
Here’s the process of creating a “bullet spawner,” a temporary object that’s used to shoot bullets:

First, I made this function, which sets in the values:

Then, I create the bullet spawner at a position using create and calling said function to lock in the values. The bullet spawner only exists for a single frame before deleting itself, just long enough to fire the bullets. I can use this system to have any type of enemy shoot bullets easily, as you can see, I have the bullets shooting from the enemy’s mouth.
The bracketed code is the one being shown in the GIFs provided here.

Then, in another external event, this determines handling the bullet’s properties so that they apply correctly. Here, the bullet spawner is transferring it’s values to the bullets it creates:

And FINALLY, here’s the system that determines the bullet’s lifespan. It’s lifespan value loses 1 each frame, and once it’s lifespan value reaches 0, it’s “health” changes to 0, where the game then deletes it.

I’ll run a more specific test to showcase the issue again just in case:
This is what’s supposed to happen, the bullets all die at the same place:

If I tab out, the bullets travel too far:

If the player attacks, the bullets die too early:

Because of how complex my bullet system is, with the ability to change the amount of shots fired, random variances, various bullet properties, and more, is it still recommended to retrofit the positioning suggestion you provided? And if so, what would be the best way to do so?

Also, if anybody could see a potential problem with my system and why it’s working the way it is (Based on the screenshots provided), is there a better way I can implement lifespan for my bullets? Or is this some kind of bug within the engine itself?

EDIT: When tinkering a bit, it seems that it scales with the FPS. Apparently, even the TEENIEST TINIEST dip in FPS, even if it’s just 1 frame, throws off the whole thing? Or maybe I’m wrong?

Is there a way to combat framerate issues in this case? Like applying TimeDelta() in places where it should be?

If this is all too complex, I can share the project if you’d like to see for yourself

[Shadowbonnie7]

EDIT: I can now confirm that FPS is the primary issue here. My only issue is that I have no idea how to fix it.

I made a small lag machine which lowers the framerate to about 30-40, and sure enough, the bullets are travelling too far as a result!

I was afraid this would’ve happened before, so I had the foresight to use TimeDelta() for the lifespan here:

From what I remember, TimeDelta() makes it so that the variables will change consistently, no matter the processor or framedrops.

But… it doesn’t appear to be working? Removing the TimeDelta() from this logic just nets the exact same results…

(I even tried to use the extension that pauses the game when it loses focus, but no luck…)

I FEEL like TimeDelta() is the solution here, but if it’s not working, I must’ve put it in wrong? Can anybody please help? Am I using TimeDelta() correctly? Or is there a better way to do this?

[Keith_1357]

I think floor() is canceling out TimeDelta. It’s losing the fractional part because it’s rounding down. It’s the same as using 1. I believe the formula would be TimeDelta * 1. Or distance per second/frame rate. 60 pixels per 60 frames equals 1 times timeDelta

If you remove floor() then you would need to use lifeSpan <= 0 because it’s extremely unlikely to ever be exactly 0 when using a floating number.

The advanced projectile behavior might help. You could either use it or learn from it. The lifespan by distance works by setting object variables to the X and Y of when the object is created. It then compares the distance from the current position to the X, Y.

The duration lifespan by time uses an object timer. Create/start the object timer when the object is created and then compare the elapsed time to a lifeSpan object variable.

[Shadowbonnie7]

Ahhh yes, that was it!
Floor() was in fact the issue here, I used it to round the value to a nicer looking number, I had no idea it would have this sort of consequence!
Your other ideas are also interesting, I’ll have to put those into practice as well.
Thanks for your input!