Announcement

Collapse
No announcement yet.

Small Mod compilation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • liked the 4.30, the ghost problem i had where it froze coming out of the body is fixed,thanks seven!

    Comment


    • ... now we only need to wait for Jakub to rework all new particle effects to make them look good.

      Last edited by Seven; 06-19-2013, 10:03 AM.

      Comment


      • if you use Win7 64, DP uses different .cfg files. The ones inside your windows / documents / games folder overrides the one in ID1
        LATEST DP uses different .cfg files. The ones inside your windows / documents / games folder overrides the one in ID1


        this totally drove me nuts, figuring out why no changes to my autoexec.cfg made any in-game difference. Newest DP uses the games folder regardless of OS.
        http://www.nextgenquake.com

        Comment


        • Hello Smith,

          There is an issue in the "refraction_fix" code.
          Thank you Josh for reporting the bug.

          It can remove the self.weaponmodel permanently (until next map start) and it changes the view angle of player.
          It only happens when player is in water (waterlevel 1 or 2) of course, as the code jumps in then.

          Best map to quickly simulate it is E1M3 (but it also happens in other water maps):
          Give yourself the rocket launcher and go into the water area where the golden key is (you can use notarget to get their quicker).
          Now shoot into the water and the weaponmodel will vanish (it will not come back till next map start).

          Rearding the change of players view angle:
          When shooting with rockets in the water (near your feet) you normaly perform a rocket-jump.
          During rocket-jump the view angle normaly does not change: you keep looking down. But the code changes the view angle to look straight forward while in air and when you touch water again, you will correctly look down again.
          This seems to be related when changing the scale, the models default orientation will be used. At least that seems to be the case, I could not really understand why it should do this else.

          Other than that your idea works very well, so I tried to find another way to remove the player model, when he is in waterlevel 1 or 2 and try to understand why the code has the described issue.

          I think I found the root cause:
          "self." is not always the player entity inside the player´s code.
          self can be (depending on the currect situation. In this case "shooting".) also the weaponmodel entity: aka self.weaponmodel, as it runs through players code as well.

          So, it seems that self.scale will affect the weaponmodel under specific circumstances...


          After replacing the "self.scale" idea with something that can only be the player entity and not/never the weaponmodel, the code seems to work robust.

          So all that needs to be changed is:
          if ( autocvar_player_reflection_fix && (((self.waterlevel == 1 ) || (self.waterlevel == 2 )) && !( deathmatch || coop )))
          self.scale = 0.01;
          else
          self.scale = 1;
          into this
          if ( autocvar_player_reflection_fix && (((self.waterlevel == 1 ) || (self.waterlevel == 2 )) && !( deathmatch || coop )))
          self.model = "";
          else
          self.model = "progs/player.mdl";

          Anyhow, both ways are an evil hack.
          And it is only used/meant to get rid of the bug in Darkplaces builds since october 2011, which reflects the player.mdl model much too strong inside the water with r_water enabled.
          As long as LH has no solution for this, this hack can be used.
          I contacted him recently and reported all the issues that people have found at quakeone lately.
          One bug he already fixed in new auto builds.

          So, I will put this into V4.31.

          I saw that you decided to enable your reflection fix by default, so this is maybe interesting for you.
          I also noticed, that you enable "darkplaces_build" by default too, but use a DP build < 20130301 in the compilation. This will lead to wrong particle counts.

          As you surely noticed, LordHavoc´s DP autobuild compilations (with all OS versions in one .zip file) has been corrupted since 20130314. Till then, they were missing. He didnt seem to notice it... as they are created automagically every 6 hours.
          I mentioned it in the mail too and he fixed it. In my opinion, the builds after the latest beta from 20130614 are really good. You (or anybody else) should test them too, as you can download the DP build .zip compilations again.

          I also could modify my terrible red teleporter to look acceptable in the new auto´s again. That was one of the reasons, that kept me from using the 2013 builds
          Now I became a friend of the 201306xx builds...

          Thank you for reading (I started this as a pm, but thought that maybe also others may find some things useful)

          Best wishes,
          Seven

          Comment


          • wow you fixed that fast! good work seven!

            Comment


            • Hello again,

              ahhh, now I understand why you used:
              self.scale = 0.07;

              Because it circumvents this issue
              self.scale = 0.01;
              does not. That is interesting...

              I thought, this uneven value had something to do with a specific person...
              But it didnt.


              Anyhow,
              At least the other points may be interesting for you Smith.

              Have a nice weekend,
              Seven

              Comment


              • Fix this the Afrit problem, Seven?
                I talk about the fire animated one I send you!

                Comment


                • Hello webangel,

                  The Afrit "animation" issue you are talking about was only related to the Darkplaces build.
                  That special shader-keyword you used for the wings animation has been introduced into DP not too long ago. It is independent to the SMC.
                  The "old" 2011 build didnt know it.
                  The DP build you are using has no issue with it...

                  I am an old man and dont like "new" things.
                  That is why I am still using Win XP

                  Gute Nacht.
                  ... aber träume nicht von Quake

                  Comment


                  • the fix seems to work for me
                    disregard the pm i sent

                    also check the misc/null.wav it telling me its not precached... you know the only reason i find things like this is cose i play the smc all the time

                    Comment


                    • Hello Seven

                      It's a quirky issue and I should had written a comment there, but unfortunately I am lazy.
                      self.scale is rounded down to a multiplier of 1/16 so a value smaller than 1/16 will result in zero and that seems to cause these “certain circumstances” here.
                      This is why I've used self.scale == 0.07; but your solution is even better.

                      Another thing is, I've also recently realised that this work around should be also disabled when chase camera is being used, so you can add to condition:
                      && cvar_string("chase_active") == "0"

                      BTW, to be precise the issue is that the player model is rendered in water shader refraction layer when in FPP view, so it is not a reflection issue.

                      Thanks for noticing us about wothwhile DP builds. In fact you were so reliable about it, that I've stopped to bother checking them myself.
                      You are truly doing an outstanding job on many fronts

                      Regards Smith

                      P.S. Discussion about tiny code changes is indeed probably better suited for PMs, so check it for follow up.
                      Last edited by _Smith_; 06-21-2013, 03:42 PM.
                      Quake HD: Embrace the decline and have some guilty pleasure with it, or join a club for monocled gentlemen at quaddicted and play Quake the way it's meant to be played.

                      Comment


                      • Hello Josh,

                        Thank you for your testings and finding.
                        I will add it to the precache list.



                        Hello Smith,

                        The issue I see with the "water reflection" fix is the impact on the engine workload. As the check must be made every frame (!).
                        And I do not know if it is less "workload" for the engine to always rescale a model or reassign the model for the player....

                        Spike told me once to not use so many auto_cvar checks in functions, that are called every frame (as the engine has to look/check its value and compare it each time).
                        The "fix" goes in the same direction I worry.
                        That is why I try to use global floats whenever possible instead of auto_cvars in these kind of functions.

                        Until now, I didnt notice any performance issues though. The SMC uses really a LOT of auto_cvars, but their performance impact seems to be not noticable.
                        Sure, most of them are only checked/used once (mainly around map start), maybe that is the reason why they do not impact.

                        Maybe Spike can say something about it ?
                        And maybe can give a suggestion, which "trick" the fix should use (.scale or .model) ?
                        Knowing that these kind of hacks are not what Spike likes/supports.

                        Comment


                        • Originally posted by Seven View Post
                          Hello Josh,

                          Thank you for your testings and finding.
                          I will add it to the precache list.



                          Hello Smith,

                          The issue I see with the "water reflection" fix is the impact on the engine workload. As the check must be made every frame (!).
                          And I do not know if it is less "workload" for the engine to always rescale a model or reassign the model for the player....

                          Spike told me once to not use so many auto_cvar checks in functions, that are called every frame (as the engine has to look/check its value and compare it each time).
                          The "fix" goes in the same direction I worry.
                          That is why I try to use global floats whenever possible instead of auto_cvars in these kind of functions.

                          Until now, I didnt notice any performance issues though. The SMC uses really a LOT of auto_cvars, but their performance impact seems to be not noticable.
                          Sure, most of them are only checked/used once (mainly around map start), maybe that is the reason why they do not impact.

                          Maybe Spike can say something about it ?
                          And maybe can give a suggestion, which "trick" the fix should use (.scale or .model) ?
                          Knowing that these kind of hacks are not what Spike likes/supports.
                          seven, you can use alpha value; for not change every frame the alpha value (tough check waterlevel in every frame) you can simulate flags or something like that
                          for example in WaterMove function

                          if ( autocvar_player_reflection_fix && ((self.waterlevel > 1 ) && (self.waterlevel < 2 )) && !( deathmatch || coop )))
                          {
                          if (self.alpha == -1)
                          return;
                          else
                          self.alpha = -1;
                          }
                          if (self.waterlevel <= 1)
                          {
                          if (self.alpha == 1)
                          return;
                          else
                          self.alpha = 1;
                          }

                          if (self.waterlevel >= 2)
                          {
                          if (self.alpha == 1)
                          return;
                          else
                          self.alpha = 1;
                          }
                          the invasion has begun! hide your children, grab the guns, and pack sandwiches.

                          syluxman2803

                          Comment


                          • Hello Nahuel,

                            Thank you for your post.
                            Yes, that is in principle exactly the way it could be done.
                            It is even irrelevant in this case, which "trick" the fix uses
                            - .scale
                            - .model
                            - .alpha

                            Important thing is, to compare the condition, wich should be the case with the current condition.

                            If they are identical --> return;
                            (which is 99.999 % the case in-game)
                            Only change if they are not identical.

                            The code lines get a bit more, but it has as little as possible affect on workload i *think*.

                            Comment


                            • When there is no new particles effects involved, there is exactly 0FPS difference, between SMC and vanilla progs.dat with all the stuff we threw there. Can't imagine how accessing few variables per frame could matter at all. Unless I am missing something important ( possible ) it would have to be hundreds variables to access, to tick an FPS counter down on a modern hardware ( modern = less than 10 years old ).
                              Seriously, lets start to worry about it once our progs.dat drops a single FPS for the first time

                              .alpha can't be used, because it affects viewmodel too.
                              .model is better than .scale because with scale 0.07 a funny, tiny player model is still visible when you look stright down ( usually it is hidden under weapon viewmodel ).
                              Quake HD: Embrace the decline and have some guilty pleasure with it, or join a club for monocled gentlemen at quaddicted and play Quake the way it's meant to be played.

                              Comment


                              • Originally posted by _Smith_ View Post
                                When there is no new particles effects involved, there is exactly 0FPS difference, between SMC and vanilla progs.dat with all the stuff we threw there. Can't imagine how accessing few variables per frame could matter at all. Unless I am missing something important ( possible ) it would have to be hundreds variables to access, to tick an FPS counter down on a modern hardware ( modern = less than 10 years old ).
                                Seriously, lets start to worry about it once our progs.dat drops a single FPS for the first time

                                .alpha can't be used, because it affects viewmodel too.
                                .model is better than .scale because with scale 0.07 a funny, tiny player model is still visible when you look stright down ( usually it is hidden under weapon viewmodel ).
                                there is a problem with, model, scale and alpha values, the shadows (if we are using shadows) for the player will not cast.
                                The solution is possible to add a script file (and a second skin in player.mdl) to get a second null skin for the player
                                progs/player.mdl_1
                                {
                                dpshadow
                                }
                                and just change the skin value to 1.
                                the invasion has begun! hide your children, grab the guns, and pack sandwiches.

                                syluxman2803

                                Comment

                                Working...
                                X