SMG_Man

looks good, reminds me of Akira

fuck it, assumptions it is. I am working off of the guess that your DECORATE code for the weapon looks like the following: Actor BFG2 : BFG9000 replaces BFG9000 { States { AltFire: BFGG A 10 A_BFGSound BFGG A 0 A_TakeInventory("Cell", 40) BFGG A 0 A_JumpIfNoAmmo("ANoAmmoState") BFGG BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 1 A_FireOldBFG BFGG B 0 A_Light0 BFGG B 20 A_ReFire Goto Ready } } There are a few problems if your code looks like this. In order: You do not have an alt-fire ammo use amount defined. The original BFG9000 actor doesn't have any value set for it either (since the "OldFire" state isn't actually used) so it defaults to 0. In order for "A_FireOldBFG" to use ammo, you need to add this property in. "A_TakeInventory" will remove items even if the player doesn't have the full amount requested. For example, if the player has used the Plasma gun and dips to 32 cells before switching to this BFG and fires, the "A_TakeInventory" line you have there will remove the 32 cells. Using this to remove ammo is inadvisable since weapons already have multiple ways to natively handle this kind of check. Relating to number 1, "A_JumpIfNoAmmo" will only perform its jump if the player's current ammo is below the amount used in its current attack mode. For the Alt-fire, that amount is currently 0 since it's not defined, so the jump immediately fails. Furthermore, "A_JumpIfNoAmmo" will either jump by an offset value or to a specific state. "ANoAmmoState" does not seem to be some sort of internal alias or special value or whatever, and you didn't include a definition for a state named "ANoAmmoState", so even if the jump's ammo check worked it would still fail and fall through. The "A_FireOldBfg" function uses ammo, and will fail if there isn't ammo left to use. Conversely, since your alt-fire does not have an ammo use defined, it cannot fail - it doesn't use any ammo! I get that this may seem like a lot, but the old BFG firing state is a bit weird to make good use of. There's a shit-ton to go over and probably a few different (and better) ways this could be handled, but based on what you've described this is probably how I would handle the DECORATE code for it: Actor BFG2 : BFG9000 replaces BFG9000 { Weapon.Slotnumber 7 //Should now be selectable by pressing "7" like the original BFG Weapon.Ammotype2 "Cell" //Ammo type for the alt fire Weapon.Ammouse2 1 //Amount of ammo used for each "A_FireOldBFG" that gets called in the alt fire States { AltFire: BFGG B 0 A_JumpIfInventory("Cell", 40, "AltFire2") //If the player has at least 40 cells, fire. If not... BFGG B 0 A_SelectWeapon("PlasmaRifle", SWF_SELECTPRIORITY) //Switch their weapon as if they were completely out of ammo. AltFire2: BFGG A 10 A_BFGSound BFGG B 0 A_GunFlash("Flash2") //The "OldFire" state provided by the ZDoom wiki doesn`t have a gun flash defined. I gave it one. BFGG BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 1 A_FireOldBFG BFGG B 0 A_Light0 BFGG B 0 A_JumpIfInventory("Cell", 40, "AltFire2") //If the player has at least 40 cells after firing, allow them to return to the READY state or refire. BFGG B 0 A_SelectWeapon("PlasmaRifle", SWF_SELECTPRIORITY) //If not, switch their weapon. BFGG B 20 A_ReFire("AltFire") //When re-firing, return to the initial check just in case. Goto Ready Flash2: BFGF ABABABABABABABABABABABABABABABABABABABAB 1 Bright //wheeeee Goto LightDone } } Hopefully my comments make enough sense. This should work, but I haven't done extensive testing, so I apologize in advance if it misbehaves.

an easy solution would be marking every frame as "BRIGHT" via dehacked a less easy solution would be to use the colormap hack to make those specific colors full-bright regardless of the sector brightness and for the most work, (in ZDoom-based ports) you could make brightmaps for each sprite rotation It can be done

Post the entire DECORATE code you're using for your modified BFG in a code block like this There's not enough information for me to proceed without making assumptions, and I'd rather not do that.

I'm very fond of the Stalagtite

if I were in your shoes, instead of modifying the palette, I would do a color-remap of all the necessary sprites -OR- give every actor (except the blue keys that you want to stay blue) a translation string in their DECORATE/ZSCRIPT. If you're making this for GZDoom, there's no need to define a 256 color palette when you have free control over the color of everything within the game.

I recommend that for a projectile with a very, very high speed like 1000, that you have it inherit from "FastProjectile" if at all possible. The ZDoom wiki page goes over it in more detail, but the short of it is that the normal movement handling begins to behave improperly past 60 or so Speed. The "FastProjectile" class was made with special handling to remedy these issues.

