BMS devs, please allow us to compile prop_physics with "allowstatic" as prop_static.

[Snaiper]

Long story short, see all the HL2 props? Well, they are compiled as physics, yes, but in the GUI they also show as available as static. Why? Because they have an “allowstatic” parameter embedded in them, however, ever since the SDK 2013 that parameter remains undetected by the VBSP and so the only way to use these props in non-physics way is with prop_dynamic_override, which can very much negatively impact performance, especially on older machines.[/size]

This guy has fixed this for SDK 2013, I would kindly ask BMS devs to try and fix it in their version of the engine.[/size]

Why am I writing this? Why am I writing this right now? Well, some time ago before I took a break from my mod, I faced the same issue. My friend right now is forced to either recompile hundreds of models or consistently use prop_dynamic_override.

[Johnwalter]

Maybe it will be fixed with the Xen update?
Just asking.

[Crypt]

What’s wrong with the “motion disabled” flag?

[k3nny1550]

Static props are cheaper to render and you can use more of them than dynamic objects without significantly affecting performance, at least from my understanding.

[Snaiper]

@Crypt

What’s wrong with the “motion disabled” flag?

1. Static is much cheaper than physics, which means better performance.
2. Static does not count towards engine’s entity limit, which means that you can put in as much as compiler can take.
3. Knowing which props are static and physics out right helps with mapping, instead of having to look at their flags individually, especially if for debugging you want to disable certain prop type.

[Crypt]

I understand the technical caveats and difference between the entities, I’ve made a map or two in my time. I’m just curious of how it’s really a hindrance considering in practice this is a really limited issue wouldn’t have a huge impact considering the props it affects.

Not that it shouldn’t be fixed of course, just that I didn’t imagine it being a real obstacle in any otherwise properly optimized map. Not to the degree of having to recompile hundreds of props, anyway. Seems like the sort of edge case where Motion Disabled would do the trick. Unless your map is entirely HL2 phys props made static, in which case EW

[Snaiper]

@Crypt

I understand the technical caveats and difference between the entities, I’ve made a map or two in my time. I’m just curious of how it’s really a hindrance considering in practice this is a really limited issue wouldn’t have a huge impact considering the props it affects.

Not that it shouldn’t be fixed of course, just that I didn’t imagine it being a real obstacle in any otherwise properly optimized map. Not to the degree of having to recompile hundreds of props, anyway. Seems like the sort of edge case where Motion Disabled would do the trick. Unless your map is entirely HL2 phys props made static, in which case EW

The devs do not have to recompile the props. They just have to add a line or two into their VBSP, as I’ve originally stated. The props support this, but the VBSP does not, for some reason, this is the case in SDK 2013 as well.
Only 1/3 things I stated was about performance. So, there’s other reasons too.

[LordDz]

It’s not just for the hl2 props… Fixing two lines of code would solve a lot of headaches for mappers alike.

[Flavrans]

I’m not entirely sure what the OP is asking for, but I’ve looked at the VBSP source code in SDK 2013, and as far as I can tell, it’s working as intended. As long as the model has the keyvalue “allowstatic” set to “1” in the model’s prop_data, it can be used as prop_static. For example, the crate @LordDz used in his example does not have the “allowstatic” keyvalue set:

Whereas, for example, this model has the “allowstatic” keyvalue set:

I did some tests and confirmed that BM’s VBSP is accepting the barrel01 model as prop_static, whereas the metalcrate01 model gets deleted:

Error! prop_static using model "models/props_blackmesa/metalcrate01.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_blackmesa/metalcrate01.mdl"!
However, what that mod does, which was linked to by the OP, is enabling models to be used as prop_static regardless of whether the “allowstatic” keyvalue is set or not.

[Snaiper]

@Flavrans

I’m not entirely sure what the OP is asking for, but I’ve looked at the VBSP source code in SDK 2013, and as far as I can tell, it’s working as intended. As long as the model has the keyvalue “allowstatic” set to “1” in the model’s prop_data, it can be used as prop_static. For example, the crate @LordDz used in his example does not have the “allowstatic” keyvalue set:

Whereas, for example, this model has the “allowstatic” keyvalue set:

I did some tests and confirmed that BM’s VBSP is accepting the barrel01 model as prop_static, whereas the metalcrate01 model gets deleted:

Error! prop_static using model "models/props_blackmesa/metalcrate01.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_blackmesa/metalcrate01.mdl"!However, what that mod does, which was linked to by the OP, is enabling models to be used as prop_static regardless of whether the “allowstatic” keyvalue is set or not.

Wait, really? I swear that last time I put in a physics prop with “allowstatic” in it, it didn’t appear. I’ll test more.