Xaser

Check out DECOHACK (and its sister tool doommake) -- works natively on Linux, and it lets you add flags on existing actors without needing to know the old ones (i.e. it will fill in the gaps for you when building the patch). Much more user friendly than trying to write a patch by hand (which is painful no matter how you slice it).

A_FireOldBFG has surprisingly good port compatibility -- it was introduced in MBF (complevel 11), which every modern "Boom-compatible" source port also supports. Did a quick search and it's present in DSDA-Doom, Woof, Eternity, GZDoom, and even OG PRBoom-Plus, to name a few, so you're good. That said, I gotta do my usual thing and also point at MBF21 if you haven't seen it yet, since it's got a ton of new DEHACKED features and is also supported in a wide range of ports. If you're looking at using the beta BFG codepointer for the sake of crafting something brand-new (i.e. not emulating the beta BFG exactly), there may be some other tools in the MBF21 kit that may work a bit better. If you end up going that route but still want the beta BFG's bouncing behavior, adding MBF's "BOUNCES" flag (along with "MISSILE") will do the trick. [EDIT] If you're looking to do a 1:1 beta BFG emulation, you'll need to modify the weapon states a bit too (i.e. call A_FireOldBFG several times over many frames, instead of just the once) -- the ZDoom wiki has the state sequence, as a handy reference.

The latest common cross-port standard is a thing called MBF21 -- it's a Boom successor, and is supported by the vast majority of commonly-used source ports. I would highly suggest starting here -- going any "lower" is just limiting yourself for no reason, unless you wanna target pure vanilla Doom (not recommended for newcomers, it's hard :P ). Also check out UMAPINFO while you're in the neighborhood -- it's a very important feature that's also supported by the same family of source ports as MBF21. Just a heads-up, the best answer to "hey what common format do I start with?" used to be Boom, so you'll still see a lot of posts/articles/etc recommending it, but these answers are all out of date, without exception. MBF21 is rather new -- the 21 stands for 2021 -- so common knowledge is still catching up with the present day. For nodes, use ZDBSP -- that gives the best results for maps that aren't aiming to run under vanilla limits (zokumbsp is the best option in those cases).

This is sort of a slant answer since it's not a standalone mod (yet? ;), but I overhauled the jump physics in Adventures of Square to be friendlier in general (remove the delay, add a bit of "coyote time", and some other related platformer feel-good-ness). May be worth taking a look at that and yoinking the code out of the player definition... or remind me this afternoon and I'll do it. Been meaning to, just forgot. :P

I tend to straferun in whichever direction allows me to most efficiently collide with a rocket.

Cacowards have been given to projects in a "near-final beta" state many times before. This isn't anything new.

Huge Congrats to all the winners, mentionees, and other associated purveyors of chaos. Here's to another 30 years.

The unkillable-ghosts thing is probably because the A_RadiusDamage call is dealing damage to the FamineSoul itself, making it randomly jump to the Pain state. Try giving it the NORADIUSDMG flag -- or if you want the explosions to be able to kill other FamineSouls nearby (i.e. to set off a fun chain reaction), use A_AddFlags to give NORADIUSDMG in the death state just before calling A_RadiusDamage. That should fix that up.

@OP, you should probably show something of your own first -- you just signed up to the boards today and have 3 posts, and no other social media presence that I can see -- how do we know you're capable of successfully running a community project? It's way tougher than it looks.

The rerelease is essentially an improved, more feature-complete version of Doom64 EX, not the other way around like how PC Doom sourceports tend to work. Nowadays you typically only want to reach for ye olde EX if there's no other option (e.g. trying to run an old mod/map or somesuch).

Truecolor (i.e. non-paletted) graphics aren't something the original games support -- they work in GZDoom and a few other ports, but not Crispy, etc.

Did you convert those graphics from PNG over to Doom Patch format? If not, that would explain the intermission screen crash, since INTERPIC is one of the lumps in question.

This thread is for people to show off the cool stuff they've made -- putting requests in the middle will just clutter it up.

Damn! I'm getting too predictable. :P Thanks to you for helping push forward all the cool new tech (and making some damn good maps in the process ;) -- y'all are doing the real work here, I'm just a messenger.

Nice to see this using episodes and secret maps (hell yeah), though I gotta at least pitch MBF21 as the target map format -- it's got a couple of line and sector specials that will really come in handy for some of the map themes (e.g. void-city would benefit a ton from insta-death sectors and the "block land monsters" line), it's a superset of Boom so folks aren't absolutely-required to use all the new tools (i.e. they're not locked out of making something in the config they're used to using), and it should already be available to all the mainline ports that support UMAPINFO and Boom. Easy upgrade.

All of them, so far. Haven't seen a dead one yet.

True :P

It's better to have the files included so power users (i.e. people installing source ports) can find what they need rather than being absent completely.

