Viewmodel skins Control

[Mexicouger]

This is a very hacky way to do this, but helpful in some situations. I think it is better to have some control, than none.
You would create a cvar, and register it. This cvar counts as the skins number, and you can change it as you wish.
On the PSP platform, you would goto the file, video_hardware_main.cpp and then in the function R_DrawViewModel, you would put this code:

Code: Select all

      //Mexicouger: Viewmodel skin support
      currententity->skinnum = ((int)viewmodel_skin.value);

It is really my first experiment with Changing up entities in the engine. This gives you control over the skin on the viewmodel.

One drawback of this is that it changes it for all the models. You can, however, create a control function in QC to control what weapon has what skin, but thats going beyond what this does.

[Downsider]

What exactly are you using this for? I can garuntee there's probably a better, RAM-saving alternative.

[Mexicouger]

I'm sure there is a WAY better way of doing this, but this is simple, easy, and gets a quick job done.

I just added this code for my teamplay system, so I can use a red texture for red team hands, and a blue texture for blue team hands.

[mankrip]

For team colors, use the colormap, just like the external player model uses.

By the way, good point, I don't remember whether the engine applies the player's colormap to the viewmodel.

For skin control, a much better way is to implement something like a .weaponskin (this idea is so obvious I bet some engines already support this), or use MOVETYPE_FOLLOW along with .drawonlytoclient, which is even better (and only works on some custom engines).

[Dr. Shadowborg]

For team colors, use the colormap, just like the external player model uses.

By the way, good point, I don't remember whether the engine applies the player's colormap to the viewmodel.

It doesn't apply it to the viewmodel.

For skin control, a much better way is to implement something like a .weaponskin (this idea is so obvious I bet some engines already support this)

Oddly, to my knowledge, nobody and I do mean NOBODY has actually done this. Which is pretty glaring when you think about how long the engine source has been availible. Especially since this is actually a pretty useful and IMO a sorely needed feature.

[Mexicouger]

Well The viewmodels aren't handles as entities as like rockets or Temp entities are I think.

So there is no way to directly talk to the viewmodel in the QC, which makes using a .weaponskin impossible.

I think you could probably do something like self.weaponskin for the player, which seems like an easy fix. Another method you could use is set the weaponskin to the same number as the player skin, which would work in some circumstances(Such as mine, where I need the hand color to coordinate with the Player color). Then you could just match up viewmodel skin the player skins, and wala.

[Dr. Shadowborg]

Well The viewmodels aren't handles as entities as like rockets or Temp entities are I think.

So there is no way to directly talk to the viewmodel in the QC, which makes using a .weaponskin impossible.

I think you could probably do something like self.weaponskin for the player, which seems like an easy fix. Another method you could use is set the weaponskin to the same number as the player skin, which would work in some circumstances(Such as mine, where I need the hand color to coordinate with the Player color). Then you could just match up viewmodel skin the player skins, and wala.

*facepalm*

self.weaponskin IS what I was talking about.

Making the weaponskin the same as the player skin is...really bad in more ways than one. (like, it totally defeats the whole point and usefulness of having different skins for your weaponmodel. *hint* digital weapon displays, different types of plasma in a plasma gun barrel, etc.)

[Downsider]

*hint* digital weapon displays, different types of plasma in a plasma gun barrel, etc.)

ouch, my ram hurts

[Dr. Shadowborg]

*hint* digital weapon displays, different types of plasma in a plasma gun barrel, etc.)

ouch, my ram hurts

Indeed it would...IF you were doing a 99 round pulse rifle. If you were instead doing a 5 unit bar instead to delineate 20 round segments with an empty display instead though, you would only have to worry about 6 skins total.

Besides, the point here isn't that you COULD maliciously gobble up huge amounts of disk space and ram with a 5-billion skin model, but rather that you had a useful feature instead. Seriously, think about what you could do with a IQM model...but won't because it isn't practical to do so. The same applies to a quake exe, a progs.dat, or even C/C++. (i.e. Somebody COULD write a virus that fried your computer's bios, reformat your harddrive, brick your PSP / Mobile Phone, or just reduce your fancy 4-8GB Ram desktop's availible memory to a mere 128kb, but is that reason enough to completely outlaw C/C++?)