[0.4.2][Duke3D] Too high enemy count

[markanini]

I get a ridiculous enemy count in E2L4.

Save file: https://www.dropbox.com/transfer/AAAAAN ... SRofXPejKM

[sinisterseed]

This can also be seen in EDuke32 if I am not mistaken.

I've always had this happen on E4L9 Derelict. Something in that level just causes the counter to go nuts.

[Graf Zahl]

Still warrants investigation.

[sinisterseed]

Cross-checked in eduke and curiously, I can no longer reproduce it there. I ended E4L9 without the counter glitching again.

I've also checked E2L4 (which never glitched for me), and it seems to be fine there too. I wonder if this was just a lucky occurrence or it got fixed at some point.

[sinisterseed]

Investigated this in Rednukem as well and it seems I've hit a dead end when it comes to the origins of the bug. Rednukem's counter is broken... the current kills seem to glitch periodically...

But the total did not, so I still ended with 220 kills. I'm at a complete loss now. This must have been inherited from somewhere because I've seen it before - and multiple times no less - , but no idea why I can't reproduce it at all anymore. Maybe it only happens under specific conditions that are unknown to me? I don't know what to say anymore.

[Graf Zahl]

The only code in the entire game which might cause this is this fragment:

Code: Select all

                            // JBF 20041129: a slimer eating another enemy really ought
                            // to decrease the maximum kill count by one.
                            if (sprite[pData[5]].extra > 0)
                                g_player[myconnectindex].ps->max_actors_killed--;

which can cause an underflow - and the kill counter is an unsigned 16 bit value.

[sinisterseed]

That could be it, since there are LOTS of slimers on the maps where this can trigger, particularly on the ship level.

Intended behavior, unintended side-effect I guess.

[Graf Zahl]

In that case this piece of code may be considered broken. RedNukem has removed it, btw.

[sinisterseed]

In that case this piece of code may be considered broken. RedNukem has removed it, btw.

Oh? How does it deal with this then?

If it has a better way of handling it, perhaps we shouldn't bother to fix what is broken by design either.

[Graf Zahl]

Not at all. This code was added by JFDuke to address an apparent problem - but from the looks of it it isn't without side effects.

[sinisterseed]

Then... slimers reducing enemy count is actually NOT part of vanilla behavior?

Damn. I guess I learned something new today. In that case, maybe it isn't even worth preserving...

[Enjay]

If it is possible to fix, however, I would suggest that it would make sense for the enemy count to be reduced.

To me the fix is similar in "should it be done" concept to spawned enemies from Pain Elementals and The Icon of Sin, plus resurrected enemies not being added to the enemy count in vanilla Doom (and thereby making >100% kills possible).

[sinisterseed]

^ That actually makes perfect sense from a logical perspective, the problem is that this code is apparently broken by design, so to do that we might as well go back to the drawing board and do it again than fix something that never really worked correctly or without its side-effects.

[Graf Zahl]

It should be done if the fix works. If it doesn't work and starts undercounting enemies because it removes too many, it's just as bad - if not worse than just leaving it as-is.

[Gez]

There are lots of oddities with the enemy counter, I've often seen it lower than the actual enemy count. I guess it's because some enemies are dynamically spawned when you move to a sector or when a babe is killed.