Aurelius

They do work, you just have to put the sector action thing in the control sector of the 3D floor.

Agreed, Diabolist is one of faves as well. It's indeed very possible to make one in MBF21, pretty much to the same effect as in Supercharge. I finished a prototype roughly two years ago, even after initially thinking it might not be possible. Testing it out in the latest DSDA-Doom, some weird stuff was happening, but it could just be that I didn't find the latest version (of the Diabolist). Here's a clip: My first attempt had the flames follow the player even behind walls, but I opted to go back to the more classic approach where the flames are only spawned when there's a sightline.

You can change the sound lumps a monster uses from the Things tab. People commonly replace the sounds of the Wolfenstein SS, Commander Keen and Icon of Sin, but there's also some unused sound effects like: DSSKLDTH (unused Lost soul death) DSFLAMST (used in the Arch-vile fire attack but never played in-game due to an engine quirk) DSTINK (a multiplayer sound not used in Doom 2, at least according to DoomWiki) You can find a comprehensive list of sound uses here.

Change your '<=' to '==' so that the two checks will only affect the desired skill levels, and not everything below them as well. More info: Also, it's more readable to refer to things by their typename and not number. So T_BARON instead of 3, and so on. Check this list for reference

It's hardcoded behavior. From MTrop's DecoHack docs: The plasma rifle's muzzle flash is called at random between [FlashFrame] and [FlashFrame]+1 on a call to A_FirePlasma. Each gun has both a fire state and a muzzle flash state. Fire state activates when you press the fire button with said weapon equipped, while the muzzle flash starts when the given fire codepointer (in this case A_FirePlasma) is called. Muzzle flash sprites are then overlaid to the fire state sprites. This is why their timings must match, so that the correct sprites are being overlaid at correct times. To have full control over the animation, you can set the desired sprite order directly in the fire state. This way there won't be any randomization beyond what you (potentially) would want, depending on your format. You can then use the muzzle flash state for the light changes (A_Light0, A_Light1, A_Light2) with blank sprites, but consider that the randomization is still there, so you'd have to use identical frames for the two and then define more frames for further light changes. You can also forgo using the muzzle flash state entirely and do everything in the fire state. You can use 0-duration frames to have multiple codepointers happen simultaneously, in case you want light changes during actual firing behavior (like A_FirePlasma and A_Light2 for example). However iirc the muzzle flash affects the Doomguy sprites from 3rd person view, so if you care about multiplayer (or just having accuracy there in general) you need to use the muzzle flash state.

Did you add editor numbers for you custom actors? You can set them in MAPINFO.

I'm so used to ADS playing modern games that I feel somewhat inaccurate without it. It's a funky placebo thing where by right-clicking I feel more "focused" and (at least think) I can land better shots. In Doom though, with auto-aim and relatively big projectile sizes you usually hit what you're aiming if you're in the general direction, so it's a different feel. I like the Turok 2 approach (can't recall if the first Turok had something similar) where you hip fire all guns by default, but for a few ones you can zoom in with a scoped view to get those long distance hits. Either way is fine really. After 10 minutes or so I get used to whatever scheme the game decides on anyway. As Murdoch said, it's all about the implementation, not so much the concept itself.

A filter that only shows textures with transparency in the texture browser. Especially with larger texture sets I often wish I could quickly scan through all the options for partially transparent textures like fences and windows. Even with surprisingly consistent naming conventions (like FENC or MID) you can still miss some.

As a side note, OTEX exists in pk3 format as well, so you could try downloading that and see if it works. It uses ANIMDEFS instead of the Boom lumps.

What port are you testing with? I tested your files with Chocolate Doom, Woof! and DSDA-Doom, all it worked fine for me.

As mentioned by ETTiNGRiNDER, your projectile speed is too fast, which causes wonky behavior. A good rule of thumb is that the projectile speed should not be faster than twice its radius. You can get away with deviating from this rule (mostly by reducing the radius, not by increasing speed), but it's mostly trial and error to find a good balance. Personally, I've never used a projectile faster than 32.

There is a Link values button next to the scale options that links two values on a given row. If you want to modify scale on one axis only (in this case, mirroring in the horizontal), make sure the values aren't linked.

You can set generalized Boom actions monster activatable by setting their Model property as Numeric instead of Trigger. Example map.

No specific system requirements to share, as there really isn't any data on performance with different hardware apart from people commenting on this thread. For some tips and tricks to make the map run better, check out the Technical stuff and requirements section in the OP, specifically the Performance options part. You can also check out MrLordi's post for some further recommendations. Hopefully some of these will help!

In the line properties menu, go to Other Properties and click the Show All box at the top. The property you're looking for is Lock Number. Refer to https://zdoom.org/wiki/Key_types to figure out which key / set of keys you want.