Chocolate Doom

[axdoomer]

When I press "enter" to use an item in Chocolate-Heretic, why does it sometimes changes to another item or the current item doesn't get used? Is that a bug from the original game? Most of the time, it doesn't work as expected.

[BigDickBzzrak]

https://www.doomworld.com/vb/doom-general/90315-runuse-inventory-scrolls-the-inventory-one-item-back-in-heretic/

A bug, most likely.

[axdoomer]

There should be a bug page about Hexen and Heretic on the DoomWiki. There is already one about Strife (and one about Doom of course).

[Jon]

axdoom1 said:

There should be a bug page about Hexen and Heretic on the DoomWiki. There is already one about Strife (and one about Doom of course).

Yep, and categories; it's worth thinking of a scheme because some bugs will apply to all engines, some to a mixture, some to just one...

[VGA]

The chocolate doom guide/wiki should have a list of known bugs for the games it supports. Since the actual intention is to emulate these bugs and not fix them.

[axdoomer]

Bugs that apply to the Doom engine should be in the Doom bug list. Engine-specific bugs should be in the engine bugs article of their corresponding game. For example, in the Strife bugs list, there are no duplicates of bugs found in Doom.

The problem with undocumented bugs is that someone discovers them, never says anything about it, then they are rediscovered by someone else years later and this cycle repeats again and again.

Doom bugs: https://doomwiki.org/wiki/Engine_bug
Strife bugs: https://doomwiki.org/wiki/Engine_bugs_in_Strife

[scifista42]

axdoom1 said:

The problem with undocumented bugs is that someone discovers them, never says anything about it, then they are rediscovered by someone else years later and this cycle repeats again and again.

But once somebody reports/documents them, which tends to eventually happen, they'll stay documented, so this is (probably inefficient but still) a progress into a good direction, not so much a cycle.

[VGA]

So Chocolate Doom has these merge and nwtmerge cmdline options so the user doesn't have to manually use DOS programs like Deusf, NWT or screw his iwads. For some reason I seem to remember that there was also a cmdline option to just output the resulting wad into a new file instead of running the game ... but I cannot find anything about it in the wiki or google.

[fabian]

That's Crispy Doom's '-mergedump' parameter.

[VGA]

fabian said:

That's Crispy Doom's '-mergedump' parameter.

Oh, that explains why I couldn't find anything in Choco wiki :D

What about ... -nwtmergedump ?

[fabian]

It makes no difference. The '-mergedump' parameter exports the lumps that are currently in memory to disk, no matter if this lumps order was constructed by means of '-file', '-merge', '-nwtmerge' or whatever.

[PVS]

For Chocolate Heretic I see "-hhever <version>" command line parameter. It means that the Chocolate have support compatibility with Heretic 1.0 and 1.2 executables versions? From the command description I do not quite understand, which means "HHE patch"?

I have Heretic v1.0 and try to start Chocolate Heretic in the compatibility mode 1.0: -hhever 10 (or 1.0, 1_0), but I do not see that it worked for me.

I would be grateful for any help on this question.

[BigDickBzzrak]

^ HHE is kind of like DeHackEd, but for Heretic.

[chungy]

Chocolate Heretic requires the 1.3 (Serpent Riders) IWAD, -hhever is only for applying patches.

[PVS]

I hoped it compatibility with 1.0 executable, now I see, that -hhever command in Dehacked section of CMDLINE.txt, thanks.

Interesting, this command added only for Heretic, anyone knows examples of using this command? Which patches/wads is required this?

Also interesting information - than differ the Heretic 1.0 source from 1.3 version? Maybe someone have the Heretic 1.0 sources? But I think, the Raven never published them...

[ETTiNGRiNDER]

I can't think of a mod where it becomes important off the top of my head, but the thing with HHE is that instead of exporting a "generic" patch that could then be applied to multiple versions of the game, like DeHackEd did, HHE exported its patches as specific offsets in the EXE file to be altered. Therefore the patch would only apply correctly to the version of Heretic it was made with.

This and other shortcomings that were never rectified have left HHE a less convenient and useful tool than DeHackEd. A very few mods ever used it, fewer for anything beyond changing some text strings.

[CapnClever]

PVS said:

I have Heretic v1.0 and try to start Chocolate Heretic in the compatibility mode 1.0: -hhever 10 (or 1.0, 1_0), but I do not see that it worked for me.

If you absolutely want to, the v1.0 IWAD plays in Chocolate Heretic. It's not made to work precisely as v1.0 would (e.g., the demos still don't sync), and I haven't done an entire playthrough to check, but you can boot it up and it runs. If there were any non-WAD patches (mechanical changes, typos, etc) between 1.0 and 1.3 (or 1.2), those aren't handled by Chocolate Heretic.

ETTiNGRiNDER said:

I can't think of a mod where it becomes important off the top of my head,

This Heretic PWAD on idgames is an example of where the -hhever command comes in handy. Assuming all the files are in the same folder as Chocolate Heretic, you can run the following:

