wildweasel

The feature that you're after is a Titlemap: https://zdoom.org/wiki/TITLEMAP

With Dehacked, the sound a weapon makes is tied to the code pointer that is used for the weapon's attack. Unfortunately, the Pistol attack and the Chaingun attack are both hardwired to DSPISTOL, and there is no easy way to change the sound of one without affecting the other. I can certainly think of a couple of Seriously Hacky ways to do it, but they come with very noticeable side effects; the safest would be to simply replace DSPISTOL with a copy of DSSHOTGN, though this would also affect zombies.

Another potential thing to look at: ensure that the player's StartItems include ammo for the weapon.

Just to make sure, are all those sprites present (in the correct place) in your wad file? If they are missing or not located in the right subfolder/markers, the actor doesn't appear.

That'd be the problem; the versions of GZDoom that used FMOD aren't compatible with FMOD Studio and need a specific older version of FMOD Ex. For whatever reason, the FMOD people didn't make Studio backwards-compatible. I don't know which specific version of FMOD Ex you need to successfully compile, but this might be a decent place to start: https://zdoom.org/wiki/FMOD_Ex Or try compiling a newer version of GZDoom that supports OpenAL.

The question remains, who is going to put in the time to do that to literal thousands of files? They can't "just" be automatically generated as-is; someone would have to write the code to do that, too, and account for edge-cases that will undoubtedly come up when your data set is that large.

But...how is the player to decide which to play? Even GZDoom's episode menu can only take a certain number of entries before it starts going off screen, and that number is well below the "thousands" of maps on these discs.

Unfortunately, The Golden Souls and its sequel make non-trivial changes to Doom actors and behaviors, making Brutal Doom incompatible with it. You could certainly still try, but it would have unpredictable results and may potentially make the game unplayable.

Update for those that care: I got the toolchain installed, along with what I assume are all its dependencies, but upon trying to Make in the 64doom/src folder, I'm running into problems where it's failing to #include libdragon.h and I don't understand how to tell it where to look for it. I even copied the libdragon files into (a copy of) the /src folder, no effect. I'll take a break from this for the time being - if I pick it up again, I'll probably go start a thread in Source Ports to avoid cluttering this one too much. (unless someone else feels like trying).

Favorite: Julius. A true "veteran" who never got a (canonical) game of his own, the best part of Julius is that he factors so heavily into the "bad" endings of the Sorrow games - and in Dawn, the bad ending is effectively its own remixed game. Sure, we know next to nothing about him as a person (besides him being a Belmont, and being irritatingly protective)...and we never did get that "war of 1999" game...but one can't deny, a Belmont with facial hair (and a kickin' trench coat) is pretty awesome. Least Favorite: Brauner. He's a cool boss fight, but he's totally wasted potential, because no sooner do you meet him, than he's unceremoniously booted out of the storyline in favor of Dracula, as if to say, "Fie to this pretender, there is room for only one Lord of the Night in this series!" (edit: weasel lives up to his member title yet again)

Well, given 64doom's maintainer never wrote compiling instructions (only instructions to build the ROM), this is gonna be an adventure...and it starts with installing the N64 toolchain. Here we go... 😖

I was going to say "Challenge accepted!", since I have an Everdrive 64 and all, but then I realized 64doom doesn't have a way to accept DEH patches or embed external files, unless I've missed something. I could merge D64D2.WAD into DOOM2.WAD, but that DEH does more than just rename maps, and I get the feeling the game would be pretty significantly broken without it...

The difference between them is that -file works exactly as -file did in vanilla Doom, where loading PWADs with changed sprites (or flats?) would throw out all sprites/flats present in the IWAD and use the ones in the PWAD instead - many older mods needed to include every single unchanged sprite/flat from DOOM.WAD for that to work correctly, which was illegal (you may see a lot of 1994/1995 WADs on /idgames that are noted as "cleaned" versions, as a result). Tools like DEUSF and DMADDS were used later, to splice the unchanged sprites into a PWAD in order to then use it with -file; -merge mimics this behavior so that these tools are unnecessary. Disclaimer: I have not read the Doom Specs and may be referencing certain facts incorrectly or just plain getting things wrong.

I can't be the only one a bit disappointed that these are just trading cards and not an actual deck-of-52. (Has that ever existed in a Doom form?)

It seemed appropriate, given the wallpaper. [edit] I keep forgetting I have this user title. Guess I've lived up to it again.

I've been thinking about playing through some classic megawads using prboom-plus, and the demo recording and playback functions in that port are amazing, especially the ability to fast-forward and rewind, change camera angles, etc. What I have to wonder, though, is could this be used for gameplay purposes? If I make a mistake in a play session (while a demo is recording), could I then go back through the demo and arbitrarily decide to "take over" halfway through?

Meanwhile I'm left wondering why a HUD mod is 200 megs.

Well, I've looked into it, and it seems only the LuciferSam86 account is deactivated (due to inactivity). Merlin86 is still active; you probably just had the wrong password.

The most advanced ZDoom mod is, by definition, the most advanced GZDoom mod. Remember the two are basically one and the same nowadays.

Screenshots! Cola 3 is a sequel to an unfinished sequel to a really old early-GZDoom mod of mine, The Adventures of Mister Cola. The original mod was a basic set of weapons that all had powered-up versions that'd enable when you found a six pack of cola. The sequel gave weapons gradual (albeit uninteresting) upgrades that came from, of all things, health pickups. Both, I'd argue, were missteps in the realm of gameplay and theme. Nowadays, though, I felt like randomly giving the concept a third try, using the basic gameplay of Cave Story as inspiration. In Cola3, you have a small selection of weapons that have infinite ammo (with reloading because damn it I like reloading), but every enemy drops a pile of "cola bubbles" that fill that weapon's upgrade bar. Each weapon has 3 upgrade levels, with significant behavior changes (so it's not like cola2 where it just boosts damage). However, you must take care not to get hit, as taking hits reduces your weapon's upgrade bar, and you can lose levels this way. Weapons and Items The Credits Enough Already, Let's Try It Out Get it from the new itch.io page - don't worry, it's still 100% free to download, I'm not selling it or anything, but if you feel like giving me a little donation as thanks, you may do that now.

That's sort of what I was shooting for (pun intended) with the ww-skillguns proof of concept some years back - though I'd want to really retool it internally if I were to make it any more fully-featured. Serious mods are nice and all but there are just too many things I'd have to make compromises on to make them work with the average Doom level, which sort of encourages the odd bit of silliness. It's nice to be able to let loose once in a while and not have to worry about "is this gun firing the right caliber ammo? are the penetration characteristics correct?" etc. Man, if I'd remembered this existed while I was working on the mod, I'd totally have figured out some way to sneak in a reference to it somewhere. I was pretty much morally required to give the playing cards Mutant Powers once someone mentioned him during early development. (grin)

It's probably better that I leave it that way, since this is how Doom engine has always handled dropped items. Considering they're not strictly essential items like keycards...

From what I recall, Brutal's headshots are handled by having all enemies spawn separate actors that represent their "head," while making the "main" actor slightly shorter than normal. If the "head" is damaged/killed, it kills its "master." This has some side-effects - it doubles the amount of CPU load per actor (possibly more than doubles, I haven't tested), but also has (had?) a tendency where enemies were accidentally head-shotting themselves if they were trying to aim up too steeply.

Given I haven't had anybody tell me that there's any outstanding bugs or balance problems with the mod in a while, I guess I'm going to go ahead and consider what's uploaded to be a Release Candidate. I'll see about putting it on /idgames and declaring it "done" if I don't hear anything for the next week or so.

I have no idea what this is and reading this thread told me almost nothing.