RjY

4 maps, 92:37 sid: ct. 2, dead on map04, 83:30 bauhaus: ct.1, stuck on map02, 8:37

ct. 2 (familiar), dead on map12, 23:58

quit after 5 maps finished, 1:20:00 (blind)

blind, survived in 1:10:15

They are in the wrong order. IMO certain aspects of the game progression, especially certain features of certain maps, make much more sense with the original episode order.

I believe it is tea time at cheonsanggye by antares031.

I believe these are called elastic collisions. The Movement Bible has more technical detail.

It's... getting eaten by a spectre! I didn't see the spectre at first, either, I needed to rewatch. Got all excited, what's going on there, how could that happen..! But no :)

I'm afraid this was already known, although perhaps not well-documented. Here is one post mentioning the inconsistency. But please keep trying! There are always more discoveries to be made. And do join us in TABYJFO :)

I think a new compatibility level is the right time to migrate to blockmap-based line-of-sight. Presumably one of the reasons UDMF support was introduced is for the likes of Insane_Gazebo, Bemused, et. al. to be able to make high-detail slaughter maps of such complexity as to exceed the sidedef or even linedef limits. But maps with tens of thousands of monsters and sectors are precisely those which still need reject tables to run performantly due to the inefficiencies of using the BSP tree to check line-of-sight. Building reject tables for very large, complex maps is increasingly a problem. While workarounds were found for most of Bemused's work, the same tricks failed for the later maps in Sunder. Only one, map15, has a nontrivial reject table -- which unfortunately was not even built with publically available tooling, but with some arcane process known only to Ribbiks. The state of the art has improved a little since 2018-9, with ZokumBSP -- TTBOMK, the only remaining maintained reject builder -- now able to build Sunder's reject tables, but with its lack of UDMF support (and Zokum's primary focus being vanilla Doom) it seems prudent to look for another approach. That approach is of course to change the line-of-sight algorithm to one that is far more performant. Having P_CheckSight use the blockmap instead of the BSP tree sidesteps the problem, to the tune of a fivefold improvement in one case I measured. ZDoom has of course been doing this for years, allowing ZDBSP to ignore the problem entirely and even fully omit the reject table from wads it builds instead of filling them with huge blocks of zeroes by default. Moreover, I recall entryway mentioning how much faster the Heretic algorithm was in comparison when he added it for v1.2 demo compatibility. In my own experiments, I observed a reduction from 7.87 to 1.39 seconds, that is an increase from 23.6 to 134 fps, in running 186 tics of -nosound -nodraw -timedemo standing still at the start of Cosmogenesis map05 (obviously first having zeroed out its existing reject table :) ). Just remember that you would need to fix the corner bug.

If you are partially invisible, a random angular deviation is made to the monsters' aim. [1], [2] That's it. That is its only effect.

I don't know if it makes any difference but every CWILV graphic is included twice in the PWAD, with the earlier ones having the title written nearer the top of the 320x200 image than those that come later. Funnily enough, earlier, at first I thought you had miscredited TVR, which has a similar but distinctly different blue starry sky texture. But then I noticed you had used TVR's version of ASHWALL6/RW27_2, explaining its credit. Having done some more searching, it seems since recently DSDA-Doom deliberately detects fullscreen CWILVs and work around them. (This strikes me as potentially unfortunate for cross-port compatibility...)

Sorry to say the pun in the title did not work for me. It just looks misspelt.

It would, because it is precisely the sky texture from DOOMCITY.WAD, edited to tile vertically. :) (BTW, FWIW, this seems to be missing from the credits)

This is one of the many effects of voodoo dolls and the zombie player bug. You have a map where there is more than one player start. One of them is linked to the real player's view and input. The others are known as voodoo dolls, because when they take damage it is also applied to the real player. If the real player runs out of health, he dies as normal. If no individual player object takes enough damage to die, but the sum total of damage done to the real player and all voodoo dolls exceeds 100, the real player's view weapon will lower and he will no longer be able to attack, but he still may move around. If one of the voodoo dolls takes enough damage to die, the real player's view sinks to the floor and he can no longer move. But his in-game object is still alive. Monsters will attack it until it dies, whereupon the real player will "die" a second time. I think the latter is what you observed. If you (the reader) are not familiar with this, it is likely you play most of your Doom with ZDoom, which keeps voodoo dolls' health in sync with the real player.