ratrace135

If it were one thing, I'd guess it's the AnimNodeSequence object in the DefaultProperties. UTPawn already has two AnimNodeSequences called MeshSequenceA and MeshSequenceB, so trying to overwrite MeshSequenceA might be causing the problem. Try commenting out those two lines in your pawn's DefaultProperties (right above the commented-out DynamicLightEnvironment) and see if that helps.

Failing that, there's always the obligatory "make sure the animation actually works in the editor" advice.

Also, I've heard that DefaultProperties doesn't like spaces with declarations, like "BirdWalkAnim = WalkOnLand"... Apparently it's better to write "BirdWalkAnim=WalkOnLand". I've personally never had any problem with it either way, but can't hurt to try, even though it's probably not the source of the problem.

Hope something here works for you

Glad to hear that the collision cylinder's aligned now

As for animations, the PlayAnim function takes a name as the first parameter, not an AnimSet (which is what I assume you're trying to call with that line).

If the anim name you want to play is WalkOnLand, then assuming that you have BirdWalkAnim set in the DefaultProperties, you'd use the line:

Pawn.Mesh.PlayAnim( BirdPawn(Pawn).BirdWalkAnim, , True );

There's no need to mess with the file path OR anim set with the PlayAnim function, which will search the SkeletalMeshComponent's AnimSets array to find the correct animation.

Yeah, that's super common. Characters smaller than bullets and guns bigger than buildings.

I'd just place the model in a level and scale it however much you need it to be in UDK. Take note of how much you scaled it, then go into blender or any other modeling tool, scale it to that size in there, and reimport. A trick to help with that is to have your (correctly-scaled) character model in the scene when you're modeling, to use as a reference for scale.

But yeah, definitely correct the scale in your modelling tool and reimport... Dealing with a bunch of models out of scale is way more of a headache than it's worth.

Ahh yes. For the pawn mesh, if you're extending from both UTPawn and UTBot, you have to deal with UTFamilyInfo... There are two things you can do. One would be to extend your own class from UTFamilyInfo and set that as the CurrCharClassInfo in your pawn. The other choice would be to overwrite the family info function in your pawn if you don't want to deal with family info at all, like

simulated function SetCharacterClassFromInfo(class<UTFamilyInfo> Info)
{
	//Ignoring family info
}

As for animations, I can't see if you're calling any animations. The typical way of getting the pawn to start playing animations is to, in the controller/bot class, set the player's physics to PHYS_Falling by calling Pawn.SetMovementPhysics() when the controller class has possessed a pawn (which has already been done in UTBot). However, that only gets animations playing because of the animtree. So if you wanted to play an idle animation on startup for example, you'd need to directly call the animation.

//We're in the bot class
function Possess( Pawn aPawn, bool bVehicleTransition )
{
   super.Possess( aPawn, bVehicleTransition );

   aPawn.Mesh.PlayAnim( BirdPawn(aPawn).IdleAnim, , True );     //Loops a hypothetical IdleAnim
}

Finally, for the player hovering above the ground, that would most likely be that the collision cylinder and the mesh aren't aligned. Play the level and in the console, type "show collision". What you'll probably see is the collision cylinder touching the ground and the mesh hovering somewhere above that. To fix that, you'll need to modify the WPawnSkeletalMeshComponent's Z Translation in the DefaultProperties. UTPawn has it set to 8, but you'll have to change that number to work for your mesh, depending on where its pivot point is.

The problem would be that you're using a SkeletalMeshComponent in the SetSkeletalMesh function, which takes a SkeletalMesh (sorry if I didn't make that clear in my post).

But if you have the component added in the DefaultProperties (like you have it), there's no need to dynamically attach it again. Dynamic attachment is meant for cases when you can't have the attachment in the DefaultProperties because you don't know what it will be (such as armor pieces for a pawn, weapon add-ons, etc).

