                ==============================
                DynamicInfo Player Mesh System
                ==============================
                       (release 3 - UT)

Code/Concept: 
    Ob1-Kenobi (ob1@planetunreal.com)
	
Webpage:
    Swing by http://www.planetunreal.com/umodwizard for updates.
    (no dedicated homepage)

It's my hope that Epic integrates either this system or a similar 
system in to the Unreal Engine (tm) to add player mesh changing as
a default engine feature.

Now that would be nice, wouldn't it? :o)


Changes in this release:
------------------------
Please read 'DPMS_ChangeLog.txt' for a list of changes made to the
DPMS classes in this release.


Contents:
---------
	File List
    Introduction
    Using The Classes
    Class Structure	
    Animation Classes Currently Supported
    Console Commands
    Development Notes
    Current Release Notes
    Features to be added or being implemented

Still to come:
--------------
    Class descriptions
    Code examples
    Adding support for the classes
    Creating animation classes
    Using the PlaySpecial function


File List:
==========
    DPMSExample.umod               - an example UT game type using the DPMS code
    DPMSExampleSource.zip          - the source for the example
    DPMSExample_readme.txt         - the readme file for the example
    DPMS_Souce_r3.zip              - the DPMS source code for this release
    DPMS_ChangeLog.txt             - list of changes in made in this release
    dpms_readme.txt                - this file


Introduction
============
The DynamicInfo classes can be used to add in game player mesh 
changing to a mod. All the mod author has to do is sub-class
the DynamicPlayer class and add functionality for the mod. The
game type will also need some minor adjustments to implement 
the mesh changing code (a few extra functions).

When a player changes mesh, all other players on the server will
also see the change. The sounds for that player are changed as
well, so that players do not end up running around with the wrong
sound effects (although you can easily implement this if you want).

The whole point of these classes is that they are freely available
for use by the Unreal mod community - no restrictions. The only thing
I ask is that you let me know of any changes or improvements made to the 
mesh system so that they can be implemented in future releases of the
classes. This is just so that the classes can be kept up to date.

Also that you try to avoid modifying the actual core DynamicInfo
classes, so if any changes or special function handling needs to be done
you can do it in a sub-class. Thanks. It'll make things easier to debug
if there are any problems.

There should be no compatibilty problems with each release of the classes
as if any major changes are made, the animation classes will be updated
also. This wont make any difference to the use of older code, that should
still work with the relevant release of the animation classes.

All sugestions and contributions to the classes are welcome. This is
after all for the mod community :o)


Using The Classes:
------------------
The classes are meant to be included with the other classes of a mod 
rather than an external package. This avoids any version potential compatibitly
problems between different mods. For example, if user has a mod installed 
with an old DynamicInfo package for a mod and tries to log in to a server with 
a newer version, the client would get a version mismatch error and would not be 
able to connect. By including the classes in to the mod package, it doesn't 
matter what version the classes are as they are unique to that package.

I feel that this is better than me maintaining a pre-compiled DynamicInfo 
package, as there would probably end up being many different versions of
the same package floating around.

If you'd prefer to include them in an external package, make sure that the
package has a fairly unique name.


Class Structure:
----------------
The principle idea behind the system is that all animation and mesh
information is treated as a class object (a child of the PlayerMeshInfo
class). The player class just forwards the animation calls to the 
PlayerMeshInfo object to play animation. All of the animation code 
resides within the animation mesh info class. 

The skin setting functions have also been moved to the mesh info class.
This is so that custom skin handling can be implemented for meshes,
eg. you'd set the skins differently for a MultiSkinned mesh than you
would a single skinned one. This can be done in subclasses of 
PlayerMeshInfo.

All the functions are called statically. The dynamic info classes are
never instantiated (never created using spawn()), so no class management
needs to be done. Each static function takes a pawn parameter, this is
the player that the animation is going to be played on.

The animation class has a set of properties, the "DefaultSoundClass" 
property is the class containing the default sound information class 
for the current mesh. The sound info class contains all the sound playing 
functions for the player class.

<Info>
    o DynamicInfo
        o PlayerMeshInfo
        |   o (mesh info classes)
        o PlayerSoundInfo
            o (sound classes)

<TournamentPlayer>
    o DynamicPlayer

