Hideous Destructor 4.10.0b

[Matt]

Hey Matt,

Long time doomer but decided to do a playthrough of Doom 2 then all Doom's 4 episodes with HD. I did all of this using `hd-4.8.2a.pk7` with a rolling GZDoom version with the rest of my updates (GZDoom version g4.9.0-m tonight)

Today I'm on map05 of TNT then will wrap up with Plutonia. But my save00.zds quick-save became corrupted with an error on load: `Attempt to instantiate abstract class BlockThingsIterator`.

I also noticed this save's map05.map.json is 1.6MB while my map03.map.json earlier savegame was only 390K with an overwhelming majority of the text being from decals. Not sure how to resolve this just yet. I take hourly snapshots so I'll try comparing it with an earlier save00.zds, though I would rather not lose the progress given this error happened just before the next hour. Is this a known problem if somebody takes too long in a map or something of that tone?

Sorry, no idea... wouldn't even know where to start with that.

At first I misread your post and thought you'd upgraded versions and loaded a game based on an older GZDoom or HD or both, but that doesn't seem to be the case. (Is it?)

[ipaq]

All good, it seems something in the gzdoom save format really didn't like "something" between my save near the beginning of MAP05 in tnt.wad versus later into that long map. I noticed when I extracted my save00.zds file during this tnt.wad run, most of the lines in map05.map.json were related to `ImpactDecal`'s which made it ginormous for a text file, but removing those by hand with `jq` didn't seem to fix the savegame either. Would love to find out what I've done...

I had to rollback a few hours before I had a working save again. Didn't realize how long it had been busted for until I tried reloading

I might hit up GZDoom's devs about this one as well, they may have an idea of some limitation I may have hit during gameplay somehow.


E: Successfully recovered the save. Couldn't just delete the "BlockThingsIterator" classtype error in the Object's section of the save because something was still referencing it. So I replaced it with some ItemStorage class just below it and that was enough to finish and leave the level and save fresh on the next one.

Please see this gzdoom github issue thread for more info towards the bottom of the page: https://github.com/ZDoom/gzdoom/issues/1876; They seem to believe this is a bug with the mod trying to store that class in a save file in the first place. But, I have no idea where to start with fixing that sorry.

[Eric_]

HERPs can be "picked up" by revenant drones and mancubus fireballs. In the case of the former, it actually duplicates the HERP dozens of times, because of the shrapnel triggering the pickup behavior multiple times at once.

[Matt]

HERPs can be "picked up" by revenant drones and mancubus fireballs. In the case of the former, it actually duplicates the HERP dozens of times, because of the shrapnel triggering the pickup behavior multiple times at once.

I think it should be fixed now, which is remarkable because I couldn't even figure out the logic of what was going on until after I'd made the commit...

(basically a revenant could launch a missile at a robot, then switch targets, then attack something else in melee just as the missile hits, and it would count as a melee attack on the robot)

[Toybasher]

Will there be any plans to add a COOP mode that has each player get separate lives?

We currently have:

1. All players have a shared lives pool. When you run out of lives, the map immediately restarts even if some players are still alive.

2. All players have a shared lives pool. When you run out of lives, players can keep playing but respawning is disabled. Once all players are dead, the map restarts.

Can we get a mode where each player has a separate lives pool, and the map only restarts if all players have ran out of lives and died? I don't like having the team get punished just because one player tends to die a lot. (Having that player run out of lives faster and you're now down a soldier for the rest of the map, while you still have your own lives would be enough of a punishment.)

[Karl515]

I crashed when a babuin mauled my derp.

[Matt]

I don't like having the team get punished just because one player tends to die a lot.

Failure to protect and coordinate with that team member is a team skill issue.

I crashed when a babuin mauled my derp.

This needed a check after damage was inflicted during the latch. Should be fixed now.

[Toybasher]

Failure to protect and coordinate with that team member is a team skill issue.

Aye. I still think separate lives/respawn tickets would be a good compromise and let us lower the lives pool to something more reasonable.

Currently I set very forgiving lives pools to take into account our lives are shared. Having it an optional setting would be best for people to configure as they prefer.

[ZikShadow]

Code: Select all

`hd_pof` (false): Stands for "Power of Friendship". When this cvar is turned on outside of deathmatch, you can't respawn until all living allied players are in sight and within range. Once you do respawn, you will be raised on the spot subject to a brief moment of incapacitation.

Have ya tried this, yet?

