Destructible geometry

[ZZYZX]

Hello.

So basically this is a horizontally borrowed feature from another 199x game called Radix (just because I occasionally poked at the map format of Radix and realized we can have it here as well).
In the original engine, the point is that wall has some hitpoints, you can shoot at the wall and once hitpoints reach 0 some scriptable trigger is executed.

Intended usages:
Automated glass breaking by explosive effects (without having scripted actors)
DN3D-like forcefield effects (since this actually returns information in the form of "wall X was damaged at X/Y/Z")
Script effects based on any shooting at specific parts of sector linedefs or even sector floor, with numbers (i.e. count of damage, damage type...)
Ideally, once ZScript part is implemented, it should be straightforward to script it in a way that the user only needs to put a specific texture (e.g. lamp or glass) that will do some actions once destroyed (spawn effects, change textures, flags) — with everything else managed from events.

Video!
https://streamable.com/4qmal

Changes to UDMF entities:

• sector
  • healthfloor
  • healthceiling
  • health3d
  • healthfloorgroup
  • healthceilinggroup
  • health3dgroup
• linedef
  • health
  • healthgroup
  • damagespecial (flag)
  • deathspecial (flag)

Added specials:

• 150:Line_SetHealth
• 151:Sector_SetHealth

Added ACS functions:

• GetLineHealth — returns health for either first line by id, or health group's health if it's set
• GetSectorHealth — returns health for either first sector by tag+part(floor/ceiling), or health group's health if it's set

Here's how it visually works in the geometry:

The "health3d" field in the sector is expected to be used in 3D floor control sectors for convenience (along with SECPART_3D and separate trigger things for this).

About health groups:
"Health group" is an object that synchronizes health for all participating geometry (lines and sectors).
This is so that you can have a single visual object composed of multiple sectors/linedefs that will receive damage synchronously.
Any damage-related specials (either by line activation or sector actions) will be called for each of the participating objects.

About logic of receiving damage:
With ACS and line/thing actions, it's simple: hitscans and projectiles inflict damage directly, radius damage inflicts radius damage based on closest part of sector (or closest part of damage group) that's not blocked.
Specials will be executed either on each damage or when health of object is zero (i.e. it dies), depending on which trigger is used (there are two kinds of line activation flags and sector triggers).
With ZScript, I'm planning to make an event that should provide all the detailed information on who hit which object and how, and provide a way to modify received damage in the event callback.

Current issues:

• ZScript interface planned but not implemented
• Portals are not supported for radius damage (p_map.cpp:P_GeometryRadiusAttack) because the logic is complex enough even without portals
• Radius damage is kinda weird with slopes
• ACS_ExecuteWithResult combined with health groups is going to return weird values for GetHealth resolved
• Behavior of shooting at portals/skyboxes/other weird line/sector types is undefined (suggestions?)
• 3D floors not yet implemented — planned as sector triggers in the control sector (with health also taken from the control sector) resolved

Overall this is still somewhat in dev and testing, code review/opinions/whatever highly welcome.

Build for testing if anyone is interested: https://www.mediafire.com/file/zblzrcfc ... y.zip/file
PR for GZDoom: https://github.com/coelckers/gzdoom/pull/611
PR for ACC: https://github.com/rheit/acc/pull/74

Example wad (only works with destructiblegeometry branch or build above):
http://www.mediafire.com/file/nahkay69e ... t.wad/file

[Graf Zahl]

Can you please reorganize this that it isn't scattered throughout the code? This is such a complex and extensive features that all related code should be in its own file so that they are easier to find later. Also, after doing that, please squash the commits into one.

This looks like something that will most likely be extended later, and nobody wants to hunt for all the code involved.

[ZZYZX]

Squashed.

Moved most complex logic to p_destructible, with the exception of handling projectile death (because it's too closely related to the collision code).
Overall most of the scattering is due to existing structure — UDMF fields are declared in one file, action specials in another, ACS functions elsewhere... But yes, tried to have most special logic in the separate file.

[Graf Zahl]

Overall most of the scattering is due to existing structure

I know. At some point I'd really like to clean up the code. But this has grown over 24 years by now - 4 of those even before ZDoom came to be.

[ZZYZX]

btw, a random bug that I've found while implementing this, is that P_XYMovement doesn't trigger "actor hits ceiling" actions (can be resolved by this condition)

Easiest test case is making a slope like this and running into it:


I think just logging it here for now to avoid merge hell later if I report/fix it separately.

[Graf Zahl]

Added.

Now you can add the fix for the last mentioned issue.

[ZZYZX]

https://github.com/coelckers/gzdoom/pull/614

Actually I didn't expect this to be added so soon, so it's a bit unfinished
One thing that I can remember right now is that savegames are not handled at all, so I'm going to soon make a new PR to serialize list of FHealthGroups as well as Health values for various entities, so that it at least starts being usable.

Everything else from the issues (ZScript, 3D floors...) maybe later as a single different PR.

[Graf Zahl]

Actually, if you have unfinished features it's not time for a PR. It's better to just start a discussion thread here then. I actually missed the serialization issue completely when looking through it.

[ZZYZX]

Well on serializing, here it is: https://github.com/coelckers/gzdoom/pull/615
With 615 in, the unfinished features are more like "there's still something to add" rather than "it doesn't work".

But on the actual feature addition — hence the "maybe later" — after a discussion and some planning that is. Since while existing parts are very unlikely to change, I'm still not sure how some new things are going to work.

Either way sorry for submitting an incomplete PR, actually expected some review and responses ranging from "[No]" to "X is broken, redo before adding please" Won't do it again.
Going to make the second part more complete. Other than that, I actually missed the serialization as well. Only realized after merging.

[Rachael]

In GitHub, where you first create a PR (before actually submitting it), you will get a compare link in your location bar.

If you want to trigger a discussion and a review for your code, share this link, before actually submitting the PR.

Here is an example of such a link: https://github.com/coelckers/gzdoom/compare/master...jewalky:destructible-saveg?expand=1

[Gez]

Or perhaps you can name it accordingly, e.g. this is currently entitled "[DON'T MERGE YET] Shadows".

[dpJudas]

Having an open PR that is being worked on isn't so good because it produces emails each time someone commits to it.

[Sir Robin]

Hello, I know this is an old thread, but I wanted to know if the zscript features were ever implemented? I ask because using level.FindHealthGroup() gives me an object that I don't understand.

For example, with this code:

Code: Select all

		HealthGroup hg = level.FindHealthGroup(args[0]);
		if (!hg) return;

		console.printf("HealthGroup number:  "..args[0]);
		console.printf("HealthGroup id:      "..hg.id);
		console.printf("HealthGroup health:  "..hg.health);
		console.printf("HealthGroup lines:   "..hg.lines.size());
		console.printf("HealthGroup sectors: "..hg.sectors.size());

the id is not equal to the id I searched on
the id seems to be a random number, usually about 9 or 10 digits long
the health seems to be a random number, usually in the 300-600 range
the lines count is always 100
the sectors count is always 0