[bug] interlevel blood splats do not persist across map exits

[elf-alchemist]

I have been trying to recreate the intermission screens from Doom 1 and I have noticed that the map completion splats are not persisting across map completion, which is not present in KEX. Both are using the same definition, extracted from LoR's id1.wad and having it's coordinates and graphics adapted to E1. The same behavior is also observed on Legacy of Rust, itself.

The lump in question:
https://gist.github.com/elf-alchemist/8a3f6e09afc037aa7aa9e3f4266dd737

Currently on Woof:

Currently on KEX:

[rfomin]

I can't replicate it yet. How do you test it, do you use -warp command? Woof stores the player path in save files. What is your UMAPINFO file?

I've made intermission screens for Sigil using this recources:
sigilint.zip

[elf-alchemist]

My testing is to idclip, iddqd and idkfa my way to the exits. This particular test of mine was done on my custom IWAD, again. Plainly using EnterAnim and ExitAnim:
https://gist.github.com/elf-alchemist/7b519bd333edeb874d2132dbc7ac96f8

I was actually planning to port all of the intermaps by DevilMyEyes myself, once I'd grokked the format well enough with D1.

I've just tested your compilation and it still happening. This one being done on plain doom.wad with KEX's sigil.wad. As I keyboard-cheated my way to exits of Sigil M1, M2 and M3, the blood splat on M1 did not persist:

EDIT: I should note, all other animations are working fine, it is just the blood splat itself that is not persisting.

[OpenRift412]

I don't know if this was something that was added to Woof but I believe the interlevel format takes level warping into account.

For example, completing the levels sequentially will show blood splatter sprites for all completed levels. But if you IDCLEV to a level and then complete it, the map will only show a splatter for the level you just completed. This is just my observation. If I'm missing anything, let me know.

[elf-alchemist]

Aaaaaaaand even weirder, when just running this PWAD on doom.wad the blood splats now work, but the 0.667/0.333 "You are here" graphic timing is displaying incorrectly, looks more like 0.9/0.1?

EDIT: Forgot to be explicit, but yes this is the exact same set of interlevels.
EDIT2: Just tested with KEX and it works properly.

d1_interlevel_splats_arrow.zip

[rfomin]

For example, completing the levels sequentially will show blood splatter sprites for all completed levels. But if you IDCLEV to a level and then complete it, the map will only show a splatter for the level you just completed. This is just my observation. If I'm missing anything, let me know.

Yes, this is intended. With UMAPINFO it's not always possible to determine the player's path (there can be forks in the road), so Woof stores completed levels in save files. Does the KEX port behave differently? Anyway, I don't think this is a problem.

Aaaaaaaand even weirder, when just running this PWAD on doom.wad the blood splats now work, but the 0.667/0.333 "You are here" graphic timing is displaying incorrectly

There is only 0.333 duration in this file? Looks correct to me.

EDIT2: Just tested with KEX and it works properly.

d1_interlevel_splats_arrow.zip

KEX port crashes with this WAD for me with this error message: "Victory lump ExINTER is malformed."
I run it this way: doom -iwad doom.wad -file d1_interlevel_splats_arrow.wad

[elf-alchemist]

Sorry, I accidentally sent the wrong version. This is the one I actually ran:
d1_interlevel_splats_arrow.zip

[rfomin]

Duration issue should be fixed here: #2036

I still can't replicate the splats problem, it always works for me.

[Ethel486]

I have been trying to recreate the intermission screens from Doom 1 and I have noticed that the map completion splats are not persisting across map completion, which is not present in KEX. Both are using the same definition, extracted from LoR's id1.wad and having it's coordinates and graphics adapted to E1. The same behavior is also observed on Legacy of Rust, itself.

The lump in question: https://gist.github.com/elf-alchemist/8a3f6e09afc037aa7aa9e3f4266dd737

Currently on Woof:

Currently on KEX:

I think it may be the fact that they are all condition: 3 which states in the Interlevel specification that the map corresponding to the param value has been visited.

I think condition: 1 may work? But im not sure so give it a try first

[elf-alchemist]

I've tested this branch with my usual local building process cd build && rm -rf * && cmake .. && sudo make install and the issue persists, even on id1.wad.

https://github.com/rfomin/woof/tree/fix_doom1_anim

On my end, the only other issue I see right now is that Cmake complains to me that it can't find yyjson, but all other JSON lumps work fine, so I doubt that's related.