chocolate-heretic.exe -file shadow.wad -deh shadow.hhe -hhever 1.3

The most immediate change from the HHE patch is that the fifth episode in the menu is labeled "Shadowcaster".

[ETTiNGRiNDER]

By "becomes important" I meant more a patch where it won't do to just assume v1.3 off the bat.

[PVS]

Work v1.0 IWAD not very important to me, I think - Chocolate Heretic have full compatibility with Heretic 1.0, but I was wrong.

CapnClever, thanks for command line example, can be useful. I see your recent work in the Heretic/Hexen demo code for Chocolate project, great, that someone doing this. But I have problem with the latest auto-detect function for demoplayback in Heretic (possible for Hexen too, not tested).

Playback nomonsters and respawn demos recorded on original Heretic 1.3 - not working in Chocolate for me on the latest SVN build, and impossible force desired mode with "-nomonsters" and "-respawn" parameters. Chocolate always run in wrong mode for this demo records. Can you reproduce this for yourself?

Also, you use 0003h byte for auto-detect function, but I think - Heretic steel used 3-6 bytes in the demo header for 1-4 players in netgame.

[CapnClever]

PVS said:

Playback nomonsters and respawn demos recorded on original Heretic 1.3 - not working in Chocolate for me on the latest SVN build, and impossible force desired mode with "-nomonsters" and "-respawn" parameters.

I would expect that behavior. The auto-detection functionality I included (which is a throwback to vvHeretic) works because Chocolate Heretic modifies the player one byte during recording in such a way that it (or vvHeretic) can understand when reading the demo file without breaking vanilla functionality. If you record the demo in vanilla Heretic, that program doesn't apply the modification, so of course Chocolate doesn't read it. It's a flawed system, but there's not much that can be done when those games lack the proper header information in the first place.

In short, vanilla is doing what it should be doing and Chocolate was enhanced as a special exception. At the very least, any demos recorded using vvHeretic (which is an incredibly minor modification to vanilla by contrast) will be compatible with Chocolate Heretic: by doing that much I was able to include compatibility for Heretic-N demos.

For the record, Chocolate Hexen works in the same manner: special write during recording, special read during playback, both done by Chocolate Hexen only. Using vanilla Hexen at either end would require extra parameter usage to get the desired playback.

[PVS]

CapnClever, if I understand correctly - you also can not play these demo records?

New demo auto-detection functionality in Chocolate Heretic/Hexen - it is friendly to the user feature only, that be the "dear user" is not worried about nomonsters and respawn parameters. For this reason - Chocolate lost compatibility with vanilla for this demo categories? Now it turn the situation - vanilla have compatibility with Chocolate, but Chocolate not. I do not think, that this a good choice...

I'm agree, demo auto-detect it's good function and may be the default, but where the ability to turn it off and record/playback vanilla demo without modifying 0003h byte? Also, why manually added -nomonsters and -respawn command line parameters not work now for this vanilla demos, or have a higher priority over the auto-detect function?

vvHeretic can not playback this demos too and also due to the demo auto-detecting, that's bad, but this is a patch. I do not know, maybe the developer could not realize all that he wanted, because needed to patching the real executable. Chocolate have full source, anything can be compiled.

In nomonsters and respawn categories in Heretic-N archive - presents not only demos, recorded on vvHeretic, it also has a original Heretic 1.3 demos. And now, vvHeretic and Chocolate can not playback this demos...

This is just my opinion, of course, I wish all the best for the Chocolate project.

[Gez]

PVS said:

I hoped it compatibility with 1.0 executable, now I see, that -hhever command in Dehacked section of CMDLINE.txt, thanks.

Interesting, this command added only for Heretic, anyone knows examples of using this command? Which patches/wads is required this?

Also interesting information - than differ the Heretic 1.0 source from 1.3 version? Maybe someone have the Heretic 1.0 sources? But I think, the Raven never published them...

AFAIR an important difference between Heretic 1.0 and 1.3 is that Heretic used to have additional actors that were not used and eventually removed from the source entirely. Notably there was some mummy bandage (look at the SHRD sprites that are between the MUMM sprites and the FX15 sprites in heretic.wad), possibly intended to be dropped when the mummy was hurt (kind of how chickens will sometimes drop feathers).

Adding or removing mobj types from the tables affects the dehacked number of all the mobj types listed after them. This is in addition to all the offsets being changed.

[fraggle]

PVS said:

the latest SVN build,

????

[CapnClever]

