[Demo Recording] Any WAD with UMAPINFO will ignore complevel arguments and instead use a specific PR+UM complevel

[andrikpowell]

So recently, I've been in charge of a vanilla community project and had asked participants to submit their Internal Demos for the final WAD.

Unfortunately, one of the participants' many demos were incompatible with vanilla. He had recorded the demos with PrBoom Plus (UMAPINFO) with the default complevel set to Doom 2 v1.9...

However when you take a look at the demo file itself, it was not using the Doom 2 demo format, but a new PR+UM demo format.

The WAD itself includes a UMAPINFO specifically for level names for the bonus maps MAP33-MAP35.

Among many tests, I found that even when I used the argument "-complevel 2", PrBoom Plus would only record demos in PR+UM demo format. It seems that if there is a presence of a UMAPINFO lump, PrBoom Plus will only use it's own PR+UM demo format regardless of complevel specified.

This causes a huge problem for demo recording since most players expect using the complevel argument to actually set the complevel of their demo. I could see this being a huge issue with players thinking they recorded complevel 2 demos, only to find that their demos are incompatible.

DSDA Doom seems to do this correctly, with the complevel argument overriding everything when recording demos.

[rfomin]

We have removed the extended UMAPINFO header in DSDA-Doom and Woof, discussion: #337
PrBoom+ currently enforces the extended UMAPINFO header at all complevels because there are a few fields that can cause demo desync (intermission fields, bossaction, etc). I don't think there is a consensus about this.

[kraflab]

The umapinfo header is just a wrapper. The actual complevel header is right after it and does change based on complevel.

[andrikpowell]

The umapinfo header is just a wrapper. The actual complevel header is right after it and does change based on complevel.

I can confirm after opening the demo in a hex editor and removing the UMAPINFO header, it does in fact include a normal complevel 2 demo.

My main problem though is that there is no reference to this added UMAPINFO demo header in the PrBoom+ readme or download page. I'm honestly surprised not many people have run into this issue before me, especially with the increasing usage of UMAPINFO lumps in WADs today.

Plus, this isn't a specific issue of just mine. Yes I was able to salvage some demos by removing the extra header in a hex editor. Most people that just wanted to record a demo in PrBoom Plus with complevel 2, are not going to use a hex editor to make their demo work in Vanilla. If you try to load such a demo in Chocolate / Vanilla Doom, you will get an error that the header is wrong.

I wouldn't really call someone like me who regularly compiles source port code and edits files in hex editors, a casual Doom player/speedrunner. Most people aren't gonna know how to fix their supposedly "Vanilla" recorded demos. They are just going to think that their demos are borked and not understand why they can't get their demos to work correctly in other ports.

We have removed the extended UMAPINFO header in DSDA-Doom and Woof, discussion: #337 PrBoom+ currently enforces the extended UMAPINFO header at all complevels because there are a few fields that can cause demo desync (intermission fields, bossaction, etc). I don't think there is a consensus about this.

I use the UMAPINFO lump for very simple things like par times and level names for MAP33-MAP35, after all the UMAPINFO is supposed to be a universal map definition lump. I understand that some of these fields can cause a desync, but I honestly suggest to only add the UMAPINFO header to the demo if the UMAPINFO includes these desyncing prone fields like bossaction (bossdeath). With threads like the UMAPINFO Appreciation Thread on DW, I can see this demo header becoming quite a problem in PrBoom Plus.

[rfomin]

With threads like the UMAPINFO Appreciation Thread on DW, I can see this demo header becoming quite a problem in PrBoom Plus.

The content by me in that thread is not meant for demo recording. Due to intermission changes, most of these UMAPINFOs will cause a desync.

If you ask me, I think we should remove the UMAPINFO wrapper/header from PrBoom+ too. For your project, I suggest making a separate PWAD for cosmetics like UMAPINFO, wide assets, etc.

[kraflab]

I think it's not common to have someone that is using custom umapinfo lumps in prboom+, recording demos, and wants those demos to play back in legacy ports. It's also not as common as you might think to be recording demos in pr+um in general, since most demo activity migrated to woof or dsda-doom. This isn't to say that the header should still be there, as rfomin mentioned I removed it in dsda-doom, but maybe this helps to understand why there isn't an uprising on this subject.