$frame bugs Thread - qc

Original (v1.06 at last revision) quake-c has some bugs in $frame.

In knight.qc:

$frame attackb1 attackb1 attackb2 attackb3 attackb4 attackb5
$frame attackb6 attackb7 attackb8 attackb9 attackb10

and in oldone.qc:

$frame shake1 shake2 shake3 shake4 shake5 shake6 shake7 shake8
$frame shake9 shake10 shake11 shake12 shake12 shake13 shake14
$frame shake15 shake16 shake17 shake18 shake19 shake20

The bugs are in red. Two frame labels have been duplicated.

How often do mod coders fix these? I think I'm the only one...
Which I find odd as some compilers (fteqcc) give warnings for these.

What is the result of the bug?

I finally know from testing shubbers:

void() old_thrash10 =[ $shake10, old_thrash11 ] {lightstyle(0, "e");};
void() old_thrash11 =[ $shake11, old_thrash12 ] {lightstyle(0, "g");};
void() old_thrash12 =[ $shake12, old_thrash13 ] {lightstyle(0, "i");};
void() old_thrash13 =[ $shake13, old_thrash14 ] {lightstyle(0, "k");};
void() old_thrash14 =[ $shake14, old_thrash15 ] {lightstyle(0, "m");};

- ls: e --- trace on: monster_oldone - frame: 55 - in: 0.097222 ~ 0.1
- ls: g --- trace on: monster_oldone - frame: 56 - in: 0.097222 ~ 0.1
- ls: i * frames jumped by: 2
--- trace on: monster_oldone - frame: 58 - in: 0.097222 ~ 0.1
- ls: k --- trace on: monster_oldone - frame: 59 - in: 0.111112 ~ 0.1
- ls: m --- trace on: monster_oldone - frame: 60 - in: 0.097222 ~ 0.1

This is my tracer code for the qc++ framer() project: Moddb.com

The red "frames jumped" indicates a frame got skipped. You can see in blue the set goes from 56 to 58.

$frame causes the first repeated label to be skipped. so:
shake11 = 56
shake12 = 57
shake12 = 58

What about model frames?

You can see a duplicate frame with the exact same naming.
So the effect of running this code appearance wise in game is none!

Since the duplicate label attackb1 attackb1 and shake12 shake12 are true duplicates in the models,
the frame macro skipping them has no effect appearance wise for players in game.

So then how do we fix the compiler warning?

Like this:

$frame attackb0 attackb1 attackb2 attackb3 attackb4 attackb5
$frame attackb6 attackb7 attackb8 attackb9 attackb10

$frame shake1 shake2 shake3 shake4 shake5 shake6 shake7 shake8
// note - the original code essentially skips the first of a dup frame and uses the 2nd
$frame shake9 shake10 shake11 shakeb12 shake12 shake13 shake14
$frame shake15 shake16 shake17 shake18 shake19 shake20

We just rename the first frame of the duplicates something else.
The compiler warning goes away and there is no effect in game.

To remove the duplicates the models would need edited to remove the actual
duplicate frames.

There is a bug also in the standard ID axe code. I had been improving the axe to do more damage depending on the frame the player happens to be in, as hes using 2 hands sometimes. I got carried away, and wound up making a "beheading" / brutality frag out of it all. Fits in neat with my mod, but thats another story.

On this forum, Im Cobalt:
Quakeone.com

Someone had jumped in and pointed out the old bug, which I had no clue of. There also is a fix I think from the old QIP site , which seems to work well.

Things like this, I believe are good to have in the clean sources I mentioned in the other post. This ones hard to replicate and since I have played Q I have never ever seen it happen , so its rare, but hey, this is Quake, and it deserves the best.

I dont believe I've ever seen that.

There's also a frame issue I had once with vanilla code that you wont see until you start making changes.

Something like using normal run frames with currentammo = 0 on any weapon but the axe and wierdness occurs.

You never see that with the vanilla code which always switches when a wep runs out of ammo. Until you end up with the axe.

But, say you made a mod where an out of ammo condition must be handled by the player.

I think what I had was a gatling that if you ran empty you couldnt switch until it spun down all the way.

I finally fixed it, but it took a bugger long time to find.

"Until you end up with the axe."

Yes, I'm experimenting with code that will make the player drop the axe if alot of damage is taken when falling....and it winds up making the player animation for running happen too fast. Im using a model called "dude" for the alternate where there is no weapon on any of the frames, just open hands, so that part looks ok, but the animaiton speed probably means player_run is being called constantly , probably in weapon_frame someplace....

That sounds exactly like what I fixed.

I'll see if I can track down the fix.

---

I manifested the axe frame bug. I'll make a new post for it then.

Just like they say, you wait till walkframe > 6 in stand frames, fire the axe and immediately run.

The frame count never stops going up.

VM_FrameBlendFromFrameGroupBlend: no such frame 411 in model progs/player.mdl

And framer() does nothing because I didnt recode player_run...

It has full bounds check, and resets for any out of bounds such as coming from another frame set.

self.frame < sframe || self.frame >= eframe

Had to put that in - was easier to do with framer() code.

What gets me is that the stand code is correct.

And I vaguely recall coming across that long ago. Never figured out what did it.

Edited by: numbersix