rhinoduck

I think ZDaemon has an issue with them being placed directly on top of the linedef they are supposed to activate; IIRC I've seen the the same issue when aaliens was in development. The solution is simple: Move the dolls or the linedefs so that the doll's centre does not sit directly on top of the linedefs (i.e. the distance between the centre of the voodoo doll and the point it should cross the line at must not be zero), ZDaemon will then detect the line activation. Writing this from memory again, so someone best test it. If the above won't help, another possibility is to move the lines outside of the doll's bounding box (i.e. to not have them overlap at all); but I think the first approach I mentioned should be enough. I also noticed a couple of issues with coop starts in tnswutil's output when checking which maps make use of voodoo dolls... MAP08 has three player 2 starts and none of the higher ones; MAP14 is missing coop starts.

Indeed, that's what it looks like. The problem here is that Vanilla only has a single 'thing is in multiplayer' flag (unlike Boom which has two additional flags 'not in dm' and 'not in coop') so the desired effect cannot be achieved this way; the things will always appear in both dm and coop (I assume you're aiming for Vanilla/limit-removing compatibility). I think this may be the desired behvaiour for Icon of Sin maps; you'd get monsters stuck within each other at the target spots otherwise; but i guess whether that will happen often or whether it is a problem depends on the overall design of the map and author's intentions. Anyway, this is why it behaves the way it behaves for D64 in ZDaemon now... Here's an excerpt from ZDaemon's changelog: 4. 1.10b03 release (2015-01-01) ----------------------------------------------------------------------- ... 22. A "monsters telefrag each other" option was always forced on on any map called "map30"; it's useful for the "Icon of Sin" map in doom2.wad, but not for other WADs. We changed it so that this flag is turned on for map30 only when doom2.wad is loaded and it's the only wad. In this way it will work for normal DOOM coop, but it will not conflict with other WADs (one can turn on that flag from mapinfo for any map on newer WADs). And here's the MAP30 block from D64's MAPINFO lump: map MAP30 "The Absolution" levelnum 30 sky1 SKY3ATAL forcenoskystretch next EndGameC secretnext EndGameC titlepatch CWILV29 music D_OPENIN cluster 8 allowmonstertelefrags The MAPINFO flag responsible is AllowMonsterTelefrags. It may be possible for the server host to override this (without editing the original PWAD) by loading another PWAD with a MAPINFO lump with a new definition for MAP30 (omitting the flag) to get rid off this behaviour on a particular server; mind that I think this should work, but I did not test it.

There is an RSS feed for each (sub)forum now. For example, if you want to subscribe to DW News, go to https://www.doomworld.com/forum/20-doomworld-news/, scroll to the bottom, and locate the RSS icon on the right; depending on your bowser, an RSS icon might also appear in your address bar.

The first thing that came to my mind as well xD

The Cure - Lullaby

The torches used to have the "Not cooperative" Boom flag (at least) in the version from 2017-06-05 which was masking the issue in boom-compat ports. The flag has since been removed in some subsequent release revealing the problem everywhere. Vanilla being the target, this approach was doomed from the start.

Results of static analysis to somewhat expand on damo2k's report... Coop starts $ tnswutil -c coopstarts -w sf3_c.wad ... ---MAP08 1 1 1 0 ... ---MAP21 10 2 0 1 ... As for MAP13, there are multiple (of each) p2-p4 spawns at the start. Scrollers potentially problematic in ZDaemon I only listed them, I did not check them in editor this time. Also, this command is not present in the current tnswutil release yet. Btw, as long as the length of the resulting vector for scrolling the sector is at least the minimum required value, it "should" (I didn't redo the test now) work ok. What it means in practice is that the scroller in MAP02 should work fine even though there are such short lines, because if you combine them (they all have the same tag and thus affect the same sectors), you will get an effective length of 64 (assuming they all face the same direction). OTOH, MAP22 will be problematic even after combining the lines as you will only reach an effective length of 16 (again, assuming they both face the same direction). $ tnswutil -c zdaemonscrollers -w sf3_c.wad ---MAP02 line: 2209; special: 253; tag: 11; length: 16; line: 2212; special: 253; tag: 11; length: 16; line: 2238; special: 253; tag: 11; length: 16; line: 2241; special: 253; tag: 11; length: 16; ---MAP22 line: 2434; special: 253; tag: 10; length: 8; line: 2456; special: 253; tag: 10; length: 8; W1 Teleports Having someone familiar with the map recheck that the following W1 teleport won't break progression in coop might be worthwhile; there's too much going on for me to give it the time to go after each possible path at the moment. ---MAP31 line: 9656; tag: 118; type: 39 - W1 Teleport Map names @damo2k The WAD does not contiain a MAPINFO so only maps 1-32 which were originally present in Doom 2 will have a name; DEHACKED also allows changing the name only for these original maps (at least in all the ports I am familiar with AFAIK).