DECOHACK is absolutely the way to go, both for MBF21 and vanilla things even -- it takes a bit of up-front setup but it makes life way easier than doing any sort of dehacked patch the old way (no more "state jump spaghetti", it'll figure that part out for you ;P ) [EDIT] while on the topic, certainly don't write the text by hand, that's an exercise in masochism ;P -- I've seen loose reports of people trying to do it that way, and its painful. The MBF21 extended features were designed to be easy for tools and source ports to read and write, not humans ;P

It's still sorta "swim at your own risk" territory since the UDB devs aren't Linux users themselves, but I was able to get it all working on my box (which uses an Ubuntu fork, for reference), and that was the magic missing step. (Also sorry for being weirdly blunt in my last post, that first line of mine is way too much like "the previous answerer is WROGN!!!1" in hindsight :P )

Sorry, the above posts are misleading -- it isn't necessary to manually run a nodebuilder; there's just an additional one-time configuration step you'll need to do on Linux. In the directory where the UDB executable is installed (can't remember the default path on Linux, which varies by distro anyway), find the "Configurations/Nodebuilders" subfolder, open up the .cfg files in this directory, and remove ".exe" from the end of the lines that have "program =" in front of 'em. That should make everything work, since you've already got zdbsp installed.

Personality is also a learned skill. Socializing too. Both worth developing just to make life better in general -- not always easy to do, but don't let anyone ever tell you it's innate. It ain't. :P

This is sort of a rehash of previous posts, but a lot of what folks tend to perceive as "natural talent" is really just the ability to apply an existing skill when learning a new one. There's a lot of forms this can take (e.g. see mouldy's post about prior art), but one of (if not the) most important ones is the ability to accurately self-critique your works and then iterate, i.e. recognize "hmm this doesn't work", figure out why, then use that self-feedback to make your stuff better. This is one of the hardest things to learn when pursuing any artistic (or even scientific!) discipline, but people who build up this skill tend to have the easiest time picking up new skills since they're able to apply this process to figure out how to learn it most effectively. It's like a force multiplier for learning -- it's great. Relatedly, I've heard plenty of stories that go along the lines of "I took a music composition class and it made me a better mapper", even though you'd think those two disciplines wouldn't cross over that much*. Developing the "artistic eye/ear" absolutely translates across fields. It even makes you a better programmer, though that's a topic for a different thread, I think. :P [*we do have quite a few musician-mappers in the community, though, and many of them started as mappers and picked up midi tracking as a hobby, then just kinda kicked ass at it seemingly almost immediately. Food for thought. ;]

Try "disabling" the crusher section with a walkover line (or two or three) that's only reachable by Player 2 -- e.g. put the Player 2 start somewhere that Player 1 can't reach, like a high ledge in the start room, then have the trigger up there. Since the crusher is reached via teleporter, I'd probably make the disable-trigger "swap" it with a second teleporter (e.g. close one teleport sector and open another) that uses a WR action and skips the crusher-activate linedefs. May need to scoot around some map geometry to fit, but it all oughta work without needing to reach for anything port-specific. For BTSX et.al, I've gotten a lot of mileage out of this sort of "player 2 activates a co-op shortcut" trick. Beyond just fixing up stuff to work better in MP, it's a great way to let respawning players jump back into the fray in a large map, so it's a useful thing to have in the toolbelt. [EDIT] Here's a gordian-knot-cut that may be easier in practice, provided you're fine maintaining two versions of the map: make a copy of the map called MAP14B or somesuch, convert it to Doom-in-Hexen (no UDMF support for ZDaemon IIRC), then use MAPINFO to go to that map instead of MAP14. From there, you've got full control over TIDs in the map, so you can script up the co-op fix without the trouble. IMO it's not as ideal as going the vanilla route, since you'll have to maintain two maps in case of any future bugfixes or edits, but it's worth a try if the other way gets too tricky in practice. It'll allow the fix to live within the same wad, rather than a separate patch, so that's one base covered.

The vast majority of the time when folks say "ZDoom", they mean "GZDoom" -- back when ZDoom-proper was still in development, the two ports were basically in lockstep on feature development (aside from GZDoom-specific hardware renderer things), so "ZDoom" and "GZDoom" were effectively synonyms when it comes to feature-support unless discussing something hardware-specific, and that's still pretty much the case today since it was the norm for so long. Using "ZDoom" to refer to the entire extended family, including Zandronum, ZDaemon and Odamex, is very unusual despite being technically correct to a degree. You'll have to explicitly name these in order for folks to understand what you're looking for. Back to the matter at hand: my eyes skimmed over the word "vanilla" in the opening post, and in that case an ACS patch is certainly tackling the problem from the wrong end. If there's something in the map that works in vanilla but not in the "Z-family" ports, or if this is a multiplayer-specific issue, there's usually something that can be fixed up map-side as long as you're not doing something crazy on the level of, like, KDiKDIZD :P. It'll probably be less of a pain to post or describe the setup in the map (e.g. why does this crusher need special behavior? what's broken?) and approach a map-side solution, rather than trying to band-aid over it in a language that wasn't designed for this use case (ACS is a very poor fit here no matter how you slice it, unfortunately). If the undesired behavior seems like it's a port issue, it's also worth bringing to the devs' attention so it can get fixed there instead. If ZDaemon is indeed the odd one out, its most recent release was two days ago -- development is plenty active there.