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.

Client Side Physics, broken keyvalues?

Discussion in Mapping Discussion started by nyronic, Mar 9, 2013

  1. May 17, 2011
    So I started to populate my map with physics props everywhere, only to run into this annoying problem.

    Physic props can have a .qc setting that specifies if they are:
    - Solid, Server Side
    - Non-Solid, Server Side
    - Non-Solid, Client Side

    Almost all of the valve props have this, when you use prop_physics_multiplayer there is a setting at the bottom called physics mode. It has 4 settings, the first one is Auto Detect which means it uses whatever data was inside of the .qc file when the prop was compiled. The other 3 settings are the same as the ones in the .qc file. I assume this is meant to be used to override the props default physics mode, but when I use them it appears to be broken.

    All 3 settings spawn a Solid, Server Side prop. When using Non-Solid, Client Side it does in fact spawn a client side version, but the server side version is also there, leading to double props.

    I found a setting in all 3 physics props(physics, multiplayer, override) called:
    Override Parameters <string>
    A list of physics keyvalues that are usually embedded in the model. Format is key,value,key,value,...
    Here's some examples of what I tried, with ALL THREE physic prop entities...
    - physicsmode,3
    - physicsmode,2
    - physicsmode,1
    - physicsmode,0
    - prop_data{physicsmode,3}
    - prop_data{physicsmode,2}
    - prop_data{physicsmode,1}
    - prop_data{physicsmode,0}
    - $keyvalues{prop_data{physicsmode,3}}
    - $keyvalues{prop_data{physicsmode,2}}
    - $keyvalues{prop_data{physicsmode,1}}
    - $keyvalues{prop_data{physicsmode,0}}

    I even tried these in combination with the physics mode setting in the _multiplayer entity set to different things.

    NOTHING WORKED, override parameters seemed to do nothing no matter what I tried, and I was getting the same results as when I didn't use them. I even tried other settings such as health and breakable model. Nothing works and I don't think this functions.

    I did find a work around to all this but it's not ideal.

    Make a prop_physics_multiplayer set to Non-Solid, Client Side, and have a logic_auto kill it at the start of the round. The client side copy will still be sitting there. The problem with this is the edict count will spike at the start of every round.

    The only other solution I can think of is to decompile all of the models, and then recompile them with the client side setting.

    If anyone has some input to shed some light on this please share.

    TL;DR - There doesn't seem to be a way to override the physics mode settings that are embedded in the models.
  2. May 14, 2011
    @JorisCeoen might be able to help as he is good with models.

    Also, I re-read the post but couldn't actually find what you are trying to achieve.

    In response to your fix; Maybe this is silly but you could try to template the prop and check change the flag that controls whether or not to spawn the entity at the start of the round so it doesn't spawn. Maybe spawning the prop makes a difference. At the very least you could stagger the spawning.
    • Useful Useful x 1
    • May 17, 2011
      Server side physics hog the edict count and cause network lag where as client side physics don't. I'm trying to force props that were designed to be server side to be client side but the options for it don't work.

      I'll give the template thing a try.
      Post Merged, Mar 9, 2013
      It worked! The clientside copy still spawns in it's place, and it doesn't spike the edict count on round start like the other method. It's a little annoying to have to name every prop individually though but it will be worth it. I can just kill the templates after the round starts too.
      • Informative Informative x 1
      • May 14, 2011
        Nope. You don't have to. Name sections of props the same name and you can template them as a massive group.

        It will show up duplicate names in red but it works. Unless it doesn't work in this particular case, I've never tried to achieve what you are trying to do now, but I have spawned multiple entities under one entry in a template.

        EDIT: Remember the "!self" command can be useful at this point if you want an entity to kill itself after a certain time.
      • May 17, 2011
        It worked, thanks. For some reason I remember trying to spawn multiple entities with the same name and it wouldn't work, I don't know why.
        • Like Like x 1
        • May 14, 2011
          Maybe you later wanted to manipulate them and with name fix-up that can be very hard to do if they are under the same name. Anyways, glad to know it worked, good luck with your project/map.
        • May 17, 2011
          No they're all client side now, which cannot be interacted with nor would I want to.

          Basically the template thing fixed this bug.
          • Like Like x 1
          • Nov 11, 2011
            You are the template master lol. :victory:
          • Apr 9, 2012
            Are you trying to compile for custom gibs or something? In that case, clientside is the safest because server-side causes network lagg