Things about Doom you just found out

[rehelekretep]

disgraceful! where was the QA?!

[Scypek2]

I found out that in Crispy Doom you can actually come back to life and continue playing if you type IDDQD while dead.

[SiFi270]

And I just learned not to do that if your corpse has been squished by a door. Pressing any key will restart the level with no hud, no weapon graphics, no messages, not even the main menu when you press esc. It's all technically there, but now it's invisible.

 

But going back to just letting the player corpse get squished, it turns out your health percentage is replaced with the crushed gibs graphic when that happens.

 

Edit: Turns out the second thing I found only applies to the backgroundless version of the hud.

Edited April 16, 2018 by SiFi270

[Koko Ricky]

I live really close to Andrew Hulshult (Brutal Doom composer). Maybe I'll try to hook up and jam some music some time.

[fabian]

5 hours ago, SiFi270 said:

And I just learned not to do that if your corpse has been squished by a door. Pressing any key will restart the level with no hud, no weapon graphics, no messages, not even the main menu when you press esc. It's all technically there, but now it's invisible.

 

I am unable to reproduce that. I mean, sure, you will get stuck under a door if you resurrect there, but I cannot see the other effects you mention.

[Percival232]

Mancubi Have 3 Sets Of Demon Tiddies

[SiFi270]

58 minutes ago, fabian said:

 

I am unable to reproduce that. I mean, sure, you will get stuck under a door if you resurrect there, but I cannot see the other effects you mention.

Turns out it was the "save clean screenshot" function that did it. Originally, I thought I'd get a screenshot of myself in the void, not realizing I had PrtSc bound to that and not a normal screenshot. Then I experienced the bug and jumped to the conlusion that any key would have done it without bothering to check.

 

After some more testing, it seems the hud is the main factor in all of this, and god neither being crushed nor activating god mode had anything to do with it. If you have the full grey bar and you try to take a clean screenshot while dead, you'll restart with that bar and your weapon, but no messages or esc menu. It's when you do that with the hud that's just numbers and letters that they all become invisible.

[fabian]

5 minutes ago, SiFi270 said:

Turns out it was the "save clean screenshot" function that did it. Originally, I thought I'd get a screenshot of myself in the void, not realizing I had PrtSc bound to that and not a normal screenshot. Then I experienced the bug and jumped to the conlusion that any key would have done it without bothering to check.

 

I believe it is this bug that you experienced:

https://github.com/fabiangreffrath/crispy-doom/commit/20d05e7374d439a748f0115d091850adfa60ecad

[Empyre]

In some ports, you can type resurrect in the console to resurrect. I have no idea which ports have this and which do not have this.

[ShoDemo]

42 minutes ago, Empyre said:

In some ports, you can type resurrect in the console to resurrect. I have no idea which ports have this and which do not have this.

 

I am sure it works for GZDoom and ZDoom, but those are the only ports I have tried it on.

[kb1]

@zokumTwice now you've accused me of confusion. Did you ever consider that, maybe, people respond to exactly what you say, not what they may read into your words? We are, after all, responsible for how our words are perceived. Anyway, I've done my best to get my point across without confusion, so I've got nothing left. Hopefully the message is clear.

[Lila Feuer]

20 hours ago, HAK3180 said:

I just noticed that in the Doom menu, "New Game" and "Quit Game" have capital G's, whereas "Load game" and "Save game" do not.

And now Doom has been officially ruined for me. Bummer!
 

6 hours ago, GoatLord said:

I live really close to Andrew Hulshult (Brutal Doom composer). Maybe I'll try to hook up and jam some music some time.

He's a cool dude, also does music for DUSK and AMID EVIL. His 2013 ROTT renditions were great too IMO.

[zokum]

1 hour ago, kb1 said:

@zokumTwice now you've accused me of confusion. Did you ever consider that, maybe, people respond to exactly what you say, not what they may read into your words? We are, after all, responsible for how our words are perceived. Anyway, I've done my best to get my point across without confusion, so I've got nothing left. Hopefully the message is clear.

I checked with others, as far as I can tell you're the only one who have a problem with what I am stating and the way I am saying it. Every time you've had a question, I've tried to clarify my point.

I'll show you what I mean:

You say:

