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.

So, without needing to omit it, the same info can almost all be rephrased to take up fewer words, fewer sentences, and use fewer graphics. Cvoxalury (talk) 08:50, 20 June 2024 (PDT)

Another idea is maybe to form a table for all of it at once?

It would take some consideration on how to group what together... but something like this

Engine	Max static props[i]	Supports vertex lighting	Supports lightmaps	Supports uniform scaling
2007	8192	Yes, but not with $bumpmap or $phong	No	No
2013SP	8192	Yes, but not with $bumpmap or $phong	No	No
2013MP	8192	Yes, but not with $bumpmap or $phong	Yes, but not with $bumpmap	No
CSGO	20480	Yes	Yes	Yes

and so on...

(the [i] would be a ref saying it's shared with other entities)

This doesn't describe all bugs, but maybe it can help alleviate the issue.

The whole nest of caveats with lightmaps on static props - I'd allocate a separate page with a tutorial on that. As a mapper I can say it's been a subject that's defeated me, so that can be useful. Cvoxalury (talk) 09:02, 20 June 2024 (PDT)

And they're not even actual bugs. That something wasn't in a particular engine feature isn't a bug... bug is unexpected behavior, but that limited behavior isn't a result of that.

I think the section should be rechristened "Known limitations" and organised in sub-sections, which would be mostly concerned with lighting, limits, and a few known behavior quirks. Cvoxalury (talk) 13:55, 20 June 2024 (PDT)

I gave it a try with rewriting the section. Tell me what you think. Cvoxalury (talk)

Reads a lot better to me and doesnt feel near as filled with colorful junk that is impossible to decipher. --Haaselh0ff (talk) 21:13, 20 June 2024 (PDT)

It's longer, but it's clearly written, so hopefully people will complain less now. I added in some notable information that got lost in the rewrite.
— SirYodaJedi (talk) 09:16, 22 June 2024 (PDT)