Much Ado about Breakable Doors

[chumbucket91]

EDIT: This maybe should've been in the editors guild instead of here, whoopsie.

I am working on a map and trying to design a breakable wooden object so that my players can bash their way into a junky old wooden hut. So far, I've converted a func_static model into a func_damageable that triggers a func_remove, func_emitter for some sparks, and speaker for a wood smashing noise.

This solution is working, but I have a couple questions about it:
 1. Right now the effects I've put together are missing a little spice - I'd like the object to spawn some wooden plank giblets when it breaks that go flying generally-up-and-away from the player, and then remain as physics objects on the ground. I saw this sort of thing referred elsewhere on the wiki as "flinder", and I found the junk models I'd like to use, but I'm having trouble finding a generic entity-with-velocity-and-spread multi-spawner? Maybe I've just missed an obvious but weirdly named func somewhere?

 2. Is there an easier built in way to do this with fewer moving parts? I found func_breakable, which had a lot more built in spawnargs (and the whole flinder mechanic), but that seemed to be optimzed for turning brushes into breakable glass panes. When I changed my func_static's class to func_breakable, the model disappeared, so it seems like its not the tool for this job unless I did something wrong.

 3. If the answer to (2) is "not really", is there a good way for me to duplicate this work so that I can make more breakable wooden objects that work basically the same way? Behind this door, I would like to make a makeshift "barricade" of several pieces of furniture and crates and etc that I would also like the player to be able to smash through. I can copy and paste the whole setup and just change the model, but I'm wondering if I can make my own kind of multi-entity prefab definition in DR that only has a few configurable bits that I actually want instead of all possible args for func_emitter, func_remove, speaker, etc.

Edited April 13 by chumbucket91

[chumbucket91]

After doing a bit more homework and poking around, I've discovered that the answers to (2) and (3) are "make your own prefab", and a prerequisite for doing that is "make a proper project folder for your map, in which you can place a prefabs/ subfolder", which is a thing that I should have done anyways before I spent several hours making a wooden shack for players to break into, and also a long winding forest path up to said shack.

So the only real question I have now is (1) - is there any sort of entity multi-spawner for chunks of physics objects that I can use for wooden flinder.

[datiswous]

I think here is some info about flinders: https://wiki.thedarkmod.com/index.php?title=Breakable_objects#What_happens_when_an_entity_dies?

So I think you replace the door model with different door pieces that fall to the ground. Maybe it's possible to make a custom one for wood pieces. Also maybe it's good to add a quick smoke particle or something that happens when it breaks so (maybe) you can hide the transition.

 

I wonder if you could set:

"def_flinder"               "models/darkmod/junk/door01_broken_piece.lwo"
"flinder_offset"            "0 0 -5"
"def_flinder1"              "models/darkmod/junk/door01_broken_piece1.lwo"
"flinder_offset"            "0 0 5"
"def_flinder2"              "models/darkmod/junk/door01_broken_piece2.lwo"
"flinder_offset"            "0 5 -5"
"def_flinder3"              "models/darkmod/junk/door01_broken_piece3.lwo"
"flinder_offset"            "0 -5 0"

Because I think"flinder_count1" probably makes copies and maybe you don't want same looking door pieces.

 

At least that's my idea currently. But I never tried any of this.

[chumbucket91]

9 hours ago, datiswous said:

I wonder if you could set:

"def_flinder"               "models/darkmod/junk/door01_broken_piece.lwo"
"flinder_offset"            "0 0 -5"

Gave all of these flinder defs a shot in the door func_damageable entity, and had no luck - if these flinder objects spawned, they didn't spawn near the model or anywhere in the viewport that I could see. I did assume that I wasn't supposed to redefine "flinder_offset" 4 times? and named the subsequent ones "flinder_offset1", "flinder_offset2", etc. and tried a few other variations as well. Nothing seemed to spawn, and there were no interesting console entries either.

Any debugging tools I could try to look for these?

[snatcher]

While working on the Fragile Bottles mod (idea / release) I examined the Flinder feature and my conclusion was that it never was fully realized and it is not ready for general / complex use.

Here is the relevant topic:

For the breakable bottles I couldn't figure out safe offsets and I found flinders would often clip with one another or spawn where they shouldn't and I opted for a scripted solution to have full control. I originally intended bottles to break into two pieces but sizes and heights of bottles vary and I ended up using only one piece but that piece along with a particle and the sound sell the effect nicely, imho.