That kind of depends... what can be reduced to a "simple" circlestrafing case, or a combination of controlled dodging, monster luring, and infight initiating in SP can become a bloody clusterf*ck when different monsters start targeting different players in MP (especially if large mobs are involved, or if a specific strategy is required). Not that faster monster influx is a bad idea; it just probably needs to be judged map by map and encounter by encounter keeping the above in mind. But these are just my two cents coming mostly from the disorganised world of public survival servers, so, perhaps, keep that in mind too.

Cool! Then we shall still have an out-of-the-box ZD-compatible Stardate 20x7 :) Thanks!

The following scrollers will be extremely slow in ZDaemon: ---MAP04 line: 8835; special: 253; tag: 98; length: 14; ---MAP05 line: 9378; special: 253; tag: 109; length: 16; line: 9386; special: 253; tag: 110; length: 12; line: 9392; special: 253; tag: 111; length: 12; line: 9398; special: 253; tag: 112; length: 12; line: 9404; special: 253; tag: 113; length: 12; line: 9720; special: 253; tag: 131; length: 3; line: 9723; special: 253; tag: 130; length: 3; line: 9917; special: 253; tag: 132; length: 8; See this post for an explanation why that happens and how to avoid the problem. Now, I don't know if you will even want to put the effort into fixing this; if the answer is no, hopefully someone else will pick this up and make a ZDaemon-compatible version (I am refraining from doing so this time). Very minor nit: In MAP32, it is possible to AVJ through the windows to the keys and get stuck there (the probability is tiny, but it did happen to me, heh).

Thanks! I wasn't familiar with EDF at all, so I didn't even know that that's where I should have been looking. For those who might be in the same situation as I was: cflags

Silly question: What does 'cflags' mean in this context?

There is a coop issue with MAP07; the lowering bars lock out usually all but one player at start. And if the player who made it in dies, the map can never be finished. Here is a fix WAD I made for the servers I run: cereal-killer-20170330-coopfix1.zip I tried to keep with the style of the map; here is a bit from the coopfix readme which describes what has been done (the tag numbers should make it possible for everything to be identified): Maybe you will find it acceptable to be used as it is, or you'll have a different idea of what this should look like; either way, it would be nice if the map ended up being coop-friendly in the final release.

The guideline: Make your lines with carrying specials at least 22 map units long to avoid any issues. This actually goes back to at least Boom 2.02, so anyone targeting the original Boom or PrBoom+ complevel 9 should also keep this in mind; somewhat. Unlike ZDaemon, these two ports will accelerate voodoo dolls to intended speed after a real player has moved (as Melon pointed out); other things will still scroll slowly though. Explanation: If the momentum/velocity of a thing falls below a certain threshold, the engine resets it to 0 effectively bringing the thing to a complete halt. Boom scrollers accelerate things by adding only a small fraction of their speed value to the thing's momentum/velocity each tick; it thus takes multiple ticks to accelerate the thing to full speed. For very short scroll special lines, this fractional value will be below the above-mentioned stop threshold, and thus the thing's momentum/velocity will get reset to 0 each tick effectively making it move at only a tiny fraction of intended speed. The details: The threshold value: STOPSPEED = 0.0625 The multiplier to get the fractional boost value: CARRYFACTOR = 3 / 32 = 0.09375 The formula: carry_speed_increment = line_length / 32 * CARRYFACTOR Results for line lengths around the critical point: 21 -> 0.0615234375 (less than STOPSPEED; will get reset each tick) 22 -> 0.064453125 (more than STOPSPEED; will start accumulating properly) The exact break is at 21.333 (periodical), but 22 is easier to remember and measure. Source code references: This is the part responsible for resetting the momentum/velocity (GitHub). The example comes from ZDoom 2.8.1, but it is functionally identical to what appears in the source code of ZDaemon 1.06; from observation, it remained the same in ZDaemon 1.10b07 also. This is the way the issue has been remedied as it appears in ZDoom 2.8.1 (GitHub). The acceleration will be smoothed out only if the fractional value would be larger than STOPSPEED; if it won't be (it won't be for scroll line lengths <21.333), the thing is simply moved at the scroller's full speed right from the start, and the whole momentum/velocity accumulation is not used. This also means that, in these cases, the thing will come to a complete stop as soon as it leaves the scroller because there will be no momentum/velocity accumulated; but it will move at intended speed while on the scroller. Obviously, ZDaemon is missing this fix/workaround. Both examples come from the P_XYMovement() function located in p_mobj.cpp.

In MAP32 (as it appears in b6), tag 30 can block progression in coop if no one survives the trap to unlock the area. Or at least this seemed to be the issue people got stuck on in the server; I wasn't able to spot a way around it while taking a quick look in DB.