As far as avoiding overlap goes, I would probably choose to balance it in the following fashion: • The rifle would do consistent damage at a range, between the max hit of the regular shotgun and the super shotgun, with little spread and only a single bullet. • To make up for its more positive DPS traits, it would probably need a re-fire time close to the SSG, so that way there's still a valid reason to use the shotguns in close quarters and/or against groups of enemies. • With an actual precision weapon available, chaingun-sniping would probably need to be explicitly removed. I don't think the pistol would need any change since sniping with it is more cumbersome than the chaingun. The only issue then becomes, what ammo would it use? As it is there's a fairly precarious balance in the original four ammo types, and adding a fifth ammo type unique to it may feel a little out-of-place ("why can't it just use regular bullets?").

Personal favorite is the original; it's fucking loud sure, but I love the crunchy unique sound it has. Runner up would be the quake 3 plasma gun. As far as the remaining sounds go, I think I would order them Doom Eternal > Doom 64 > Doom 3 > Quake 2's hyperblaster > Doom 2016. Honorable mentions though to the doom 3 rifle's weapon-up and reloading sounds, they're quite perfect honestly.

For (G)ZDoom, check out this page on the ZDoom wiki. For limit-removing ports that can use UMAPINFO, check out this page on the Doom wiki (look for the "episode = " portion of the Supported Keys section).

cutting and pasting this from another post I made okay, so F_SKY1 is the flat that you use in the map where you want the sky to show. That's all there is to it - it's hardcoded to render the map's associated sky texture the way it looks in Doom/GZDoom. You never need to specify you're using the F_SKY1 flat in your MAPINFO or anything like that; the game already knows how to handle it. By doing what you've done, you're telling the game you want the placeholder image attached to F_SKY1 (which you normally never see under any circumstances in-game) used as the texture for the sky, which is definitely not what you want. What you're supposed to do instead is have "sky1" set as the actual texture you want displayed. In Doom2 this is one of the SKY1, SKY2, or SKY3 textures. If you have new sky textures you want to use that don't overwrite the default ones, use the texture names for those instead. For example, if you added a new starry night sky texture named "STARSKY" and wanted that used by the level, you would write in the MAPINFO sky1 = "STARSKY" and that's it. Or if you wanted to have your first map use the burning city sky texture from the city levels in Doom2, you'd write sky1 = "SKY2" That's all there is to it. Does this make sense?

Ah okay, in that case the important part is really that you're using GZDoom, the reason being that GZDoom itself is more of its own advanced engine at this point. In which case, no matter what WAD(s) you use as a resource, you can implement new player classes via DECORATE or ZScript. The link that NiGHTMARE provided goes over both ZScript and DECORATE, though if you're building for GZDoom most would recommend you use ZScript.

