ZDoom

Polyobjects do "Crush" type damage.

Keep in mind that the stock MakeFootsteps() code is essentially a placeholder for mods. I added it in so that those undocumented broken TERRAIN properties that have been around for longer than ZDoom even used Git would be tied to something. Of course since it was added by randi to ZDoom probably ...

Your previous code would've worked to, but for anonymous functions you just need it to still end in SOME kind of state return. usually that would just be return State(Null);. Which is no return and makes the actor just go to whatever the next state is.

However, I have only ever used reasonably traditional polyobjects, so there might be a cunning trick that someone knows about that I don't. There isn't. You can make a polyobject that appears to have a finite height by making it out of a raised floor (A lowered ceiling would probably work too but I ...

The splash thing was intentional and done by me, since logically, taking steps in a liquid DOES make it splash. Being able to trigger splashes on the floor below when walking on a 3D floor is absolutely a bug however. If I'm not busy working with other stuff tomorrow, I'll look into fixing it ...

Well, it's been merged so a moderator should probably move this to the closed feature suggestions subforum.

About friction, the reason for that is that friction values are very precise, you'd need to mess with more decimal points down, like 0.63467 or something. Also, you can directly modify the move and friction factors of sectors in the Edit Sector window under the custom tab. factors.png As for ...

This is because Jay pushed a fix for ZScript that makes arrays more strictly obey what type they're supposed to be. For Gearbox at least, there was a discussion on the ZDoom Discord where the cause of the error seemed to be that m8f was using a TextureID array by passing actual plain integer values ...

I mean, GetRadiusDamage() would be used to determine how much damage each actor should receive at the specified distance. That's literally how P_RadiusAttack() itself works after all, too.

Keep in mind that ZScript also has a GetRadiusDamage function, which is what RadiusAttack() uses to calculate how much damage the actor should receive with the specified distance and damage. So you can use that to implement custom explosions.

Here's some sprite edits (And original sprites) that I decided to make this week. Normally the sprites I make are hundreds of model-> sprite renders, the kind of stuff that can't be folded neatly into a sprite sheet, and has to be taken from my mods directly, where I make them using a partially ...

I know absolutely nothing about math, I can't even do anything above like 3rd grade arithmetic myself.

Oh also, maybe you should check if the actor that died has a Death state of the damage type that killed it using FindState(). i.e checking for

If (!FindState("Death.Fire",True))

So that the custom fire death effects will NOT be applied to actors that already have their fire death state.

What the actual fuck? What kinda fucking coincidence is this? You asked for a function like LookForEnemies() that returns an array of all valid enemies 3 days after I wrote a function that does exactly that, and then 3 days after THAT, it was merged to GZDoom. Uh, anyway, yes, you happened to ask ...

Hmm, this mod seems to be pretty universal (In terms of mod compatibility), but some things could be implemented better so it doesn't replace anything at all. The blood colors on the monsters could be changed without replacing them at all, while you can't directly change blood colors like you can ...