I think I get what you might be trying to say. For example, you record a Chocolate Heretic demo using the -nomonsters parameter, and when you attempt to playback that demo in vanilla Heretic (again including -nomonsters because that's how vanilla works) the expected end result isn't what you recorded: in short, recent changes cause a desync. I admit I haven't thoroughly tested the synchronization of these demos, only checking the following:

• The enhancements worked via a basic record/playback test in Chocolate Heretic
  
• Demos recorded from Heretic-N with special parameters play without desync problems (only checked a couple though)
  
• Changes to the demo file didn't mess with vanilla Heretic's ability to play them back, even if they (correctly) desync without the inclusion of parameters.
  

I hope I didn't break this, but if I did you can be sure I'll prioritize vanilla compatibility when it comes to fixing it.

If, on the other hand, you're saying "this was broken in vanilla, therefore it should remain broken in Chocolate", I don't believe there to be harm in these enhancements. There may be a little confusion whether or not certain parameters are required, but it's a 100% safe bet to run it as vanilla does. The worst case would be attempting to play a demos in vanilla recorded with -longtics, which is guaranteed to desync... but this is true even in Doom: the only difference is that vanilla Doom will exit prematurely stating that the version is wrong, whereas Heretic demos lack a version to check and the viewer to left to understand that the demo was recorded under special circumstances. Why should the content of the demo file matter, so long as vanilla produces identical results regardless? (I mean if we stuffed 10MB on the file for no reason that'd be one thing, but this is a modification of a single byte that vanilla doesn't know to read any differently.)

I'll list out the possibilities so you know how it's currently designed:

• Vanilla recording, vanilla playback: parameters are required on playback
  
• Vanilla recording, Chocolate playback: parameters are required on playback
  
• Chocolate recording, vanilla playback: parameters are required on playback
  
• Chocolate recording, Chocolate playback: parameters are not required on playback, but you can include them anyway
  

Note that I can't affect the first three cases up there, since vanilla does what it wants. If anything's causing desync issues I'll look into a fix right away, but otherwise I don't think the concept of these changes is in direct violation of Chocolate Heretic's philosophy. Maybe I should make a new parameter to determine if the byte is read/written differently? I figured that as long as vanilla performs exactly the same way no matter what it wasn't important.

EDIT: Chocolate Heretic ignores the -nomonsters and -respawn parameters from the command line on playback, which is a bug. I'll fix that right up: thanks for identifying the problem!

[myk]

Hello,

I'm pretty clueless at coding but I'm trying to extend the INTERCEPTS limit for Chocolate 2.2.1 to 2048 by editing the code. I see that p_local.h says the following:

// Extended MAXINTERCEPTS, to allow for intercepts overrun emulation.

#define MAXINTERCEPTS_ORIGINAL 128
#define MAXINTERCEPTS          (MAXINTERCEPTS_ORIGINAL + 61) 

That final line of code is pointless if I increase the value to 128*16, right? If I were edit the last line to...

#define MAXINTERCEPTS          (MAXINTERCEPTS_ORIGINAL)

...would that just make MAXINTERCEPTS equal to the (new) value of MAXINTERCEPTS_ORIGINAL, or should I be doing something else here?

[CapnClever]

If you check p_maputl.c, there's a function called InterceptsOverrun() designed to emulate what happens when the number of intercepts is exceeded. The first thing this function does is check to see if overrun emulation is necessary at all:

if (num_intercepts <= MAXINTERCEPTS_ORIGINAL)
{
    // No overrun

    return;
}

Given this, I suspect you'd want to alter the value of MAXINTERCEPTS_ORIGINAL to properly increase the limit. Because it's a #define, I recommend either writing out the value explicitly (as 2048) or using parentheses like so:

#define MAXINTERCEPTS_ORIGINAL (128 * 16)
#define MAXINTERCEPTS          (MAXINTERCEPTS_ORIGINAL + 61)

The above is nothing more than defining values, with MAXINTERCEPTS being defined in terms of MAXINTERCEPTS_ORIGINAL. It'd be like if I defined a = 3 and b = a - 2: b is clearly equal to 1 but a might be used elsewhere, so they're defined separately.

[myk]

I see, that makes sense because exceeding the raised value would also require an emulation in respect to an equivalently-hacked vanilla. I will try it like that, many thanks!

[PVS]

My English is not good, very hard for me to write in English on technical topics, sorry for this.

Gez said:

... Adding or removing mobj types from the tables affects the dehacked number of all the mobj types listed after them. This is in addition to all the offsets being changed.

Interesting information for me, thanks. I collect information than the Heretic 1.0 is different.

fraggle said:

????

For Chocolate this is "daily builds", for win32 I take them from page here: http://latest.chocolate-doom.org/
"SVN" it is from another project, my mistake...

CapnClever said:

EDIT: Chocolate Heretic ignores the -nomonsters and -respawn parameters from the command line on playback, which is a bug. I'll fix that right up: thanks for identifying the problem!

Yes, that's exactly what I'm trying to say.

[fraggle]

PVS said:

For Chocolate this is "daily builds", for win32 I take them from page here: http://latest.chocolate-doom.org/
"SVN" it is from another project, my mistake...

Ah, I see. I was confused since Chocolate Doom migrated off Subversion years ago.

[PVS]

Chocolate Hexen: for me not work in game "Move backward" action assigned to the middle mouse button. In Chocolate Heretic this work fine.

Сan someone test this for yourself?