ZDoom

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

Hey this seems really cool and I really want to try it out but my computer kinda sucks so I'm stuck on the latest test build of Lzdoom before it was sadly discontinued, and I believe this causing me to have an error over something called "XF_Thrustless" despite in theory this mod should work with ...

Yes, portals are a question of trade-off between capability and flexibility. The most powerful portals must be static; and dynamic portals are more limited in what they offer, but less limited in how they can be set up. The main issue is that allowing even dynamic portals to behave like static ...

After looking into it, it seems like this would be relatively simple to do, so I'll see about maybe making it into a pull request in the near future. Main problem will just be having to learn how new events are defined.