Prop_static

[Silenthunter]

So while i was mapping i tried to put in a prop_static, but i cannot get it to stick to the grid so that it doesn't clip walls or other objects, is there anyway that i can fix this so that it lies on the grid, or does it just have to clip a little bit on each side?

 

[Rogue Sniper]

Moving one prop at a time bases of the X or center.

Moving multiple props bases it off the corner youre dragging on.

If you go to view/map > Snap to Grid, it aligns to grid if thats what you want.

 

[Silenthunter]

Well what i was talking about is how do i snap the box around the prop to the grid, to align it so it doesn't clip walls or the floor of my map.

 

[ACCIDENT PRONE GUY]

You can always move it manually while holding alt to move it exactly to your liking.

 

[pickles]

You cant. It the prop. If you choose a similar prop it might work. Its just the size of the prop doesn't correspond to the grid size.

 

[Valiant Fluffy]

In Css this happens all the time. In the OB engine valve is better about this.

 

[evicted]

Prop_static seems useless to me, its all errors in game and there is no customizing of any kind. I'd suggests using prop_dynamic instead.

 

[pickles]

Prop_static seems useless to me, its all errors in game and there is no customizing of any kind. I'd suggests using prop_dynamic instead.

or you could also use prop_physics. I don't really know and am not really concerned about the differences.

 

[PhaseXero]

When you open the prop browser, under the info tab it lets you know exactly which entity types it can and cannot be. If you are getting errors chances are you assigned a prop_static to a strictly prop_physics design.

The differences between the prop entities are that they use increasing amounts of cpu and gpu processing power. Static, Dynamic, Physics, Ragdoll <- Ascending order of power usage.

 

[pickles]

Okay, so what I've learned from PhaseXero, use Dynamic most.

 

[PhaseXero]

How much customization do you need, according to the valve sdk wiki:

"It cannot move, animate, or accept input, and in fact doesn't actually exist as an entity after the map has been compiled. The vast majority of models appearing in a typical map are prop_static."

If you just need it to sit there and look pretty, this is pretty much the object for you. If you need it to move then prop_physics, and actually i would suggest prop_physics_multiplayer to reduce complex movement and reduce cpu/network time.

This is the source sdk wiki page for all your prop needs: http://developer.valvesoftware.com/w/index.php?title=Category:Entities&from=Phys+constraintsystem

 

[batterytime]

Sorry for semi-thread necro, but to clear this debate up, if using a prop_static doesn't break anything (i.e., the prop doesn't disappear or something) use prop_static for a static, nonmoving model. Some models aren't compiled static_prop, so you'll have to use prop_dynamic there, but for performance, use prop_static if possible. In fact, if you don't even need for the prop to be solid, use prop_detail, which is just the visual model (no collisions) and is even better for performance.

 

[BeaverKing]

shouldnt be using dynamic the most pickles. hehe

im not sure what the intial question was here, but you can always decompile a model, edit the .qc to include staticprop capability, and recompile it if you need to...

 

[batterytime]

But Beaver, that increases the time needed, increases the map size (have to pakrat it in) and increases annoyance, just for one model. It's just easier to use a prop_dynamic, you can use like a couple hundred in a map anyways.

 

[BeaverKing]

i understand that... was just saying, if youre really worried about decreased performance tho from a lotta dynamics it's an alternative, albeit a last resort sorta one :biggrin:

 

[Rogue Sniper]

A dynamic without any active animations aka a dynamic in disguise as a static is basically a static.

So basically 200 dynamics = 200 statics if done correctly.