CMake Warning at CMakeLists.txt:110 (find_package):
  By not providing "Findyyjson.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "yyjson", but
  CMake did not find one.

  Could not find a package configuration file provided by "yyjson" with any
  of the following names:

    yyjsonConfig.cmake
    yyjson-config.cmake

  Add the installation prefix of "yyjson" to CMAKE_PREFIX_PATH or set
  "yyjson_DIR" to a directory containing one of the above files.  If "yyjson"
  provides a separate development package or SDK, be sure it has been
  installed.

[rfomin]

I've tested this branch with my usual local building process cd build && rm -rf * && cmake .. && sudo make install and the issue persists, even on id1.wad.

I doubt it will help, but can you try AppImage artifact: https://github.com/fabiangreffrath/woof/actions/runs/11914116472/artifacts/2207403010

Are you aware that id1.wad was updated in the last major KEX port patch? The "level number" logic was changed. Otherwise I'm not sure what's wrong. Could you please make a minimal example with the bug? d1_interlevel_splats_arrow.zip works, right?

[elf-alchemist]

Are you aware that id1.wad was updated in the last major KEX port patch? The "level number" logic was changed.

Yes, I updated my $DOOMWADDIR as soon as the update hit.

Otherwise I'm not sure what's wrong. Could you please make a minimal example with the bug? d1_interlevel_splats_arrow.zip works, right?

Yes it is still having issues to me on the branch from the PR.

I doubt it will help, but can you try AppImage artifact: https://github.com/fabiangreffrath/woof/actions/runs/11914116472/artifacts/2207403010

Aaaaaaand wouldn't you know it, the AppImage works with the blood splats in id1.wad and d1_interlevel_splats_arrow.wad.

But now neither the AppImage or the local build of the PR branch are rendering the "Entering" and levelpic graphics.

I don't know if it'll help but my local woof.cfg config is here, as always:
https://github.com/elf-alchemist/dotfiles/blob/main/local/share/woof/woof.cfg

[rfomin]

Aaaaaaand wouldn't you know it, the AppImage works with the blood splats in id1.wad and d1_interlevel_splats_arrow.wad.

I suspect there is something wrong with the git merge. For example, my fork of Woof is out of sync, I only use it for PRs and experiments. What is the output of the git remote -v command?

But now neither the AppImage or the local build of the PR branch are rendering the "Entering" and levelpic graphics.

Should be fixed now. I recommend using AppImages so you don't have to deal with the build process: https://github.com/fabiangreffrath/woof/actions/runs/11924808188?pr=2036

[elf-alchemist]

Okay, Ive tested with the newest commit. Here's my setup right now:

1. My local git clone of the fabiangreffrath/woof's master branch, for build from source

2. My local git clone of rfomin/woof, currently checking out fix_doom1_anim, for building as well

3. The downloaded AppImage from Actions' rfomin/woof:fix_doom1_anim

My current testing is to load -file id1.wad enter the first map of the first episode normally, then keyboard-cheat idclip, iddqd and lastly, twice iddt. I navigate through E1M1, enter E1M2, exit to E1M0.

Both 1 and 2 exhibit the non-persistent blood splats on id1.wad. The third shows blood splats normally.

Both 2 and 3 now show the "Entering" and levelpic graphics for a split-second before disappearing, while 1 is still missing the blood splat but showing the "Entering" graphics normally.

Not sure if it helps, but on a plain Debian Stable system with backports and proposed-updates repositories enabled. At this moment, the only thing I can think of is plain non-reproduced builds 🤷

OS: Debian GNU/Linux 12 (bookworm)
KERNEL: 6.1.0-22-amd64
CPU: Intel Core i5-8350U @ 1.70GHz
GPU: Intel Mesa Intel UHD 620 (KBL GT2)
GPU DRIVER: 4.6 Mesa 22.3.6
RAM: 8 GB

[rfomin]

2. My local git clone of rfomin/woof, currently checking out fix_doom1_anim, for building as well

Don't do that, my fork is very broken. I recommend using the GitHub CLI tool apt-get install gh.
Use only fabiangreffrath/woof repository, then run gh pr checkout 2036 it should merge correct version.

I recommend to delete your local copy of Woof repo and start over.

[elf-alchemist]

I just did gh repo clone fabiangreffrath/woof and gh pr checkout 2036. The result remains the same, blood splats still don't persist and "Entering" graphics still disappear after a split-second.

[rfomin]

Antother fix (AppImage): https://github.com/fabiangreffrath/woof/actions/runs/11925764645/artifacts/2210963380

[elf-alchemist]

