Arsinikk

Hobomaster's Doom Launcher is amazing for me, since I have a large database of Doom WADs. It really helps to put them in categories such as megawads, miniwads, etc. Years ago I used to use ZDL, which is also a great simple launcher... but not so great when having a huge library of WADs.

Sorry to hear that... Sounds quite annoying. Hopefully you'll get to feeling better :) Right now it's set as Saturday-into-Sunday midnight, but tbh I'm a bit flexible. If you still need some extra time to complete it, I can allow that. The goal is to put out the project Christmas morning-ish CST-time, so just keep that mind as I still need to compile everything before then. (Though putting in one map shouldn't be a huge hassle)

Here's a new update (v1.3) for the Doom Christmas resource pack! Apologies, I've been a bit busy during this Christmas season. :) This should fix an oversight on loading the XMASPACK.WAD in GZDoom (oops) @Superjustinbros This also includes some sprite refreshes as well as a few new textures. Doom Christmas Enhanced is now cut into two different packages. The first XMASPACK is similar to the original Doom Christmas as you can load it with Doom / Doom II / Plutonia / TNT and it’ll work. It’s meant for playing and NOT for mappers. The second package XMASPACK-Resource is the actual resource for mappers to use in their projects. Links: XMASPACK WAD (for players): Download XMASPACK Resource (for mappers): Download Hopefully this resource will be useful for anyone who wants to make future Christmas Doom WADs! Regarding some things that could be added to the resource, we are still missing some things: Christmas sprites for the Spider Mastermind Still missing some Christmas versions of Vanilla Doom textures Special thanks to both @Craneo and @ThatKidBobo for their work on new sprite and texture edits. Thank you! Arsinikk

Title: Snowflake and Chill Author: Arsinikk Music: "Carol of the Bloody Bells" by Arsinikk Link to level: Download MEOW ≽^•⩊•^≼ Difficulty settings: All difficulties implemented. Comment: Christmas castles and some doomcute. Kewl snowflake slotter. Has some level transformation just cuz. Additional credits: Added 1 new animated texture (3 patches) by Arsinikk (me). Specified sky via UMAPINFO. Screenshots:

I'm currently working on a fix/update. Thanks for letting me know. I'll try and get this updated when I can :)

Pushing the due date for the project a tiny bit to allow mappers a bit more time: December 24th, 2023 (12am midnight CST on 12/24/23). Just a little reminder that even though "slaughter" is in the project name, you don't necessarily have to make a slaughtermap. It seems this caused a bit of confusion for some. :) The project has some slaughtery maps, but we also currently have maps that are NOT slaughter.

Well I was concerned about the overall item count changing, since the whole point of items in this project is that it counts how many gnomes are in the map and if you've collected all of them. But of course in order to collect them you have to catch / kill them first as they run away from the player. Yeaaaaaaaaaaaah. I'm a little disappointed I probably won't be able to keep my fancy "AddFlags" solution since I thought it was a really interesting way to use MBF21 codepointers. I don't think having a sector of a bunch of items is worth it tbh. However like Doomy__Doom pointed out, the start item count probably doesn't change from it's initial count, so I could probably just abuse that. So it's similar to how some maps can have over 100% secrets if you change the effect of a sector tag and it affects all of them creating more secret sectors. You could argue that GZDoom dynamically keeps track of how many items are in a map, but tbh this method straight up doesn't even work in GZDoom, as it seems the port doesn't have full MBF21 support. So I'd probably have to create some custom DECORATE solution instead anyway, which I was already just thinking of spawning an item in death... Although I was a little unhappy about that due to GZDoom's dynamic item count. Good thing is that I was smart enough to not let the thing be resurrectable nor spawnable. You do make a point in that the item count is usually set at the start of the map, so I could probably do something like that. There are 2 little problems that I think I can probably solve: Because of how the gibs are created, I think that it turns a monster into crushed gibs at any time in their death state... This means that it technically possible for a monster to not drop an item or spawn an item if they are crushed before that frame is reached. I think a solution for this is to have the spawn item start at the death frame of the monster as it turns into the item, and since that thing doesn't have a death state, it shouldn't be crushed. I think this is probably unavoidable but spawning things doesn't keep the momentum of the monsters when they are killed. It's a minor thing, but it can be a little weird / a shame if you rocket the monster and the spawned item doesn't get thrown back. I did have an interesting idea, although it didn't seem to work out. So the sprite used for gibs is POL5A0. And the sprite of the monster uses BON2A0 so that it can be picked up. I tried using sprite blocks to set POL5A0 to use the BON2A0 instead (and of course rearranged the sprites so that the first one was what was originally POL5A0). Sadly even though you can change the default gibs sprite in this way, when enemies are crushed it doesn't use the same hacky logic based on sprite names when assigning what kind of pickup it is. So sadly it still throws the error and crashes.

This was an idea I had, but I'm not exactly crazy how it would affect the overall item count. What's nice about changing the monster into an item is that it keeps the initial map item count consistent.

So in a certain Christmas community project I'm running, I've been dabbling with alot of fun MBF21 DeHackEd stuff. One of which is having an enemy counting as one of the item count. As in when they die, I use "AddFlags" to add the "pickup item" flag and since the sprite name is BON2, it treats it as a armour bonus pickup. However I've run into a problem... If the enemy gets crushed from either a crushing ceiling / lift raising up to a ceiling (0 height), the monster will turn into squished gibs. This results in a crash (DSDA Doom) if the player tries to pick it up, since it no longer is the sprite BON2. Is there anyway to stop a DeHackEd thing from ever turning into squished gibs in MBF21 or no?

