Pathnoding Kickers

UT2003's UTJumpPad

UT2003's UTJumpPad is much easier to use. Most of the pathing is taken care off by the engine, so LiftCenter and LiftExit actors are no longer necessary. The jumppad itself is also a NavigationPoint and will automagically be linked into the pathnetwork upon a rebuild.

An UTJumpPad is basically linked to a PathNode or any other actor which can act as one, such as another jumppad, weapons, ammo, etc., which'll function as it's destination. This is done using the NavigationPoint → ForcedPaths[0] property. Simply set this to the name of the destination PathNode (found in the Object → Name property, such as PathNode35) and (partially) rebuild the path network.

After the rebuild you can see the jumppad's path simply by selecting it. It'll show up as a pink parabola. If you're not satisfied with the height of the jump, then you can change this with the JumpZModifier property. Another rebuild is needed after changing this, or the change won't show up in the editor nor work ingame.

Finally, you can set up a sound using the JumpSound property. Select one with the sound browser, click the property's input field and the small "Use" button. (or you can manually type it)

Example maps: DM-Plunge, CTF-Face3

UT

Pathnoding kickers in UT is an abolute pain, if not a nigh impossibility - especially as there are a few quirks in the bot/kicker interaction.

Generally, when putting a Kicker in a level you need to get completely consistent results out of the Kicker (being booted across a huge gap is great as long as you always wind up on the other side). There are two attributes of the Kicker that will effect this.

bKillVelocity: Setting this to true ensures that the player or bot velocity is "removed" before the kicker velocity is applied. If this property is set to false then it will appear that you are getting an element of random "kick" behaviour even though that's not the case. I reccomend setting this to true.
bRandomise: If this is true then you will get random behaviour from your kicker - use at your peril

Now, besides the kick velocity there is one other really useful attribute of the Kicker - KickedClasses. If you have ever placed a Kicker on a map that has X and Y components you will see that every now and then the bots will simply bounce vertically upwards. For some reason the bots do not always have the horizontal velocity components applied to them. The KickedClasses property will let you get around this.

Simply add another Kicker to your map directly above the "real" one and set the KickedClasses property to "Bot". This will ensure that only bots are kicked by the kicker not players. Players always interact correctly with Kickers.

Now that we have covered off all of the basics, lets get down to actually pathing the kicker in so that the bots will use them. Typically a Kicker and path is represented by these objects.

Kicker: Well, you need one really don't you. Generally you need two - a primary one for players, and a secondary one to kick bots that have got "stuck" bouncing on the jump pad for eternity.
SpecialEvent: This is used to make the kicker sound.
Trigger: Used to trigger the SpecialEvent. This should also be used as a trigger for the lift in the LiftExit object.

You don't need a separate Trigger to fire an event when the Kicker is touched. Just set the Kicker's Event property... —Mychaeel

I did wonder about that, but that's the way Epic do it. However, I've found that the bots use the kicker more readily if the trigger is placed on the kicker and the bots believe they have to touch it to trigger the "lift". - EntropicLqd

LiftExit (UT): You will need two of these. One placed just in front of the lift exit, and one placed near the point the bots are supposed to land. They will both need the same LiftTag property. It's also worth while setting the LiftTrigger property to the Trigger used to make the kicker sound. This ensures that the bots will run into the kicker.
LiftCenter: In this case the LiftCenter is primarily used to determine whether the bots will attempt to use the kicker or not. The LiftTag property needs to be set to the same value as the two LiftExit objects. The MaxDist2D and MaxZDiffAdd properties define how close the LiftCenter needs to be before the bots will try and use/jump onto the lift. By setting the LiftTrigger property these values seem to have less of an effect. If your LiftCenter needs to be in mid air then you MUST use a JumpSpot as LiftCenters are not pathed to if they are floating. If you do use a JumpSpot as your lift center then its well worth setting the bAlwaysAccelerate property to true.

The most important thing about the placement of the lift center is that the bot must be able to travel through it while walking (being kicked through a lift center doesn't seem to count).

Essentially, the common structures are as follows:

LiftExit (UT)

→

SpecialEvent
Trigger
Kicker
LiftCenter

→

Your big gap

→

LiftExit (UT)

→

SpecialEvent
Trigger
Kicker

→

Your big gap

→

LiftCenter

→

LiftExit (UT)

If you've built the kicker this way and are still seeing strange things happening with your bots then try using two one way lifts (set the bOneWayPath property to true for your two LiftExit (UT)s and LiftCenter) and see if that helps.

Example maps: UT's DM-Morpheus, CTF3-InstaTheEyes.

Pathnoding Kickers

UT2003's UTJumpPad

UT

Related Topics