View Full Version : Re: support for custom models/skins (long, technical)

2nd Jan 2001, 04:15 AM
This was going to be a followup to the thread on the UT board, but I moved it here because it was getting a bit technical to not be editing :-)

Basically, some people on that board were complaining that UT had no real PPM support in the same way as Quake 2/3 or Half-Life. I thought about the idea a bit and here's the result.

Here's one way to do it as a mod:

- Really generic player class:
- PPMEnabler extends TournamentPlayer
- PPMEnablerBot extends BotPlus
- Plugin player model classes:
- PluginPlayerModel extends Info (or something)
- SkaarjHybridPPM, NaliPPM, RumikoPPM... extends PluginPlayerModel
- UTBuiltInPPM extends PluginPlayerModel
- MaleSldPPM, MaleCmdoPPM, FemSldPPM, FemCmdoPPM, BossPPM extends UTBuiltInPPM

- The PPMEnabler and PPMEnablerBot classes have a variable DesiredPPM with the name of the PluginPlayerModel subclass they want, and FallbackPPM with the name of the UTBuiltInPPM subclass they want.

- Skins could be handled like this:
- PPMEnabler has DesiredSkin, FallbackSkin, DesiredFace and FallbackFace.
- PPMEnabler follows this pseudocode:
if DesiredPPM is available {
use DesiredPPM
if DesiredSkin is available {
use DesiredSkin & DesiredFace
} else {
use DesiredPPM's default skin
} else {
use FallbackPPM
if Fallback is available {
use FallbackSkin & FallbackFace
} else {
use FallbackPPM's default skin
DesiredPPM = Skaarj Hybrid
DesiredSkin = Predator
DesiredFace = Masked
FallbackPPM = Male Soldier
FallbackSkin = Overkill
FallbackFace = Rail

The setup used, in order of preference, would be:
Skaarj, Predator, Masked (preferred)
Skaarj, Arena Warrior, Berserker
Male Soldier, Overkill, Rail
Male Soldier, Marine, Othello (if all else fails)

- The server op puts PPMEnabler's package in the server packages (running a mutator might also be necessary, I hope not though).
This package also includes the classes PPMEnablerBot, PluginPlayerModel, UTBuiltInPPM, and all UTBuiltInPPM subclasses, to guarantee that everyone has them.

- Clients install the same package, plus a package containing a model selection UI (could go in the Mod menu), and a package for each PPM they have, which includes a PluginPlayerModel subclass.
New models could be released with both a traditional player class and a PPM, while add-on PPMs could be released for old models.
PPMs should probably be listed in INT files like old player classes, for the UI's benefit.

- PPMEnabler has functions for all the model, animation and skin related stuff available to player classes, even the functions which aren't normally overridden. These just call a function in the PPM which does exactly the same thing. PluginPlayerModel contains copies of the default implementations of these (as on Male Soldier for example), which can be overridden by subclasses as required.
PPMEnablerBot is exactly the same but is a bot; all the same comments apply.
PPMEnablerBot uses the same PluginPlayerModel subclasses (this is one of the big advantages of this system).

- PluginPlayerModel and its subclasses are entirely client-side (any UnrealScript experts want to tell me if this is possible?) I think Usaar33 made a mod once which changed skins on the client, ignoring what the server wanted, is this still around anywhere?

- I'm not sure whether voicepacks can be treated like this because they have different numbers of taunts, different mature taunts, etc., but I think skins and models are likely to get higher priority. I might look into this later.

Obviously, this system has possible backwards compatability problems, and requires server reconfiguration (which server ops may be reluctant to do).
However, if Epic Games read this board, we might be able to talk them into using this or a similar system for U2 or UT2.

Advantages of this system:
- It's impossible to use cheating invisible models, as everyone who doesn't have them will see the fallback model instead
- It's impossible to use cheating or offensive custom skins
- Checking for skin hack cheats is still possible (client-side) - the client could even have an INI file containing legal or illegal packages to use (so you don't like fighting Warcows? Set them as a "cheat" model and use the default instead!)

One big problem is collision cylinders. Everything would probably have to use the same collision outline (fair in gameplay terms, but liable to cause confusion).

Suppose your desired model is short and fat (Nali WarCow) and your fallback model is tall and thin (Female Soldier, for example).
If someone shoots the edge of the cow's collision cylinder, it might miss the human completely, and vice versa for headshots. Look at the ChaosUT Chreks if you don't believe UT has any funny-shaped models.

Any comments? I know it seems a mad scheme, but it might even work...
If Epic do read these boards, any "official" comments would be great - I suspect any efforts to make server ops use a PPM system would tend to die without official support!

2nd Jan 2001, 09:08 PM
we'll have Tim get right on that :)