Xaser

@knifeworld Some people are much faster at using the command-line than a GUI tool. It takes me a lot less time to type out the name of a WAD file (not that I even have to -- tab-completion does the trick) than it does to find the WAD in a file picker dialog or open it up in File Explorer to drag-and-drop it somewhere. Plus, if it's a wad combo I load frequently, I'll toss together a .bat or .sh script to make loading it even faster (e.g. I can just type "supplice-dev" to fire up Supplice with all the right -file/-iwad args instead of manually writing it out each time, 'cause I launch that one quite a bit ;). Launchers and drag-n-drop are good too -- folks oughta use whatever's most comfortable to them. But for some of us geeks, that's the good ol' terminal.

Way back on the Skulltag forums, there was a minor meme where folks would jokingly suggest "tech temple" as a theme for a map, because of how goofy it sounded. And here you are making a reality, and kicking ass at it. :P

All you need to do is pick the MBF21 config instead of Boom in the dropdown from UDB -- that's it. You can even do that after a Boom map has already been created, since it's the same format under the hood (i.e. no conversion necessary like if you were going to UDMF). It includes all the familiar Boom specials, plus a bunch of new ones, so the only thing you need to do to use it is... use it. :P

This definitely seems like something to change on GZDoom's end, worth opening a bugreport there. I can't think of a reason why you'd want to exclude voodoo dolls from the comp flag; I've heard of plenty of voodoo-scripting-timing-difference anecdotes over the years and this is certainly a relevant thing (if not the thing).

This advice is only a small part of this balanced breakfast, but one little digestible "nugget" of designing good gameplay is: try and make it so the player is engaged by enemies from different directions (e.g. forward, from the side, from behind, pincer attacks, etc). It sounds like a small maybe-obvious thing, but maps that only ever place monsters directly in front of the player and nowhere else usually feel very "flat", gameplay-wise. Thinking about this area tends to lead to more interesting/creative designs in general, I find, and modern classics tend to be very good at this particular aspect.

Doomworld regulars tend to be extremely skeptical of any sort of "hey, I'll pay you to make a mod" sort of post because the following are very common: The project pitch is something nonsensical and/or impossibly huge in scope The offer is insultingly low The OP is not suffering from #1 at all (which is nice for a change), though #2 remains to be seen. The pitch is clear enough that someone could probably give you an estimate, though, which is a big leap above most such posts. There are a few cases of commissioned work floating about, but that's generally artists or musicians who know how much they ought to charge for. I'm not sure offhand if there's really been many successful cases for coding, e.g. "paid to make a mod" type deals, 'cause of the two bullet points above, so this is somewhat uncharted territory as far as the community is concerned. That and most people's maps have the words "here be dragons" written over that spot. ;)

GZDoom has a "compat_boomscroll" compatibility flag you can set in ZMAPINFO -- try setting that and seeing if that resolves or improves the issue. There's a weird "flaw" in Boom's conveyor belt code that has been carried forward into all demo-compatible ports (by necessity ofc): when a thing's bounding box touches more than one scrolling sector, the scroll thrust for all sectors is applied to the thing. This means, in effect, that if your scrolling conveyor belt is split into multiple sectors (which is almost always the case except for simple voodoo closet setups), then it's going to double-apply the scroll to actors for a couple of tics while it crosses the sector boundary. It's jank as hell, but it is what it is. GZDoom by default only applies a single scroll thust at any given moment (IIRC if the actor is touching multiple scrollers it averages them all -- don't quote me on that though), but the compat_boomscroll flag re-enables the old behavior. No idea if that will make it 100% accurate, but it certainly won't hurt. :P

It's less of a technical reason and more of a historical one. There are a few things in the EXE that DEHACKED could have changed (e.g. par times), but never got around to adding for whatever reason. The line between vanilla and not isn't perfectly straight, but the definition for DEH as far as Chocolate Doom is concerned (which, let's be frank, is the real arbitrator of what's considered "vanilla" ;) is "could dehacked.exe do it"? In theory if someone were to develop a dehacked.exe successor with new features and sell fraggle on the idea, there could maybe be some sort of "new vanilla features" standard... but that starts to feel a whole lot like re-treading old ground. Plus there are so many cases where I'm sitting here asking "why even make your project vanilla/limrem in the first place?" :P -- like unless you're explicitly going the BTSX/demoscene route of seeing what cool stuff you can do within the limits, most projects of that sort are just leaving "money on the table", so to speak, by choosing not to use features that are easily within reach. Or the mapper really really likes Crispy Doom, I guess. :P