Quote

 

Yep - node rebuild might fix/improve it. ZokumBSP can fix it with the right settings, but engines deriving from MBF cannot use these nodes, unless those engines test for the absence of Line 0 entries in every block of the blockmap. Unfortunate.

 

But, doing a standard node rebuild with a good nodebuilder might be adequate.

 

Then I respond:

Quote

That's not correct. When I found out that so many ports had buggy blockmap behaviour due to inheriting a bug from MBF, I turned off that optimization by default. Also, this has nothing to do with nodes, it has to do with the blockmap. I don't know if that is the problem with this map, but that is where the compability problem was.

Notice here how I correct you when it comes to rebuilding the nodes. This is not a nodes related behaviour. I also clarify that the blockmap optimization that MBF/boom has makes many ports handle this valid data incorrectly, and due to that, I disabled it in the following version of the ZokumBSP, which has been out for like a year or so, if not more.

Then you respond with:

Quote

Why is what I said incorrect? I said "ZokumBSP can fix it with the right settings", to which I was implying that you had to choose a specific option in Zokum. And, yes, it's my understanding that the problem being experienced is the inclusion of that 0-line, making puffs appear as bullets hit "an invisible barrier".

You were incorrect in stating that this would be fixed with a rebuild of the nodes. It won't. You also stated that ZokumBSP needed the right settings in order to fix this. For quite some time the default settings has produced iwad-like blockmaps. Thus the default settings are the right settings. When you state that the right settings are needed to fix this, something that might be technically correct, it implies the default settings aren't correct. To the average person you're telling them that the default settings produce problematic blockmaps. If the default settings worked ok, it would be pointless to point out that you need "the right settings", hence it logically follows you need to use the different from default settings, else you would never have told people to use the right settings.

You've also mixed up several bugs here and made completely false statements, like in:

Quote

 

"If you remove the MBF code and only fix the tools:

Old ports playing new maps: The first line is skipped.

New ports playing old maps: the 'bullets hitting invisible barriers' bug comes back."

 

The line about new ports simply isn't true. These are two separate problems. Bullets hitting invisible lines can occur for any line, not just the 0-line. I've had to correct  several of your faulty assumptions. If you reread the posts earlier and do not use bad assumptions, it should be clearer what I am trying to tell you. As for old ports not handling new maps, that is a fairly nieche case and to be honest, not unexpected. We're most likely talking about maps that should run fine in doom2.exe, prboom+, 3dge, gzdoom, eternity, etc. Running vanilla designed maps in ports that aren't vanilla compatible isn't something one can reasonably expect to always work. Known bugs are known bugs.

I've had to correct you so many times. can't we take this discussion on irc? I am sure the rest of the community has very little interest in this :)

[kb1]

@zokum

Yeah, the rest of the community gets it, I'm sure. There's nothing to discuss. You're being selectively thick, IMHO, when it serves you, and I don't appreciate the misplaced condescension - I didn't do that to you :(

• I admitted that I used a technically incorrect term "rebuild the nodes" to mean "rebuild the behind-the-scenes map resources", to include nodes, ssectors, reject, and blockmap. Fair enough, though typically such tools are called node builders, as far as I've always known.
• Yes, non-default settings are required to remove the extra 0 line in the blocks, The default settings will NOT accomplish this. No implication here.
• There are 2 bugs, and yes, they are not the same, but, yes, they are related. A line incorrectly running through 100 blocks is 100x more likely to exhibit ANY bug. You're not correcting anyone. There's nothing 'deep' in your posts that require multiple reads - geez.

My only problem with your original post was that you suggested that the 0-line issue should be fixed in the map-building tools, but not in the source ports.

 

If I were in a particularly nasty and "corrective" mood, I'd claim the obvious: Your removal of the 0 line in each block is a bug, at least as much as id's inclusion of it, or MBF's bypass of it. Id built the format, and, regardless of the fact that they incorrectly parsed the 0 lines, that has been the designated format since forever. MBF happened to find a way to reduce the prevalence of another bug, without causing any problems. Your removal of the 0 lines marked the first time since 1993 that maps started to have serious problems related to this 0-line, in source ports with the MBF change.

 

