Announcement

Collapse
No announcement yet.

Crouch Function Problem

Collapse
X
Collapse
 
  • Page of 2
  • Filter
  • Time
  • Show
Clear All
new posts
Previous 1 2 template Next
  • #1

    Crouch Function Problem

    Ok, time to strut my rookie coder status again. My reasoning for putting this in a new thread instead of RiftQuake is so that others with a similar problem may stumble upon it easier.

    I'm coding up a player crouch function for RiftQuake. Here is what I've done so far:

    * Re-valued the VEC_HULL_MIN and VEC_HULL_MAX to '-16 -16 -28', '16 16 28' to put the origin dead in the center for simplicity.

    * Re-valued the view offset in PutClientInServer() to 18 to maintain the original eye level, as changing the origin obviously changes this.

    * My crouch function re-sizes the player to '-16 -16 -16', '16 16 16' (or 32x32x32 instead of the standing size of 32x32x56).

    * Dropped the player's origin on the z-axis while in crouch (self.origin = self.origin - 12) to place the hull_min on the floor, and restored it upon standing (self.origin = self.origin + 12).

    * Successfully decreased speed by a scalar of 0.65 while in crouch to add realism (checked in PlayerPreThink()).

    * Successfully coded a CrouchToggle() function that is called on Impulse 21 to either crouch the player if standing, or stand the player if crouching.

    The problem is, even with what appears to be proper re-sizing and re-positioning of the origin, the player won't walk under low hanging BSP clips while in crouch.

    I found this while searching through the forums for an answer:

    Originally posted by MH
    Collision hulls would also need to be worked over for the new sizes - current Q1 bsp formats assume that you've got 3 collision hulls and they've all got fixed, hard-coded sizes.
    That quote came from this thread about player sizing:

    http://quakeone.com/forums/quake-hel...-monsters.html

    I have a few working solutions that I'd like to check with you pro coders.

    1) If I use Q3's map format for levels, thus side-stepping conventional Q1 BSP clipping, will this hull check still apply?
    2) Is there a DP/FTE extension to override this?

    I may also not have a clear understanding of what exactly I'm modifying by changing the player size and origin values. What I have done makes sense in my mind, let me know if I'm wrong.

    Here's the code from my PHYSICS.QC file:

    /*
    ================================================
    PLAYER CROUCH

    This governs the player's crouching ability.
    ================================================
    */

    void() PlayerCrouch =
    {
    if (!self.velocity_z)
    {
    self.origin_z = self.origin_z - 12;
    setsize(self, '-16 -16 -16', '16 16 16');
    self.crouch = 1;
    }
    };

    //======================================

    void() PlayerStand =
    {
    makevectors(self.v_angle);
    tracebox(self.origin, '-16 -16 -28', '16 16 28', self.origin + '0 0 16', FALSE, self);

    if ((trace_fraction == 1) && (!trace_ent.takedamage) && (!self.velocity_z))
    {
    self.origin_z = self.origin_z + 12;
    setsize(self, '-16 -16 -28', '16 16 28');
    self.crouch = 0;
    }
    };

    //======================================

    void() CrouchToggle =
    {
    if (self.crouch == 1)
    PlayerStand ();
    else
    PlayerCrouch ();
    };
    Here's PlayerPreThink() from my CLIENT.QC file:

    void() PlayerPreThink =
    {
    CheckImpulses();
    PosChasecam();

    if (self.crouch == 1)
    {
    self.velocity_x = self.velocity_x * 0.65;
    self.velocity_y = self.velocity_y * 0.65;
    }

    if (self.button2)
    {
    if (self.crouch == 1)
    PlayerStand();
    else
    PlayerJump();
    }
    else
    self.flags = self.flags | FL_JUMPRELEASED;
    };
    And here's where it's called on in my IMPULSES.QC file:

    void() CheckImpulses =
    {
    if (self.impulse == 21)
    CrouchToggle ();

    self.impulse = 0;
    };
    I know the problem isn't in IMPULSES.QC or CLIENT.QC, but I included them here so you can make the connections if you need them.

    Thanks guys. I'll be actively searching for an answer in the meantime, but if you would like to offer some quick and dirty advice, I'd appreciate it.
    'Replacement Player Models' Project
    Tags: None
  • #2
    q2/q3bsp does not have hulls and thus does not have the limitations imposed by only 3 sizes of hull.
    hexen2 and halflife maps both have a crouching-sized hull, but their other hull sizes can be different too.
    automatic methods to ignore hulls require that the engine also ignore clip brushes, which is not desirable.
    the hull is aligned to the absmin position of the entity. if you set your size too small, it will extend outwards along the positive direction of each axis, and NOT the negative direction.

    to explain:
    Quake's bsp collisions are based upon an infinitely small point. In order to give the player a size, it is not the player which is made larger but instead the walls. Each brush is pushed out along its surface normal (for some distance based upon the direction and the hull size), the corners are beveled, and an additional copy of the bsp tree is generated for each of the defined hulls.
    In this way, the player remains infinitely small and the collision code doesn't have to care so much about simultaneously being both infront and behind a plane at the same time.
    In contrast, q2 and q3 contain a copy of the actual brushes that went into generating the bsp. The bsp tree is not used for collision any more, but rather only to find the brushes that may potentially be within the trace's general area. The brushes still exist, and must be beveled (no corners sharper than 90 degrees), but the actual collision happens at run time instead of at compile time.

    Q3bsp is the answer to all things collision-hull-related. However, note that they don't support lightstyles any more.
    Q2bsp or rbsp/fbsp do, but DP does not support those (and quite frankly, q3map2 can be a bit buggy with rbsp/fbsp too).
    You can use shadowless rtlights as a surrogate instead. You'll get better specular lighting at least, but lower framerates.
    Some Game Thing

    Comment

    • #3
      Originally posted by Spike
      In order to give the player a size, it is not the player which is made larger but instead the walls.
      Learn something everyday, and that explains a lot. I now understand that q1's BSP collision is "engrained" so to speak, and exists upon compiling, vs. brush detection checking in-game for q2 and q3. Interesting...and terribly inconvenient.

      Q3bsp is the answer to all things collision-hull-related. However, note that they don't support lightstyles any more.
      I'm now at a crossroads. I was really looking forward to adding crouch/prone positions, but I heavily rely on lightstyles to add that extra touch of horror in maps. And my PC is, at the moment, a dinosaur that doesn't like RT lights.

      I suppose crouching will still be useful for ducking for cover, as enemy attacks (such as fired shots) are still checking against player size I imagine. I'll have to make a decision here.

      Thank you Spike for your response. You always help me out of coding jambs, and I really appreciate it.
      'Replacement Player Models' Project

      Comment

      • #4
        I should probably mention that collisions against SOLID_BBOX stuff is NOT limited to the fixed hull sizes (the engine does actually generate a temporary hull based upon the bbox size at run time, a bit wierd but hey, a solution is a solution and at least its consistant).
        Its entirely possible to make some func_fakeceiling entity that uses SOLID_BBOX instead of SOLID_BSP. Your air ducts (or whatever) would need a traditional ceiling height of at least 64qu, but if you add your fakeceiling entity as axially-aligned brushes somewhere between that true ceiling and the floor, you should be able to require crouching in that passageway.
        You can't do sloping ceilings this way, of course - any fake ceiling height changes need to be axial, including entry/exit areas.
        Non-world entities accept lighting naturally so you shouldn't have any discrepancies there, but be aware that they don't normally cast shadows so you might end up with light shining through the entry areas of your 32*32*32 passageways too easily.
        Does that make sense?
        Some Game Thing

        Comment

        • #5
          Originally posted by Dutch View Post

          I'm now at a crossroads. I was really looking forward to adding crouch/prone positions, but I heavily rely on lightstyles to add that extra touch of horror in maps. And my PC is, at the moment, a dinosaur that doesn't like RT lights.
          *Shadowless* rtlights don't nearly eat so much performance. Give it a try.

          Yes, lightstyles in q3map2 are currently buggy, inasmuch as they do work but a styled light can affect parts of a map where it shouldn't be visible. However if you have styled lights everywhere, that wouldn't be terribly noticeable unless you use the more extreme styles.

          For lightmap lightstyles, q1bsp currently remains the best suited. If q1bsp turns out to be too restrictive for a game (ie clipping hulls, low resolution lightmaps, stupidly low limits, no support for curves/models etc) then rtlights can provide very pretty styled lights.

          Lightstyles are a valid argument in favour of q1bsp though, I will admit that.

          Until they get fixed in q3map2.
          Scout's Journey
          Rune of Earth Magic

          Comment

          • #6
            Hello Dutch,

            Whatever your decision will be, be sure to implement the ducking feature.
            Here you will also find a useful page with DP code for ducking.

            If I recall correctly you like playing Gears of war.
            In this game you are using the duck feature (hide behind crates/rocks) a lot.
            And a simple duck feature like this (to minimize the players bbox) should be part of your mod, as it is fun (especially in multiplayer).

            A real crouching feature would be neat too, but not mandatory in my opinion.

            Regards,
            Seven

            Comment

            • #7
              I dont see where you are changing the players frame at all for the crouch. If you are using the stock player.mdl, there are no really good crouch frames, though you could re-use some deathframes to make it look a little better, but there is an old mode called : deathmatchessentials that has I think the best crouch frames out there. Though there is also a seperate player model for each weapon , there are attack frames, pain frames and death frames I think for the crouch position. I also was curious if they altered the hitbox size during the crouch , and they sure have, and so far I have not been able to see a case where it effects collision at all. I ran the mod on Darkplaces and hosted it as a server for a while just to see as a test. You can DL the mod and check it out yourself:

              Quake done Quick: Tools

              Comment

              • #8
                @spike: yep that makes perfect sense and it's brilliant. That's going to be the solution right there. I'll just be sure to include this in the readme for mappers.

                @Golden_boy: yes i agree. For mappers like me that put lighting on the same importance as geometry, lightstyles become a deal breaker for non q1 bsp. The shadowless runs ok, its still a little laggy but i plan on beefing up system anyway. My other reason for staying q1 is so i can use Gypsy's Virtuoso gamepack for NetRadiant thatcis tailored for q1. I finally set this all up and it is SWEET.

                @Seven: i think i'm in the right direction now so it's looking like crouch and duck will both be there. And prone (laying down/army crawl) to be coded tonight.

                @Cobalt: i will be using a new model, which is why there are no frame calls yet. I've actually played that dm mod and thought it was pretty cool, i think i'll read through the source and see how similar it is. That mod uses almost the same methods i was using.

                Thanks guys.
                'Replacement Player Models' Project

                Comment

                • #9
                  Yep, impulse 100 activates the crouch. Even the Axe when crouching is represented. All those new models for each weapon is interesting....but there is no weapon on the back of the player like the normal player has. I guess its obvoius that when you have the real weapons being held, where does he keep all the other weapons when hes not using them? I guess if yoiu wanted to show the previous weapon on his back after you select a new weapopn, that means even more models....

                  Originally posted by Dutch View Post
                  @Cobalt: i will be using a new model, which is why there are no frame calls yet. I've actually played that dm mod and thought it was pretty cool, i think i'll read through the source and see how similar it is. That mod uses almost the same methods i was using.
                  Thanks guys.

                  Comment

                  • #10
                    @Spike: the Bbox fake ceiling works like a dream. That was a brilliant idea, thank you sir. I coded in a prone position tonight. Doing some finishing tweaks to it now. Each player position has a float value now (float .stand, .crouch, .prone) that makes it really easy to check on the player's current state.

                    @cobalt: that always kind of bugged me about the weapons: where in the hell does a guy stash away up to 8 weapons? I plan on inserting separate weapon models that are animated to match the player's movement while strapped to his back (when not equipped).
                    'Replacement Player Models' Project

                    Comment

                    • #11
                      I have another quick question. When changing the player size, is the origin automatically adjusted because of the MOVETYPE_SLIDEBOX property of the player? In other words, does the VEC_HULL_MIN of the player align itself with the floor if the z-axis of the size is lessened?

                      So, if I do this (crouching size):

                      setsize(self, '-16 16 -8', '16 16 8');

                      after it was previously set as this (standing size, slightly modified):

                      setsize(self, '-16 -16 -24', '16 16 24');

                      will the VEC_HULL_MIN of the player automatically drop down the ground, giving the player a height of 16 from the ground, in which case I would need to re-set the origin to:

                      self.origin_z = self.origin_z + 16;

                      upon standing up again after being in the crouch position?

                      Thanks.

                      EDIT: I think I figured it out. Looks to me like my assumption was correct. I removed all code subtracting self.origin_z positioning, but left in additive self.origin_z positioning, and found crouching and prone positions to be much more smooth and proper.
                      Last edited by Dutch; 04-07-2014, 05:17 AM.
                      'Replacement Player Models' Project

                      Comment

                      • #12
                        As I said before, the hull bbox is aligned to the mins of the entity bbox. This means you can set your mins_z to whatever you want and collision will still work (but need to keep mins_x and mins_y set to the hull size in order to avoid the player being offset horizontally).
                        your maxs_z value should be set to how big the entity bbox is really meant to be, basically ignoring hulls completely. This should be safe and should affect only bbox collisions (still using hull 1).
                        thus you should probably set your mins_z such that you don't have to change view_ofs (because vanilla QW has it hardcoded to 22) and so that you don't have to change all the projectile spawn positions (because we all want to be lazy).
                        you should not set max_z to a value less than 0. doing so will confuse tracelines that are checking to see if the player's origin can be seen, etc. such traces will no longer impact on the player while trying to reach his origin. So try to keep mins+maxs separate sides of 0.

                        you should use tracebox to see if the area is safe for you to stand up in, and block standing up until tracebox succeeds (with the proper size+position that you would use if uncrounching were to succeed). If you change mins_z you'll need to bias accordingly.
                        Some Game Thing

                        Comment

                        • #13
                          My other reason for staying q1 is so i can use Gypsy's Virtuoso gamepack for NetRadiant thatcis tailored for q1. I finally set this all up and it is SWEET.
                          I can make a gamepack for anything. If you want to use Q2 or 3 I can modify virtuoso for you. I can't give you support on anything other than Q1 mapping though, as that is where my mapping experience begins and ends. The workflow and options change dramatically from q1 to q3.

                          However if all you may be worried about is map limits (pure conjecture) All of the Map2 compilers are included in virtuoso. So, if your map starts breaking limits just use the compilers with a 2 in them. Also, just a note, in default build menu there is a [tc] var. That var dictates how many processor cores the compiler will use to do the job. I think I have this set by default to 1 (cause everyone has at least one processor). If you have more than one core it is highly recommended you change this number to reflect that. You will find the var in the top section of default_build_menu.xml. I think I even commented out the document into sections. Something like:

                          <!-- USER VARS -->
                          user stuff
                          <!-- DO NOT TOUCH -->
                          stuff you shouldn't change

                          the var I am telling you about will be in the USER VARS section (or whatever I wrote that is equivalent)
                          http://www.nextgenquake.com

                          Comment

                          • #14
                            A models .origin is usually dead enter with respect to its shape.....except for the .bsp's like the health and ammo boxes, theirs is positioned at the corner. If you change the min_z of the bounding box to a smaller value, as long as you spawn it with enough clearance, it will merely come to rest on the floor if its got a movetype that recognizes gravity.

                            But for crouching and proning, all you really need is adjust the max_z of the hitbox to match the size of new frame. If you use an engine like DP its got an r_drawbboxes feature that will show you the size of your bounding box of all models when set to non zero....very helpful with this kind of modifications.

                            Comment

                            • #15
                              I'd like to add something about the "This is sweet" comment

                              In reality, I did not "make" the virtuoso game pack. The virtuoso game pack fixes the oversights of radiant. Those oversights are:

                              1) Radiant comes with no Q1 compilers
                              2) Radiant does not natively run a Q1 map from it's GUI with any success

                              To fix #1 I simply included every sensical compiler that other people made
                              To fix #2 I wrote a work around .bat

                              So at this point Virtuoso gamepack is just a pre set up Q1 gamepack with an extra .bat. I then added a modicum of extra bells and whistles. For instance my sunlight compass and my gridz wad. I also wrote some example Q1 style build menus, as-well-as pioneered violating the build menu to store some global vars.

                              So, yes virtuoso is sweet, but it is not "Gypsy's" virtuoso game pack. It is just as much Bengt Jardrup's, Bakers, MH's, LordHavoc's and anyone else that spent their time making better compilers for us.

                              In short, all I did was set radiant up for you and include all the overlapping options. My other contributions to the gamepack are not an absolute necessity, they are there to put a little more of my effort into the entirety and make some things a little nicer.

                              I don't feel right taking so much credit for something that is 90% other people's work. Now if I built the compilers for Virtuoso, then yeah, It would be Gypsy's Virtuoso gamepack but, I didn't and actually wouldn't even know where to begin.
                              http://www.nextgenquake.com

                              Comment

                              Previous 1 2 template Next
                              Working...
                              X