damage isn't rounded well?

[Honktown]

If using a mod that adds bullet damage upgrades, you can have a 50% total damage upgrade, which adds 2.5 to firearm magazines. 7.5 * 2 should mean a 15 health biter dies in two bullets. It doesn't. It dies in 3, every time. Probably the floating-point under-calculates the total damage. I would think rounding (ceiling) damage to the nearest tenth or hundredth would solve it.

It doesn't come up in vanilla Factorio, because the bonus goes 10 + 10 + 20 %, to 10 + 10 + 20 + 20 for pistol/SMG. Same with turrets, going from 20 + 20 to 20 + 20 + 40 %

[Rseding91]

Biters also have resistances. Are you accounting for that?

[Honktown]

Biters also have resistances. Are you accounting for that?

Small biters have no resistances.

[Klonan]

The biters have health regen, which applies every tick,

So in the time between the shots, they can regen a tiny bit of health

[PyroFire]

Biters also have resistances. Are you accounting for that?

The biters have health regen, which applies every tick,

So in the time between the shots, they can regen a tiny bit of health

Confirmed "issue".

/c local e=game.player.selected local pt=game.entity_prototypes[e.name] game.print("Resistances for prototype: " .. pt.name .. " = " .. serpent.line(pt.resistances))

/c local p=game.player local e=p.selected local tiny=0.0001 e.damage(7.5-tiny,p.force) e.damage(7.5-tiny,p.force) e.damage(tiny*2,p.force)





This will leave the biter alive at 1hp from tiny=0.01 to exactly tiny=0.00001. make it a single zero longer or shorter than this range and it kills the biter.

[Klonan]

This will leave the biter alive at 1hp from tiny=0.01 to exactly tiny=0.00001. make it a single zero longer or shorter than this range and it kills the biter.

Yep, and they regen 0.01 per tick, so even with the shortest delay between shots, they would always survive 2.

Moving to not a bug unless something else is uncovered

[PyroFire]

This will leave the biter alive at 1hp from tiny=0.01 to exactly tiny=0.00001. make it a single zero longer or shorter than this range and it kills the biter.

Yep, and they regen 0.01 per tick, so even with the shortest delay between shots, they would always survive 2.

Moving to not a bug unless something else is uncovered

I've made a table of this nonsense for you:
tiny=
0.1=death
0.01=survives
0.001=death
0.0001=survives
0.00001=survives
0.000001=death
...
0.00000000001=death


Indeed, it is really up to you whether you see this as a bug or not.

Personally it looks like a bug, mostly because the reasoning is valid from the players perspective.

The +0.01 health after first damage event per tick is an unseen, and unavoidable variable, much like asking how much energy is contained in steam.
The code is given to show there is no delay between shots, so the regen effect should not be considered at that point.
Unless what you're saying is, after the code is executed, the biter is, for the shortest delay after the shot, both dead and alive at the same time.
The +0.01 biter health regen then snaps our Schrodingers Biter out of its quantum superposition of insanity and madness back into both reality, and the "still alive" state shortly afterwards in the same moment, effectively being magic'd back to life.

Now with the unknown variable known, we can account for this using some magic that's a bit more sane.

/c local p=game.player local e=p.selected local regen=0.01 local tiny=0.01 e.damage(0.01,p.force) e.damage(7.5-tiny,p.force) e.damage(7.5-tiny,p.force) e.damage(tiny*2,p.force)

Leading to its logical conclusion...

Code: Select all

function TrueDamageEntity(ent,amount,force,etc) if(ent.tick_of_last_damage~=game.tick)then ent.tick_of_last_damage=game.tick ent.damage(0.01,force,etc) end ent.damage(amount,force,etc) end

[Klonan]

This will leave the biter alive at 1hp from tiny=0.01 to exactly tiny=0.00001. make it a single zero longer or shorter than this range and it kills the biter.

Yep, and they regen 0.01 per tick, so even with the shortest delay between shots, they would always survive 2.

Moving to not a bug unless something else is uncovered

I've made a table of this nonsense for you:
tiny=
0.1=death
0.01=survives
0.001=death
0.0001=survives
0.00001=survives
0.000001=death
...
0.00000000001=death


Indeed, it is really up to you whether you see this as a bug or not.

Personally it looks like a bug, mostly because the reasoning is valid from the players perspective.

