Ladder

#1 I have implemented ladders for my game and I plan on posting as a resource (as soon as I find the time). I did it all in c++ and you can make the player climb any dts shape. Triggers seemed ugly and a pain in the rear when modeling.

#2 I would suggest checking out the quake 2 or half-life game sources for great examples of ladders :)

In such games, the ladder is merely a trigger object that causes the player to conform to the ladder space, kind of like the water physics (except no floating down). Pretty much like your example, except there are more movement types for the player object than just "normal" and "ladder".

Afrim's example would also work great, if you would prefer making shapes to climb (as opposed to the quake/half-life approach).

#3 The problem i had with triggers was that they wouldnt TRIGGER all the time as they are supposed to. The onenter event would always fire as expected. But the onleave event wouldnt always fire so my player would get stuck in a climb anim when not climbing.

Also as far as i know you cant make the player move vertically in script, you also cant change the players max climb angle unless you change the players datablock. You see something very simple becomes very hard and ugly. Assuming that you do all of the above, that is way more code and way more overhead than implementing a few lines of code in the C++ side.

#4 I am hoping to use a volume of some sort (like trigger) being that our mappers are used to UnrealEd style mapping which uses the ladder volume approch. This allows you to climb up a wall or BSP object as well as a DTS shape.

I'm sure I could pull it off, I'd just like some direction on where playermovment is handled in the C++.

#5 Check out Player::updateMove() in Player.cc and I think you will find what you are looking for.

#6 Thanks. I'll take a look.

#7 I made good use of the findcontact function. But I gues that depends on how you implement it. I treat my latter as any walkable surface and in the findcontact function i detect if the player is facing and colliding with a ladder. If he is then i allow him to walk on it. Now the ladder has to be slightly slanted. Then i set a flag that tells the rest of the code that he is climbing. Then in the updateanim function i take care of the animation...

#8 Thanks. I just looked at the function and it's working great, that's for saving me a good few hours of searching.

#9 I set a var in Player (the class) and added it to the custructor of the class to default as false. Anyway - I'd like to know if I should include it in updatePacket or writePacketData. I would also like to know how it is exposed in the console. (Client's Control Object.var?)

Thanks

#10 Yes because the check is handled in the server and the client wont know unless you write it in the packet data. Also you should handle all the code in C++ there is no need to expose the variable to the console. What you should do is raise an event on the console so that if the player is climing you can handle the "What to do part" in script. The "What to do" part would not include what animation to play, that should also be handled in the code, but instead it will handle things like should the player put away his weapon while climbing etc...

Since this is a private forum when i get home tonight ill post my code here. I wanted to improve it and didnt have time to both improve it and write a resource otherwise i would. In my implementation i didnt handle the "What to do" part but everything else works fine.

#11 I want to use a trigger (because it creates a volume - our mappers are used to that) so i need to expose something to the console.

#12 Using my method I add a ladder DTS object to the scene and thats it. You dont think your modelers can get used to that?

#13 The idea is that we will be able to have the player climb up walls or any other object for that matter.

#14 What I implemented works the same way. I was going to post here what i did but its too many little changes so i got annoyed. I will post a resource this weekend when I have more time.

FYI after you implement my resource you will be able to do this in script:

datablock StaticShapeData(Ladder)
{
   // Mission editor category, this datablock will show up in the
   // specified category under the "shapes" root category.
   category = "Ladder";

   // Basic Item properties
   shapefile = "~/data/shapes/ladder/ladder.dts";
   
  //The following line is the key
   dynamicType = $TypeMasks::ClimableItemObjectType;  //This makes the shape climable

};

Your mappers will be able to select the shape from the mission editor and it will be instantly climable.

#15 Well - I'm about 1/2 done with my meathod. All that's left is to add strafing ability (add it correctly) and set-up the trigger volume. I should have a resource for UT/HL Style ladders within the next two days. It would be nice to see your ladder code because maybe I can make opimazations on mine - based on yours. Anyway, thanks for all the help thus far.

#16 If anyone could explain to me how the move.x, and the move.y vars are manipulated so that it moves the player based on the direction he is facing, it would be great. I am having problems having the player move in the right direction when he has his ladder state set.

Thanks.

#17 Move.x and move.y (there is also move.z, maybe you could use that for climbing the ladder?) are relative to the player's coordinates (so a positive Y moves the player towards the direction it's facing, as example).

Their values are input by the move manager. It collects the move global variable defined in the client (like $mvForwardAction) and build move objects. These are used to instantly update the player (so the client gets an instant reaction), and are also sent to the server so it can properly progagate on the network (otherwise the client-side movement will be soon nullfied by whatever is going on in the server-side).

#18 Negitive. Move.x and Move.y are not relative to the direction the player is facing. Move.z is useally null. For the ladder I am changing mVelocity.z. :P

#19 Huh? move.x and move.y *are* relative, unless you have another definition of "relative".

If you set move.y to "1" the player moves "forward" along it's own Y axis. Are you telling me it's world-relative?

#20 I was under the impression that setting move.y would make the player travel in a direction relative to the player itself, not the world.