But, there's no need to go down that path. Talk about re-reading posts: I am trying to embrace your efficiency tweak: I think it's a good thing. The only issue with it is that a new detection step is required to ensure that ports can handle either type of map. Some ports have included such a detection step. I claim that this is a good thing. That's as clearly as I can state it, and there's nothing I can add. I would have thought that my attempt to make sure your new setting would work out well for everyone would afford me a little bit of common courtesy? Why the hostility?

 

[DynamiteKaitorn]

12 hours ago, Empyre said:

In some ports, you can type resurrect in the console to resurrect. I have no idea which ports have this and which do not have this.

 

GZDooM does :D

[zokum]

Quote

My only problem with your original post was that you suggested that the 0-line issue should be fixed in the map-building tools, but not in the source ports.

Yes, I think it is the best since it allows for better compatibility. This is the only way we can get it to work in doom2.exe and all the other official ports. The later ports we have the source for, like boom and mbf are much easier to fix.
 

Quote

MBF happened to find a way to reduce the prevalence of another bug, without causing any problems.

Except that it DID cause problems. One couldn't play back tons of demos without this 0-entry being parsed. This led to MBF pretty quickly adding an option to include the first linedef anyway. The problem lies in the fact that these ports in many cases could handle the blockmap just fine, but it didn't automatically do it, they had to be told to do it via a complevel etc. I don't have any numbers on how often this skipping fixed a problem. It was by all accounts a fairly rare occurence from my doom 2 iwad test.

There is a bug in the original source code with regards to the collission code being faulty when moving slowly. This one also affected demos a lot when I removed the 0-lines or used subset compression. The shooting bug is much more obvious than the slight 'nudge' the other bug feels like, but the nudge happens a lot more often from what I could tell.

I'm a big fan of the speedrun / demo recording scene. For me this compatibility is very important. One of the goals I had was to enable the playback of 1.9 demos with a rebuilt blockmap without desynchs. Something I did manage to do, and with a severely reduced blockmap size.
 

Quote

I would have thought that my attempt to make sure your new setting would work out well for everyone would afford me a little bit of common courtesy? Why the hostility?

I'm not being hostile, I am just trying to be very precise and exact, to avoid confusion. When writing programmer specs one needs to be very clear about the functionality one wants and how it is supposed to work and why a tweak/fix/compability option could/should exist.

As far as I have understood it this type of 'correct' blockmap has been discussed and handled a long time ago (over a year?), the first release of ZokumBSP was in August 2016. I've talked to several major port authors and as far as I could tell, we've come to an agreement about how to handle this. It's not really a hard thing to fix. Having the code work as it did in id's released source code is a decent way of fixing it and enables the best backwards compatibility. Ports wanting compatiblity with boom/mbf era demos need more complicated functionality. There's already a huge mess there with loads of complevels. I really don't want to touch that wasps nest.

My goal has been to make it possible to have doom2.exe and chocolate doom compatible maps that allow for big maps with cool special effects. If ports aren't doom compatible, the port authors are the ones that should decide what to do about this incompatibility. Any decently compatible port should have those maps working just fine. When i wrote this code I tested it on several really long 32 map runs in order to iron out any bugs. Originally it didn't occur to me that ports could have introduced bugs that broke this fix in the tool chain.

[RjY]

On 15/04/2018 at 1:09 AM, zokum said:

It doesn't actually end with -1, it ends with FFFF. It just happens to be that if you specify -1 and converts that to unsigned 16bit it ends up as the value 65535 (0xFFFF). It's a programming hack that is a bit nonsensical for people that aren't aware of how integer numbers are stored in C etc. Exactly why this convention is in use here is a bit odd. If you view a wad in a hex-editor, it's obviously FF FF in those two bytes..

This is a strange thing to quibble about. I think you can assume in a technical discussion that your audience knows how two's-complement representation works. More importantly, doom2.exe and Chocolate Doom read the blockmap as an array of signed shorts. From the vanilla engine's point of view, the terminating delimiter really is -1. In fairness, Boom later changed it to unsigned / 0xFFFF to allow larger blockmaps (before giving up and writing an internal builder when that was found to be insufficient).

[zokum]

5 hours ago, RjY said:

