Framegroups are indexed as single frames. If your first framegroup starts at frame 250, the other frame(group) following it will have the index 251, no matter how many frames are inside of the framegroup.

Framegroups were most likely a late addition to the engine, because none of the vanilla models uses this feature, even though it's certainly beneficial to idle and running poses. 

Some more info: I had forgotten that the torches uses framegroups�
http://renep.home.xs4all.nl/qmehelp/concepts.htm 

Here. Click on the "Main Window" link, and then scroll down to the "Frame Tree Panel" section:
http://renep.home.xs4all.nl/qmehelp/ 

Ok so how do I add these without using QME? :)
Preach do you have some magic tools for this per chance? 

There's a way to do it using the Helper in the python module. The Vortex model from

https://tomeofpreach.wordpress.com/2015/12/30/vortex/

has an example in its python script, the relevant portion are:

from qmdl.helper import Helper

#read the model file
mymdl = Helper()
mymdl.load("model.mdl")

mymdl.group_frames(0, 15, "spiral")
mymdl.save()
 

How about now?
http://image.noelshack.com/fichiers/2016/03/1453459546-wip2-bfg9500.png 

Hmmm too much edgework with no light direction.

https://www.dropbox.com/s/00e0kunjg9z5bvs/Quake_3_Weapons_2.jpg?dl=0

Here is some inspiration and the textures show a lot of directional lighting and tasty little highlights. 

I knew I was going to have to get around to installing the python tools at one point...

Now my question Mankrip about framegroups... does it only really help at the end of the file or if I start adding them in the beginning and it somehow encapsulates them making each index add to the count instead of the actual frames? What is the theoretical limit? :) 

I wanted the edges to be rough like that.
Although yeah I could rework on the overall light, to be on top. 

Daya: That BFG 9500 looks really good for Quake, it just needs some weathering.

Skiffy: If you group the first scenes, you'll have to modify the QC code, and that means making your models incompatible with everything but your own mod.

Let's say you have a model with these frames�

0 base
1 idle
2 idle
3 idle
4 walk
5 walk
6 walk

� and then you group the "idle" animation:

0 base
1 idle(1,2,3)
2 walk
3 walk
4 walk

See how the indexes of the "walk" animation were affected by the grouping of previous frames. 

only thing with frame groups walk and run anims: stock models have different movement per frame. this is accounted for in the code, but with frame groups, you do not know what frame you are on because to the code, it's all the same frame index. you would need to redo the animation so that the movement is constant on all frames. 

Framegroups do support individual timing for each subframe. 

So if I understand this correctly I could have 255 frame groups for some crazy reason? Its not a 255 frame limit but index limit. But if you dont group frames then they each take an index... so to speak.

Daya I do look forward to having this in Quake though :)

Here is another take from the one mode that added all the quake2 weapons to quake 3.

http://www.wireheadstudios.org/album/album35/strogbfg_shots.sized.jpg 

Amusing... I thought quake1 ran at 10fps logic all the time. Then again I think the minotaur in Arcane has some at a higher framerate? 

the individual timing thing doesn't work. also, timing isn't the issue, it's distance. 

Individual timing does work. But IIRC, maybe not in GLQuake.

PS: Confirmed, it's a GLQuake-only bug. All hail software rendering!
http://celephais.net/board/view_thread.php?id=60097&start=179&end=179 

And here's the proof that it does work in WinQuake. See the function R_AliasSetupFrame:
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c 

Hmm so now I just need to make a model that uses a zillion frames and work with a programming on this form crazy enough to do it with me? Shub Niggurath proper boss fight anyone? :)

Dont let her just sit in a pool of lava waiting to be tellefragged. Have her take off and hover and fly around after a certain amount of damage coming after the player with all manner of evil spells. 

IMO I think you should animate it so you can use it to replace the current model. You can always add extra frames at the end anyway which will be ignored by standard quake. 

Any future models I would add additional features on the back end for any intrepid programmer to tinker with if they are up for it. I plan to add at least 1 new range attack and death for the shambler after his first release. Some sort of AOE lighting sphere channel attack is what I have in mind. 

Any future models I would add additional features on the back end for any intrepid programmer to tinker with
If you want I can add the new Shambler model to AD with alternative channel attack. Please don't listen to anyone about framegroups, they are freakin nightmare to get right in QC.

Things to consider with your model, add idle animations (checking hands, looking around etc), alternative death animations, maybe a stomp to the ground attack (could be cool for a stomp+lightning combo) Any new stuff you add, let people know the movement speed you animated at, it will make implementing the QC easier.

Also if you have time, update the horrible head gib model, that is so damn ugly it makes me cringe when I see it in game. Any extra gib models (claws+feet) are always welcome! :P 

In ad-obd I saw a shambler foot gib that reminded me the cyberdemon, and it felt great. 

http://image.noelshack.com/fichiers/2016/03/1453567594-wip3-bfg9500.png 

Since the topic came up, the group_frames function in qmdl does support an optional 4th parameter called duration, which defaults to 0.1 if not set. This sets the duration of frames in the framegroup. Because of the GLQuake bug that prevents per-frame setting of the value in most engines, the function only takes a single value and applies it to all frames. You could write your own code to set individual values if you desired but I wouldn't recommend it. 

Avoid mixing blue tones with gray, that's very hard to get it looking really good in the software renderer.

Try to use similar hues for both the base image and the weathering, only drastically switching hues on neighbouring pixels that have the same brightness, to smooth out the transition.

Grayscale tones are difficult to mix with other colors. They mix better with more desaturated colors.