There's kinda two big takeaways here -- well, three, if I can interject my own since it follows from the other two: If you're working on a solo project, shooting for a smaller "episode-length" release is a good idea in general, versus trying to overextend yourself to make a megawad. Stuff's hard. Megawads don't have to be exactly 32 maps. UMAPINFO support is very good these days, and for vanilla/limrem there's never been anything at all stopping folks from making a wad with less than 32 maps (or splitting things across multiple wads if there's more than 32, a la BTSX). When hosting a community project, if you shoot for exactly 32 maps, you're shooting yourself in the foot. On that third point, I've given the spiel a few times in various community threads, but I'll post it here too for completeness. For projects that reserve exactly 32 map "slots" and are popular enough to attract some decent attention, the following sequence of events inevitably occurs: All slots get claimed (i.e. project becomes "full") Further interested contributors are turned away at the door, because the project is "full" Over the course of the project, several people end up dropping their slots, for various reasons As the deadline approaches, it becomes clear there will be less than 32 completed maps Because potential contributors were turned away when the project got "full", there are no additional maps available to fill the remaining slots From here, the project leader has to make a choice. They can either: Release whatever submissions they got Extend the deadline Scramble to try and get a bunch of extra maps to hit the 32 count anyway A chaotic combination of 2 and 3, sending the project spiraling down to the depths of development hell Just give up and let the project die Unfortunately, I see waaaaaaaaaaaaaaaaaaaay too many people not choose option #1 (or a reasonable-timeframe variant of #2) and instead lead their project to ruin, just because of that arbitrary magic number 32, and for absolutely no other reason whatsoever. There are several semi-abandoned threads in the community projects subforum at risk of #5, despite having ~20-ish submissions, which is just senseless. :P Even beyond the community project angle, there are plenty of reasons why your well-oiled solo or team project should target some map count / structure other than doom2.wad's "32 maps, secret exits on MAP15 and MAP31" formula: You don't have to. No seriously, you don't have to. I'm listing this twice despite how captain-obvious it sounds, because lots of folks either don't know this or are otherwise operating under the notion that they Have To, for whatever reason. If your target port's got UMAPINFO (or another mapinfo variant), the sky's the limit. If not, you're a bit limited in a few areas (e.g. can't use episodes or move the secret exits), but nothing at all is stopping you from targeting less than 32 maps, and your project will probably be healthier and happier for it. 32 maps is a tired cliche. Literally hundreds of projects have already done this, and by following the "tradition", you're doing the same thing that hundreds of projects before you have done. Mix it up, dammit! :P 32 maps is a lot. For a solo project, that's a crazy number of maps to produce on your own. As a player, a solid block of 32 maps is a rather imposing number to play through, especially if the maps lean toward the longer side. Episodes are great -- splitting your project into multiple episodes (e.g. Eviternity 2) provides clear "breaks" for players, plus it works wonders for map flow -- you get the best of both worlds between continuous and pistol start play, and you get more than 1 shot to craft a gameplay scenarios that work best from pistol-start without having to hack in a death exit. Secret levels are great -- they're the perfect place to put strange/unusual/difficult gameplay, and are the ultimate reward for secret hunters. If your secret exits are on MAP15/MAP31, they're not exactly secret anymore, because that's exactly where everyone expects to find 'em. Quit pre-spoiling your secret exits. :P If you don't want secret maps at all, you don't have to add them at all. This doesn't even need UMAPINFO, you can do this in vanilla too. :P The presence/absence of a text screen is not nearly as important as people make it out to be, especially given how very few projects put any emphasis on story/narrative at all. If you've got UMAPINFO, it certainly doesn't hurt to add this extra bit of polish, but if you're in vanilla/limrem land, there's not a damn thing wrong with capping the set off with an "endmap" and calling it done. And fiiiiiiinally... even though this is a repeat of the previous bullet points, lemme tie this waaaay back to the point brought up in the first place: does your project even need to be a full megawad, or is 10 or 5 maps a perfectly solid length? Is your project All Killer, No Filler? That should be your goal, not an arbitrary number of any sort. ;) I do feel like episode-length wads have gotten a big bump in general popularity as of late (e.g. there's been many threads expressing this sentiment as of late, folks like Squonker Team are doing kickass episode-length wads, the DBPs have been saying "screw 32 maps" for years now, and so forth), so part of me feels like I'm choir preaching, but I still do see a ton of community projects (often from people brand-new to the community) fall into the usual cliches, usually to the detriment of the project. tl;dr: pick the format that makes your project the best it can be, instead of just performing a ritual because you saw someone else do it. :P

