Doom2 v1.92 - no more visplanes and drawsegs overflows

myk said:
If any usual settings were to still (otherwise) work as usual, and if the only difference were the place of the lever on the screen, it wouldn't really change much. I use sens 75, so I gather the lever would appear a bit to the right of the middle, instead of off the screen (causing the V_DrawPatchDirect error). If I'm not mistaken, you're still basically raising a limitation.

Try it and give me feedback.
sens.crk

myk said:
About something that might well not be Doom+ specific, what about the following bugs?

http://doom.wikia.com/wiki/Fast_doors_make_two_closing_sounds
http://doom.wikia.com/wiki/Ouch_face
http://doom.wikia.com/wiki/Picked_up_a_medikit_that_you_REALLY_need%21

Could they be hacked? Maybe making a separate patcher? What binary changes would be required?

It is not a problem.
bugsfree.crk

entryway said:
Try it and give me feedback.
sens.crk

This one seems to be working quite perfectly (I loaded my stanrard CFG and also tested with a default one changing the sensitivity to see how it went).

It is not a problem.
bugsfree.crk

The medikit and door sound cracks seem to work just fine, but the ouch face shows up sometimes when it shouldn't, or fails to show when it should. I saw it when damage was 8 and 16 from a Baron of hell's fireball, for example, and it failed to show up when the damage was 64. With some other damage values (40 and 48, for example) it came up properly, though.

but the ouch face shows up sometimes when it shouldn't

Try to redownload and check up it again. If it still does not work, give me a demo with detailed explanation.

entryway said:
If it still does not work, give me a demo with detailed explanation.

The newer version doesn't seem to bring up the ouch face at all. I did some more thorough testing with the older one, that did sometimes show the ouch face, and recorded a number of demos in DOOM and DOOM II levels showing the player taking damage (pretty masochistic, ha!), with a text file showing what face came up on each hit. Some of this must be pretty redundant, but hopefully helpful, so I included all the demos I got.

The ouch face shows up only when the Player is struck by an enemy? It never showed up due to slime, or Barrels blown up by the Player himself.

I cannot understand, what I should do. Some ports have fixed "ouch" behavior. Eternity and prboom 2.4.7 for example.

  // old code: if(plyr->health - st_oldhealth > ST_MUCHPAIN)
  if(st_oldhealth - plyr->health > ST_MUCHPAIN)

I hope I did the same. So I want to see a demo which plays differently in Eternity and Doom2+my fix

P.S. wiki's suggestion is:

if(plyr->health - st_oldhealth < ST_MUCHPAIN)

It totally differs from correction in Eternity and GZDoom. The latest version of the crack includes both variants. You should apply only one of them.

entryway said:
So I want to see a demo which plays differently in Eternity and Doom2+my fix

