Making a default hl2 model breakable?

JFry

Tank
Joined
Sep 1, 2004
Messages
1,420
Reaction score
0
What I'm trying to do is make it so you can shoot a radio model and cause it damage until it breaks.

I've tried setting it to prop_physics_override and giving it a health value but this didn't work. I've tried making it a prop_physics and turning off smart edit and adding a health parameter but that didn't work either.

I also tried parenting a func_breakable to the model and having it kill the model on break. This worked but it seemed to create too much lag and when carrying it with the gravgun the prop would block you unless you drug it behind you.

I tried to get the model's source files and recompile it as a breakable model but due to my own lack of understanding .qc files this didn't work either.

I'd appreciate any ideas anyone has as this is really holding me back on a map I'm making.
 
I'd go with the breakable but make sure that the breakable is nonsolid and all that....
 
Not sure if I'm understanding you correctly here. Are you saying use the func_breakable method and set it to non-solid? There doesn't seem to be a setting in func_breakable to do this.
 
Let me just say that I don't map, however, I doubt anything originally non-breakable could be made breakable, as the model(s) for it when its broken would not be there.
 
Well, the func_breakable is really not meant to be dragged around and whatnot so I can see it causes lag and all of that.

However, a physbox is really just a physically simulated breakable that can be set to being nonsioliod and all of that. Plus it's meant tio be dragged around. :)
 
Well I tried func_physbox but it wouldn't break (in hl2dm anyway). Yet with the same settings on a func_breakable it breaks. Maybe its just messed up sdk. I'm using the ep1 engine because its more stable (or supposed to be).
 
Does HL2DM use CSS gcf? If so then there is a breakable radio there. From cs_office.
 
Wouldn't you have to make separate models for the Gibs that would show when you break the radio? Or do you just want it to dissappear?
 
I don't think you can use CS assets for hl2dm. Also I'd prefer the radio from hl2 as my map is based around rebels vs combine.

As for the gibs I would be ok with it just disappearing on break but I'm fairly certain you can make it spawn generic gibs (i.e. metal,small). I just can't seem to get it to work.
 
So make a physbox which you can darg the radio around with and then have that trigger the radio to kill itself once damaged.

Also parent an env_shooter to the physbox and have that shoot out a multitude of gibs.
 
I tried parenting a nodraw physbox to the radio prop but this gave me the same lag problem as the func_breakable. For now I've stolen the prop's textures and slapped them on a physbox as a workaround. It's a fairly simple prop so it doesn't look too bad.
 
I had to get a cure for this one, and luckily I found one...

Here is what you need to create a radio that breaks on bullets and physics using a non-breakable model.

1. prop_dynamic_override

This shows our radio and nothing else. The _override allows us to use props meant to be physically simulated = prop_physics*. If your prop is static then just use prop_dynamic.

Name: radio
Parent: invisible_helper
World Model: models/props_lab/citizenradio.mdl (Is the one i used. This is of course optional)
Collisions : Not Solid

All other options are optional.

2. func_physbox

The physbox handles physics and damage. Make it occupy roughly the same space as the radio model and give it a proper material. The material will not show, but is used for calculating weight, friciton and sounds etc. etc.

Name: invisible_helper
Strength: 1 (Any value except 0 will cause this to be breakable)
Material type: Metal (Spawn metal gibs when broken)
Render Mode: Texture (Allows us to set the transparency of this object)
FX Amount : 0 (Fully transparent = invisible)

All other options are optional.

Finally give the physbox the following output
OnBreak - radio - kill

Compile and play. =)
 
Thank you it works great. I appreciate you taking the time to spell it out for me.
 
Not a problem. I like working things like thiese out.

For the record, what was messing it up for you before was having two physically simulated objects / two colligin objects inside each other. (By this I mean either 2 phys objecs or one dynamic an one phys)

Phys object is grabbed by the gun and then the object collides with the other object inside itself, making it lagy and buggy. In the case where you pushed it in front of yourself you moved the phys object but then collided with the other objecgt (phys or dynamic) making you stop, and then the phys object collides with the other object and the mayhem is started.

The key is as always to override settings in objcets so that only one object has one kind opf setting. If only one object is allowed to collide (and thereby also allowed to be physically simulated), only one object is allowed to render, etc, then tere should be no trouble.
 
Back
Top