Talk:Prop static

Physics prop reported as static

Despite having both physics and static flags in model browser, when I try to use furnituretable003a as prop_static, it gets deleted during compile :

Error! prop_static using model "models/props_c17/furnituretable003a.mdl", 
which must be used on a dynamic entity (i.e. prop_physics). Deleted.

The same problem occurs with other mdls boasting both physics and static modes. I want these props to get involved in the lightmap ... so they need to be prop_static right ? --Beeswax

yeah oddly the same happens for me, also some phys_props tend to have incorrect collisions too, some of the car's mainly. The only fix would to be to recompile the original model into a static prop. Oddly they might be missing the $static parameter.--Gear 19:50, 27 Mar 2008 (PDT)

Is it not a bug in the Hammer compiler ? I tried to search the SDK bugzilla db but could find nothing relevant ... --Beeswax 06:03, 28 Mar 2008 (PDT)

I believe what's happening here is that this prop has the $staticprop keyvalue in the .qc, but does not have the allowstatic key in the Prop Data block. Without compiling the model with the allowstatic key, it cannot be used as a static prop. This was on done Half-Life 2 to force physics consistency with props. The fact that Hammer reports it as static looks like a bug. Thanks for pointing this out. --JeffLane 12:00, 28 Mar 2008 (PDT)

This isn't as weird as it sounds, dear readers, because $staticprop means that the model has no moving parts, not that it does not itself move. --TomEdwards 12:24, 28 Mar 2008 (PDT)

If so the $staticprop description needs some clarification --Beeswax 12:48, 30 Mar 2008 (PDT)

That's really weird stuff, thanks for pointing that out. If only it allowed you to override QC settings like in prop_physics entities. Solokiller 12:31, 28 Mar 2008 (PDT)

Wouldn't it be nice to have a prop_static_override entity ? ;) --Beeswax 12:48, 30 Mar 2008 (PDT)

Color and Alpha

I assume Color is for applying a color to models with $blendtintbybasealpha on? ... but what's Alpha for? The description says "Alpha of the fade", and I have no idea what that means. Steve the Pocket 22:36, 14 August 2011 (PDT)

Optimizing

If you make an area you cannot go to but you can see and compile prop_static with no collisions, does this speed up compile times and/or optimize the map?

If so, I'd assume it would be because vbsp doesn't have to compile the collision model.

--Mandrew (talk) 21:16, 9 July 2019 (UTC)

Regarding complaints about the giant "Bugs and Limitations" section

I've heard quite a few complains on Discord about the growing size of the section. While all the information provided is important to be documented somehow, but it could be reorganized and/or moved.
Some suggested altercations:

• Move the section to lower on the page.
• Move the section to a subpage.

I really don't have any clue what would be the best way to handle this without omitting notable information, so I open the floor for suggestions.
— SirYodaJedi (talk) 08:25, 20 June 2024 (PDT)

I was thinking about it just earlier today. I'd say based on what I feel when looking at it, it feels overwhelming and discourages from actually getting information. Perhaps if it's more laid down in form of sentences and not graphics it can get the point better across. Yes, prop static is kind of notorious in how it's implemented in regards of models, lighting, feature support in the engine branches, but throwing down that info in the panels and banners is just so dense.

For example, there's bright yellow "risk of confusion" saying:

"Prop will be vertex lit more similarly to dynamic props, being lit based upon its origin instead of per-vertex. Set this to "Yes" to significantly reduce VRAD compile times if the prop does not benefit from complex lighting.

Risk of Confusion:This doesn't actually disable vertex lighting, but rather uses a simpler form of it that calculates vertex colors based upon the color, brightness, and direction of the origin (or $illumposition) at runtime instead of prebaking the them per-vertex into a VHV file (which is packed into the compiled BSP).

"

That's kind of... a combo of too niche and over-explanatory. Why not compress it to...

"Prop will be vertex lit more similarly to dynamic props: in real-time, based on its origin or $illumposition. This can significantly reduce VRAD compile times if the prop does not benefit from complex lighting."

It is still saying the same thing, effectively.

Because these templates... they feel like someone discovered it and ran to document it ASAP just to have the info. It wasn't relayed in form of encyclopedic information.

The warning about limits includes same repeating text that can be rolled into the numbers using <a></a>, couldn't it? The limits can be descriped in a subsection rather than big red banner. It's screaming at me that there's this limit in a thousands, but for prop statics it's rarely reachable so it doesn't need to be that front and center (speaking as someone who makes vast maps and yes, I have hit that limit once).

The bodygroup notice again can just be a bullet point. Cvoxalury (talk) 08:46, 20 June 2024 (PDT)