Doing anything beyond changing assets that are stored within the WAD file (mostly sprites, maps, textures, and other graphics) has to be done by modifying the .exe; for vanilla Doom hacking, you'd use DeHackEd or something similar for it. I've never looked into modifying Hexen like this, but there seem to be similar programs available for it. They seem much less refined than the Doom ones (probably because vanilla Hexen modding isn't anywhere near as popular as vanilla Doom modding), but that would definitely be a start.

This is mostly a (G)ZDoom thing. This page should go over the important parts. In general, the ZDoom wiki is a huge asset for making things work in its engine. If you're wanting to accomplish this in Boom or some other engine, I don't know how possible that would be.

I would recommend taking a look at Doom and Doom 2 levels with outdoor areas to see some practical examples you'd be familiar with, but in general what you do is make a sector around your outdoor perimeter with the F_SKY1 flat as its ceiling, then lower it by some amount to reduce the height of the impassable walls, thus creating the large expanse of sky. If you're getting HOMs when doing this, then I'm not sure what could be going wrong as far as using the technique goes. One thing that does come to mind, if you're making a larger and more complex outdoor area, it's possible your approaching some sort of engine rendering limit. For example, I have a map that in CrispyDoom the outdoor area looks fine: but in ChocolateDoom there is a noticeable HOM effect when moving around As long as the fundamental technique you're using is sound, it's possible that you just need to simplify the map geometry to avoid visual errors in vanilla doom. I would try opening your map in CrispyDoom or some other limit-removing engine to see if the HOMs persist; if they don't, then that is almost certainly the problem.

Written only using DECORATE for everything involved. Again, custom pain chances will allow you to accomplish this. Note that it's only rigged to work on the imp in this state since it's a proof of concept; getting it to work on other enemies is largely a matter of copy/pasting and replacing the imp's frames with the appropriate ones for the other enemies. TAZERIFL.zip

Custom pain states do not innately require ZScript; they can be used normally in DECORATE code. It's difficult for me to say exactly how to convert that code above into DECORATE primarily because I've never seen it in use, but it appears that it's simply spawning a bunch of spark effects and damaging the monster while it's in the tazer pain state, which wouldn't be difficult to do in DECORATE.

This sounds like it wouldn't be too hard to implement via custom pain states. Give the tazer weapon a unique damage type, then give each enemy an alternative pain state for that damage type, and that should be it.

wow, I stand corrected then; my bad

You've probably learned that it's possible to make a simple invisible barrier that blocks projectiles and bullets by making a thin sector, raising its floor to just below the ceiling, and leaving its lower sides untextured. It has a lot of uses in vanilla doom, where you can't simply set a line to "block everything". However, this can be taken further - if the barrier is made into a self-referencing sector, then while it will still block projectiles, it will no longer block line-of-sight checks or hitscan attacks... in less advanced engines. blocking_walls.zip In this WAD, there are three different types of blocking walls. In Chocolate Doom, Crispy Doom, and DSDA-Doom, the middle wall is a self-referencing sector and works as described above. If opened in GZDoom, it will still block hitscan attacks. My apologies, I was unaware this behavior had a compatibility flag in GZDoom.

I'm guessing if you want it like Half Life, you mean that the level transitions without some kind of intermission screen. This would be easiest accomplished in a more advanced format such as "Doom in Hexen" or UDMF. There is a line special in those two formats called "Teleport to Map", which allows you to make (semi-)seamless transitions like you see in Half Life and Hexen.

Chaingunners - The only Doom 2 addition that I could see appearing in Episode 1, and even then I'd probably limit their use to UV only because of the threat they pose. Remember, episode 1 is meant to introduce the player to Doom; it shouldn't be anywhere near the difficulty of the rest of the episodes. Hell Knights - Introducing them before the Barons of Hell are used reduces the impact of seeing them as a boss in E1M8, and compared to the other enemies used in the shareware episode Hell Knights are still noticeably stronger and tankier. I would go the simple route and replace every Baron in Episode 2 with a Knight (except for in E2M9), and then in Episode 3 replace most (not all) of the Barons there with Knights. Revenants and Pain Elementals - Due to their small/medium sizes and Cacodemon-level HP pools, Episode 2 would be a good place to have these start showing up. I think a good introduction for the Pain Elemental would be in E2M3, with one or two replacing the Cacodemon(s) in the large room immediately to the player's right at the start of the level, and maybe a few more here and there. I would put the first Revenants in E2M5 in the large open central area, replacing the two Barons on the pillars that lower. Arachnotrons and Mancubuses (Mancubi? Mancubopodes?) - Larger more open areas in Episode 3 would be good for these two types of enemies. The three halls at the the south end of E3M4, the central area in E3M5, E3M6 as a whole, the expanded parts of E3M9, and E3M7 as a whole would all be able to accommodate them. I'd also go ahead and replace the Spider Mastermind's minions in E3M8 with three Arachnotrons to better threaten the player than the Cacodemons/Baron can. Archvile - Even with license to use the full Doom 2 bestiary, I don't think I would use Archviles at all in episodes 1-3 because of how much of a threat they are. Perhaps in Episode 4 they could show up in a few clever places because of the overall difficulty spike, but outside of that I think they're better left unused. Bonus: Super Shotgun - I would skip over putting it in Episode 1 or 2 entirely. I would place the first one in a secret somewhere in E3M2, and the next would be out in the open somewhere in E3M3 (probably replacing the regular shotgun in the room immediately north of the player starts).

Somehow you managed to copy in a blank ASCII character. Delete lines 20-22 and re-type the two closing braces, and it should be fine.

Checking one of the more smaller and less-detailed UDMF maps I've made, it looks like the elements in its TEXTMAP are broken down into essentially five sections at UDMF's simplest: 1. Things 2. Vertexes 3. Linedefs 4. Sidedefs 5. Sectors Each linedef has information from two vertexes and one (or two if it's double-sided) sidedefs, and each sidedef refers to a sector. To give you an idea of how much effort making a map "by hand" (by word-processor?) would be, this small, fairly close-to-vanilla map hits just over 30,000 lines of code in its TEXTMAP entry. I don't think it's very feasible for a human to "type-up" a map of even such minor complexity as this.

Okay, so this code is written in DECORATE. The kind of effect you're wanting would probably more reliably be accomplished with ZSCRIPT, though I admit my own knowledge of ZSCRIPT is lacking so I can't help you with the specifics.