Was about to log off when I saw b644b00 on my notifs. Rebuilt the local repo and tested with id1.wad, now "Entering" screen works -- same with the AppImage. Splat issue remaining 😕. Will have to take another look tomorrow.

[rfomin]

Splat issue remaining 😕.

Just did a walktrough of the first 3 levels of Doom 1 with d1_interlevel_splats_arrow.wad, everything works as expected:

AppImage doesn't work either? My only theory is something in the autoload paths. Try running it with the -noautoload command line parameter.

[fabiangreffrath]

Could this have to do with the way we build and link yyjson? The AppImage embeds the Debian shared library, right? @elf-alchemist Could you try to install the libyyjson* packages from Debian testing (or backports if provided) and build Woof again?

[fabiangreffrath]

I can confirm that the arrow is blinking with a very strange rhythm in the fix_doom1_anim branch.

[rfomin]

The AppImage embeds the Debian shared library, right?

No, we build it on Ubuntu, which does not have yyjson.

I can confirm that the arrow is blinking with a very strange rhythm in the fix_doom1_anim branch.

Have you tested d1_interlevel_splats_arrow.zip? I thought the arrow was fixed now.

[fabiangreffrath]

No, we build it on Ubuntu, which does not have yyjson.

Right, it's in Debian just since May. Ubuntu hasn't caught up yet.

Have you tested d1_interlevel_splats_arrow.zip? I thought the arrow was fixed now.

Yes. The arrow is visible for about a second and then starts blinking.

[elf-alchemist]

Could this have to do with the way we build and link yyjson? The AppImage embeds the Debian shared library, right? @elf-alchemist Could you try to install the libyyjson* packages from Debian testing (or backports if provided) and build Woof again?

I'm on Stable, It is not provided by backports yet, no. As far as I can understand, if I edit /etc/apt/sources.list to include testing but I do not apt upgrade my system packages should remain safe, correct? I won't try anything if it'll risk my install to revert to Stable.

Barring third-party repos, my sources.list looks like this:

[fabiangreffrath]

I'm on Stable, It is not provided by backports yet, no. As far as I can understand, if I edit /etc/apt/sources.list to include testing but I do not apt upgrade my system packages should remain safe, correct?

Please don't do that. What you could do is download the libyyjson0 and libyyjson-dev packages as deb files and install them manually with dpkg. But I don't want to push you into experiments.

[elf-alchemist]

I've rebuilt using Testing's libyyjson0 and libyyjson-dev. This time no yyjson CMake error message (so I assume it is linking to the newly installed one) and splats remain bugged.

[elf-alchemist]

Just did a walktrough of the first 3 levels of Doom 1 with d1_interlevel_splats_arrow.wad, everything works as expected:
AppImage doesn't work either? My only theory is something in the autoload paths. Try running it with the -noautoload command line parameter.

I overlooked this one ealier. I just tested id1.wad and d1_interlevels on my local build with -noautoload, the issue persists. And yeah the AppImage works with both, -noautoload or not.

Although I have just noticed, on my local build of fix_doom1_anim, that the old blood splats seem to "blink" for a very brief period before disappearing, while the just-visited map remains, maybe that could be a hint as to what is happening?

[rfomin]

Have you tested d1_interlevel_splats_arrow.zip? I thought the arrow was fixed now.

Yes. The arrow is visible for about a second and then starts blinking.

Should be fixed in 23a49b5

And yeah the AppImage works with both, -noautoload or not.

Where do you run AppImage? Maybe there is a different configuration of environment variables like DOOMWADDIR. For example, Woof automatically loads "extras.wad", maybe you have such a file somewhere with modifications. Could you paste a startup log of Woof here? For example:

W_Init: Init WADfiles.
 adding c:\develop\woof\build\src\woof.pk3
 adding C:\downloads\wads\doom2.wad
 - "DOOM II: Hell on Earth" version

M_LoadDefaults: Load system defaults.

[fabiangreffrath]

Should be fixed in 23a49b5

I'm glad you could fix this. I'll be able to check tomorrow.

[elf-alchemist]

Where do you run AppImage? Maybe there is a different configuration of environment variables like DOOMWADDIR. For example, Woof automatically loads "extras.wad", maybe you have such a file somewhere with modifications. Could you paste a startup log of Woof here?

I've had extras.wad removed from my $DOOMWADDIR since its autoloading was added. So unless I have -noautoload I only see the woof.pk3, the IWAD, the autoload dir and PWAD just as normal.

Locally built fix_doom1_anim with d1_interlevel, for example.

