SMG_Man

That looks correct so far. The music that you're setting should be either a lump in your WAD, a file name (in a pk3), or a lookup string (such as "$MUSIC_E1M8"). By default, (G)ZDoom should play whatever the original music in your map slot was if none is specified. However, there are some exceptions to this - for example, if you are making a WAD that uses the 'mapXX' convention for level numbers, but use Ultimate Doom as your base WAD (which uses 'eXmY' for its levels), there will not be any "original music" in your map slot to use. Therefore it is always safest to simply define what music you want to have play if you're going through the effort of adding MAPINFO to your WAD/pk3.

Use the PK3 file structure instead of a WAD for your project. It's going to be a pain in the ass getting things set up initially, but the organized file structure will make your life a hell of a lot easier in the long run. image: Being able to store things in folders does wonders for organization. Note: While your project is in development, SLADE/UDB/GZDoom can simply load an ACTUAL FOLDER (using the pk3 structure) on your computer, instead of having to compile and re-compile a PK3 in Slade any time you make changes (because a PK3 is just a ZIP file, and a ZIP is just a compressed directory). You can read more on PK3s/ZDoom-supported directories here: https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement

If you play using less-advanced ports (Chocolate Doom, Crispy Doom, etc.) there's no way around this without using DeHackEd to seriously modify the game, I'm pretty sure. This is outside my realm of expertise. For ports that at least support UMAPINFO (PRBoom+, DSDA Doom, and some others), you can re-rig E1M8, E2M8, and E3M8 to directly lead into the first map of the next episode instead of ending the current session. For ZDoom (and other ports that have the same console commands, like GZDoom) you can use the command "changemap e_m_" (the first blank being for the episode number, the second blank being for the map number) to begin a new level without losing your current inventory. For example - playing Phobos Anomaly; instead of going through the final teleporter after defeating the barons, you would bring up the console by pressing ~ and you'd type "changemap e2m1" to begin episode 2 without losing your inventory. edit: please note that "changemap" is different from the "map" console command in ZDoom. Using "map" to change levels is just like using the regular IDCLEV cheat, and will reset your inventory.

The main thing for me is that the games were originally designed around not having to look up/down, and the auto-aim function makes up for the lack of free-look pretty well. It's antiquated sure, but it also just plays legitimately solid. On a similar note, I played the Metroid Prime remaster using the classic GCN control scheme (rather than with a modern Halo/CoD-like dualstick setup) because its lock-on function was pretty perfectly designed to compensate for the movement and aiming quirks a single-stick setup has. In a sense, neither of these games were designed to test the player's ability to "aim", so adding it in doesn't do much for the games unless you also make further changes (in my opinion, of course).

If you use DECORATE or ZSCRIPT to write your new monsters (both of which GZDoom supports), you can define the monster's scale explicitly.

In your DECORATE/ZSCRIPT definitions, you can place stuff called "editor keys" which UDB will detect and use to sort your new actors into folders/subfolders. If an actor isn't written in DECORATE, it's (almost certainly) written in ZSCRIPT, a more advanced language for GZDoom. Because of the way ZSCRIPT works, you cannot place the editor ID in an actor's definition. You will instead have to make a MAPINFO lump with the editor number definitions. Please note - in order for UDB to parse ZSCRIPT actors properly, you must include gzdoom.pk3 as one of your resources when creating a map:

back in the days of XWE and the original Doom Builder, you know what used to happen when you did this? I'm gonna second the suggestion to keep your map data entirely separate from your DECORATE/other assets while your project is in active development. It's a lot less of a headache for one, and also foolproofs you against fuckups like the above.

