Gez

Well, aside from the obvious recommendations of the medieval fantasy Heretic and Hexen... Doom map sets with medieval or fantasy medieval aesthetic include Eviternity (first episode), Hell-Forged, The Alfonzone (Mad Gothic), Lost Civilization (at least Castle and Courtyard), Tangerine Nightmare (though it's kinda Halloweeny), DBP20: Dungeons and Demons, and also (kindof) DBK01: Dungeon Synths. I'll also mention Verdant Citadel as a stand-alone map.

And people love Doom because of Doomguy? That's news to me. I suppose that can apply to those Doom Slayer games, where they hyped up the game as being this character. But the classic Doom that we love here are not about Doomguy, sorry. Anyways, favorite video game guys? Lance Boyle, Guybrush Threepwood, and Sir Mullich. First two because they're funny, last one because he's incredibly overpowered. To give an answer with a bit more depth, I'll add Daeran and Regill from Pathfinder: Wrath of the Righteous. Both of the characters, when I first met them, I expected to hate. But both grew on me quite a bit as you go through the story with them. They're still evil bastards but they have their good sides.

Actually he promised (in 2017) cargo ships in 2022, and a manned mission in 2024. So far, the Starship has achieved to nearly-but-not-quite reach LEO while empty. Also the guy who was bankrolling the "dearMoon" mission has canceled it, for some reason. I'll wait for when the full-self-driving Tesla roadster will travel along the hyperloop between Earth and Mars, personally. It'll be ready any day now, I'm sure.

Quality bait.

The Cacodemon was hand-drawn, too. And so the pain elemental, which is a caco frankensprite. Clay models were used for the player/zombies, the baron/knight, and the cyberdemon. Latex models were used for the spiderdemon/arachnotron, the mancubus, the revenant, and the arch-vile. So in total, models were only used for about 2/3 of the monsters. The main problem with 3D models in Doom is that monster movement and animations were not designed for 3D models. The way they move works fine with sprites because sprites' lack of granularity force us to overinterpret what we see and basically fill in the blanks. It's similar to the uncanny valley effect.

Depends. Are you going with the game-mechanical implementation of the Doom II monsters, or the "lore" version? Mechanically, they're very very stupid and they lack in long-range attack possibilities. Their projectiles are rather slow, and even their hitscan attacks have a distance cap of 2048 units, which is like about 50 meters IRL. That's a ridiculously low range for a firearm. Most of what makes them dangerous is not in the monsters' own mechanics, but in the level design. Like teleport ambushes when you cross a line. The monsters can't teleport by themselves after all. But in your invasion scenario, they wouldn't be fought in a designed level, they'd fight in the real world where there's no teleporters and no linedefs. The lore version, well, the lore version is that they overran the Earth just before Doom II, so obviously they'd be able to, since by definition they did.

Well, there was that neural upscale project a few years ago already.

This seems like the same basic idea as 3D middle textures/walkable middle textures, though with more customization capabilities at the expense of a more complex setup.

I did say "scripted" after all.

That was one of the very first things to appear in source ports once the source code was released. For example, Doom Legacy v1.11 (February 1998) and DOSDoom 0.64 (June 1998) both boast high resolution, up to 1280x1024 in the case of DOSDoom.

Blame the text template. Not a lot of originality you can do with just Boom-compatible DEHACKED.

Originally from the Monster Resource WAD. Originally created by @Jimmy for the Realm667 "beastiary", way back in 2007. Okay, the behavior is original to Valiant, though the sprites are those of the Diabolist from Demon Eclipse. The Devils of Demon Eclipse, again with a different behavior. (Though much less different, since they haven't been promoted to boss monster status.) Those were originally created by Tormentor for the Realm667 beastiary, way back in 2007. And, obviously, they're based on the Serious Sam enemies. Those are the Guardians from Hell-Forged, themselves an evolution (with brand new sprites) of the Guardians from Demon Eclipse, which used recolored spawn cube sprites originally. Reason is that historically, the wiki editors have been rather reluctant about having pages for fan-made monsters, weapons, or other free-floating resources -- a whole mod, okay, but a mere resource for a mod, eh, nah. Now it's okay to have pages for custom monsters if they're relatively common, at least commonly enough to be used in several notable mods.

From Sunder's text file: * Copyright / Permissions * Authors MAY use this level as a base to build additional levels. Seriously, go have some fun! It's not like I'm getting paid for this. I think that's a yes. Tough to be safe, full credits of the Hive Mother if you want to know who to contact to ask for permission: (I replaced names with @ Doomworld handles. I've also replaced "me" by "Insane_Gazebo" just to be clear, since he's the "me" who wrote that text file.)

Yeah, you can do that kind of things, using ACS to do something that will then cause ZScript to enable the shader, but there's no pure ACS way of tinkering with shaders; you need ZScript somewhere.

You can't. ACS was never extended to shader operations. You'll have to use ZScript instead. https://zdoom.org/wiki/Shaders

Attack is exactly the same. Literally uses the same attack function. void A_BruisAttack (mobj_t* actor) { int damage; if (!actor->target) return; if (P_CheckMeleeRange (actor)) { S_StartSound (actor, sfx_claw); damage = (P_Random()%8+1)*10; P_DamageMobj (actor->target, actor, actor, damage); return; } // launch a missile P_SpawnMissile (actor, actor->target, MT_BRUISERSHOT); } As you can see, there's nothing in the above code that would change the function's behavior depending on what used it. So it is exactly 100% the exact same perfectly identical thing without any difference at all. The only differences between HK and BOH are: - different sprites - different sight and death sounds - only half as much health

Yes, that's an odd misconception. The wiki examples for spawning things at map spots even show repeated use: https://zdoom.org/wiki/SpawnSpot That should make it clear that spots aren't getting transmogrified.

If you put each level in a separate cluster, you can have entertexts and/or exittexts for these clusters, as well as scripted enterpics and/or exitpics for the levels. I think that would work. UMAPINFO allows you to have intertexts for maps, but I don't think this standard includes scripted intermissions.

You get a semicolon error there because you put the >> 16 outside of the function call. It should have been Delay(FixedMul(35.0, 4.405)>>16); Desired duration divided by timeslice length gives you how many timeslices you need: 4.405 / (1/35) = 154.175 Also note that dividing by 1/x is tantamount to multiplying by x, so you could also have done: 4.405 * 35

It's because during development, for player gib death, they had thought about the body getting cut in half. So there was a top and a bottom part. https://github.com/chocolatiers/RomeroDoomDump/blob/master/DOOMART1993/death5_1.png So at that point they needed two different gibbed player objects, one for the torso and one for the legs.

Sprites shouldn't be added to patches/textures unless you actually want to use them as such.

Oh yeah, in that case I suspect it's an offsets problem. The origin point of an actor in game is at the bottom center of their collision box. The sprite is drawn from this position. That means it needs offsets to be displayed properly -- by default, the origin point of an image is the top-left corner, meaning that the sprite will appear below and to the right of the actor's invisible collision box. Using SLADE, you can set offsets to your PNG file. The horizontal offset (X) should be half the image's width, and the vertical offset (Y) should be the whole image's height.

What do you mean exactly by transparent? Is is visible but translucent? Or fully invisible? Since it's a PNG, if it's translucent, it may have an alpha channel value even in the parts that you would want opaque. This can be fixed in an image editor like GIMP by setting an alpha threshold. Also I'm not sure if you're using it as a sprite for an actor or as a texture for a wall. You've said you've renamed it to a pre-existing item so that would imply a sprite, but also that you have "converted to texturex" so that would imply a texture. For a sprite, it could be an offset issue, that would push the sprite below the object and thus make it invisible, not because it's transparent but because it's hidden in the floor. Lastly, what item have you reused exactly? Maybe the corresponding actor has a transparent render style.

Well, that's a confusing but insistent naming convention.

https://www.doomworld.com/idgames/levels/doom2/Ports/m-o/mumphuq2 Like mumphuq1, it was made for Doom Legacy. Dunno how much Legacy features it uses (haven't tried it); it might run in GZDoom which has some amount of Legacy-compatibility built-in.