linuxdoom shortfalls [barrel glitches]

OK, so we all know that the linuxdoom v1.10 source code, even if it probably was a direct "ancestor" of most modern source source ports, was certainly not very clean, lacked sound, and even lacked some essential functionality, especially when it came to functioning with all the different IWADs.

Regarding the latter, here are the ones that I noticed:

• Horribly incomplete handling of TNT/Plutonia IWADs. They don't even register as "Doom II-like" in many specific checks, so that's one part that needed major recoding.
  
• Missing switch initialization for Ultimate Doom's Episode 4 switches.
  
• Apparently, there's no way for an exploding barrel that has been destroyed IN A SINGLE HIT to transmit inflictor information to its targets, thus making infighting caused by barrel explosions extremely hard or even impossible (though it did happen in Doom).
  

I am not so certain that the last one isn't how it's actually meant to work. Damaging a barrel WITHOUT blowing it up and THEN blowing it up with a coup-de-grace WILL set the inflictor information correctly and pass it on to splash damage targets, but if P_KillMobj is called within P_DamageMobj, then inflictor information is not set. Hmm perhaps this requires a test map...

Maes said:

I am not so certain that the last one isn't how it's actually meant to work. Damaging a barrel WITHOUT blowing it up and THEN blowing it up with a coup-de-grace WILL set the inflictor information correctly and pass it on to splash damage targets, but if P_KillMobj is called within P_DamageMobj, then inflictor information is not set. Hmm perhaps this requires a test map...

Suppose you have two monsters infighting and both are cleverly taking cover behind the same barrel, on opposing sides. Monster A damages the barrel, but it survives. Monster B damages the barrel again, and makes it blow up.

Who's the inflictor, A or B?

Gez said:

Who's the inflictor, A or B?

From my understanding of the linuxdoom code, A will be considered as the inflictor. B blowing it up will NOT cause the inflictor source to be set to B (because the call to P_KillMobj occurs before that).

Now, if A blew it up in one clean hit, there would be no inflictor considered. And if B hit it but STILL without blowing it up, then B would be considered the inflictor (with the same rules that apply to monsters regarding target priority and damage thresholds).

Then again, only a test map can definitively convince me...

Edit: hmm not even Chocolate Doom does transfer the inflictor. I made a map with two monsters strong enough to blow a barrel with one hit, connected by a chain of barrels. No matter what, the monsters never get angry at each other, not even when one barrel survives the initial hit (this is to be expected, as the next barrels in the chain all explode in one hit, and thus can't propagate the inflictor). So the only way to cause infighting in this way seems to have monsters B getting hit by the blast of a specific barrel which withstood at least one attack by A.

Edit 2: I made another room where two cacos could hit the same barrel, depending on how the player goaded them. If the barrel blew in one hit, the cacos never turned against each other. If however one of them got a weak hit on the barrel and then a "good" one, only then they would infight.

barrel.wad - 4.4 KB (E1M1)

The "fix" for this bug would be to add an inflictor setting during P_KillMobj, as a hack to get around this limitation in barrels. If this is set, then even barrel chains propagate the inflictor.

My solution? I think we should petition John Romero for the original source dump. I'd actually really like to see that

Maes said:

The "fix" for this bug would be to add an inflictor setting during P_KillMobj, as a hack to get around this limitation in barrels. If this is set, then even barrel chains propagate the inflictor.

Or move it in P_DamageMobj to before P_KillMobj is called.

I also noticed that IDCLEV cheat doesn't work with doom2.wad, plutonia.wad, or tnt.wad. It only works with doom1.wad, doom.wad and doomu.wad.

IDMUS cheat appears to work with all IWADs ("MUSIC CHANGE" message appears in top-left corner).

Rather than just blaming linuxdoom on the barrel glitch, did you test any official versions? Since Choco doesn't fix the bug it's possible that it's there in older versions, in which case fixing it would break demo compatibility.

I think I made it clear enough (?) that this is not actually a linuxdoom bug (and, in fact, the thread should be split IMO), but a normal feature.

I performed the tests with Chocolate and vanilla doom.exe v1.9, so it's actually the expected behavior, and this info should go into the wiki regarding barrel-induced infighting, as it can't occur but under very specific circumstances.

I started checking this only because I noticed that with Mocha Doom it was nearly impossible to get the barons in E1M8 to infight from luring both in the vicinity of the barrels and having them detonate them, and thought that this behavior was wrong.

Edit: re-checked, and in fact not only is vanilla Doom supposed to behave like this, it's even exploitable in another way: if a monster damages a barrel without blowing it up and then the barrel is exploded by another cause (ANY cause) as long as it's in ONE hit, then the monster who damaged it last without blowing it up gets the blame. In my test barrel.wad map, in the second room with the trapped cacodemons getting one of them to strike the barrel without blowing it up and then shooting it, will cause the other cacodemon to get angry at the first one, even though it was the player who actually caused the barrel to blow. PrBoom/PrBoom+/Boom also behave exactly in this manner.

ZDoom is an exception though: it actually propagates inflictor attribution through barrel chains, and it also attributes "blame" even for single-hit barrel explosions.

Sorry to revive this old thread - but I recall that Legacy had some code designed to get barrels to carry the inflictor information from barrel to barrel, in an attempt to reward the proper player with a frag in deathmatch. (check P_KillMobj)