andrewj

It's a Slime Trail, see: https://doomwiki.org/wiki/Slime_trail Some node builders can help minimize the chance of it, otherwise fiddling with the angles of lines in that area of the map (testing each time to see if it still occurs) is all you can do.

Oh, what makes it unfriendly to multiplayer?

The utility is DEUSF, but it only needed for people using DOS, every source port on modern systems supports sprite replacements in a simpler way, e.g. Chocolate-Doom and similar ports require using -merge instead of -file when giving the pwad.

Try the +NEVERTARGET flag.

You can't control the initial weapon, but via DEHACKED you can set the initial number of bullets to zero.

As I understand it, it is something old editors used to do, and was usually fixed by the nodes builder. Eureka and glbsp/ajbsp all have some "lax" logic to detect such levels. I would assume all source ports would crash and burn with such a case, but I guess ZDoom allowed it at some point. I noticed the ticket for the blockmap issue later on last night, and understand it can't be fixed unconditionally due to demo compatibility.

@fabian The following 7z archive contains an updated nano_bsp.c for Woof! which fixes the infinite loop problem. It includes the last five commits from my repo (ending with 12ec4f), plus I removed the local copy of R_PointToDist() and instead it calls P_GetOffset() from p_extnodes.c. The planisf2.wad map is working for me now. nano101.7z BTW, I am glad you support a -bsp option to force generation of nodes, it was something I was thinking of myself. Another BTW, you probably don't need to call the slimetrail fixing function for the XNOD family of nodes, since their vertices (for splits) are already in 16.16 precision. PPS, I get collision problems in planisf2.wad in the NE area of the map, around X=6000 Y=8800 (over quite a large area actually), which must be the blockmap builder, since I tested with the wad built with ajbsp (with XNOD format) and the same thing occurred at that location.

Yeah it is quite a "monster" :) Well, the issue is primarily about a loss of accuracy (due to fixed-point math), where one part of the code thinks a seg should be split, but the computed intersection point ends up in a place not really splitting the seg. Will be working more on it tomorrow.....

I will check it out that wad and see if I can reproduce the problem.

BTW, I just simplified things a little bit more and removed the "side" field which I added to the seg_t struct. That value was only needed to compute the offset, and can be determined easily enough by looking at the deltas.

It is sufficient to just rename it (via File menu) and change the project settings (also in File menu).

This is probably because Doom 1 uses map names of the form ExMy where x and y are numbers, but Doom 2 uses map names of the form MAPxy, and with vanilla and chocolate doom you need the right name (you cannot run E1M1 with Doom 2, or MAP01 with Doom 1). Source ports usually relax this, but it is a good idea to stick to that convention. You can rename the map (via the File menu) if you started off with the wrong name.

Ahh, that is an important case which I hadn't tested yet, but I just did and it works fine :)

I felt like working on this today, and I'm pretty pleased with how it has turned out. It should more-or-less drop into a code-base, but note that seg_t still needs two additional fields, that was fairly unavoidable. It should work with the larger indices in Woof, like children[] of node_t , since I use int rather than short, and it will pick up the new NF_SUBSECTOR flag. But let me know if any issues come up, happy to discuss any aspect of the code :)

Yeah, it does make for a better UX when things "just work". I will begin adapting the code to be more suitable, not sure when, probably next week sometime.