Aurelius

To add to what JadingTsunami said, some nodebuilders are better at doing this than others. Funnily enough, I had to go through more hoops with a vanilla optimized ZokumBSP than DeepBSP, the latter of which had no issues whatsoever a simple self-ref 3D bridge setup. I recommend trying to swap your nodebuilder to DeepBSP if you're using something else (in my personal experience, the default Zennode is usually not good for, well, anything). Here's a link to a working prototype faux 3D bridge using a self-referencing sector, with nodes built using DeepBSP. You can take a look, just in case there's something amiss in your own implementation.

They don't. However, I suspect you didn't generate a new COLORMAP to go with the new palette. The software renderer uses the COLORMAP to determine how colors fade from one to the other in different light levels and under diminished lighting. If your new palette shuffles things around a lot, the new ranges won't match the existing patterns in the Doom 2 palette, which causes the default COLORMAP to be a garbled mess. In Slade, you can click on your PLAYPAL lump, then go to the Palette options menu and choose "Generate Colormaps" to generate a new COLORMAP lump. Also, just in case you didn't do it yet, also choose "Generate Palettes" so that the appropriate pain, item pickup and radsuit palettes are added.

At this point it could be any number of things. I've taken your script as it was originally, added the NoiseAlert call and placed the appropriate actors in a map. It all worked as it should. No drastic redesigns should be necessary, these mechanisms aren't that complex. Most likely some other part of your setup is either incorrect or interfering in a way that you might not even realize. At this point it'd be easier if you just posted the relevant files. If you don't want to share your project publicly, you can DM it to me directly and I'll take a look. That should save plenty of troubleshooting time for all participants.

I tested it, and it works fine. I added NoiseAlert(0, 49); to the end of your script. This alerts all monsters near a thing with tag 49 to the player's (first arg 0) presence. Since your Cacodemons all have tag 49, they become emitters and alert each other (and themselves). Make sure they don't have the Ambush players flag set, because if they do, they won't move until they have a sightline of the player. Also, you mentioned they are behind a wall and float to the playable area? This could mean that they are already alerted to the players presence unless you're using sound blocking lines as Stabbey mentioned. The Ambush players flag would explain why they're still not moving even if they can hear the player. If this is the case, you don't need to use NoiseAlert, and just removing the flag should work (if they're dormant, they'll only attack when they're activated as long as they're alerted).

The script itself works as intended. Maybe they just haven't been alerted? For monsters, ThingActivate will only remove the DORMANT flag, but it will not alert the monsters to the player's presence. You can make sure they either see or hear the player before activating, or use NoiseAlert if they're in a separate space and cannot interact with the player prior to being activated.

Function arguments are separated by commas. You only have one comma, so you've only set two arguments, not three. By default, the optional third argument is set to -1, which means whatever the line itself is set to. That's why the action was not repeatable until you toggled the "Repeatable" flag. Replace the second bitwise OR with a comma to make 1 the third argument of the function, or remove it entirely and set the line itself repeatable. Either way works.

First off, script 20 only has a single action (Teleport) which already exists as a predefined line action (70), so there's no point rewriting it as a script unless you're adding other actions to happen alongside the teleport inside the same script. If not, just remove that script and use line action 70 instead. The first arg of SetLineActivation should be the tag of the lines being made activatable, not the destination thing. SetLineActivation doesn't know or care anything about the teleport action, only what lines to give activation flags to. Currently it's told that a line with a tag 39 should be made activatable with SPAC_Cross, but since there's no such line, nothing will happen. SetLineActivation will only set the activation method of your line, not the action itself. So make sure that the teleport lines have the Teleport action set, but leave the activation method empty (no boxes ticked). Also make sure these lines have a tag so that SetLineActivation knows what lines to activate. Also, if you want the action to be repeatable, add a positive number (like 1) as a third argument to SetLineActivation (see the wiki article).

You can first use paint selection or regular group selection to choose all sectors (paint selection allows you to have them in desired order). Then from sector properties, you can add tags using using the >= syntax. For example, if you selected four sectors, and set >=101 in the tag box, it would give them tags 101, 102, 103 and 104 in order of selection. Alternatively, if you want more control over increments, you can also choose the Tag Range option (top row in the toolbar, right-most symbol, looks like an actual tag).

Are you using A_SpawnProjectile? It has args for spawn offsets (both horizontal and vertical).

A really neat set of maps, always love to see more complex vanilla mechanisms in action. Enjoyed all the puzzles. It takes some doing to make vanilla puzzles feel distinct enough from each other given the limited set of tools, but I think you pulled it off nicely here. Found one "bug": Another thing that's not really a bug, but messed with my brain: Keep it up! Would love to see more stuff like this in the future.

There's a bunch of textures that are identical to their IWAD counterparts (RW22_1, SW3S0 etc.), which is most likely the cause of your rejection. Removing the duplicates solves the issue as you said, but at least for me there were no duplicate patch errors. The only errors I saw were from missing switch textures, which I assume are the ones from cc4tex you didn't end up using and had deleted. The SWITCHES lump still contains references to those deleted textures, which causes the errors. You can take a screenshot of the command prompt list when you run the wad, and then just manually delete those switch definitions from the SWITCHES lump. It might seem like a long list but it's just a few minutes of work. DoomTools should be able to do this, but I haven't used it myself to compile texture stuff so can't help you there.

Does the crash happens in MAP15 or MAP16? You say the error occurs when trying to load MAP16. Do you actually get to and past the MAP15 end tally screen? If so, the error is probably unrelated to the boss monster and there's something in MAP16 that's causing the crash. You can drop the files in DM to me if you want, so I can take a look.

Haven't looked into the maximum size for M_DOOM, but you can adjust the position of the image in-game by changing its offsets in Slade, just like you would adjust sprite offsets. This is something you usually have to do whenever your images are larger/smaller than their vanilla counterparts.

This such an incredibly cool concept, I don't think I've ever seen anyone make maps around demos like this. A fresh and unique mapping restriction, community project worthy even, I'd say. Also, happy birthday to 4shock, and congrats on your recent achievements!

Your sprite names follow the appropriate naming conventions, but they have to be named with the exact sprite prefixes that exist in Doom 2, or the added SP00 to SP99 range that DEHEXTRA introduced. This is because in Boom, MBF and DEHEXTRA format dehacked you are not allowed to add new sprites or rename existing ones, so you have to use names that are available. In vanilla, you can rename sprite prefixes, but it still means replacing something that is already there. DSDHacked allows sprites of any names to be included, but DEHEXTRA is currently more widely supported, so if your project does not contain a boatload of new things and sprites then DEHEXTRA is probably sufficient. As such, prefixes like STAT, TREE and TRET do not exist in Doom 2 or DEHEXTRA. You can name your STATA0 into SP00A0, TREEA0 into SP01A0 and TRETA0 into SP02A0. Or you could clump together static sprites of similar style and put all tree sprites into SP01. However you want to organize. You could also look into DoomTools for your dehacked needs (Decohack more specifically), as it makes modification and iteration a great deal easier. Here's an introductory post I made on the topic.