For flinders to work I guess the first step is to work with the original model and split it into pieces while retaining the origin. I think this is the most important aspect to avoid issues. If you then add some dust particles you can probably hide the swap a little and do away with less pieces. Since you can hardly control where the pieces will end and to prevent the player from getting stuck, flinders will have to be frobable or perhaps non-solid and fade out shortly after spawning.

"In Remembrance of Him" by @RPGista can perhaps be a source of inspiration. Go to coordinates 12305 -5900 -185 for a less elaborated but still effective alternative to what you are trying to achieve.

[Dragofer]

I have a working setup of a destroyable 3D objects in the form of the camgoyle, security cameras and the turret. I've extended the flinderize system for these entity types, but the basic components that should work on any static entity type are:

• A health spawnarg, so that the entity knows when to break. By default it'll be vulnerable to sword attacks, broadheads, fire arrows and fast-moving moveables.
• A "broken" spawnarg, which defines the model to switch to when the entity is broken.
• The flinder spawnargs shown above.

The damage detection on a func_static is simple. For example, a fire arrow's splash damage is always 30 as long as the entity was within the splash radius, and you can't disable certain damage types. I don't recall a general-purpose entity type that offers better control atm, but technically you could turn your door into a disabled security camera if you wanted to make use of all of the damage spawnargs described on this wiki page, but you'd need to assign a simple collision mesh to the door.

[HMart]

idTech4 engine has used on Doom 3 already had a destructible entity system for the destructible barrels, was that removed? 

In Doom3 you can create debris entities and they become physics entities, never heard of this "flinder" stuff so I assume is a new TDM entity type.

Don't know if this is useful for TDM, if not ignore, but who knows could give some hints. 

This was how I created a simple destructible wood barrel in Doom 3 engine. 

First I defined the broken debris peace's: (yes they are individual entities and models) 

entityDef debris_woodbarrel_1 {
	"spawnclass"				"idDebris"
	"mins"						"-3 -3 -3"
	"maxs"						"3 3 3"

	"model" 					"models/maps/temple/mapobj/pipo broken/pipo_debri_1.lwo"
	//"skin"						"skins/exp_barrel_red"

	"health"					"0"					// amount of damage projectile can take if damaged (0 means it can't be destroyed)
	"velocity"					"1 1 450"			// how fast the projectile leaves the gun (or distance if fuse is 0)
	"random_velocity"			"1"						
	"angular_velocity"			"105 215 10"	    // how the projectile is rotating when it leaves the gun
	"thrust"					"0"					// the rate of acceleration (always in the direction of the projectiles model)
	"thrust_start"				"0"					// when to start accelerating
	"thrust_end"				"0"					// when to stop accelerating
	"linear_friction"			"1.0"				// "air" friction
	"angular_friction"			"0.1"
	"contact_friction"			"0.9"
	"bounce"					"0.1"				// how much speed a projectile retains when it bounces off of objects (coefficient of restitution).  0 means no bounce.
	"mass"						"50"
	"gravity"					"1066"				// how much gravity affects the trajectory.  gravity direction is same as the entity that fired it.
	"fuse"						"10"					// how long before the projectile is removed or self-detonates.  Use 0 for beam weapons (velocity == distance).

	"detonate_on_fuse"			"1"					// whether projectile should detonate when it's fuse runs out
	"detonate_on_death"			"0"					// whether projectile should detonate when it's "killed" (health runs out)
	"detonate_on_world"			"0"					// whether projectile should detonate when it hits an obstacle
	"detonate_on_actor"			"0"					// whether projectile should detonate when it hits a character in the game

	"smoke_fly"					"debristrail.prt"	// particle effect while in the air
	"snd_bounce"				"tray_impact"

	// parametric particles -- temp
	"model_detonate"			""
	"smoke_detonate"			""					// particle effect when detonates
	"smoke_fuse"				""
	"smoke_bounce"				""
}

entityDef debris_woodbarrel_2 {
...
}

etc,

then I define the main entity:

