Welcome to PlagueFest.com! Log in or Sign up to interact with the Plague Fest community.
  1. Welcome Guest! to interact with the community and gain access to all the site's features.

prop_physics in ZM

Discussion in Mapping Discussion started by Satin Storm, Jun 12, 2013

  1. Mar 8, 2013
    I'd like a definitive answer as to when the different types of prop_physics are appropriate.

    As I understand it, small and/or breakable objects such as potted plants/trashcans/wooden chairs etc should always be prop_physics_multiplayer.

    What settings should cade props (sofa.mdl, vending_machine.mdl etc) use? I've decompiled maps made by others and the standard seems to vary. Some use prop_physics, others use prop_physics_override. Certain mappers use massScale=0 while others have it set to 1. For my map, I want solid cades (meaning players can't "float" through them). What should I go with?

    I'd appreciate any insight on this, as well as on what effect server-side settings (sv_turbophysics?) and plugins have on props.
  2. Feb 27, 2012
    prop_physics_override makes props that do not have physics properties be a physics prop. Some props are only static or dynamic, so using that one will force it into physics mode.

    prop_physics_multiplayer makes props glitchable and of course have physics output when you shoot it. Glitchable props like this should only be used on small little objects like milk crates, bottles, or certain props in a cade room that if they were non glitchable would instead make the room impossible for zombies to enter.

    prop_physics is for props that have physics properties. if the prop does not have physics properties, then it will not show up when you render the map.

    Example of something with physics properties. You can see that it also has static properties, so you can actually set it as a prop_static, although if you do, it will not generate a movement output when interacted with or shot.

    Example of something without physics properties. Only has static and dynamic, so it has to be set as a prop_physics_override

    Now, i can't remember if you can use a prop_physics_multiplayer on props that do not have physics properties, but i think you can, since i remember making soda machines in my other map glitchable.

    For the mass scale, i believe you can use that to add on to the weight of the object, but i can't remember since i was only told about it and never really messed around with it. You shouldn't need to either. In both screenshots you can actually see the Mass of the object under the info tab.

    Maybe @GRUDGE or @GiGaBiTe will be able to help you out and explain anything better, and correct anything that i may have misinformed you of, if i have.
    • Informative Informative x 1
    • Useful Useful x 1
    • Jul 28, 2011
      I think you summed it up pretty nicely, @Tony the Tiger!! :D

      Also, I think that it may be more expensive to render physics_override, but that might just be my brain making stuff up.

      I personally like to have my cades non-glitchable and use prop_physics_overide with default settings.
    • Feb 27, 2012

      I think you're right about it making it more expensive to render, since it has to calculate how it will react with bullets, how it will move, and anything else it will need to know how to be a physics prop.
      Also, i like to make the majority of items in a cade non-glitchable as well. But if i have random vendies around, i like to make them glitchable, that way people don't shoot them into a tiny room and have a giant room full of props making it impossible for zombies to kill you.
    • Jul 28, 2011
      I should clarify though that in your standard zombie map, you shouldn't worry about the prop_physics_override causing any kind of lag compared to prop_physics_multiplayer. As long as you don't go absolutely off-the-walls crazy (I'm thinking a room full of 1000 vendies), you should be fine with whatever tickles your fancy.
    • Mar 8, 2013

      so I shouldn't bother fiddling with massScale at all? just leave it at 0?
    • Jul 28, 2011
      I know some people change it. I just leave it at 0. It's all personal preference though.
    • Mar 26, 2009
      massScale just changes the mass multiplier for the prop you set it on. A massScale value of 0 or 1 will make the prop weigh whatever it was set to weigh in the model QC. Just leave it at default (0) if you don't need to change the weight of the prop.

      So if a prop weighs 10kg and you use a massScale value of 2, the prop will weigh 20kg.

      Just remember heavier props are harder for humans to move around and may cause gameplay problems.
    • Apr 9, 2012
      There are a few things to clarify because I specialised myself in the making of prop_physics from the bottom till the ground up, with gibs and everything else and I made a lot of discoveries:

      Impossible as there is a limit on the amount of prop_physics (not entities in this case!). It's around 200 I think but I'm not sure.

      Anyways, the behaviour between prop_physics (PP) and prop_physics_multiplayer (PPM) is pretty big as PPM bounces players away as they reach their bounding box. What I mean with that is that, if for example you would make a physical prop that is built with a lot of holes in it where you would actually be able to stand into (and the actualy collision model would allow it if it was for example a static prop) then with prop_physics_multiplayer you wouldn't be able to at all since the bounding box always goes around the outermost points of the model, and as such bounce you away as you try to push or jump/run into it.

      PP doesn't however, and as a result is slightly, but nearly unnoticeably more expensive. PPM was designed exactly to avoid bugs with players bumping into props so that they wouldn't actually get stuck into it. prop_physics should usually be used for props where you can walk into and that actually make part of the geometry of your level that defines where you can walk etc. Why would you want to use that? In cases where you wouldn't be able to walk throught PPM as if it's thin enough, you can jump throught a PPM. You can't do this with PP

      Moreover, a PPM can be broken with any projectile such as a nade/flash/smoke while a prop_physics can't, not even with the "Break on pressure" flag.

      If you want a physical prop that doesn't allow players to pass throught them, jump over them without being bounced etc... they should be prop_physics only if the prop is never ment to move :-/. You might be wondering why you would use a prop_physics if it shouldn't be moved... Well I don't know as well, but making them too light will result in them flying around everywhere by the first the best shot, and if a plyer gets stuck into them, they can only escape if they shoot it themselves or by other players.

      What I'm trying to say is that you would never be able to have a physical prop that wouldn't pass throught players when shot or being moved (as I assume that's what you are going for otherwise there is no use in using prop_physics).

      And about massscale, it has already been answered by Gigabyte, but to expand on the info:

      0 is default and is useful because it lets the engine automatically calculate the mass for the object by its size (in .QC the command is $automass by which it does the same thing). However sometimes that comes out unhandy, so using a custom mass scale is sometimes required. Arguably all the Valve physical prop have a mass being compiled into their .mdl so if you're using a Valve stock physical prop, never change any parameters unless you really want to.

      Massscale is especially important when using custom gibs on a custom model (and should also be using a .QC command rather than the mass scale in the prop_physics tab in the engine!) as if you don't compile or use a mass, shooting your physical prop will make your gibs fly from one side to the other side of your map, and making it super-heavy will instant-splash/smack them onto the ground.

      Anyways, I hope this helped!
      Post Merged, Jun 13, 2013

      "Generally, if a prop_physics in your map has been removed because its model wasn't meant to be a physics prop, you can use this entity to still make it a prop_physics, without any drawbacks."

      If anything, the more expensive any physical prop will become depends on the complexity of the collision model.
      • Mapping King Mapping King x 1
      • Useful Useful x 1
      • Feb 27, 2012