Any way to edit around the 4 model limit?

[Enjay]

GZDoom has a limit of 4 models per actor. Multiple models are sometimes used on a single actor at the same time; such as one model for a soldier and a second for his gun. However, models can also be used sequentially, say one model for the walking states, another for attacking and another for death etc. In both cases, as far as I know, with normal MODELDEF conventions, the limit of 4 models applies.

With the first scenario the 4 model limit seems reasonable and I have never needed more than 4 models in that set of circumstances. In the second, however, it is very easy to run out of model "slots" and I have had to compromise a few times. I have now come across a source of models where, if I try to use them in GZDoom, I am likely to hit the limit quite quickly.

The source is the game SiN. It has some great models that I think will work pretty well in GZDoom. However, the models for enemies are not like Quake2 models where all the animations are in a single model but, rather, each phase of animation is in a separate model. So, there is a model for idling, another for walking, another one (or more) for pain, a firing model, possibly a melee model and then, finally, another one (or more) for death. Even with the basic Doom states of spawn, see, missile, pain and death, I'm one model slot short. If I want alternative deaths, pain animations or a melee attack too, I'm well short.

So, the question is, is there a way around this that anyone knows of? I guess that I could do something like spawn a death actor to take care of the death frames but I wonder if there might be a configuration file (like an MD3 .C file or something) that can be used to augment MODELDEF and allow more than 4 models.

[Graf Zahl]

Unfortunately not. This use case was never considered.

Can you send me a sinple mod with such a setup so I can run some tests?

[Enjay]

Can you send me a sinple mod with such a setup so I can run some tests?

Certainly. [edit] file removed - no longer needed [/edit] Attached is a file that replaces the Doom zombie with one of the quake 2 guards. Normally this model wouldn't require this kind of setup but, to illustrate the point, I chopped up the the model into individual models for each animation sequence (of course, I realise that I could have set up the MODELDEF without doing this but I wanted to make the example authentic).

Just load the zip and start a game. The actor uses the A_SPosAttack pointer because it fits in with the animation a bit better.

Inside the zip are the models, skins and DECORATE needed to illustrate the point. In addition, there is:

modeldef.txt
This is the MODELDEF loaded by default. It sets up the actor to use the first 4 models and also has the code necessary to use the additional models commented out. When those sections are uncommented, GZDoom drops to the console complaining about too many models being defined in MODELDEF.

In game you will see the enemy idling, walking and attacking while looking like a Quake 2 trooper. He has 2 pain sequences. If you shoot him (and don't kill him) he may go into one of them. The first one will use a model but if he chooses the other one, he will display some imp sprites (i.e. there aren't enough model slots to cover the second pain sequence).

When you kill him, his regular death will display pinky sprites and his extreme death will display baron sprites.

The commented out sections use model numbers 4, 5 and 6 to cover pain2, death and xdeath.

zzmodeldef.txt
This was included mainly for my testing purposes. If you use this instead of the other MODELDEF, the model allocation is the other way around; the idle, walk and attack frames are commented out and use various sprites and the pain (1 & 2), death and extreme death animations use the model. It's a little hard on the eyes because the sprites show familiar poses but for inappropriate actions. However, it does all work as intended and was really just used by me to make sure that I had got all the frame allocation for the later sequences correct.

This MODELDEF also demonstrates a nice feature of this setup: the death frames are set up to use a different (more damaged looking) skin to the other frames.

It is worth pointing out that this test setup allocates models 0, 1, 2 and 3 to the later sprite sequences but the commented out sections for the earlier sequences also use those model numbers and so this MODELDEF should not be used for testing if any additional functionality is added.

question.txt
This file is just in place because when I first set up a multiple-model actor like this (a few years back), I expected the syntax to be like it is in question.txt. However, it doesn't work. If you use question.txt instead of modeldef.txt, you will see multiple models appearing on the actor as it moves around. From my reading of the file at least, I don't *think* that should be happening because only one model is ever applied to any one sprite frame.

[Graf Zahl]

Ugh...

Why aren't you just using model index 0 for each separate definition - if you do that it'll work fine.

The limit is 4 models PER FRAME, but you needlessly use higher model indices for the later definitions. But since they never overlap in any way with the previous ones there's no need to.

[Enjay]

Why aren't you just using model index 0 for each separate definition - if you do that it'll work fine.

Ignorance and (false) assumption I'm afraid.
I assumed each new model allocated to an actor needed a new index. It worked so I assumed that I had it right. I didn't even consider that the model limit was a per frame rather than a per actor one.

Thank you very much for pointing this out. It's actually a bit of a game changer for me because this incorrectly-assumed limit has restricted what I was trying to do in the past and forced me to make some ugly work-arounds too.