entityDef moveable_woodbarrel {
	"editor_color"				"0 .5 .8"
	"editor_mins"				"-16 -16 0"
	"editor_maxs"				"16 16 48"
	"editor_rotatable"			"1"
	

	"editor_usage"					"Moveable woodbarrel. Works just like a func_moveable. However the barrel"
	"editor_usage1"					"has special handling to make it appear more round. This version also explodes when damaged enough."
	"editor_usage2"					"Only add model, model_detonate or model_burn or health to override defaults"
	"editor_var burn"				"number of seconds to burn before exploding."
	"editor_model model_damage"		"model to leave as damaged base"
	"editor_model model_detonate"	"ips model to switch to for explosion."
	"editor_model model_burn"		"ips model to show when on fire."
	"editor_var def_debris"			"add as many as you like, debris1, debris2, etc.. "
	"editor_var health"				"how much health the barrel has, default is 5. If burn is set to 1, the health is effectively doubled so you have to kill it twice to get the explosion"
	"editor_var respawn"			"if non zero the number of seconds to respawn after killed"
	"editor_var respawn_range"		"no player in distance range to actually respawn - default 256"
	"editor_var respawn_again"		"try again in seconds if player in range - default 10"
	"editor_var triggerTargets"		"if set to 1 will trigger targets after being killed"
	"editor_mat mtr_lightExplode"	"light shader to use for explosion"
	"editor_mat mtr_lightBurn"		"light shader to use for burning"
	
	"spawnclass"				"idExplodingBarrel"

	"density"					"0.02"
	"friction"					"0.2"
	"bouncyness"				"0.4"
	"def_splash_damage"			"damage_moverCrush"
	"ignore_player"	            "1" 
	"model"						"models/maps/temple/mapobj/pipo.lwo"
	"def_debris"				"debris_woodbarrel_1"
	"def_debris1"				"debris_woodbarrel_2"
	"def_debris2"				"debris_woodbarrel_3"
	"def_debris3"				"debris_woodbarrel_4"
	"def_debris4"				"debris_woodbarrel_5"
	"def_debris5"				"debris_woodbarrel_6"
	"def_debris6"				"debris_woodbarrel_7"
	"def_debris7"				"debris_woodbarrel_8"
	"def_debris8"				"debris_woodbarrel_9"
	"health"					"35"
	"snd_explode"				"wood_barrel_breaking"
	"snd_bounce"				"woodimpact"
	
}

This was the effect:

https://drive.google.com/file/d/1lsXwNssxp-QO3MZKOmUiBd1DWhd0V7HY/view?usp=sharing

Hope this helps. 

Edited April 19 by HMart

[chumbucket91]

13 hours ago, Dragofer said:

A "broken" spawnarg, which defines the model to switch to when the entity is broken.

Ah, this might be the piece I'm missing.
What would I set this to if I still want to spawn the flinderize pieces but I want the model to effectively disappear? The point of attacking the door is so that you can proceed to walk through it, so I don't want to leave an even-more-broken mesh behind, if that makes sense. Currently I'm removing the door with a func_remove when it reaches a health value of <= 0, but if I could instead replace it with some empty mesh maybe the flinder bits will stick around.

Edited April 20 by chumbucket91

[Dragofer]

9 hours ago, chumbucket91 said:

Ah, this might be the piece I'm missing.
What would I set this to if I still want to spawn the flinderize pieces but I want the model to effectively disappear? The point of attacking the door is so that you can proceed to walk through it, so I don't want to leave an even-more-broken mesh behind, if that makes sense. Currently I'm removing the door with a func_remove when it reaches a health value of <= 0, but if I could instead replace it with some empty mesh maybe the flinder bits will stick around.

You could use the spawnarg hideModelOnBreak 1 to hide the entity completely. You may still need to set the broken spawnarg, even if its the same as the model spawnarg.

A suitable broken model if it were still visible could be something that just has the hinges and one board left, but probably not that easy to tweak models when youre still new to mapping.

[chumbucket91]

Quote

basic components that should work on any static entity type

It seems that this isn't as much of the case as one would hope, unless I'm still doing something else wrong. I added the broken and hideModelOnBreak spawnargs to my current setup, but the model isn't hidden on destruction and the flinders still don't spawn.

I then took a slightly different track and tried to rig the security camera to actually be a door. This approach seems like the correct-er one, although the sound effect when striking it with a sword seems a bit off. Like its repeating every frame that the sword is in contact with the model, maybe? Also, setting the clipmodel correctly is giving me trouble, so you have to swing at some air on the left side of the door to destroy it - I'd like TDM to derive the clip from whatever is set in the model arg, but setting a clipmodel to 0 or "" or some other obviously invalid value doesn't seem to trigger that behavior like the documentation strings claim it does - instead, it throws an error when I attempt to map (dmap completes just fine either way).