Also, for some reason I was under the impression you were extending from a class below UTPawn... UTPawn has the WPawnSkeletalMeshComponent, whose settings you can change pretty quickly to get a visible body mesh. UTPawn also already has a DynamicLightEnvironment and two AnimNodeSequences (for the arms meshes, but we can steal them for the body mesh if you aren't using an anim tree ). The "Mesh" variable from the Pawn class is also referenced to WPawnSkeletalMeshComponent, so you can use that in your code. This will be enough to give your pawn a mesh that's capable of playing animations:

class BirdPawn extends UTPawn;

var name BirdWalkAnim;

simulated function PostBeginPlay()
{
    super.PostBeginPlay();
    SetMeshVisibility(true);
    `log("The player birdpawn has spawned!");
}

defaultproperties
{
    Begin Object Name=WPawnSkeletalMeshComponent
          SkeletalMesh=SkeletalMesh'BirdPackage.BooboodayPacked'
          AnimSets(0)=AnimSet'BirdPackage.Armature'
          Animations=MeshSequenceA
          AnimTreeTemplate=None
          Materials(0)=Material'EditorMaterials.WidgetMaterial_X'
          LightEnvironment=MyLightEnvironment
          Scale3D=(X=0.25,Y=0.25,Z=0.5)
    End Object

    BirdWalkAnim = WalkOnLand
}

Depending on the scope of your project, it may be worth it to spend the time making an animtree. They're a pain to make, but they make it very easy to change or blend animations based on pawn physics, looking direction, etc.

- Must my model be in a specific directory? If so, which one?

Nope, you can put it anywhere you want (though the package itself should be somewhere in the Content folder). And don't worry about the file type and path... unless you're like me and you enjoy typing all of it out

StaticMesh=TexPropCube_Dup would get you the same result as StaticMesh=StaticMesh'UN_SimpleMeshes.TexPropCube_Dup'.

- Do I need to use unrealscript to do it, or is that simply the recommended way?

If you only want the mesh attached to the player for one part of the level or for some other scripted event, it might be better to use the AttachToActor node in Kismet. If you want the mesh attached all the time though, it'd probably be better to have it in Unrealscript. Also, you can only attach to an actor in Kismet, but in Unrealscript, you can attach components to an actor or to the actor's SkeletalMeshComponents.

If you're attaching something to the player, then you'll be attaching directly to the actor (as opposed to if you were attaching something to an enemy pawn, where you'd be attaching to the actor's body mesh). One way is with the DefaultProperties like you have written out. Another way is to create and attach the components dynamically, which would look something like this:

var() SkeletalMeshComp Comp;    //Can also be a StaticMeshComponent.... or any other component type

function AttachMesh()
{
   Comp = new(self) class'SkeletalMeshComponent';
   Comp.SetSkeletalMesh( WhateverMesh );
   Comp.SetLightEnvironment( MyLightEnvironment ); 

   AttachComponent( Comp );
}

You can use a local variable instead for the component you're attaching, but if you later want to detach it from the actor, play an animation, etc, it'll be easier if you kept the variable. Now to animations... Unless you're using an AnimTree, you're going to have to call the animations using the SkeletalMeshComponent's PlayAnim(name AnimName, optional float Duration, optional bool bLoop) function (I left out the rest of the optional variables but those are the main ones you'll be using). It's not difficult, but you'll want to avoid playing an animation while an existing one is being played on the component, as the first animation will be stopped and can be pretty ugly unless the first animation is something subtle like a weapon's idle animation. Also, you're going to need to have an AnimNodeSequence to play the animations on (see code below).

Since static meshes can't play anims, I'm going to pretend that the TexPropCube_Dup is a skeletal mesh for an example.

class BreakDancingCube extends Actor
   placeable;

var() SkeletalMeshComponent CubeMesh;
var name CubeMeshAnim;

simulated function PostBeginPlay()
{
   super.PostBeginPlay();

   CubeMesh.PlayAnim( CubeMeshAnim,, True );   //Play a looping animation
}

DefaultProperties
{
Begin Object Class=AnimNodeSequence Name=MeshSequenceA    //Don't need to change any settings, but you need to create it
End Object

Begin Object Class=SkeletalMeshComponent Name=BasicMesh
        SkeletalMesh=SkeletalMesh'UN_SimpleMeshes.TexPropCube_Dup'
        AnimSets(0)=AnimSet'UN_SimpleMeshes.TexPropCube_Anims'        //Totally made-up anim set
        Animations=MeshSequenceA                                      //Animations won't play without this line
        Materials(0)=Material'EditorMaterials.WidgetMaterial_X'
        LightEnvironment=MyLightEnvironment
        Scale3D=(X=0.25,Y=0.25,Z=0.5)
End Object
CubeMesh=BasicMesh       //So that we can reference this in the code
Components.Add(BasicMesh)

CubeMeshAnim=BreakDance   //Made up anim name for the made up anim set
}

Yeah, that's definitely not something that kismet will be able to do... I looked through the Unrealscript terrain code and I don't see any easy way you'd be able to modify layer blending from there either. However, I'm not sure that modifing the layer blending would be the best way to acheive that effect in the first place. To get the patches to appear with a relative accuracy to where the player's feet are landing, the terrain would have to be tesselated way too densely. A better option might be to spawn a decal or particle system (or both) where the player's feet land, which wouldn't be too hard to implement, though you'd have to muck around in Unrealscript code.

I'm not sure if you're interested in doing that, but if you are, then basically all you'd have to do would be to extend the UTPawn class, modify the GetMaterialBelowFeet() function to store the material under the player's feet, and modify the ActuallyPlayFootstepSound(int FootDown) function to compare that material with whatever your mud material is and to spawn the corresponding decal/particle system if it's the right material (and then you'd have to extend the UTGame class to reference your pawn class instead of UTPawn). Not the most elegant solution, but it wouldn't require any additional functions and would keep the additional code required to a minimum.

Ahh, no, ThrowWeapon() would spawn a DroppedPickup in its place. You'll have to remove the weapon directly with the InventoryManager's RemoveFromInventory(Inventory ItemToRemove) function. I wrote out what to do, but then where's the fun in that? I'll let you have your fun figuring it out instead of just giving you the answers

The DefaultInventory's given to the player when they're spawned. After that, the weapon will be in the InventoryManager, and you'll have to use the DropFrom(vector StartLocation, vector StartVelocity) function from the inventory class to get the pawn to throw out its current weapon... Luckily, that's already done for you with the PlayerController's ThrowWeapon() function (which calls the Pawn's ThrowActiveWeapon() function), so you don't need to make the function at all.

I mostly enjoyed programming features like Quests, Characters, Skills, Inventory, etc...

Yup, that'd be gameplay programming. I'd highly recommend checking out the job specifications for gameplay programmers in the companies you'd be interested in working at. For example, here's a link to a gameplay programmer position at Ubisoft: https://sjobs.brassring.com/1033/ASP/TG/cim_jobdetail.asp?SID=^xYuE9YwT_slp_rhc_lgCgzPl8VE6Q3UqJqdr7SFbGntXMOCxW64U0_slp_rhc_GojwjgyZ9JmUPwT_slp_rhc_zM&jobId=836068&type=search&JobReqLang=1&recordstart=1&JobSiteId=5290&JobSiteInfo=836068_5290&GQId=1324

Notice that you will have to be familiar with scripting languages for that position. As a gameplay programmer, whether or not you'll be using a scripting language will be up to the company and can go either way, so I wouldn't limit myself by saying "I'm not a scripter".

As for which engine you should start with, I don't think any of us can say that for you, as there's really no "best" choice, it's all subjective. However, it is true that for UDK, you'd be using Unrealscript, which is not applicable outside of the unreal engine and is being replaced with C++ for the approaching Unreal Engine 4, so I'll let that speak for itself. In CryEngine you'd be using C++ and/or lua, while you be using either C#, Boo (Python), or Javascript in Unity (C++ would only be if you're using Unity Pro IIRC).

If you're up to it, I'd say one of the best things to get a job would be to, well... make a game. Much easier said than done, but not only is it great for experience, but you'll have explored multiple different programming aspects (mainly gamplay, AI, and UI if you're working on an existing engine) and will be able to better decide what kinds of positions you'd most want to apply for.

Back again

In the MagpiePawn code, get rid of the NPCController variable and simply use ControllerClass (the var defined in the Pawn class). If you want your current code to work, you'll have to add in the MagpiePawn's PostBeginPlay(), the line:

ControllerClass = NPCController;

BUT, the only reason you'd have the NPCController variable in the first place is if you wanted it to be editable from in-editor, by declaring it like

var() class<AIController> NPCController;

Also, just a little tip, instead of using 'log("string"), you can use WorldInfo.Game.Broadcast( self, "String"), which will display the string in-game (usually more convenient).

So code should look something like this:

class MagpiePawn extends UTPawn placeable;

var StaticMeshComponent MyMesh;
//var(NPC) SkeletalMeshComponent NPCMesh;

simulated function PostBeginPlay()
{
    super.PostBeginPlay();
    SetMeshVisibility(true);
    WorldInfo.Game.Broadcast( self, "The magpie pawn has spawned!" ); //this appears fine, and I believe the pawn works okay
    WorldInfo.Game.Broadcast( self, self );
}

defaultproperties
{
  bBlockActors=True
  bCollideActors=True
  ControllerClass=class'MagpieController'    //<- Notice we're using ControllerClass

  Begin Object Class=DynamicLightEnvironmentComponent Name=MagpieLightEnvironment
  bEnabled=TRUE
  End Object
  Components.Add(MagpieLightEnvironment)

  Begin Object Class=StaticMeshComponent Name=MagpieMesh
        StaticMesh=StaticMesh'UN_SimpleMeshes.TexPropCube_Dup'
        Materials(0)=Material'EditorMaterials.WidgetMaterial_X'
        LightEnvironment=MagpieLightEnvironment
        Scale3D=(X=0.25,Y=0.25,Z=0.5)
  End Object
  Components.Add(MagpieMesh)
  MyMesh=MagpieMesh
}

Probably the easiest way to get an NPC would be to extend a placeable pawn (from your existing MyAIPawn class) instead of using a separate NPCActor class. In the DefaultProperties, you can set the "ControllerClass" variable to class'MyAIController' if you haven't done so in the MyAIPawn class.

The Example NPC section of http://udn.epicgames.com/Three/CharactersTechnicalGuide.html should help you out. Assuming you'll be using the same AIController for all NPCs, there's no need to create a separate variable for the controller class.