Both the PlayerMeshInfo and the PlayerSoundInfo have functions that are
called from the DynamicPlayer class. There is also a PlaySpecial function
that can be used to play animation (for the mesh info class) and sound (for
the sound info class) or call other functions.

The animation info and sound info class structure mirror the pawn class 
structure. This makes the animation and sound code easier to maintain.

For example, there is a PawnMeshInfo class and a PawnSoundInfo class which
extend the main PlayerMeshInfo and PlayerSoundInfo classes, and there is
PlayerPawnMeshInfo class and a PlayerPawnSoundInfo class which extend the
PawnMeshInfo and PawnSoundInfo classes,... etc.

For the currently supported classes the PlayerMeshInfo class structure 
looks like this:

<PlayerMeshInfo>
    o PawnMeshInfo
        o PlayerPawnMeshInfo
            o TournamentPlayerMeshInfo
            |   o TournamentFemaleMeshInfo
            |   |   o TFemale1MeshInfo
            |   |   o TFemale2MeshInfo
            |   o TournamentMaleMeshInfo
            |       o TMale1MeshInfo
            |       o TMale2MeshInfo
            |       o TBossMeshInfo
            |
            o UnrealIPlayerMeshInfo
                o HumanMeshInfo
                |   o MaleMeshInfo
                |   |   o MaleOneMeshInfo
                |   |   o MaleTwoMeshInfo
                |   |   o MaleThreeMeshInfo
                |   o FemaleMeshInfo
                |	    o FemaleOneMeshInfo
                |       o FemaleTwoMeshInfo
                o SkaarjPlayerMeshInfo
                o NaliPlayerMeshInfo

With the same structure mirrored for the PlayerSoundInfo classes.

Animation Classes Currently Supported:
--------------------------------------

From UT:
	TMale1
	TMale2
	TFemale1
	TFemale2
	TBoss
	
From Unreal:
	MaleOne
	MaleTwo
	MaleThree
	FemaleOne
	FemaleTwo
	SkaarjPlayer
	NaliPlayer

To change to a UT mesh use the console command SetMeshClass and just 
type the class name (no need to use "BotPack." before name).
	
	eg. 'SetMeshClass tmale2'	

To change to an Unreal mesh use the SetMeshClass console cmd
with "Unreali." before the class name,

	eg. 'SetMeshClass unreali.malethree'


Console Commands
----------------
The console execs to do with class changing require server
side functions to implement so that the info is set correctly.


"SetMeshClass <class name>"
  o Change to mesh associated w/ <class name>. If class
	is within the BotPack package, no need to type "BotPack."
	before the class name.
	
	eg. 'SetMeshClass tmale2'
	    'SetMeshClass unreali.maleone'

	
"SetMeshInfo <info name>" [not yet implemented]
	o Change to the sepecified mesh info class

	
"SetMesh <mesh name>" [not yet implemented]
	o Change to the specified mesh


"SetSkin <skin name>"
  o Change skin to <skin name>, the name can be the skin
    description (eg. "War Machine" or "RawSteel") or can
    be texture name (eg. blkt for marine skin). Will only
    change if skin valid for current mesh.
    
    eg. 'SetSkin RawSteel'


"SetFace <face name>"
  o Change face to <face name>, the face skin will only
    change if valid for the current skin.
    
    eg. 'SetFace Slain'


Development Notes:
==================
The old Unreal skin packages need to be included in 
the server packages list for skins to display properly
on the client.

ServerPackages=Male1Skins
ServerPackages=Male2Skins
ServerPackages=Male3Skins
ServerPackages=Female1Skins
ServerPackages=Female2Skins
ServerPackages=SkTrooperSkins


Current Release Notes:
----------------------
HUD status doll icons aren't replicated to the client when viewing
a team member in a team game.

To fix the current (v4.02) UT decap head gib network problem, 
the unreal head classes are used but the mesh is changed to the 
players default head gib mesh. eg. For TMale1, class'MaleHead' 
is used and mesh set to class'UT_HeadMale'.default.Mesh before
calling "carc.Initfor(self)". Changes have been made in:

	TournamentMaleMeshInfo
	TournamentFemaleMeshInfo
	TBossMeshInfo (also set DrawScale to 0.220000 after Initfor())


Features to be added or being implemented:
------------------------------------------
o Add a DynamicInfo bot class
o Add support for bGreenBlood property in PlayerMeshInfo
o Do something with bCanHoldWeapon
