"UMAPINFO" discussion

[Altazimuth]

 

4 hours ago, kb1 said:

There's no precedent for allowing demos to survive its parent WAD changing. Most UMAPINFO have a detrimental effect on the critical timing required for the proper playing of demos. If you add a UMAPINFO to a wad after demos have been created, there is a good chance that the demo (or demo 2 of a multi-level demo) will go out of sync.

A feature that can't be trusted on to be stable for demo compat, and/or has behaviour that can't be replicated in future versions, doesn't belong in PRBoom+. Of course a demo shouldn't survive a wad changing, but in PRBoom+ the demo should survive the port changing. The most robust solution would be to have a secondary complevel for UMAPINFO so we can replicate any older demos that use UMAPINFO. The only other real way of doing it is to ensure that UMAPINFO never changes.

 

4 hours ago, kb1 said:

I was kinda hoping that there'd be more time, before this started getting implemented en masse, in multiple ports, with multiple changes to fix this or that. It would be nice, if any fixes were done to Graf's PrBoom+ implementation only, at first.

Well neither implementation have made it into a release build of anything yet, so that's not an issue. Kinks can be ironed out and anybody who is relying on these features already shouldn't expect total stability.

 

 

[printz]

Don't worry @kb1, I've halted progress on UMAPINFO on EE once I realized there are unclear fields in @Graf Zahl's PrBoom+ branch (like setting endgame=true having different effect than in the doc).

[Xaser]

Some clarification on the demo-compat issue since there was some discussion about this on Discord recently: The troublesome scenario is recording a demo on a UMAPINFO-containing WAD file and then playing it back on an older PR+ version that doesn't support UMAPINFO. It's highly possible the wad will boot up fine and the demo will appear to play correctly for a bit, only to desync when it hits a UMAPINFO-caused difference (e.g. level order). Even though it's technically being played back in an unsupported version of the port, the fact the demo doesn't immediately error out is far less than ideal.

 

