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.

Using a prop_dynamic as a prop_static ?

Discussion in Mapping Discussion started by Captain Jack, May 16, 2013

  1. Apr 25, 2013
    Posts
    Is it possible to "remove" the physics from the prop_dynamics? I have some models, but they cant be used for a prop_static (bridge and some platform). I only can use them as prop_dynamic (even prop_physic dont work), so i have to remove the physics (weight, movable, gravity...) from a prop_dynamic, is it possible??

    Thanks.
  2. May 31, 2012
    Posts
    As you said bridge I assume it is a large prop, so I recommend you to make it not solid and use clips/invis to make-do the collisions. Prop_dynamics, afaik, don't have gravity/weight, so you shouldn't have any issues.
  3. Mar 26, 2009
    Posts
    Prop_dynamic shouldn't have physics, other than a collision model. You can turn the collision model off with the "Collisions" key in the model properties by setting it to "Not Solid".

    Just remember that prop_dynamic is more expensive to render than prop_static and will have a higher impact on player frame rates. You shouldn't use more than a few prop_dynamic in one area and limit their use overall in the map.
  4. Apr 9, 2012
    Posts
    You can't use a prop_dynamic model (that has been compiled for prop_dynamic) as a static or physics model because it's just the way it's been compiled. If a model was compiled without the $staticprop .QC command which is the case with the model in question, there is no way to use it as a prop_static (so removing anything, physics or anything else won't do anything).

    The only workaround would be if you decompile the model and recompile it as a simple static prop, effectivly/possibly corrupting the vertices and make the model worse in performance and appearance, which is in other words no option. Try using a similar model that is perhaps a static prop or use something else.


    prop_dynamic is indeed very expensive if it really has a collision model, but if you disable the collisions on it, and remove the .phys file associated with it (because simply disabling it will still make the engine compile it with the physical model anyways :-/...) it because about 3 time cheaper, without producing massive extra IN (actually it produces almost no extra IN, on SSBB I have 40 prop_dynamics being animated and when just standing in the middle of them, the IN is the same as if they were all not there).

    Anyways good luck!
    • Mapping King Mapping King x 1
    • Apr 25, 2013
      Posts
      @ enviolinador: It have weight, when I shoot on the bridge, it move :/
      @GiGabyte : If i turn into "not solid", the players could not walk on the bridge.

      @Joris Yes I knew I could recompile all models but I just wanted to find an alternative solution to avoid recompiling all models (more than 50).

      Anyway,I think it is better not to take shortcuts, I will compile all the damn models.

      Another thing, if I recompile my models with $staticprop , can I still use them as prop_dynamic or I have to make 2 "versions" of the model?? ( because i want to make normal bridges, and also a "rotating" bridge, so i think i will have to use prop_dynamic for it ).


      PS : What is "IN" ??
    • Apr 9, 2012
      Posts
      Ow wait loool, so as of how I'm getting this, what you are trying to do is making players cross a bridge that will be either a prop_static or prop_dynamic? You may want to stop that immediatly and make you bridge out of brushes, because using any big prop, wheter static or dynamic (if so preferably static) as a walkeable area will lagg the entire server massivly, and players will not tend to like any map that causes that. It's too complicated for the Source Engine to transfer data of players that are standing on any prop due to the nature of the collision model, while on any brush it doesn't matter.

      If you played ze_predator and on Hyper or Ultimate have taken the elevator (which is one big prop_dynamic) you will understand which lagg I mean.

      There are only 2 solutions to this:


      1) You keep your model, but make it non-solid! It HAS to be non-solid or lagg will occur. Then, place it accordingly in the map and make a collisionmodel out of playerclip/clip/invisible texture that defines the walkeable parts of your bridge. I personally would go this way because it'll keep your nice bridge and have it produce no lagg. Only backtracks are that it will not produce decal when shots, but non cares about that in ZE/ZM

      2) Make a bridge out of brushes, preferably func_detail if it doesn't seal anything, or use any other brush based entity if you want any interaction to happen with the bridge, which I presume not.
    • Jan 11, 2011
      Posts
      Just make the Prop_Dynamic non-solid. Go into its properties and inside "Collision" choose "Not Solid".
      I would also recommend going into "Disable Bone Followers" and choose "Yes", in case the model has some of those, because they are the ones that make the Prop_Dynamic count as many entities or have a high IN value which can lag the server.

      Once you are done with that, the model will be visible but non-solid; so you proceed to "paint" over it with brushes made out of the NoDraw, Invisible, PlayerClip or Clip texture (the one that fits better or you prefer, I would suggest just using the normal Clip) as Enviolinador suggested.

      The IN is "INformation" that needs to be send between the server and the players. Everything that is a MUST that is the same for all the players at anytime, generates IN. So, breaking a crate and creating some random debris? Those won't cause IN. The crate itself before (or while) breaking? It does, because all players need to see where it is, and if its broken or not.
      So, almost every entity causes IN but is usually really cheap IN. However, the physics are especially expensive, and within those, the bone followers (the precise phys-boxes of animated models, mostly) are the most expensive of them all. You can check the IN with the Net_Graph X command. Ideally it should be under 400 when playing alone (singleplayer) in every part of the map, better if its under 300 (the lower the better without discussion, depending on the server's connection and the number of players that need to recive that info at a given time it can lag with 350 or not lag with 750).
      If you don't have physics or bone followers is very hard to get it over 200. The thing is, even if you don't notice any lag with 500 IN while testing, when a server has to send those 500 IN to 40 players, the server will get laggy. This was noticeable on the old Mako Reactor bridge (v1 and v2 versions I believe) or when in old Paranoid versions when many models (Titan, Juggernaut, Antlion Guard...) were reached the Core.

      As for dynamic things (since you seem to want to do a moving/rotating bridge), beware. The engine is not very friendly at times with those; and the simpler you can make it, the better (like 1-3 brushes better than more; not using props physics, etc).
      • Useful Useful x 1
        Kaemon, May 17, 2013 Last edited by Kaemon, May 17, 2013
      • Nov 11, 2011
        Posts
        Beh, I've used prop_dynamics many times as a static prop without anyone ever complaining about lag. It really does have to do with the size of the object, the number of players, etc the usual shit. A bridge is more than likely going to cause a problem with a large amount of players.

        Your best option is to make the collision "not-solid" go into the flags tab and disable any collision with players as well (also what Kaemon suggested with bone followers). Then use nodraw or playerclip texture and create a brush where the people will run. I prefer the playerclip texture as I can still see what I'm creating and can just func_detail it.
        • Useful Useful x 1
        • Jan 11, 2011
          Posts
          Personally I wouldn't recomend PlayerClip for a big bridge, as weapons and grenades will drop through it, so at least normal Clip. He may "need" to use Invisible or Nodraw if he wants the sides/floor of the bridge to block bullets.
        • Mar 26, 2009
          Posts
          The elevator being a prop_dynamic isn't the problem. The problem is the server having to calculate the physics collisions between the players and the func_tracktrain, while at the same time calculating players moving en mass and walking around on the elevator.

          A static prop_dynamic isn't going to have the same problems because the engine ignores physics calculations on it, other than stuff colliding with it. You can have as many players walking around on it as you want without problems because it essentially goes to sleep after the world is spawned.

          He could technically make it non-solid and cover it with a series of nodraw brushes turned into a func_detail, but the problem with that is that the model will be completely black from not being able to collect a lightmap.
        • Nov 11, 2011
          Posts
          Thus... Playerclip/Clip ... -_-
        • Apr 25, 2013
          Posts
          Thank you guys, very interesting your explanation and very helpful !!! I did as you told me, make the dynamic model without collision and create a bridge with brush. It works fine.

          Another thing I'm trying to make a bridge that rotates in two axes, a vertical axis and a horizontal axis , you better understand this video: http://www.youtube.com/watch?v=tE8KPmBYRrA 1:42

          I'd like to know if it is possible to rotate an object using the entity "phys_motor", but instead the object rotates on itself it rotate around another center of gravity. Let me explain with phys_motor, I can only make the bridge turn itself, but as the video shows, the bridge turns on both itself and even it is rotating on another axis (the axis which ropes are hung). Thats what I want to do but I didnt find anything about it on Google.
        • May 31, 2012
          Posts
          I would consider trying to imitate the movement of the bridge with well timed and tuned path_tracks and a tracktrain. Using physics wouldn't turn out fine because, unless sv_turbophysics is 0, you will glitch through the physic entity (physbox, prop or whatever) and you will get stuck. Setting the cvar to 0 isn't a good idea either, since it doesn't seem to go well with ZR (from some tests Syou did, it ended up causing a memory leak and crashing the plugin within minutes). It wil be a bit tedious if you use the tracktrain and the tracks, but the result should be good enough and it won't lag, at least not much (but bear in mind movement always lags, although physics would lag even more).

          EDIT: If you do use a tracktrain and the bridge is complicated, consider making 'what you see' (the bridge itself) not solid and parented to a simple tracktrain. The simpler the collisions with the tracktrain, the better.
          • Good Idea Good Idea x 1
          • Apr 25, 2013
            Posts
            Ok so i'll just put a tracktrain, without any rotating motor. I tried to put a motor but when I jump on the bridge i get stuck or i get ejected :/ I prefer the simplicity even though I would have liked to do the same bridge in the movie. The Source engine has some limitations finally ^^