there are a variety of ways you can accomplish this in GZDoom, both in DECORATE and ZSCRIPT. In DECORATE (which I'm more familiar with) you'd probably use a CustomInventory item that checks if the player has the appropriate item in its pickup state; if the player does, it'll give them ammo and disappear; if not, it'll do nothing and stay on the ground until the player returns with the appropriate item.

I'm not perfectly consistent with this (especially when GZDoom maps allow for more granulated light intervals), but this is how I usually approach certain landmark light levels: 255 / Strong, concentrated lights (LITE3, LITE5, TLITEs in a small sector, etc.) 192 / Outdoors (daytime), soft lights (CEIL3_4, GRNLITE1, LITEBLU1, etc.), rooms being lit by many powerful light sources 160 / Indoor sectors with fewer/weaker light sources 128 / Shadows in indoor sectors that have light sources, ambient light level for indoor areas without lighting that I don't want to have visibility issues 96-80 / Outdoors (nighttime), harsher shadows, indoor areas where the visibility is a deliberate obstacle (there may be Lite-Amp Goggles somewhere) 64 and below / Essentially "pitch-black"; if it's a playable area, the player should come back if/when they find Lite-Amp Goggles Lighting unfortunately varies heavily across sourceports/user settings/monitors/monitor settings, so trying to make it perfect for everyone is impossible. I just go with what looks right to me, with my settings.

making the necessary changes in DECORATE (and probably ZSCRIPT too, but I don't really use it) is simple enough, if a bit tedious. Don't let it dissuade you.

That's my mistake, those lines are just untextured. Never noticed it while testing since I have crispy doom disable the HOM effect lol

if your computer can run it, there's no reason not to use Ultimate Doombuilder

https://www.doomworld.com/tutorials/fx5.php I followed the bottom section of this tutorial myself (the part pertaining to using BSP for the nodebuilder) when making my recreation of TNT map 21 for a community project. The process is a bit tedious, but fairly straightforward if you pay attention. Good luck.

If you're shooting for strict vanilla compatibility and want the stock textures to still be available in your maps - you will need to set a "Base Resource Archive" in SLADE. This option is in the upper right corner of the editor: Do that and select your Doom 1 wad. Next, import all of your patches/finished textures into an empty WAD, and put them between P_START and P_END markers. Make sure they're in the Doom graphic format, then highlight all of them, right click, and find the option to "Add to TEXTUREx" You will get a message saying "No Texture Definitions found" that asks if you want to create or import a texture definition list. Choose "Yes", and in the next window, choose the option to "Import from Base Resource Archive": Voila, SLADE will recreate the original Doom 1 TEXTURE1/TEXTURE2/PNAMES entries, then add your new patches and textures to them as needed: It shouldn't matter whether you add new textures to TEXTURE1 or TEXTURE2 from here. If you add more textures to your WAD after doing this initial setup, it's a lot faster. Just put the additional textures between P_START and P_END, choose the "Add to TEXTUREx" option, and that's it: Note: This is for strict vanilla compatibility (i.e., for use with Chocolate Doom). If you're targeting a Limit-removing port or higher (Crispy Doom or anything more advanced), then you can simply tell SLADE to make your texture list from scratch and not worry about importing the list. For more advanced ports, the number on your TEXTUREx lump will not matter, because they will load every TEXTURE list together instead of only the last one in the load order. I hope this makes sense.

There is some important nomenclature here, so allow me to break it down quickly: Doom stores most data (level geometry, enemy sprites, textures, music, sound effects, menu graphics, and more) inside WAD files. There are two types of WADs - IWADs and PWADs. An IWAD is a functionally complete game by itself, such as Doom 2, Hexen, Strife, and so on. You should never load more than one of these at a time, because they contain heavily conflicting data. A PWAD only includes some new things, like new (or replacement) textures and maps, and cannot be run on its own. They must be loaded alongside an IWAD to actually be played. PWADs could be any number of things - new maps, a texture resource, music replacer, etc. If you want to make a texture pack, then you're making a PWAD. There is no difference whatsoever in setting this up if it's intended for Doom 1 or Doom 2. If you found a tutorial but it's making reference to "Doom 2", you can just as easily use it for Doom 1. The process is the exact same.

Due to the way Doom handles texture indexing, the first texture in the index (position 0) will not appear properly in-game. If you look at any Doom-based game, like Doom, Doom 2, Heretic, Hexen, etc. you will notice that the first texture listed is always named something like "AASHITTY" since they're sorted alphabetically. If you try using those textures in a map, they'll functionally be the same as not setting a texture at all. With that in mind - SLADE automatically makes a dummy texture for you as a convenience. If you delete it, then whatever's the new first texture in your WAD will no longer work. Either re-do your texture list and keep the SLADE dummy texture, or make your own dummy texture that occupies the first position in the index; it doesn't matter in the end.

wanna highlight this - defining DoomEdNums in a Mapinfo lump in your WAD/pk3 is the only way for your ZScript actors to show up in the editor. Actors written in Decorate can simply have the editor number given in their DECORATE lumps, but doing the same thing in an actor's ZSCRIPT definition will not work.

if I may, I'd be interested in Map 31 once again lol

aaaaaah, gotcha gotcha. Then the answer to that is

Here, this should contain those couple of minor fixes for my map 21. administrator_2_judgement_center_hotfix.zip

Aloha; it's been a while since I fired up my map, so I took a look at it in UDB and puzzled over it a bit. 1. The two mancubi were *supposed* to get released by a trigger in the red key area (the same trigger that lowers the shelves hiding the chaingunners), but it looks like I made a mistake and actually lowered the ceiling to make a door instead of raising the floor. That's my mistake. 2. The door locking you in actually re-opens there once you go through the teleporter and reach the outside area, which is crucial for multiplayer/coop functionality (as another failsafe, the triggers around the coffin are repeatable so that a malicious player can't soft-lock the map by killing themself in the locked room). ...I forgot that there's no way to teleport back from the outside area though, so the door re-opening might as well not happen in single-player. I'm not sure if there was a way back in the original either, but I can understand one-way level design being frustrating, so I may as well change it. 3. When I was making my rendition of the level I couldn't remember how reaching that section of the map worked, so in the spirit of the project I just came up with something that "could make sense": I think there's a teleporter somewhere else in the map that takes you into that alcove, but I feel like fixing this for the sake of "being like the original" kind of goes against the intent of the project, so I don't feel inclined to change it unlike the other two issues you mentioned.

There is a lower-tech alternative for your first question, which is using UMAPINFO to attach an action to killing all monsters of a specific type. Note that it's much more limited in comparison though and functions the same way boss triggers in Doom 1/2 do; that is, they activate after *all* monsters of a given type are killed. You would have to use SLADE to create a UMAPINFO file for your WAD, which should be simple enough. Most of the time, but not always. I'm not an expert with the limitations, but I do know that (for example) GZDoom cannot handle 3D models properly if they are in a WAD file instead of a pk3. More simple things like textures and sprite-based actors should be able to be converted to work inside of a WAD file.

In situations like these, I feel the easiest way to find out is trying it out for myself and seeing what happens. So I spliced together the existing Icon of Sin textures in two different ways: 1. making three 256x384 textures comprised of the original 128x256 patches 2. making three 256x384 textures that use new, large 256x384 patches Immediately I ran into an error getting Chocolate Doom to load the level though, with the following crash message: This was coming from the multi-patch textures, so I changed their dimensions to 128x384 and made 3 more textures to cover the whole Icon of Sin. After making that adjustment, Chocolated Doom didn't crash immediately on opening the map, and this was the result: tl;dr Chocolate Doom does not seem to like textures that are more than 128 pixels tall. Attached is my WAD with the redone textures and sample map if you're curious: tall_icon_of_sin_textures.zip

It still needs to be said for others stumbling on this thread - please for the love of God do not use XWE in the year of our Lord 2022. It is very old, very unstable, and has a lot of problems like mentioned here. One of many ways in which XWE is just flat out wrong and will fuck things up for you on the conceptual level later on down the line, the doom palette does not contain cyan at all: https://zdoom.org/wiki/Palette Unfortunately I can't answer this, but it was something I noticed when I used XWE myself many years ago. The only way around it that I can think of is to open another WAD which already has the graphic(s) properly formatted as-is and copy the lumps/merge it into your main WAD. In other words, you'd probably have to get someone to do it for you with SLADE. Fun!

I would start by taking a look here https://zdoom.org/wiki/Classes:MusicChanger