Neither PrBoom 2.4.7 nor Eternity 3.33.33 show the ouch face when you suffer a lot of damage (even when using compatibility level 17, in PrBoom's case)... PrBoom doesn't even have a specific compatibility setting for it. I'm not sure if the face is supposed to appear when receiving 20 points or damage or more than 20, but either way it's not showing up when I get hit for much more than that by a single attack.

EDIT: Ah, is it when reduced to 20 or less? Still, PrBoom and Eternity don't show it.

I think wiki's condition is wrong, because (plyr->health - st_oldhealth) will always less than ST_MUCHPAIN (evel less than zero) after damage. So I still don't know how it should be. In any case you can test both variants in the latest version of a patch

entryway said:
In any case you can test both variants in the latest version of a patch

Well, the Eternity and GZDoom fix does nothing (it's the second one I had tried earlier), and the wiki one is similar to the first one but a bit different. I could produce a text file like the one in the ZIP, if you want, but it appears to be messed up because in e1m805 the Demon bites my ass for only 16 points of damage and the ouch face is shown.

Wouldn't the proper result be that the ouch face should show every time a single attack makes 20 points of damage or more? Can you tell is this is supposed to be applied only when monsters attack and not when the Player damages himself or steps on a damaging sector? I'm saying this because the same situations that cause the ouch face to work from, let's say, a Baron's firball (like being reduced from 100 to 80 hp), din't bring it up over slime.

but it appears to be messed up because in e1m805 the Demon bites my ass for only 16 points of damage and the ouch face is shown.

I think wiki's condition is wrong, because (plyr->health - st_oldhealth) will always less than ST_MUCHPAIN (evel less than zero) after damage

Isn't the wiki just describing what's in the source? That's why if health ends up higher than the old health after taking damage the face can appear. Something must be inverted there to fix it.

The behavior that I see from the "wiki" fix seems very strange, though, similar to the one from the first fix you made (the effects are shown in ouch.txt, or the demos will show it, using that crack version).

EDIT: Shouldn't the intended code be:

if (st_oldhealth - plyr->health > ST_MUCHPAIN) // ST_MUCHPAIN is 20
  {
     st_facecount = ST_TURNCOUNT;  // ST_TURNCOUNT is 35
     st_faceindex = ST_calcPainOffset() + ST_OUCHOFFSET; // ST_OUCHOFFSET is 5
  }

?

In PrBoom and Eternity the ouch face does not appear at the start of Memento Mori Map13, but neither does it appear if you take more than 20 points of damage (as one would assume), so the "fix" got rid of the strange behavior in Doom but never managed to get the "intended" one. The hack you made based on Eternity and GZDoom, on the other hand, has no effect at all, as the face is never shown while being damaged in relatively normal situations, and still shows up at the start of MM Map13. The other hacks seem to apply the face at various damage situations, but inconsistently (it even depends on how much damage the Player has).

The strangest thing is that in the standard game nearly the only way to get the ouch face is when you start in slime and with a Medikit, but with the two hacks you made that have any effect, the slime that inflicts 20 points does not bring up the face, ever, even though the face will show up sometimes if you get hit by a monster for 20 points.

I was playing with my Baron of hell friend in Map08 using ZDoom 2.1.7 and the face shows up whenever the player gets more than 20 points of damage (and not in heavily damaging slime, where you get only 20). If the fix succeeds I believe it should work like ZDoom does. But it hasn't.

I found a bug in my 'ouch' patch. The corrected version is in the same place. Wiki shows 'ouch' face every time. Eternity/Gzdoom shows 'ouch' face if you got a damage more than 20, but only during one tic. You can see this face in your lvl801.lmp in DOSBox with 1% speed

I was playing with my Baron of hell friend in Map08 using ZDoom 2.1.7 and the face shows up whenever the player gets more than 20 points of damage (and not in heavily damaging slime, where you get only 20). If the fix succeeds I believe it should work like ZDoom does. But it hasn't.

Wait a moment.

entryway said:
Eternity/Gzdoom shows 'ouch' face if you got a damage more than 20, but only during one tic.

Well, that explains why Eternity and PrBoom aren't showing it, but do you mean you saw the fix work on the patched EXE, or are you guessing I'd see it in DOSBox (I can't test because I'm on Windows 98). I saw that the patches have additional info (an equivalent fix at a different location), but after applying them, got, as far as I can tell, the same results as the in previous versions (described above).

Keep in mind the "wiki" hack is giving the ouch face at various different and strange damge situations, and the "eternity/gzdoom" hack only like the standard engine does (as in the start of mm map13).

The latest patch (same link) contains ZDoom behaviour (I hope). If it works correctly I'll apply it to the prboom source
http://prboom-plus.sourceforge.net/bugsfree.zip

entryway said:
The latest patch (same link) contains ZDoom behaviour (I hope).

Almost! The only difference is that in ZDoom Barrels and slime do not cause the ouch face to appear (even when damage is well over 20 from a Barrel). With slime it would be predictable, as it inflicts a maximum of 20 points, but I found odd behavior in the E1M2 and E1M3 demos where the damage is from Barrels and slime. The slime causes the face even if the damage is only 20, and there is a flicker when the face is drawn, as if it were quickly replacing another sprite (I guess it's the normal pain face). Similarly, when the damage is due to a (Player exploded, at least) Barrel, the face seems to flicker once for every 20 points over 20, so there is a flicker at the middle if the damage in 40 or more, or two (the second a bit of time after the first) if it's 60 or more, for example. Also, the face also appears if the damage from a Barrel is less than 20 (see e1m309 and e1m312 for good examples). There might be something in the way Barrel and slime damage is inflicted that doesn't synch with the way the face is effected.

The ouch face shows more than one tic. If it displayed for one tic, you wouldn't be able to see it. It is only meant to appear momentarily, and then proceed into the normal player pain face. It is not supposed to persist for the entire normal duration of the pain face from what I can tell.

I have thoroughly tested this in EE 3.33.50 and it works as expected (why are you still using 3.33.33?). Go to E1M1 and blow up the first barrel while standing relatively close. You'll get a nice long ouch face followed by the player pain face. This is the APPROPRIATE ouch face behavior.

Still needs a compflag though :P

I just noted that the face being displayed during the slime or Barrel flickering effect using the "ZDoom" hack is the normal "walking" face, and not the pain face. I also went to E1M1 to the 5 point slime and the ouch face showed for the first 5 points of damage, the walking face for the second, the ouch face for the third, the walikng face for the fourth, and so on.

Quasar said:
why are you still using 3.33.33?

Simply because I had obtained it from the main page of the Eternity site.

I just downloaded and tried the newer Eternity beta, and it's the same, but I don't think they intended to make the face display for so little that you can barely notice it unless you happen to take a screen shot just as it happens.

EDIT: From what I can tell, the Doom press release beta used the ouch face only for the slime damage. At least it didn't show up when monster damage was 24 or 40 (I didn't see any greater damage testing just now).

Quasar said
If it displayed for one tic, you wouldn't be able to see it

You are right, I cannot see it in most cases without "-timedemo x -avidemo y" feature in prboom-plus. Maybe you should add priority = 8 after first check on ST_MUCHPAIN

         // was due to inversion of this test:
         // if(plyr->health - st_oldhealth > ST_MUCHPAIN)
         if(st_oldhealth - plyr->health > ST_MUCHPAIN)
         {
            st_facecount = ST_TURNCOUNT;
            st_faceindex = ST_calcPainOffset() + ST_OUCHOFFSET;
            priority = 8;
         }

What explanation is there for the different behavior of the hacks in regard to slime and Barrels?

I tried the "Eternity" hack and it also displays the ouch face more easily to Barrel damage, but in a less makred way; with less flicker, and a normal pain face after the flicker, and never if the damage is 20 or less. The ouch face doesn't seem to be seen when monsters hit, though; if it is present in the severe cases of damage like the 90>20 in lvl811, then very briefly and obscured by the intense red glare.

myk said:

I also went to E1M1 to the 5 point slime and the ouch face showed

It's my bug. Some part of wiki version was present in ZDoom version. Reuploaded.
http://prboom-plus.sourceforge.net/bugsfree.zip

Quasar said:

Go to E1M1 and blow up the first barrel while standing relatively close. You'll get a nice long ouch face followed by the player pain face. This is the APPROPRIATE ouch face behavior.

So you mean ouch face should appear after barrel explosion. ZDoom team means it should appear also after a pain from monsters more than 20 (ST_MUCHPAIN) But in your version (I checked it in prboom, but it looks similar) ouch face shows also if pain_from_monster is more than 20, but during one tic only and it has no sense. In other words: In case of "// getting hurt because of your own damn stupidity" (priority < 7) your code works fine, but in case of "// being attacked" (priority < 8) your code does not do anything except showing of ouch face during one tic that can't be seen. You changed condition, but it does not help. If I understand all correctly.

It's odd that in ZDoom Barrels don't cause the face (I see no reason why they shouldn't). Was that an oversight due to some sort of separate handling of the Barrel's damage?

entryway said:
Reuploaded.

Cool, from what I've tested it works great now!

Does the pain face have a duration that depends on the amount of damage? Is that why when damage is high the pain face appears after the ouch face?

myk said:

It's odd that in ZDoom Barrels don't cause the face (I see no reason why they shouldn't). Was that an oversight due to some sort of separate handling of the Barrel's damage?

In case of damage because of your own damn stupidity GZDoom use Carmack's code. At least it looks similar.

if (OldHealth != -1 && CPlayer->health - OldHealth > ST_MUCHPAIN)

Then there are TWO bugs in the ouch face code then. Not only was the condition reversed, but the priority system is broken in a way that makes the face not work with monster damage.

This is a significant finding, guys. Thanks. It should be added to the topic on the Doom wiki I guess.

It's no wonder it was left broken in the release version of the game, since it was in fact *not* as simple as reversing the conditional statement.

Grazza said:
I don't see much point extending the maxintercepts and maxspechits limits,

What about an optional patch for these? Wouldn't they allow the patched engine to play back demos recorded with PrBoom but without overflow compatibilities? They could also be useful for using with levels from authors that in the text file recommend not using engines likely to have memory overflows, to ensure consistent demos on the levels, or whatever.

I added the priority = 8 line and now ouch face shows up properly for high monster damage. However, now I think it shows up too often. Takes the mystique out of seeing it altogether :P I really think the limit on its appearance for monster damage ought to be higher than 20...

Will Doom2.exe v1.92 work for other WADs that require ports to play, such as Speed of Doom, Community Chest 1-4, 1Monster, and such if I run deusf over these wads?

I'm just asking.

Definitely not any game that require Boom, such as Community Chest 2-4. This v1.92 would only apply to some 'limit removing' wads.

And here I was thinking this was a new thing ._.

Yep, the ones you mentioned are mainly Boom WADs.

If the text file for a WAD says Advanced engine needed: Boom (or Boom compatible, or some other port) at the top, you can be sure there will be problems.

When the text file says "Limit removing" many will work, although some may have problems. Any map that has a BLOCKMAP that's bigger than 64 KB won't work, that's certain. Scythe2, for example, was heavily tested with Doom2+, but level 30 will not work with it because of its huge BLOCKMAP. Talking about the Scythes, Erik's subsequent release, Scythe X, works all the way, but has a medusa effect I provided a fix for here. Medusas occur when a multi-patch texture is used on a double-sided line.

Eris Falling said:
And here I was thinking this was a new thing ._.

Yeah, but it's bumpable because it's more or less the "official Doom+ thread".

Alright well thanks for the info. I've also had problems with Map22. When I warp into that level, the game crashes to DOS.

I get this error message:
Z_CheckHeap: block set does not touch the next block

Has anybody gotten this error?