This is a strange thing to quibble about. I think you can assume in a technical discussion that your audience knows how two's-complement representation works. More importantly, doom2.exe and Chocolate Doom read the blockmap as an array of signed shorts. From the vanilla engine's point of view, the terminating delimiter really is -1. In fairness, Boom later changed it to unsigned / 0xFFFF to allow larger blockmaps (before giving up and writing an internal builder when that was found to be insufficient).

I really doubt most technical people know how integeres are stored, but it could be that a sizable portion of the people in here know. You're correct about the unsigned bit, iwas impreciuse/wrong there. It's only in some (most?) ports and ZenNode that one uses unsigned ints.

When I was commenting i was thinking about the way it's being referred to in the many of the wikis etc, but I didn't state that. https://zdoom.org/wiki/Blockmap and  doom-wikia-com/wiki/Bløckmap clearly states that unsigned ints are used and the end character is -1, which is a bit nonsensical. The proper doom wiki is more thorough, but it does omit some information about which entries are signed in the headers etc. I should have checked with the "real" wiki. :)

Edited April 17, 2018 by zokum

[Jon]

please consider editing that proper URL out of your last post and not give them any pagerank ;)

[Scypek2]

Remember the good old days when wikia links were automatically replaced with doomwiki links? Oh well, at least we can say "XD" and "irregardless" now...

[Linguica]

1 hour ago, Jon said:

please consider editing that proper URL out of your last post and not give them any pagerank ;)

 

Worry not fam, it's got a rel="nofollow"

[kb1]

10 hours ago, zokum said:

I've talked to several major port authors and as far as I could tell, we've come to an agreement about how to handle this. It's not really a hard thing to fix.

Being concerned with correctness and precision, you could have said that the first time, avoiding the inevitable rehash. Because now, my takeaway is that asking you for assistance is a net-negative experience, which really sucks.

[zokum]

38 minutes ago, kb1 said:

Being concerned with correctness and precision, you could have said that the first time, avoiding the inevitable rehash. Because now, my takeaway is that asking you for assistance is a net-negative experience, which really sucks.

Sorry for that, I didn't mean to be rude. I tried to give accurate and fleshed out answers. I might have been a bit terse, but I'm not too fond of adding a lot of cozy fluff :)

Over a year ago non-0-header blockmaps were tested in various ports and a list was produced with compability information:

The thread is fairly long and messy (171 posts) and i just assumed you'd read all of it, since you posted in it. It covers blockmaps working in doom2.exe, chocolate doom, prboom with right complevel, eternity with -vanilla parameter. Only reported completely broken ones were: geezy & queezy, zdaemon.

Later there's also mention of this snippet: "Presumably the "certain someone" is Graf who has already committed a change to the GZDoom code to handle blockmaps of the type under discussion." In addition there was a coder from another port that asked me to enable doomworld mail support to communicate with me.

If I'm not mistaken EE had code added that makes adding the -vanilla parameter unnecessary. We talked about this mostly on IRC.

As far as I understood it, it was fairly settled that this kind of blockmap would be fairly well supported in maintained ports. Zdaemon most likely still lacks support for headerless blockmaps. Support is not mentioned in the changelog, I just checked.

Edited April 17, 2018 by zokum

[kb1]

I remember the thread, but not all the details - I probably skimmed through it. The current level of support is good to know. It's an item I can mark off my list. Thanks.

[Xyzzу]

The lava in the final room of MAP15 is 20% damaging, even though there is no way to step in it without noclip.

[Astro]

That they used a texture in Shareware version, that was meant to be only In the full version of Doom 1.

[-Votterbin-]

martianbuddy.com redirects to the DOOM website

[Lila Feuer]

11 hours ago, Xyzzy01 said:

The lava in the final room of MAP15 is 20% damaging, even though there is no way to step in it without noclip.

To punish the curious, presumably.

[Endless]

That the Doom 1 and 2 OST actually sound a lot like some popular metal songs. lml 

[Gez]

On mardi 17 avril 2018 at 3:26 PM, zokum said:

https://zdoom.org/wiki/Blockmap [...] clearly states that unsigned ints are used and the end character is -1, which is a bit nonsensical.

No, it doesn't quite clearly state that. It says that offsets are unsigned, contrarily to most other WAD structures.