The +0.01 health after first damage event per tick is an unseen, and unavoidable variable, much like asking how much energy is contained in steam.
The code is given to show there is no delay between shots, so the regen effect should not be considered at that point.
Unless what you're saying is, after the code is executed, the biter is, for the shortest delay after the shot, both dead and alive at the same time.
The +0.01 biter health regen then snaps our Schrodingers Biter out of its quantum superposition of insanity and madness back into both reality, and the "still alive" state shortly afterwards in the same moment, effectively being magic'd back to life.

Now with the unknown variable known, we can account for this using some magic that's a bit more sane.

/c local p=game.player local e=p.selected local regen=0.01 local tiny=0.01 e.damage(0.01,p.force) e.damage(7.5-tiny,p.force) e.damage(7.5-tiny,p.force) e.damage(tiny*2,p.force)

Leading to its logical conclusion...

Code: Select all

function TrueDamageEntity(ent,amount,force,etc) if(ent.tick_of_last_damage~=game.tick)then ent.tick_of_last_damage=game.tick ent.damage(0.01,force,etc) end ent.damage(amount,force,etc) end

This all sounds like a very over complicated way of not saying anything clearly.

The biter is damaged, by 7.5. his health is now 7.5.

One tick later, he regens some health, so his health is now 7.51

The biter is damaged again, his health is now 0.01.

Since his health is above 0, he does not die.

The only thing we can consider is to add the health regen to the tooltip.

[eradicator]

This all sounds like a very over complicated way of not saying anything clearly.

I think the point that @PyroFire is trying to raise is that scripted damage all happens in the same tick and therefore regen does not apply. I've made a script to test damage increments on the player character that damages the player n times for max_health/n damage (start a new map to avoid research bonusses etc):

Code: Select all

/c
n=1
it = game.player.character
max = it.prototype.max_health

i = 0
repeat i = i + 1
  it.damage(max/n,it.force)
  until (i == n) or (not it.valid)

if it.valid then
  print(('alive with %shp/%s after %s rounds'):format(it.health,max,n))
  it.die()
else
  print(('dead after %s rounds of %s damage each'):format(i,max/n))
  end

The weird thing is that the number of rounds a) affects if the player dies or not, but b) more/fewer rounds has no direct relation to if the player dies or not, it feels "random".

Code: Select all

dead after 1 rounds of 250 damage each
dead after 10 rounds of 25 damage each
dead after 100 rounds of 2.5 damage each
alive with 3.0517578125e-05hp/250 after 1000 rounds
alive with 0.023862091824412hp/250 after 10000 rounds
dead after 99934 rounds of 0.0025 damage each

From a player perspective: In any game i generally expect the smallest possible damage increment to be what the GUI shows to me. So if the GUI shows enemy health as "100/100" i expect that all damage is calculated as integer, if it's shows as "100.00/100.00" i expect the lowest possible damage to be 0.01, and certainly not 0.00000001. So as a player for me the ideal solution would be if *all* damage interactions were clamped to a fixed number of decimal points (i.e. two). Or maybe if enemies with hp<0.01 were simply considered dead. If any of that is implementable is a different question...

[netmand]

"In the realm of the blind, the man with one eye is king."

[Cribbit]

Floating point numbers just kind of do this. It's their thing.

[Honktown]

I wasn't thinking about regen. A way to "fix" this would be to apply regen some time after taking damage - say .5 or 1 second. Then I'd expect the numbers to work out: as long as I shot the biter twice in less than a second, it dies. I'd say in most games this is how regen works - regeneration starts after not taking damage for some time.

In that respect, it'd be consistent with the way the player regenerates health.

Edit: Applying regen after not firing would also be a lot less likely to piss me off with bigger enemies. There's been times my damage was low from crap ammo or whatever, and the enemies instant regen means I do next to nothing or literally no damage if I stop firing at all. If I could sustain fire against an enemy and whittle them down it'd feel a lot better than shooting something with a lot of health and just... watching the health go back up every single shot, burning through way more ammunition than I feel I should be using.

[Rseding91]

The player regenerates instantly. The faster regeneration happens after not being in combat.

Also, there's nothing here to "fix".

[Honktown]

The player regenerates instantly. The faster regeneration happens after not being in combat.

Also, there's nothing here to "fix".

Pardon if I'm wrong, the player heals instantly from capsules, but as I understand it there's no base regen after getting hit? I've seen mods that completely disable regen, and I never recovered health, but I didn't check if the mod only changed the time delay/heal-after-leaving-combat number.

[Rseding91]

The player has regen the same as units/spawners. It also has faster regen when not in combat.