Announcement

Collapse
No announcement yet.

Axe code overhaul

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

  • #16
    Geez. Never saw this one before. Is it with standard progs.dat?

    Looks to me like the fact hes walking on that sloped surface has something to do with triggering it?

    Hes actually doing death frames sequences and still alive. I could not see what commands you entered to the con or typed in chat tho.


    Originally posted by Mindf!3ldzX View Post
    http://www.youtube.com/watch?v=9t-7W1kafvA

    Axe Bug!! Took me a moment to replicate it, and its near impossible to know if you succeeded without having chase_active 1 enabled.

    Comment


    • #17
      Looking at the vanilla source of player_run() and player_stand1(), I can see there is code to handle axe animation (obviously). There is a slight difference between the functions. In player_run() they use == instead of >= for testing if the frame offset number is too high.

      How the bug is produced is harder to deduce, but my guess is that there is a frame of player_stand1() used when it should have been player_run(), and this function allows for a higher frame offset, thereby passing the "magic number" used in the == test.

      Comment


      • #18
        It's a walkframe leak bug.


        Walkframe leak bug.
        It occurs when the .walkframe variable,
        being incremented in the player_stand function while holding the axe,
        goes higher than 6 (it can go as high as 12),
        the player fires the axe, then begins to move during the axe animation.
        When the axe animations are complete the code calls player_run and
        walkframe (>6) is tested incorrectly.
        What results is wild and rampant incrementing of walkframe such that it
        goes through all player animations.
        Reported by Ryan "Frika C" Smith
        fixed for normal Quake in URQP 1.05 (solution by Ryan "Frika C" Smith himself)
        solution:
        Just replace (self.walkframe == 6) with (self.walkframe >= 6) in player_run()/player.qc
        via Quake Info Pool - Classic Quake - QuakeWorld Bugs
        www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

        Comment


        • #19
          He seems to start entering the bug @ 32 seconds in that vid.

          He happens to execute the dual overhanded axatt frames while moving forward. From there he does not go back into player_run mode but looks like he enters stand for a moment then back to one of the axe stand frames.

          Zop may be on the right track... the .walkframe float in QC might be bumping the frame count past the actual real number of frames forthe model, which means they reset to the 1st set which are the axrun frames.

          Originally posted by Zop View Post
          Looking at the vanilla source of player_run() and player_stand1(), I can see there is code to handle axe animation (obviously). There is a slight difference between the functions. In player_run() they use == instead of >= for testing if the frame offset number is too high.

          How the bug is produced is harder to deduce, but my guess is that there is a frame of player_stand1() used when it should have been player_run(), and this function allows for a higher frame offset, thereby passing the "magic number" used in the == test.

          Comment


          • #20
            Ah, nice!

            There are (2) cases of that code, so I guess update both instances?

            Code:
            if ((self.weapon == IT_AXE))
            	{
            		if ((self.walkframe == 6))
            		{
            			self.walkframe = 0;
            		}
            		self.frame = (0 + self.walkframe);
            	}
            	else
            	{
            		if ((self.walkframe == 6))
            		{
            			self.walkframe = 0;
            		}
            		self.frame = (self.frame + self.walkframe);
            	}
            	self.walkframe = (self.walkframe + 1);
            Also looks like the clean QC SRC that I thinkn Gnouc put up lacks this fix:
            https://gitorious.org/cleanqc/cleanq...:src/player.qc


            UPDATE: I guess only do the change for the Ax instance since this only happens in the axatt modes, afaik.

            Originally posted by R00k View Post
            Last edited by Cobalt; 06-25-2015, 01:26 PM.

            Comment


            • #21
              I know other leet map hax like dm4 teleflood , I used to be able to get inside the elevator button on E1M1 ,the bottom one.

              a few others haha

              in ihoc I can do these things, I can get under a bomb box on e1m1 near the door.
              Want to get into playing Quake again? Click here for the Multiplayer-Startup kit! laissez bon temps rouler!

              Comment


              • #22
                Originally posted by Cobalt
                Ah, nice!

                There are (2) cases of that code, so I guess update both instances?
                here's what i have
                Code:
                void()	player_run =[$rockrun1,	player_run]
                {
                	self.weaponframe=0;
                
                	if (!self.velocity_x && !self.velocity_y)
                	{
                		self.walkframe=0;
                		player_stand1();
                		return;
                	}
                
                	if (self.weapon == IT_AXE)
                	{
                		if (self.walkframe >= 6) 
                			self.walkframe = 0;
                			
                		self.frame = $axrun1 + self.walkframe;
                		self.walkframe = self.walkframe + 1;
                	}
                	else
                	{
                		if (self.walkframe >= 6) 
                			self.walkframe = 0;
                			
                		self.frame = self.frame + self.walkframe;
                		self.walkframe = self.walkframe + 1;
                	}
                };
                www.quakeone.com/qrack | www.quakeone.com/cax| http://en.twitch.tv/sputnikutah

                Comment

                Working...
                X