Ladder Trigger

[Pitbull]

I'm currently working on a new level that utilizes ladders. The trigger works but not smoothly IMO. Getting on and off the ladder is a chore to say the least. Have I missed something? I know from playing DS9 The Fallen the ladders have special navigation points to allow for easy exit and entrance to a ladder. I'd appreciate any info on this.

[Masterkent]

The trigger works but not smoothly IMO. Getting on and off the ladder is a chore to say the least. Have I missed something?

No, you didn't miss anything, that system simply uses nonsensical methods, that's why it works in a weird manner. If you want something like vertical stairs and your map is supposed to work under 227i (that is, you're not going to wait for new fixes in 227j), then I'd recommend to forget about LadderTriggers and/or using PlayerClimbing state - I think, it's more easy to implement a properly working mod than fix that stuff.

I'm already considering possible ways to fix 227j implementation because I see a potential need in similar collision checks for climbing and real crouching. After preparing a solution for 227j, I'll think how to transform it into a standalone mod.

[Pitbull]

I think it just needs some proper navigation points. Should also have a default climbing sound.

[Masterkent]

I think it just needs some proper navigation points. Should also have a default climbing sound.

When you model climbing on a stairs or wall, you shouldn't allow climbing somewhere far from the stairs/wall. If you use the default cylindrical collision for LadderTrigger, then players can touch it (and initiate climbing) long before they would actually reach the stairs/wall. This problem can be solved by using special non-blocking mesh for your stairs/wall, but making such a mesh would require additional efforts from you. Another issue is that if your stairs/wall is not strongly vertical and climbing should be done vertically and horizontally, you can't properly simulate such a behavior with LadderTriggers. Jumping off the LadderTrigger is terrible, it adds velocity to the player in a non-intuitive and really weird manner. Let's be honest: mappers can use this thing only if they either don't care about the quality or don't know how to implement such things in a better way.

I don't have an opinion regarding whether special actors that would help with capturing and pushing off ladders could be useful. Probably, a quality implementation should not require using such things.

[Pitbull]

In DS9 The Fallen there are path nodes to mark the entrance and exits. Thats where I got the idea.

[Masterkent]

In DS9 The Fallen there are path nodes to mark the entrance and exits.

How are they used there? For AI?

If we were going to support AI-controlled climbing in Unreal, navigation points might be useful for determining reachability and paths. When climbing should be started and when it should be finished can and should be determined based on an analysis of the level geometry around the climbing pawn. The mapper should be responsible for specifying the surfaces which can be used for climbing, the game should be responsible for checking the movement physics.

In particular, we can define vertical or steep (above 45 degrees to the horizontal plane) surfaces where players can climb by adding a special trigger: if a player touches both the surface and the trigger simultaneously, he can climb. Example:


Climbing with ropes and pipes should use a bit different principles. It's also possible to implement climbing using ledges that would not require any triggers at all. Unlikely our character will ever be such a master of climbing as Kyle Crane or Faith Connors, but some cool things can be implemented - it's a matter of time.

[Turboman.]

That's a cool video, that ladder behavior looks much more practical then the current 227 implementation.

I tried using the current ladders in a small mapping project, but for the reasons you mentioned (odd collision, hard to get on-off) i decided not to in the end.

Just wondering, can we also shimmy sideways on these ladders? and can it also project on multiple surfaces, such as climbing a cave wall all up to the ceiling polys?

[Pitbull]

This all I can get out of DS9 but it somewhat explains what I was talking about to help exiting.

Code: Select all

//--------------------
class CTVE_NavigationAssist expands NavigationPoint
//--------------------
      native;

//-----------------------------
// Used by player and pawns to assist in navigating around the world
//-----------------------------
// VARIABLES:
//
// bNarrowOpening - Denotes a narrow opening (a narrow doorway) where pawns and players
//                              should be assisted moving through to avoid colliding with edges.
//                              Point the directional arrow in the direction of flow through opening.
//
// MaxStepHeightOverride  - Overrides the normal MaxStepHeight of pawns. Forces step up tests 
//                                          to use this height in order to fit through low openings. Also
//                                          effects path node building.
//-----------------------------

#exec Texture Import File=Textures\CTVE_NaviMagnet.pcx Name=CTVE_NaviMagnet Mips=Off Flags=2

var() bool      bNarrowOpening;
var() float MaxStepHeightOverride;

//-----------------------------
function Touch( actor Other )
//-----------------------------
{
}

//-----------------------------
function UnTouch( actor Other )
//-----------------------------
{
}

//-----------------------------

[Pitbull]

Here's a picture of what I'm using the ladders in. If I can not get them working satisfactorily I will use lifts but the ladders IMO make it better.

[gopostal]

THAT is sexy.

[Masterkent]

Just wondering, can we also shimmy sideways on these ladders?

If you mean a sort of view bobbing, then I didn't think about implementing such things and it definitely wouldn't be on the top of the priority list. If you mean a controlled horizontal movement, then yes, I think that it should be supported, but I still have no decision how exactly it should work. Even when it comes to vertical ladders, there is no any conventional mapping between movement buttons and the effects they produce. The following table summarizes the effects of movement buttons when using a vertical ladder in various games which I currently have on my laptop:

Code: Select all

[color=aqua]                     Move Forward           Move Backward          Jump          Crouch           Turning from     Strafe
                     View Up/Down           View Up/Down                                          the Ladder[/color]

[color=aqua]Chrome[/color]               Move                   Move                   Drop from     -                No Side          Strafe
                     Upstairs/Downstairs    Downstairs/Upstairs    the Ladder                     Effects

[color=aqua]Dying Light[/color]          Move                   Move                   Jump          Slide            Lock             -
                     Upstairs/NA            Downstairs/NA                        Downstairs       Movement

[color=aqua]Half-Life 2[/color]          Move                   Move                   Jump from     -                No Side          Move
                     Upstairs/Downstairs    Downstairs/Upstairs    the Ladder                     Effects          Upstairs

[color=aqua]Metro: Last Light[/color]    Move                   Move                   Drop from     -                NA               -
                     Upstairs               Downstairs             the Ladder

[color=aqua]Painkiller[/color]           Move                   Move                   Move          NA               No Side          Strafe
                     Forward                Backward               Upstairs                       Effects

[color=aqua]Quake 2[/color]              Move                   -                      Move          Move             Drop from        -
                     Upstairs/Downstairs                           Upstairs      Downstairs       the Ladder

[color=aqua]Return to Castle[/color]     Move                   Move                   -             Crouch           Drop from        Strafe
[color=aqua]Wolfenstein[/color]          Upstairs/Downstairs    Downstairs/Upstairs                                   the Ladder

[color=aqua]SiN[/color]                  Move                   Move                   Jump from     Crouch & Move    Drop from        Strafe
                     Upstairs               Downstairs             the Ladder    Downstairs       the Ladder

"NA" means that the player is not allowed to act as specified in the condition above (view down from a ladder, assign a key to crouching, or turn from the ladder);

"-" means that pressing/holding the corresponding button has no any effect when using a ladder.

Moving along walls that have a complex shape needs a well-considered movement convention. Ideally, on one hand, we should be able to move in any direction indicated by our ViewRotation (as long as we keep the distance to the wall (that is, its closest part) short enough), and, on the other hand, be able to climb up or down when looking in a different direction.

and can it also project on multiple surfaces, such as climbing a cave wall all up to the ceiling polys?

Strictly speaking, the wall even need not be a planar surface, it has to be something that blocks a player when the player tries (or would try) to move in a certain direction. In particular, it may be a corner formed by two planar surfaces or a vertex of three or more planar surfaces. This situation needs specific calculations, because we can't even say what would be the perpendicular to such a wall. Besides, the player can be blocked by more than one wall at a time. The method currently used in my implemention doesn't work satisfactory, and I have to find a proper alternative to it.

This all I can get out of DS9 but it somewhat explains what I was talking about to help exiting.

Well, that barely describes the logic how it's actually used, and I doubt it could be useful in our situation anyway, unless you want something that would work like moving on rails.

[Pitbull]

I'm just looking for a smooth exit option. Currently you have to jump to get off. The little bit of code I did post does suggest a forced step. I think that would achieve a smooth exit. I wish I could extract the code from DS9 but I don't have any idea how to do that. If you'd like to have a look at my map I can share it with you and you can have a look at the ladders.

[Masterkent]

The little bit of code I did post does suggest a forced step. I think that would achieve a smooth exit.

In my case, the hardest part is finding the exact direction where the player should move to when he presses Move Forward / Move Backward / Strafe Left / Strafe Right / Jump / Crouch. Determining when the player cannot climb anymore is a rather easy task and I really don't see usefulness of navigation points here. Of course, you're free to suggest an alternative usable implementation based on navigation points, and then we can compare which implementation is better.

[Pitbull]

Like I mentioned I can send you what I have so far and you can see what I'm talking about or what I did wrong.

[Masterkent]

Like I mentioned I can send you what I have so far and you can see what I'm talking about or what I did wrong.

That definitely makes sense, maybe your usage doesn't fit in the concepts that I keep in mind. You can publish a link here or send me a PM.

[Masterkent]

It seems, I've created a decently working (but not perfect) implementation that can be integrated in PlayerPawn, but I couldn't implement such a functionality within an independent mod without subclassing PlayerPawn (or its derived classes). The major difficulty with implementing a non-intrusive mod is a synchronization between server-side and client-side player moves. I have no any ideas how such a synchronization could be done, and I'm not going to continue any work on this (because there are more interesting things).

So, at this moment I can suggest the following steps. Firstly, we should test the modification in an online game in order to ensure it works well enough. That is, we need to organize a small meeting (I need at least one player who would help me with testing). Secondly, we should decide how to integrate new implementation in 227j.

The existing LadderTrigger does not work well in an online game due to lack of client-side prediction. When the client cannot predict when the player should start to climb and relies on the data about state changes from the server, this is can be observed as a perceivable lag even in LAN game and ping 17 ms. In order to resolve this issue, we need to make the trigger bNoDelete and RemoteRole == ROLE_AutonomousProxy. If we change default properties of LadderTrigger this way, this potentially may break existing ladders on custom maps if they are supposed to be played with custom PlayerPawns that override movement functions in a specific ways. The safest solution would be adding a new LadderTrigger-like class, but this approach implies making the code noticeably more complicated.

Another thing to consider is optimization of speculative move operations. My current implementation uses a lot of calls to Spawn every tick. The number of calls can be reduced by using the same approach as was suggested for real crouching - the same actor can be reused many times. On the other hand, speculative move operations can be implemented natively (in C++), in that case climbing won't need an aux actor at all.

[strategy-(DOG)-]

That is, we need to organize a small meeting (I need at least one player who would help me with testing).

if you still need a player to test, let me know...

[Smirftsch]

Another thing to consider is optimization of speculative move operations. My current implementation uses a lot of calls to Spawn every tick. The number of calls can be reduced by using the same approach as was suggested for real crouching - the same actor can be reused many times. On the other hand, speculative move operations can be implemented natively (in C++), in that case climbing won't need an aux actor at all.

Yes, I'll have a look into that. Sorry for delay, had to fight a freaking flu the last 2-3 weeks.

[Masterkent]

So far no any mappers or devs asked about testing this stuff. It looks like mappers are not interested in this feature, so let's concentrate on other features and issues then.

Here's the current implementation that can serve a proof of concept:
https://www.upload.ee/files/7913742/Climbing.u.html

Game type: Climbing.ClimbingCoop (for network game).

Available console commands:

Code: Select all

    Cmd SavePos  - associate the current player's location with name .
    Cmd SetPos  - move to location named .
    Cmd GetPosList - print the list of available named locations on the current map.
    Cmd RemovePos  - remove named location .
    Cmd SummonLadder [CR] [CH] - summon Engine.LadderTrigger with bHidden==false, CollisionRadius==[CR] and CollisionHeight==[CH].
    Cmd ViewNearest  - view the nearest actor of type ClassName.
    Cmd GetVar  - print the value of variable  of the viewed actor.
    Cmd SetVar   - set the value of variable  of the viewed actor to .
    Cmd GetState - print the state name of the viewed actor.
    Cmd SetState  [StateLabel] - call GotoState(, [StateLabel]) on the viewed actor.
    Cmd Remove - destroy the viewed actor.
    Cmd Map [URL] - same as "SwitchCoopLevel [URL]".

Note: all Engine.LadderTrigger actors are adjusted to have bAlwaysRelevant == true && RemoteRole == ROLE_AutonomousProxy.

[Kajgue]

I would be interested in this feature, wasn't sure if it was being included in 227 or not.

Might aswel check this out before we decide to make a more personalized ladder actor for our project, or if it could work as a better foundation.

Thanks Masterkent.

Edit: Is this only available as a gametype? For a moment I thought it was an actor that would work regardless of gametype.

[Masterkent]

Edit: Is this only available as a gametype?

Climbing.u is a sort of tech demo which is not supposed to be used as a mod on a regular basis. The game class Climbing.ClimbingCoop is used for convenience: it changes the existing LadderTrigger actors (by setting their RemoteRole to ROLE_AutonomousProxy and bAlwaysRelevant to true) so that they can work client-side and it makes sure that Climbing.ClimbingPlayer is used as the player class.

ClimbingPlayer is an indirect subclass of PlayerPawn, it implements climbing and transitions between states PlayerPawn.PlayerWalking and PlayerPawn.PlayerClimbing. I couldn't implement such things outside of PlayerPawn, hence the only thing I can offer at this moment is some code that can be integrated into PlayerPawn after optimizing (I noticed that multiple calls to Spawn from movement functions tend to crash the client, so optimizations are required).

An interesting alternative could be adding a new state like PlayerPawn.PlayerModState which would delegate such functions as PlayerPawn.PlayerTick and PlayerPawn.ProcessMove to a custom actor. This would allow implementing an arbitrary player movement logic in mods without subclassing PlayerPawn.

For a moment I thought it was an actor that would work regardless of gametype.

Technically, Climbing.ClimbingPlayer can be tested with any game class that supports arbitrary player classes. However, many popular "advanced" game classes (such as JCoopZ1.JCoopZGame) do not allow choosing an arbitrary player class.

I would be interested in this feature

How about testing it online today?

[Krull0r]

I like to test in multiplayer, tell me when and where

[Masterkent]

Climbing Test Server (it should be listed among Coop servers in the server browser), you can join right now.

[edit]Thanks to Krull0r for testing, we discovered one network-related issue: the other player sometimes appears to be falling while actually climbing. There are also 3 things to tweak additionally: players should not be able to climb regular actors and climbing players should fall after taking a damage momentum that exceeds a reasonable threshold; when "unarmed" climbing is finished, the player should hold the same weapon as before.[/edit]

[Kajgue]

Has testing finished? I would be available to participate now if the server is still running.

[Masterkent]

Update: https://www.upload.ee/files/7922022/Climbing.u.html

Changes:
- Players can climb only level Brushes and bWorldGeometry actors.
- Climbing can be ended by calls to AddVelocity (which can be invoked by TakeDamage).
- Fixed the issue with client-side weapon switching.

I have no idea how to resolve the visual issue when other players appear to be falling. In Unreal, client-side prediction works in a weird manner. The server does not replicate Physics of other Pawns to clients - it's always PHYS_None there. It looks like clients rely on the value of bCanFly when determining whether the Pawn is flying or falling. Since PlayerPawns typically have bCanFly == false, clients assume that other players should fall.