W_Init: Init WADfiles.
 adding /usr/local/bin/../share/woof/woof.pk3
 adding doom.wad
 - "The Ultimate DOOM" version
 adding /usr/local/bin/../share/woof/autoload/all-all/woofhud.lmp
 adding /usr/local/bin/../share/woof/autoload/doom-all/brghtmps.lmp
 adding /home/alchemist/Desktop/d1_interlevel_splats_arrow.wad

My doom-related dirs in my bashrc are only as follows:

export DOOMWADDIR="${HOME}/doom"
export DOOMWADPATH="${DOOMWADDIR}:/usr/local/share/games/doom:/usr/local/share/doom:/usr/share/games/doom:/usr/share/doom"

On another note, I've quickly tested both id1.wad and d1_interlevel using local fix_doom1_anim -warp and the issue persists there, as well. And still, the missing visited maps "blink" their blood splat for a fraction of a second before disappearing, while keeping only the map that was just visited.

[rfomin]

On another note, I've quickly tested both id1.wad and d1_interlevel using local fix_doom1_anim -warp and the issue persists there, as well.

This is normal. Both IDCLEV and -warp do not show completed levels, because it's not always possible to determine from UMAPINFO (there could be many secret levels and two exits on each map).

[fabiangreffrath]

I can confirm that when using IDCLEV17 in E1M1 and hitting the switch that the blood splats for the former levels appear for a split second. This is on the fix_doom1_anim branch with d1_interlevel_splats_arrow.zip loaded.

[rfomin]

I can confirm that when using IDCLEV17 in E1M1 and hitting the switch that the blood splats for the former levels appear for a split second. This is on the fix_doom1_anim branch with d1_interlevel_splats_arrow.zip loaded.

Should be fixed in 587a383

[elf-alchemist]

New, surprising development on my end.

I've started to add the actual map animations onto doom1_interlevel.wad, and by adding the WIA00* images, the locally built master now works with the blood splats, yet the fix_d1_anims branch breaks.

On branch master (the arrow presented the timing issue fixed on fix_d1_anims, otherwise they worked normally):

On branch fix_d1_anims:

[elf-alchemist]

Dumb me should stop trying to write issues late at night :p
Here's the new WAD, only the E1 inter map anims are in, for now
doom1_interlevel.zip

[rfomin]

Here's the new WAD, only the E1 inter map anims are in, for now
doom1_interlevel.zip

Splats still not working for you?

[elf-alchemist]

Splats still not working for you?

On my local build? yes. I've just quickly tested id1.wad with v15.0.0 and it still breaking. I've been trying to recreate the animations of E2 both on my custom setup and on plain doom.wad, and there seems to be some difference in behavior between the numbering in MAPxy and ExMy formats, for the following tests I have treated all maps from E1M1 to E3M9 in a single count increment from 1 to 27. Though my brain is currently not entirely useful as of the time of writing, it's pretty late. Here's the current build of it: doom1_interlevel.zip

Plain doom.wad with the new doom1_interlevel.wad, splats seem to work, but E2M8 and E2M9 were not playing nicely, yet.

Short test on my custom IWAD, same interlevel with MAPxy mode instead.

Notice, the older blood splats and E2M9 are missing, both of which are defined as condition 2 "map has been visited" and I even tried E2M9 with condition 5 "any secret map visited". Maybe this has something to do with how Woof is tracking visited maps and that particular part of the code has build-reproducibility issues? Just throwing ideas out.

I'll have to do some additional, more thorough testing tomorrow still, as E3 is also having some issues.

[Dezaimasu]

Here's an example of weird interlevel behavior I'm currently experiencing.

An array of conditions must all resolve to true for that entire collection to resolve to true

Example 1:

"conditions": [
{"condition": 2, "param": 2},
{"condition": 2, "param": 3},
{"condition": 4, "param": 0}
]
Obviously this should never be true because 1st and 2nd conditions contradict each other, current map can't be 2 and 3 at once.
Yet the splat with this array of conditions is displayed every time when the last condition is true, i.e. when I'm not entering the secret map.

Example 2:

"conditions": [
{"condition": 2, "param": 2},
{"condition": 2, "param": 3},
{"condition": 2, "param": 4},
]
And in this example as well, with 3 contradicting conditions, the splat will be displayed anyway when the last condition is true, i.e. when I'm entering map 4.

[rfomin]

Obviously this should never be true because 1st and 2nd conditions contradict each other, current map can't be 2 and 3 at once.

Should be fixed in 446fe81