The proposed fix for this involves adding a "UMAPINFO version number" or somesuch to the demo header (causing old PR+'s to bomb out when they encounter an unknown header format), at which point there's now a way to handle additional backwards-compatibility. Suppose a feature is implemented incorrectly in, say, UMAPINFOv1 and the fix causes a desync; since the version number's in the demo header, the next version of PR+ with bugfixed UMAPINFOv2 is able to add a compat check and emulate the buggy behavior if the demo says it's for UMAPINFOv1. Win-win.

[Da Werecat]

Version should already be preserved in the header. I'm not sure what's the problem here.

[Altazimuth]

Because in this case, the version of UMAPINFO used and the physics shouldn't be linked. You should have separate numbers in the header for them. I can have a mapset that is vanilla except it has 33 maps, or Boom and it decides to jump from MAP13 to MAP49, and I should be able to say "cl2 with UMAPINFO 1" or "cl9 with UMAPINFO 3" if I want to.

[Da Werecat]

Please remind me of the benefits of mixing standarts this way. Isn't it complicated enough to simply have a bunch of different complevels?

[Gez]

We go back to when I was talking about putting something like prb_complevel as a UMAPINFO property.

[dew]

2 hours ago, Da Werecat said:

Please remind me of the benefits of mixing standarts this way. Isn't it complicated enough to simply have a bunch of different complevels?

You could call it complevel 47 in the spec and it would still be "exactly like complevel 9 with UMAPINFO 4 extensions" under the hood, but the demo should not be "exactly like the Boom header with UMAPINFO specs in the footer". Older ports would gleefully try to play it back as a Boom demo, parsing just the footer stuff they recognize and inevitably desyncing. So I'm asking for a header update to block them. The rest is bikeshedding, but calling it complevel 9.4 and sneaking the extension standard into the header sounds more elegant than ++'ing the already hilariously confusing complevel counter.

[Da Werecat]

26 minutes ago, dew said:

You could call it complevel 47 in the spec and it would still be "exactly like complevel 9 with UMAPINFO 4 extensions" under the hood, but the demo should not be "exactly like the Boom header with UMAPINFO specs in the footer".

Different version in the header would take care of that. Then again, I'm not sure what said version is supposed to represent anymore.

 

Complevels used to be for emulation. Now I don't know what they are, if we're gonna have "Complevel 11 + UMAPINFO 3" as a separate complevel. It sure won't emulate anything that exists.

 

Doom source ports.

[Graf Zahl]

Guess why there has been virtual standstill on that front. The needs of demo compatibility trumped all other considerations and created an environment in which nothing could happen, except for ports that didn't care too much about these intricacies.

[TimeOfDeath666]

I think some of you guys are over thinking this. If someone is using a pre-umapinfo port with a designed-for-umapinfo wad, then it's their own fault and they deserve to suffer potential desyncs.

What's so hard about agreeing on a bare bones basic set of umapinfo options and then leaving it alone to maintain demo compatibility?

[Edward850]

1 minute ago, TimeOfDeath666 said:

What's so hard about agreeing on a bare bones basic set of umapinfo options and then leaving it alone to maintain demo compatibility?

You already know the answer.

8 hours ago, Altazimuth said:

A feature that can't be trusted on to be stable for demo compat, and/or has behaviour that can't be replicated in future versions, doesn't belong in PRBoom+

 

[dew]

41 minutes ago, Graf Zahl said:

Guess why there has been virtual standstill on that front. The needs of demo compatibility trumped all other considerations and created an environment in which nothing could happen, except for ports that didn't care too much about these intricacies.

So, would my request be that hard to implement or is it that much unreasonable from a design standpoint, or is this just you airing your hate against the entire demo community and subtly hinting at your effort to fuck with standards so much that eventually there will be no demo standard at all and Zdoom will win forever?

Edited August 1, 2017 by dew

[Graf Zahl]

I'll just refer you to:

 

8 minutes ago, TimeOfDeath666 said:

I think some of you guys are over thinking this. If someone is using a pre-umapinfo port with a designed-for-umapinfo wad, then it's their own fault and they deserve to suffer potential desyncs.

 

This pretty much sums up my standpoint on this whole matter.

 

[Edward850]

Sucks to be you then, because unfortunately for you, other people do give a shit.

[dew]

It's like saying "lol you're an idiot for playing a MBF demo on Boom". Yes? Maybe? But somehow, id versioned their headers and so did Boom and MBF. It was important to them for some reason. But this far-reaching effort at an unifying standard singles out demos as the one venue that doesn't need to be even considered? The losers who still watch demos should know their pr+ versions by heart? That is an obvious attempt to marginalize backward demo support.

[Da Werecat]

This is going so great.

[Xaser]

A key bit some folks seem to be missing: This is a solved problem. Altazimuth knows how to implement the solution and has stated intent to do it, and Graf is willing to accept a PR. That's really all there is to it.

[TimeOfDeath666]

Edward850: I meant demo compatibility for the future. Like Altazimuth said: The only other real way of doing it is to ensure that UMAPINFO never changes.

dew: I just don't see what the real difference is between a pre-umapinfo port bombing out or desyncing when trying to play a designed-for-umapinfo demo. The end result is the same, the user didn't read the wad's txt file.

[Da Werecat]

I hope that DECOLITE (or however it's gonna be called) will have its own header field as well. People should be able to add all kinds of stuff into their pure vanilla complevel 2 megawads.

[Altazimuth]

13 minutes ago, TimeOfDeath666 said:

Like Altazimuth said: The only other real way of doing it is to ensure that UMAPINFO never changes.

I mean that's not the only way. I did say the following:

 

9 hours ago, Altazimuth said:

The most robust solution would be to have a secondary complevel for UMAPINFO so we can replicate any older demos that use UMAPINFO.

 

Edited August 1, 2017 by Altazimuth
I fucked up both quotes

[Xaser]

It's dangerous to assume "UMAPINFO never changes" is even an attainable goal. There Will Be Bugs(tm), and the best-case scenario is that the demo format is equipped to handle it.

[Da Werecat]

Old engines just used version numbers for that. Then again, people didn't want things like a pure vanilla wad with a BEX patch back then, they'd just make a Boom wad.

[Xaser]

Since you seem to be convinced there are no real-world use cases for UMAPINFO & old complevels coexisting, here's two counter-examples: D2TWID and NEIS. Both are -complevel 2, and we absolutely would've used UMAPINFO to set up the MAP33/E4M0 secret exits had it been an option at the time.

[dew]

4 minutes ago, TimeOfDeath666 said:

dew: I just don't see what the real difference is between a pre-umapinfo port bombing out or desyncing when trying to play a designed-for-umapinfo demo. The end result is the same, the user didn't read the wad's txt file.

Bombing out with an "unsupported demo version" message vs. crazy desync behaviour on map21 on a 30uv run is a world of difference in giving the user an idea what's wrong.

 

Also please realize that the prboom version and complevel info in demo textfiles are just a convention that the demo community considers "good manners", we don't enforce them. Then Andy parses that info and fills out the DSDA tables, because he's a champ. Even the complevel info was added to DSDA tables only a few years ago. Don't take your precious information sources for granted. If demo runners had as much of a cavalier attitude as I see in this thread, it would be considerably harder to obtain the information necessary for proper playback.

 

I'll give you a small example. Think pl27-236. It says "Recorded using Final Doom Version 1.9", but in fact Skogsto used doom2.exe with plutonia as a PWAD. That's legit under CN rules, but if you download the demo from the archive, you will be mislead by reading the textfile. The only reason a newbie might get saved from a confusing desync is because of Grazza's insane effort with demo patters that autoload the correct wads. Well, if you're still playing "pl27-236", and demoname only is the flimsiest of shields.

 

I'm not saying a schism and a new dark age is inevitable, but I'd really like to avoid one just because demos are of the lowest importance for some.

[Da Werecat]

17 minutes ago, Xaser said:

Since you seem to be convinced there are no real-world use cases for UMAPINFO & old complevels coexisting, here's two counter-examples: D2TWID and NEIS. Both are -complevel 2, and we absolutely would've used UMAPINFO to set up the MAP33/E4M0 secret exits had it been an option at the time.

The latter sounds like cl3, but I'm nitpicking here.

 

I dunno, does something break in them in Boom-and-onwards modes?

[Xaser]

While I'm still here, a practical question: are there any actual disadvantages to this second-header route that anyone can think of? The only concrete protest I'm seeing here is "it's pointless / it's a waste of time," which would only be problematic if it actually stalls UMAPINFO's implementation. Given Altaz's track record, that's a pretty low-risk scenario.

 

[EDIT] Derplerp; got post-sniped. Also that indeed is cl3 in the latter case. Dagnabbit. :P

 

It's not a case of things breaking in Boom, but we did design NEIS E4 with vanilla physics (infinite-heights et.al) in mind (it was gonna be vanilla until visplanes/segs took our lunch money), and it'd be unfortunate to lose that. Plus there'd be the weird scenario where the hypothetical  PRBoom+ port would read UMAPINFO and enforce Boom physics on a wad that can be played (sans extra content) with vanilla physics if you load it in Chocolate or Crispy Doom.

It's a series of varying edge cases, and I'm all for just knocking all the birds out of the park with the proverbial single stone.

Edited August 1, 2017 by Xaser
responding to new post

[TimeOfDeath666]

Xaser said:

While I'm still here, a practical question: are there any actual disadvantages to this second-header route that anyone can think of? The only concrete protest I'm seeing here is "it's pointless / it's a waste of time," which would only be problematic if it actually stalls UMAPINFO's implementation.

That's pretty much all I was worried about. If umapinfo is supposed to just have basic features then why does it need to be maintained and updated? If a wad uses umapinfo just for non-gameplay stuff like music/sky/level names, could you record a demo in the umapinfo port and watch it in the non-umapinfo port (without the music/sky/level names)?

[Da Werecat]

33 minutes ago, Xaser said:

Plus there'd be the weird scenario where the hypothetical  PRBoom+ port would read UMAPINFO and enforce Boom physics on a wad that can be played (sans extra content) with vanilla physics if you load it in Chocolate or Crispy Doom.

It would've been good if more behavior differences were available as options instead of hardcoded complevel branching. At least if would make sense to set different combinations in the header. But I guess you have to work with what you have.

 

And now the complevels will transcend into a physics options surrogate. Doom source ports.

 

I don't really mind all that much, it's just weird.

[Gez]

I still think UMAPINFO ought to be able to give a default complevel for when played in a UMAPINFO-compatible PrBoom+-based port. That's the kind of things that'd come in handy for maps that require, or inversely are broken, by Boom/MBF stuff.