That's a feature I'd love to see in a source port somewhere, basically a "restart map on new difficulty" that would preserve your inventory. You'd have to restart the map when switching, and to do that the game would need to keep track of your starting inventory upon starting a new map, but it's far from impossible. Could be a boon for players wanting to play continuous anyway. ;) Could maybe make something like this in GZDoom with ZScript even, no source code required, and now I wonder if someone's already done it (I haven't checked autoautosave yet so I dunno if it has The Magic(tm) or not). :P

The word "Mod" or "Modification" is ambiguous -- many people understand this to refer to all types of wads (longer rambling-words on the topic here), i.e. a map is a mod. "Weapon Mod" is also a subset of "Gameplay Mod", so that one's redundant. If we wanted some sort of distinct term here, it'd need some more brainstorming. My understanding is that purely-visual mods are going in the Resources subforum at the moment -- that's where things like Minor Sprite Fixing Project exist right now. The line is a bit grey -- I'd have drawn it at "things meant to be used as a mod as-is" (e.g. MSFP) vs "things meant to be used by modders in their own works" (e.g. OTEX), but some wads blur the line anyway (e.g. Jimmy's Jukebox).

You're reading something in the post that isn't there -- see roadworx's post. Players will trick themselves into having a Bad Time(tm) if they catch the FOMO bug, for whatever reason that may be (heresay or otherwise). There's nothing wrong with someone trying a skill level and deciding "whoa, this isn't for me", and switching -- that's indeed how it works. There's plenty wrong with someone picking a skill level and stubbornly refusing to switch away from it even if they're having a bad time -- this is what folks are pushing back against. [EDIT] Just to tack this on: I do think that the "UV or Bust" population is a vocal minority, and the fact that Doomworld's userbase leans strongly in the other direction (i.e. "to hell with that, play how you want") is a very good thing. The best way to handle this situation as a mapper is to Not(tm). Make some cool maps, add some skill levels, and resist the urge to fudge up your map just for the sake of appeasing/confusing the unreasonable sorts.

This is incorrect. Doom's map format allows you to add flag things to only appear on lower skill levels, not just upper -- it's not a sliding linear scale where every thing in HMP must also be present on UV. Adding additional items, swapping monsters, changing progression (e.g. Doom E3M6), changing teleport ambush spots, and all sorts of interesting changes are on the table (more examples here, though some folks already linked this post above :P ). A UV player might be ""missing out"" on the invulnerability-sphere rampage or plasmagun spamfests I put into a map on HNTR, if that sort of gameplay is more up their alley than the count-your-bullets survival horrorfest I've whipped up on UV (real examples from an upcoming project btw). If you're instead trying to say that not enough map authors take full advantage of this flexibility, that might be something worth bringing up, though that's a topic best served with examples and without generalizations. [Related note: there are many well-known mappers (e.g. Ribbiks) that have explicitly stated that they design for HMP as a baseline. Do folks really want to try and make the claim that they're wrong about their own mapping process? :P ] People are rightfully pushing back against things that reinforce the "you must play UV or you're doing it wrong" stigma. Players shouldn't be tricked into reaching for a skill level that's beyond their range due to some external- or self-inflicted FOMO. It ought to be a conscious decision on their part to improve, to train, or to just accept the consequences (because dying and retrying can be fun sometimes :P ). But there are indeed people out there with "UV only" / "completionism or bust" mindsets that end up in a self-defeating cycle of playing the game in a way they don't enjoy because they feel like they Have To(tm). The idea that one particular skill level is the "most complete" or the "most correct" way to play is a gateway into this downward spiral. The experience is "complete" when the player is finished, not when the map is.

Make sure you have something to show first before starting a thread like this -- you don't have anything at all in the opening post right now.

@DNSKILL5 I hope you weren't posting that video to try and say "yeah, we already know this", because the book decino's showing off in the vid doesn't list where the lion photograph originates from (unlike a couple of the others).