[MBF21 Question] How to stop monster / thing from turning into gibs when being crushed

[Arsinikk]

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? 

Edited December 16, 2023 by Arsinikk

[ViolentBeetle]

I'd suggest you spawn a new item as first frame of his death. Not sure if this is entirely crusher-proof, but it would solve most of the issues.

[Arsinikk]

2 minutes ago, ViolentBeetle said:

I'd suggest you spawn a new item as first frame of his death. Not sure if this is entirely crusher-proof, but it would solve most of the issues.

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.

[ViolentBeetle]

16 minutes ago, Arsinikk said:

This was an idea I had, but I'm not exactly crazy how it would affect the overall item count.

Just don't give that item a flag to make it count?

[plums]

I don't think there's a way to stop something being squished into gibs with MBF21.

 

2 hours ago, Arsinikk said:

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.

 

If I understand the problem correctly, it's that spawning new items results in the player being able to get more than 100% items.

 

One potential workaround could be an inaccessible sector full of unobtainable items, one per monster that drops an item, to balance out the totals. This still maybe results in potential problems since a crusher might destroy a dropped item this way (not sure, haven't tried it). But it won't cause a crash.

[Doomy__Doom]

If Arch-Viles and spawner entities aren't involved, then just setting original enemies to COUNTITEM and making them drop an actual pickable item should keep the count consistent. A_SpawnObject-ing something with COUNTIKILL does not increase map item total. At least in DSDA-Doom, that's the only port on which I tested applying the idea to a map to deliberately go over 100% count (ammo pickups have COUNTITEM set initially in properties and are repeatedly spawned via A_SpawnObject). No clue if it's consistent with other ports' handling.

 

If Arch-Viles are involved, resurrections don't update map item total, so you'd go over 100% (again tested only on dsda-doom). In that case, you could hack a bit of logic to distinguish first death by setting one of the "free" ExMyBOSS flags and branching with A_JumpIfFlagsSet whether to spawn the pickup or not based on that. ExMyBOSS is only relevant to Doom 1 bossdeath logic, so it should not cause an issue in Doom 2-targeting map.

 

If you want entire corpses to be visually pickable up, then I guess last frame of death animation goes to TNT1, spawned "armor bonus" has the corpse frame. It's probably better to just make those enemies have no raise state to avoid the complexity of dealing with Viles resurrecting stuff out of thin air.

 

Re:original question, I honestly don't know how game decides that something needs squishing.

[Arsinikk]

10 hours ago, ViolentBeetle said:

Just don't give that item a flag to make it count?

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.

 

8 hours ago, plums said:

I don't think there's a way to stop something being squished into gibs with MBF21.

Yeaaaaaaaaaaaah.

 

8 hours ago, plums said:

One potential workaround could be an inaccessible sector full of unobtainable items, one per monster that drops an item, to balance out the totals. This still maybe results in potential problems since a crusher might destroy a dropped item this way (not sure, haven't tried it). But it won't cause a crash.

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.

 

7 hours ago, Doomy__Doom said:

If Arch-Viles and spawner entities aren't involved, then just setting original enemies to COUNTITEM and making them drop an actual pickable item should keep the count consistent. A_SpawnObject-ing something with COUNTIKILL does not increase map item total. At least in DSDA-Doom, that's the only port on which I tested applying the idea to a map to deliberately go over 100% count (ammo pickups have COUNTITEM set initially in properties and are repeatedly spawned via A_SpawnObject). No clue if it's consistent with other ports' handling.

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:

1. 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.
2. 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.

Edited December 17, 2023 by Arsinikk

[ViolentBeetle]

3 hours ago, Arsinikk said:

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.

Isn't counter set at the start of the map and not updated? So unpickable thing spawning pickable thing mid-game should keep it consistent.