I stand corrected, as it does seem to work now. I'm not exactly sure why I thought that it didn't. Maybe I mistook "compat_corpsegibs" not working as "compat_vileghosts", but after some more tests it does in fact work. Sorry about that. I do think this wiki page should be updated with "compat_vileghosts". Although I will say that I personally probably won't use it, as I look for ways to get ghosts to work in Zandronum and ZDaemon as well. Although it's cool to see that it's now easier to get ghosts working in GZDoom.

So technically, yes, this works only if you turn it on in the GZDoom compatibility options or change it in the console... However as a mapper this option is not useful for me because it is impossible to set "compat_vileghosts" via ZMAPINFO, so it's fully on the user to turn it on via the compatibility options instead. The only way I could force it in a map is not through ZMAPINFO (like it should be imo), but only via an ACS script / ZScript changing "compat_vileghosts" to true... Which is kinda lame imo.

Currently, while you can turn on the "compat_corpsegibs" in the compatibility menu and/or define it in ZMAPINFO, in GZDoom it will not do anything. It requires the compatibility setting "compat_vileghosts" to also be turned on, which is can only be accessed via the console or via a script (ZScript and possibly ACS). Note that "compat_vileghosts" requires "compat_corpsegibs" to also be turned on to work. You can see in the source code, that vileghosts is typically only added for specific WADS (just search for "vileghosts"). Worst and I figured this out the hard way when developing a pseudo ghost monster script. ... One minor thing to mention about GZDoom at the current moment, is that for GZDoom 4.11.0-4.11.3, if you turn on the "compat_floormove" compatibility setting in the menu or a map has it in the ZMAPINFO lump, those maps will completely break as the compatibility setting is currently broken and makes certain sectors just never move when they should. It has since been fixed in Github, but until a new stable release is put out, those maps will stay broken in GZDoom. (like in many maps of Hell Revealations at the moment). ... I'd say for the most part the compatibility settings of GZDoom do a good job of emulating Vanilla behaviour. Some minor things it does not do correctly like Shepardus laid out. I'll add/comment on some stuff: Mikoportals used as infinite scrolling walls don't work in GZDoom. Although this is pretty easy to "fake" in GZDoom, but just adding action 424 to the walls and it will scrolling them similarly in GZDoom. Barrel explosions can be tweaked via compatibility settings to get conveyors and the like to work pretty similarly to Vanilla. By default, yes, GZDoom physics are off, but in voodoo conveyor maps you can get them working correctly if you don't use mikoportals and you enable the right compatibility settings. The only physics based things that cannot be emulated are speedrunner tricks Shepardus listed above and running against decorations not building momentum. Technically you can still glide in GZDoom, it's just way harder than in other ports. Certain actions like a donut raising the inside sector instantly don't work in GZDoom on default. That's when you should use something like "compat_floormove" to allow for the buggy Doom floor movement code to work it's magic. It's also worth mentioning that Vanilla does things differently than Boom/modern ports, when it comes to executing actions. This is where stuff like "compat_light" or "compat_floormove" become useful. Vanilla only looks at the first tagged sector when it makes mapping changes, so when using "compat_light" it'll look for the first tagged sector lightlevel and use that for all the other tagged sectors. Boom does mapping changes per each tagged sector, which can result in different lightlevels based on what adjacent sectors are near. The same logic applies to "compat_floormove", but for moving floors instead of lightlevels. Just for fun, I'll just show what vanilla settings I set in ZMAPINFO for vanilla doom projects: defaultmap { sucktime = 1 nojump nocrouch compat_useblocking = 1 compat_nopassover = 1 compat_sectorsounds = 1 compat_missileclip = 1 compat_explode1 = 1 compat_explode2 = 1 compat_invisibility = 1 compat_crossdropoff = 1 compat_limitpain = 1 compat_light = 1 compat_pointonline = 1 compat_floormove = 1 compat_stairs = 1 compat_trace = 1 compat_soundtarget = 1 compat_corpsegibs = 1 }

Uh, particularly what would you want to be released? Regarding textures, flats, and sprite refreshes, any new stuff added to this project will eventually be incorporated into the Doom Christmas Enhanced Resource. I plan on keeping that resource up-to-date as we improve assets. There are some stuff like the new MBF21 custom enemies and graphics (HUD, titlepic, palette) specific for this project, that I'm unsure if it should be included in the main resource.

Tbf I considered/enjoyed the wad before the update. I still would have posted it here even without the extra maps. They were just the icing on top. I'd love to do something like this, but tbh I didn't really play that many WADs this year, so I don't feel I'd have much to write about. Turns out managing a community project for most of the year kinda takes time out of actual WAD playing :P

The Maskim Xul weapon includes the A_SargAttack in the weapon firing state, therefore it doesn't just take away health, but armour as well. I don't think there's a way in MBF21 that would be able to distinguish health from armour. You may be able to do something relating to ammo. Just look at the MBF21 specs and search for "ammo" to see what MBF21 allows. It seems there's alot of consideration when it comes to custom ammo types and ammo checking in MBF21.