[Abba Zabba]

The new medkit sprite that's based off the Freedoom stim sprite, frankly, looks awesome. It's also fits perfectly in ID Doom compared to the original bulk cell with a pistol grip attached, had no idea it looked that way in Freedoom before.

The new high visibility gyro grenades I'm mixed on, on one hand the overall color change to make the paint or material finish shine or contrast a bit more makes them stand out just on its own, but the bright blue and gold (possibly based on munitions seen in Ukraine?) color bands are somewhat distracting. This might be one of those personal preference things, as I've tweaked mine to look a little closer to TF2's rocket. However, the silver rod that extends the fins on armed gyros looks great, solid addition. But now the ied kit on the gyros looks nothing short of a miniature explosive Christmas tree.

[Cryomundus]

So I'm fairly certain that the Mancubus/Fatso's melee(?) is bugged, as it can cause a crash to desktop in certain cases.

https://www.youtube.com/watch?v=JfDcYM80k2E It occurs in this vid at 5:40. Had this happen to myself when zerking and jumping at a manc and it just crashed to desktop.

[Abba Zabba]

So I'm fairly certain that the Mancubus/Fatso's melee(?) is bugged, as it can cause a crash to desktop in certain cases.

So, I just did a quick test on the HD range with no zerk, but instead, just a mancubus surrounded by explosive barrels (but no other props, next most appropriate coming to mind would be burning barrels,) and it immediately caused a CTD along with this strange high pitched whoosh sound, which I guess is the sound that normally plays being distorted due to the crash? In any case, it definitely seems like it's the mancubus's melee attack connecting with or being in range of the barrels that causes this.

[Cryomundus]

So I'm fairly certain that the Mancubus/Fatso's melee(?) is bugged, as it can cause a crash to desktop in certain cases.

So, I just did a quick test on the HD range with no zerk, but instead, just a mancubus surrounded by explosive barrels (but no other props, next most appropriate coming to mind would be burning barrels,) and it immediately caused a CTD along with this strange high pitched whoosh sound, which I guess is the sound that normally plays being distorted due to the crash? In any case, it definitely seems like it's the mancubus's melee attack connecting with or being in range of the barrels that causes this.

I've had this happen with the Powersuit addon as well, so it might be something with immovable/very high mass objects.

[Marisa the Magician]

I mildly suspect this to be related to an assortment of explosion-related crashes I've gotten over the years with multiple unrelated mods that seem to all narrow down to an assert in std::clamp when the "low" argument is larger than the "high" argument.

[Matt]

The new medkit sprite that's based off the Freedoom stim sprite, frankly, looks awesome. It's also fits perfectly in ID Doom compared to the original bulk cell with a pistol grip attached, had no idea it looked that way in Freedoom before.

The new high visibility gyro grenades I'm mixed on, on one hand the overall color change to make the paint or material finish shine or contrast a bit more makes them stand out just on its own, but the bright blue and gold (possibly based on munitions seen in Ukraine?) color bands are somewhat distracting. This might be one of those personal preference things, as I've tweaked mine to look a little closer to TF2's rocket. However, the silver rod that extends the fins on armed gyros looks great, solid addition. But now the ied kit on the gyros looks nothing short of a miniature explosive Christmas tree.

Glad the new medikit device works!

The rocket grenades will be getting another overhaul soon - the single-piece fins don't make that much more sense than the original. [EDIT: of course then I find this, pretty much identical to what the old sprite does, which begins to suggest I might end up having to go with 2 separate configurations for grenade and rocket] The gold stripe is just supposed to be an indicator of which direction you're supposed to load the round in, but given the shape of the thing it doesn't make a whole lot of sense. (fwiw this is *not* a political statement, I'd actually tried to make the design look *less* like a Ukrainian flag but there's only so much you could do with "blue stripe, yellow stripe"...)

Agreed that the IED has way too many colours...

I mildly suspect this to be related to an assortment of explosion-related crashes I've gotten over the years with multiple unrelated mods that seem to all narrow down to an assert in std::clamp when the "low" argument is larger than the "high" argument.

I don't see anything in explosion.zs that could do this, unless there's some messed-up sector on the range where the ceilingz would be lower than floorz. Will have to do a broader search for clamps in other files tonight...

EDIT: Could only fine 2 places where a fireball might be placed somewhere between floorz and ceiling-height, which could run into issues if the sector is narrower than the fireball is tall.