In case it helps, I've attached a sample .map with a player start, an inventory full of smashing gear, a light, and my two breakable-ish doors. The one on the left is the doorified-camera, which sounds weird and clips weird (and crashes the game when I try to correct the latter by setting the clipmodel spawnarg to ""), and the one on the right is my model-turned-damageable and doesn't flinder or disappear. I'd be happy if I could get the left one to clip like its visual model (I would like to reuse this as a prefab, and swap out different models like half-broken crates or barrels - so just creating my own clipmodel isn't great (although it looks like a ~30s task based on https://wiki.thedarkmod.com/index.php?title=Moveables so maybe thats the way to go)), or the right one to flinderize and disappear. Is there something I'm still missing or misunderstanding about either setup?

EDIT: Making sure I've uploaded the right version of the testmap I've made

breakable_door_flinder.map

Edited April 21 by chumbucket91

[kingsal]

Coming in late in this discussion, but I've made some breakable crates for Volta 3 that work pretty well. It is a real pain to get the flinders to spawn at the right place since they need to spawn a few units away from each other or their clip models will get stuck and they'll float in the air. 

If its helpful, you can check them out in volta_breakable_crate.def. 

Breakable doors would be pretty cool, I wonder how AI will react to them? 

Edited May 2 by kingsal

[HMart]

8 hours ago, kingsal said:

Coming in late in this discussion, but I've made some breakable crates for Volta 3 that work pretty well. It is a real pain to get the flinders to spawn at the right place since they need to spawn a few units away from each other or their clip models will get stuck and they'll float in the air. 

If its helpful, you can check them out in volta_breakable_crate.def. 

Breakable doors would be pretty cool, I wonder how AI will react to them? 

I solved that issue by disabling collision between the peace's, if you see on the video I posted they don't collide with each other only the environment. Is not perfect I know, nor realistic but imo is better than making sure they spawn separate, prevents you from making them spawn in place for example, to make the break more realistic and also saves on performance what its a bonus imo, because gives you the option to put many breakables in the same space. And many comercial games used this trick as well and probably still do thou I have not being paying attention. 

[kingsal]

13 hours ago, HMart said:

I solved that issue by disabling collision between the peace's

I don't think idDebris will work in TDM.  Its mentioned a couple times in the source code related to projectiles and there is a defunct def of it in d3_junk.def. 

AFAIK - we need to use the flinder objects which I know grayman did some work on  back in probable 2.7 or 2.8 to make them usable.

Unfortunately I couldn't get them to ignore their own collision, maybe there is a spawn arg I'm missing. 

Another issue is if you break a crate by an elevator or by a door, the flinder objects could potentially stop the elevator or door from moving. So I could either have them disappear after a time OR make them grabbable so the player can move them out of the way. I opted for the later because it made more sense. 

 

Edited May 3 by kingsal

[chumbucket91]

On 5/2/2025 at 12:48 PM, kingsal said:

I've made some breakable crates for Volta 3 that work pretty well. It is a real pain to get the flinders to spawn at the right place since they need to spawn a few units away from each other or their clip models will get stuck and they'll float in the air. 

If its helpful, you can check them out in volta_breakable_crate.def. 

I took a bit of a break from poking around with mapping for a few weeks, but I will check out both the mission and these crates. Ty!

[snatcher]

On 5/2/2025 at 7:48 PM, kingsal said:

Coming in late in this discussion, but I've made some breakable crates for Volta 3 that work pretty well.

Your crates in Volta 3 are excellent. Goodies inside and all!

I wish your poweder kegs from Volta 2 were as good: for strategic playing kegs should explode with a single hit of a broadhead. Unfortunately they require many hits rendering them useless.

Elements such breakable looting crates and exploding barrels should be part of the core TDM offering.

[kingsal]

1 hour ago, snatcher said:

Your crates in Volta 3 are excellent. Goodies inside and all!

I wish your poweder kegs from Volta 2 were as good: for strategic playing kegs should explode with a single hit of a broadhead. Unfortunately they require many hits rendering them useless.

Thanks! I thought they were pretty fun. 
I haven't looked at those powder kegs in a long time, but it might be worth re making them someday. I remember them being fun to light with the flint and then tossing them on bad guys heads.  

@chumbucket91The powderkegs in volta 2 also use the flinder system but I think its a very different set up from the crates in volta 3. Might be useful in your search though. 

Edited May 4 by kingsal

[chumbucket91]

2 hours ago, snatcher said:

Elements such breakable looting crates and exploding barrels should be part of the core TDM offering.

Now this is the kind of spicy pepper that I enjoy biting into. I feel like this would be simplest to solve by adding some prefabs to tdm_prefabs01.pk4, with sensible defaults but some obvious exposed customizable bits, and maybe a tiny wiki article to document what can be done with them.
No idea what it takes to make something(s?) part of the core package of TDM prefabs, but I'm willing to put in work to make it happen. When I revisit this (which will probably be a couple weeks), I'll upload whatever solution I end up with as prefab .map files to this thread and I suppose we can test/bikeshed from there.

How to make it work well with the AI would be my big open question. I imagine kicking down a door/crate/exploding barrel should alert hostile NPCs and make neutral ones hostile, and should probably do so in a large radius. It sure feels like the kind of thing that should be a last resort with significant downsides in a Thief-y open source im-sim game. The breaking doors I was trying to get to work are in an area with no NPCs, so I haven't even tried to solve or test its effect on nearby AIs.

[snatcher]

12 hours ago, kingsal said:

Thanks! I thought they were pretty fun. 
I haven't looked at those powder kegs in a long time, but it might be worth re making them someday. I remember them being fun to light with the flint and then tossing them on bad guys heads.  

Uh.

I never figured out how powder kegs were supposed to work... until today. Such a fool I am.

[HMart]

On 5/3/2025 at 5:17 PM, kingsal said:

I don't think idDebris will work in TDM.  Its mentioned a couple times in the source code related to projectiles and there is a defunct def of it in d3_junk.def. 

AFAIK - we need to use the flinder objects which I know grayman did some work on  back in probable 2.7 or 2.8 to make them usable.

Unfortunately I couldn't get them to ignore their own collision, maybe there is a spawn arg I'm missing. 

Another issue is if you break a crate by an elevator or by a door, the flinder objects could potentially stop the elevator or door from moving. So I could either have them disappear after a time OR make them grabbable so the player can move them out of the way. I opted for the later because it made more sense. 

 

That is very surprising, idDebris imo was a very useful entity, not only for projectiles, thou this "flinder" class apart from the physics seems to be the same thing, thou I was unfamiliar with that word.

Also probably idDebrie add code that couldn't be transferred to standalone TDM or something.  

I would love to give better help because I do think more destructibility for TDM objects would be cool, but unfortunately I did that stuff so long ago that I totally forgot how I disabled the physics.

I went to look at the Doom 3 idDebris c++ code and saw nothing directly that says "disable physics" but I did saw something in Entity.cpp, a function called RunPhysics() that is also called by idDebrie class, and on there, I saw a particular entity flag, one called "fl.solidForTeam", that sounds like it controls physics for entities in the same "team" and that is probably what I used.  
So I imagine that there's a way to negate this flag through scripting?

try writing a entity spawnarg "solidForTeam 0" on the flinder objects in the editor. 

Edited May 5 by HMart

[chumbucket91]

On 5/2/2025 at 12:48 PM, kingsal said:

Coming in late in this discussion, but I've made some breakable crates for Volta 3 that work pretty well. It is a real pain to get the flinders to spawn at the right place since they need to spawn a few units away from each other or their clip models will get stuck and they'll float in the air. 

If its helpful, you can check them out in volta_breakable_crate.def. 

Breakable doors would be pretty cool, I wonder how AI will react to them? 

So I came back to revisit this, and managed to port 95% of the Volta 3 breakable crates to my current project. It looks like I'm missing a material definition for the flinder bits the crate leaves behind after exploding, but according to the .ase that texture is "textures/darkmod/wood/boards/tdm_crate04" which... sure seems like a tdm builtin? I'm not sure how the breakables can't find it. Attached a picture for reference (the FM is quite dark on purpose but those black squares shouldn't be pitch black like that).

