ZDoom

The next version doesn't have anything planned at the moment, other than distance checks being portal-aware. I suppose I could push that if you really wanted, but otherwise I think outside of maintenance this mod is mostly complete.

Unfortunately, no. Every frame of the animations had to be manually added in and that meant explicitly defining what was there and using it. This mod has a bad track record of compatibility with other mods that affect floor fluid textures, and there isn't much that can be done about that until some ...

That is beyond the scope of this project, which in its current form is trying to be agnostic to any mods that may be loaded. In other words I want this to work even with Guncaster or Brutal Doom or Project Brutality or Russian Overkill or Hideous Destructor or pretty much anything else that you ...

For me, hard drive access was the biggest problem. Whenever large amounts of files needed to be read, performance completely tanked, as an example, a complete GZDoom compile, which on my Windows system back then took roughly 1.5 minutes, took 10 in the VM. A correctly set up VM should be somewhat ...

Not a GZDoom bug, this happens when certain types of mods are loaded. The mods must use the replacement behaviours correctly for map07/e1m8/e2m8/e3m8/e4m8 to function correctly.

Over time we may refactor the actor code and make it more simplified, and things like this can be considered again. If you are using ZScript, you can use a thing iterator and find the closest corpse to your enemy and just set the your_rezzing_enemy.goal to the corpse actor. As far as I know that ...

First of all - that site you linked should positively never be used to find replacement .dll files - much too often, that site, and many others like it, are used to spread malicious files that can compromise your system and steal your information. Second of all - wsock32.dll is a system component ...

This would require a rework of the AI systems to serve a purpose that would be better done with custom scripting anyhow. You can set monster goals or even use proxy actors to make your monsters move in the direction you want towards the corpses. The actor code is too bloated in its current state and ...

Native morphing can be done with GZDoom and is already possible and has actually been done previously. And I am not talking about the type that locks you to one weapon. You can completely become the target class, so much so that the change persists even across levels, and get access to that class's ...

the1gamer g zdoom- wrote: ↑Thu Aug 14, 2025 3:58 pm sorry bro im new here why would i know?

It's simple: We can't read your mind.

If you don't spell it out for us, we don't understand.

That's really it.

Enjay gave a very good overview of what you need to do to get your requests considered and not just closed on sight immediately. There are a lot of considerations that go into whether or not a developer decides if it is worth their time to add a feature. I am not trying to be mean or anything here ...

MartinHowe wrote: ↑Mon Aug 11, 2025 9:47 am Perhaps the solution is some sort of SkullAbortThreshold property?

Actually that is a good idea.

You can do if (bskullfly && (vel.Unit()) < 0.1))

So this one is not as easy to solve as you might expect. The code is checking for "move.IsZero()" which, if we're talking about the classic fixed-point Doom code, would stop the +skullfly object at an expected velocity (very minor). But since we're using floating point, the precision by which "zero ...