Generic systems for GZDoom

[CBM]

I suggest addition of the following generic systems

1) a generic extendable weather system that can be controlled from zScript and decorate
(ie. rain, fog, snow, ...)

2) a generic extendable system for vehicles that makes it easy to use sprites or 3d models to create vehicles for gzdoom mods - native engine support would make stuff like sergeant marks tanks waaaaay easier to make or replicate

3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

4) inheritance in 3dmodeldef (ie. if you have a generic soldier model, then it would be nice to just have to specify texture for each subsequent cloned actor)

[Graf Zahl]

No comment.

[Nash]

About the only thing that would make sense here is related to (1) - if modders could define texturized particles, I think these precipitation systems would benefit more from it. Of course those weather systems would still need to be done as mods, as built-in engine features they'd make no sense because weather was never a part of any of the base games.

Regarding (4), MODELDEF should not be expanded any more. Some new model format would make more sense, going forward.

Of course this all means nothing if no one steps up to do the actual work. :^)

Ah, maybe some day when I have more free time and have more programming skill...

[phantombeta]

1) a generic extendable weather system that can be controlled from zScript and decorate
(ie. rain, fog, snow, ...)

Out of scope for the port, DIY. A ZScript solution would be more flexible anyway.

2) a generic extendable system for vehicles that makes it easy to use sprites or 3d models to create vehicles for gzdoom mods - native engine support would make stuff like sergeant marks tanks waaaaay easier to make or replicate

Waaaaaaaaay out of scope for the port, and also DIY. Same as above.

3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

Not possible in this engine.

4) inheritance in 3dmodeldef (ie. if you have a generic soldier model, then it would be nice to just have to specify texture for each subsequent cloned actor)

As Nash said, MODELDEF should not be added to anymore. It's already awful and hard to work with, it'd be easier to make a new lump and animation system.

[Redneckerz]

I suggest addition of the following generic systems

1) a generic extendable weather system that can be controlled from zScript and decorate
(ie. rain, fog, snow, ...)

There is WeatherFX, but this is quite a monumental effort first and formost.

2) a generic extendable system for vehicles that makes it easy to use sprites or 3d models to create vehicles for gzdoom mods - native engine support would make stuff like sergeant marks tanks waaaaay easier to make or replicate

This is even more of an effort. The closest equivalent is KGZDoom, and that's more of a hack job to implement vehicles (and outdated)

3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

Do you realize to the full extent of what you are suggesting here? You suggest a true 3D polygonal renderer here, in the vein of Doom3D

4) inheritance in 3dmodeldef (ie. if you have a generic soldier model, then it would be nice to just have to specify texture for each subsequent cloned actor)

Kevinevans made a 256 textures generator that does variety of actors.

In short, the suggestions aren't just relatively easy features, but significant additions that require significant development time. Given that most of the team has been occupied as is, i do like to ask what made you arrive at these suggestions of this order.

[Apeirogon]

Of course those weather systems would still need to be done as mods, as built-in engine features they'd make no sense because weather was never a part of any of the base games.

Heh, so sprite shadows in the past was a part of a base games?!

[phantombeta]

3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

:| Do you realize to the full extent of what you are suggesting here? You suggest a true 3D polygonal renderer here, in the vein of Doom3D

GZDoom's hardware renderer is a "true 3D polygonal renderer". As is the SoftPoly backend.
GZDoom not having "true 3D maps" has nothing to do with rendering. It's the way Doom's physics, collision detection, AI, sight checks, etc. work that are the problem here.

[Graf Zahl]

Keep in mind: Even though Build is also a 2.5D engine there is no realistic way to make Build maps work in Doom. Real 3D maps would be infinitely more complex.

[Gez]

You can sort-of fake it by making a non-solid 3D model of the map (or of map segments, at least) and then use regular geometry to handle the collisions. Don't forget to give your map hull things a huge render radius so that they don't get hidden when their center is out of line of sight.

I think there was someone who worked on a project using this approach but it probably went nowhere as I don't remember seeing it elsewhere than a couple of old posts in what was probably the WIP thread.

[Redneckerz]

GZDoom's hardware renderer is a "true 3D polygonal renderer". As is the SoftPoly backend.

I stand corrected.

GZDoom not having "true 3D maps" has nothing to do with rendering. It's the way Doom's physics, collision detection, AI, sight checks, etc. work that are the problem here.

So that does not work then.
Good, OP's questions are answered then.