Other than this minor hiccup, this seems like the coolest solution that is the closest to what I want - but the downside is that now my project folder has a ton of extra junk and new volta-specific folder structures, entity definitions, and whatnot in it that I blindly copied and pasted.

I'm gonna try to remove the volta specific stuff as much as I can and replace with some tdm defaults and see how it goes!

[datiswous]

12 hours ago, chumbucket91 said:

but according to the .ase that texture is "textures/darkmod/wood/boards/tdm_crate04" which... sure seems like a tdm builtin?

I can confirm the material and image file are present in core. Material:

textures/darkmod/wood/boards/tdm_crate04
{
	
	wood

	diffusemap	models/darkmod/props/textures/crate04
//         bumpmap	models/darkmod/props/textures/crate04_local
}

I wonder why the bumpmap is editted out though.

[kingsal]

On 5/15/2025 at 2:55 PM, chumbucket91 said:

 It looks like I'm missing a material definition for the flinder bits the crate leaves behind after exploding, but according to the .ase that texture is "textures/darkmod/wood/boards/tdm_crate04" which... sure seems like a tdm builtin? 
 

You might be missing the skin file. yourfm/skins/volta_containers.skin
 

On 5/15/2025 at 2:55 PM, chumbucket91 said:

but the downside is that now my project folder has a ton of extra junk and new volta-specific folder structures, entity definitions, and whatnot in it that I blindly copied and pasted.

