Chocolate Doom version 2 beta

False alert. Sorry. I made a checksum and I noticed that I forgot to copy my patched version of strife1.wad into my Chocolate-Strife folder over the v1.2 wad, I thought I did because the demo after the narrative played correctly. I wasn't aware that demos recorded with different versions of Strife don't cause an error message.

BTW your random sound issue is a vanilla problem as well. The A_ActiveSound function used by objects like waterfalls only plays a sound on the condition "!(leveltime & 7)" so, if the objects start out on the right tic, they may continuously miss their chance to make a sound every time. This will vary from playthrough to playthrough and differ as a result of using command line params like -warp versus walking into the level from another one.

Be sure to test all problems in vanilla before reporting as glitches. We are bug compatible, so anything broken there is broken on purpose.

All versions of Strife after 1.1 internally still identify themselves as 1.1, so, demos never bomb out.

I can't be aware of such bugs that are hard to reproduce because they have a little chance to do so. I don't know how Strife works technically, even if I had read the source code, I would have passed over such details without noticing them.

I've just found the engine bugs page for Strife on the Doom Wiki. I didn't even know this page existed. I also found it for Heretic and Hexen, though it was empty. This bug you've mentioned bug is not documented, so I'll write an article about it.

Excellent work Fraggle and co. I cannot wait to try this. I also noticed on that engine bugs list that it doesn't mention the Inquisitor glitch (the one regarding the one hit from a punch dagger).

Springy said:

I also noticed on that engine bugs list that it doesn't mention the Inquisitor glitch (the one regarding the one hit from a punch dagger).

No, it's there: http://doomwiki.org/wiki/Some_objects_are_removed_by_the_punch_dagger

axdoom1 said:

No, it's there: http://doomwiki.org/wiki/Some_objects_are_removed_by_the_punch_dagger

Oh, I can't see for looking. Sorry about that.

I'm not sure whether these bugs were in the original Hexen, but attempting to do multiplayer in Chocolate Hexen is extremely unstable for me. Launching the game with parameters "-server -deathmatch -class 2" crashes the game instantly with a segfault upon spawning for me. I have the mage's health gem when playing a netgame as the cleric, and when playing as the mage, I get no health gem at all.

Thanks to everyone who has reported bugs so far, you've all been a great help! Beta 2 is now available. Please give it a try.

The Doom zip for windows only has chocolate-doom.exe and NOT-BUGS.txt.

Wagi said:

I'm not sure whether these bugs were in the original Hexen, but attempting to do multiplayer in Chocolate Hexen is extremely unstable for me. Launching the game with parameters "-server -deathmatch -class 2" crashes the game instantly with a segfault upon spawning for me. I have the mage's health gem when playing a netgame as the cleric, and when playing as the mage, I get no health gem at all.

Thanks for the report. A few questions: what OS are you using? Does it make a difference if you change the command line parameters (coop instead of deathmatch for example)?

plums said:

The Doom zip for windows only has chocolate-doom.exe and NOT-BUGS.txt.

Good catch! The .zip was built wrong. This is fixed now.

Is there an item in Strife that allows the player to fly? There are keybinds for fly up, fly down and fly center in Chocolate-Strife-Setup. I guess this was left there from other games.

marineController said:

  The demo h5f3-803.zip desyncs at approx. 6m 30s.
  The demo h5s2-344.zip desyncs at approx. 3m 40s.

Both these demos playback with vanilla.

This is still the same for beta 2.

fraggle said:

Thanks for the report. A few questions: what OS are you using? Does it make a difference if you change the command line parameters (coop instead of deathmatch for example)?

Ugh, nevermind on that report. I found out what the issue was - I was accidentally using the version 1.0 IWAD by mistake. Updating the wad to 1.1 fixes all the issues I mentioned above.

marineController said:

This is still the same for beta 2.

Thanks. h5s2-344 doesn't seem to desync for me but it does end abruptly?

It desyncs in the last 3 or 4 seconds (the player doesn't reach the exit).

The abrupt ending is because (unfortunately) Heretic stops demo recording when the player reaches the exit.

axdoom1 said:

Is there an item in Strife that allows the player to fly? There are keybinds for fly up, fly down and fly center in Chocolate-Strife-Setup. I guess this was left there from other games.

No, and, yes, respectively.

Some Choco Strife vids to get everybody pumped up :P

Fuckin' Rowan.

...I hate everyone in Strife, come to think of it.

I love how Strifeguy always says "Thanks, bye!" to people telling him they'll kill him.

Will it work without voices.wad, or is this necessary?

It will work, not really sure why you'd want to though... disks aren't so tiny anymore :P

If Rowan is associated with the resistance, how does he have control over The Order's guards?

I've always treated Strife as if it had a "quantum plot" - characters associations and motivations change retroactively depending on the player's actions. It's the only way anything makes sense in this game.

Gez said:

I love how Strifeguy always says "Thanks, bye!" to people telling him they'll kill him.

Also some Acolytes saying "sorry" when they won't let Strifeguy go somewhere. Such good manners!

fraggle said:

If Rowan is associated with the resistance, how does he have control over The Order's guards?

Double agent. They don't know he's with the Front. How else could he be allowed to control some sort of console system near the Acolyte's interrogation room? He's not really hidden.

Not to mention, probably pretty much any citizen can raise an alarm in Tarnhill. The Order relishes nothing more than to flood the whole town with shock troops and do a little reckless shooting. Notice the window of the bar getting shot out by wild bullets flying from across the river? Who cares if innocent bystanders get hit :P

Beta 3 is now available! Please test it out.

OK, after messing around with the DOSBOX debugger for a bit I've found the reason for the demos desyncing:

In p_pspr.c : A_FireMacePL1B

ball = P_SpawnMobj(pmo->x, pmo->y, pmo->z + 28 * FRACUNIT - 
FOOTCLIPSIZE * ((pmo->flags2 & MF2_FEETARECLIPPED) != 0), MT_MACEFX2);

should be:

ball = P_SpawnMobj(pmo->x, pmo->y, pmo->z + 28 * FRACUNIT - 
FOOTCLIPSIZE * (pmo->flags2 & (MF2_FEETARECLIPPED != 0)), MT_MACEFX2);

The original code didn't have the parentheses and looks like it was not what the author actually intended.

marineController said:

OK, after messing around with the DOSBOX debugger for a bit I've found the reason for the demos desyncing:

In p_pspr.c : A_FireMacePL1B

ball = P_SpawnMobj(pmo->x, pmo->y, pmo->z + 28 * FRACUNIT - 
FOOTCLIPSIZE * ((pmo->flags2 & MF2_FEETARECLIPPED) != 0), MT_MACEFX2);

should be:

ball = P_SpawnMobj(pmo->x, pmo->y, pmo->z + 28 * FRACUNIT - 
FOOTCLIPSIZE * (pmo->flags2 & (MF2_FEETARECLIPPED != 0)), MT_MACEFX2);

The original code didn't have the parentheses and looks like it was not what the author actually intended.

That second code makes no sense and will never be false. MF2_FEETARECLIPPED is a constant value that is never 0.

Quasar said:

That second code makes no sense and will never be false. MF2_FEETARECLIPPED is a constant value that is never 0.

So? The Doom source also contains numerous gems like this one.
What does the C spec say about operator precedence - and more importantly - what did the Watcom compiler do with this?

Hmm yeah there are no parentheses in the vanilla code. Looks like fraggle added them to avoid a warning and in the process changed the behavior of the code.

!= has higher priority than &, so it binds lexically to MF2_FEETARECLIPPED, not to the result of the & operator.

The code is wrong, but it's a vanilla bug.