Yeah that's the downside of objects like this that have a lot of associated files. Those crates have:

-volta_breakable_crate.def
-volta_breakable_crate.script
-volta_crate_break.prt (this is the particle that spawns)

1.  volta_fx.mtr -----> textures/darkmod/volta/crate_debris01
2. dds\textures\darkmod\volta_fx\ crate_debris01.dds

- volta_containers.skin
-All the flinders in \models\volta\crate
- volta_containers.mtr

1.    models/darkmod/props/textures/crate01_d_breakable
2.    models/darkmod/props/textures/crate01_local
3.    models/darkmod/props/textures/crate01_s_breakable

I think that's it. Hope this helps.

[chumbucket91]

Alright, I've done it. And then probably went overboard.

I was able to disconnect all of the volta-named bits from the entities and rename or repoint everything to assets that ship with TDM. The results don't look quite as cool, but I still was able to make a destructable crate with flindery bits, particle effects, and smashing sounds. Hooray!

I then discovered that changing the model required whatever new model I chose to also have a clip model. So there was no way to get around making clip models in darkRadiant for whatever things I wanted to be smashable. I went ahead and made really basic (cubes or 6-sided prism) clip models for all the junky broken down wooden objects I could find in the TDM assets, most of which were missing, and used those to create breakable versions of those models.

Funny enough, this approach worked for everything except the original door that I wanted to make breakable in the first screenshot of this post! There is something funny about the collision geometry of models/darkmod/architecture/doors/oversized/old_door_02.lwo . If I used it as an entity model, the map complained about not having a collision model. But if I added a simple box as a collision model, the box didn't get used! I was able to shoot arrows and walk straight through this broken down "door". So my original chain-of-random-entities solution that doesn't make flinders is probably as good as we'll be able to get from the door.

I also used this solution to try to recreate breakable banners from TG and T2, and they work pretty well. They should probably have a "torn" version that hangs from the banner rod instead of the whole banner and rod disappearing entirely, but they will serve the gameplay purpose of being able to hide safes/secret passages behind banners well enough for me.

Coming back to flinderable entities, I realized I could probably tweak the entity definition to also make breakable ceramic pots, so I made some of those too.

I ended up with ~25 prefab objects that you can smash with the sword or detonate with fire arrows - some are small enough to be picked up, but the bigger ones can only be pushed or are completely stationary. I tried to pick reasonable health values for them based on their size and apparent sturdiness. All of these can be used as obstacles to block doors or secrets. 

I've uploaded a .pk4 that contains a simple test map, the entity definitions, and the prefabs. Feel free to download, rip 'em out, and use 'em! If there are any good candidates for smashable-looking crap that I missed or any feedback on how I could make these better, let me know. If @kingsalis cool with it (...because I basically copied his homework for the scripting), I would also support making these entity definitions, collision models, and prefabs part of TDM's core, and would be willing to make whatever tweaks we think are good to help make that happen.

breakable_prefabs.pk4

Edited Sunday at 12:13 AM by chumbucket91