How do you return a KActor to its original position, orientation, or location?

[jc!]

If you play Halo: Combat Evolved, you know that, if you accidentally flip over a Warthog, you can hit the USE key to flip it back to its upright position. The physics engine handles the rest.

Does the Unreal engine offer a comparable function that’ll return a KActor to its original position, orientation, or location?

 

[Daeval]

Don't Onslaught vehicles have a nearly identical behavior?

 

[[SAS]Solid Snake]

Yes they do, another case of not bothering to research. All vehicles that can be flipped over in UT2004 can be flipped back so that they are on their wheels again. The scorpion, hellbender and the Bulldog all have code which involve this.

 

[jc!]

I don't believe this. In all my months of playing Onslaught, not once did I ever flip over a vehicle successfully, much less encounter an opportunity to flip it back to its original orientation.

I thought the reason I could never flip over vehicles in Onslaught was because their center of gravity was too low. In fact, I recall reading that in an interview with CliffyB. Well, my mistake, my bad.

I ask, not because I intend to apply this to my own vehicles, but because I want to apply this to player models that have gone “ragdoll.”

I recall Tim once stated that “feign death” was removed from UT2003 because returning a player model gone “ragdoll” to its original orientation was impossible.

I believe, however, we can take the same function that flips a vehicle back to its original orientation, and apply it to player models gone “ragdoll.” This will allow us to bring “feign death” back to UT2004.

If that doesn’t work, a little ingenuity may do the trick. For example, you can take a player model gone “ragdoll,” return it as close as possible to its original orientation, then destroy it and instantly spawn a new, identical player model in its place. It won’t look seamless, but it should work.

It may also be possible to apply this to subject-to-Karma gates or doors. I couldn't figure out, after pushing a door open, how to return it to its original, closed, locked state. However, the above should do the trick. Does anyone foresee a problem with this?

 

[Daeval]

When you flip a vehicle in UT2004, you're not actually "returning" it to anything. The vehicle just checks to see if it's upside down and, if it is, will allow you to give it a "kick" to attempt to right it.

I'm guessing the halo vehicles work in a similar manner, but the "kick" consists of a number of checks to make sure the vehicle gets righted, whereas UT2K4 leaves it up to the player to keep kicking the thing. This is why the UT version doesn't always work perfectly.

If you wanted something more like the Halo behavior, you might temporarily turn on some repulsors and set KStayUpright to True in the Karma properties of the vehicle. Not sure how easy that would be, as changing KStayUpright midgame crashes karma if I remember correctly. But that would do it if you could make it work.

As far as ragdolls go, you'd have to record the rotations of every bone/joint in the ragdoll at the moment when it becomes a ragdoll (if that's how it works), and then try to tween them all back to that point when you "rise from the dead." Good luck with that.

 

[jc!]

Then the code used to flip vehicles back to their original orientation doesn’t actually return subject-to-Karma actors to their original orientations, per se.

The idea isn’t to rewind a subject-to-Karma actor back to its original orientation. The idea is to simply move a subject-to-Karma actor back to its original orientation, even if it involves flipping, so to speak.

As far as ragdolls go, you'd have to record the rotations of every bone/joint in the ragdoll at the moment when it becomes a ragdoll (if that's how it works), and then try to tween them all back to that point when you "rise from the dead." Good luck with that.

If it’s possible to record—at the moment a player model goes “ragdoll”—the location of every bone and joint, we stillneed a function that’ll move the player model back to its original orientation. Does such a function exist?

I have another question about Karma actors, this time about triggers. I know, if a trigger detects an event or is touched, it’ll be enabled. So, if you want trigger to be enabled by Karma physics, should the trigger waits to detect an event or be touched?

To clarify, suppose a subject-to-Karma gate is locked. You hit the USE key to unlock it, then push it to push it open. However, when you pull it closed, it’s supposed to lock.

Obviously, you need a trigger to lock the gate. If the trigger waits to be touched, you just need to lock the gate when it’s close enough. However, if the trigger waits to detect an event, you need the gate to be oriented in a particular position—in this case, closed.

Is there a function that’ll check what position a Karma actor is in, so it can enable a trigger? I imagine this would be more difficult to code, but which method is more efficient—waiting to detect an event, or waiting to be touched?

 

[BinarySystem]

Err, thery're are both the same, computational overhead wise. Getting touched causes an event. However, since there isn't really any event that would go off once the doors are closed, touching would be faster.

But what would be even faster would be to not use karma at all if all this gate is responding to is being pushed by a player and possibly being shot. You could script the gate and it would execute faster, as well as giving you better control over it's behaviour.

 

[jc!]

The gate must be a Karma actor, not a Door mover, because we need to implement a system of opening doors that’s more realistic than Rainbow Six 3’s.

Yes, Rainbow Six 3’s doors are a vast improvement over previous games’. However, implementing doors via physics, not scripting, will significantly ratchet up the level of realism, in ways very important to our mod.

For example, with physics, one team can push a table in front of a door to barricade it. The other team can throw its weight at the door until it opens a few centimeters—enough to throw in a grenade. The blast may push the table away from the door, allowing the other team to rush in.

Obviously, implementing doors via physics, not scripting, is very taxing on bandwidth and CPU. However, we’ll compensate by being frugal with the number of doors per map.

Another question about triggers and actors: Can you configure UnrealEd so, whenever you place an actor on the map, it automatically places a trigger in the exact, same place next to the actor?

Manually adding a trigger to every subject-to-Karma door, telling it when it’s locked or unlocked, sounds very cumbersome—especially if a door needs two triggers, if it swings both ways.

More worrisomely, manually adding a trigger to every subject-to-Karma door on the map leaves a lot of room for error. If you don’t place the trigger in front of a door just right, the trigger could lock the door before it even closes.

Do you know a way to integrate actors and triggers, so you can place both on the map at the same time, without worrying if they’re too close or too far apart?

 

[BinarySystem]

Yes. Just have the door spawn it's own triggers in it's postbeginplay.

PS I wasn't recommending using a mover, but rather a custom actor which you'd script yourself. This could still have collision and interact with Karma objects. However, Karma will probrably work almost as good.

 

[jc!]

But how do you integrate an actor and trigger together in the first place, so you don’t need to place a trigger whenever you place an actor?

 

[BinarySystem]

Well, you could put, in the actor's postbeginplay, code to spawn the triggers. They won't be there in the editor, but the triggers will be created "on the fly" when the level is loaded. You can set the event, etc. of the triggers (if neccessary) in the postbeginplay of the doors after you've spawned them.

 

[chip]

re: the locking doors, why the need for Triggers? if you're talking about having a Karma actor door lock under certain conditions, then why not code for detecting those conditions and put the door into a different state. all the scripting would be part of the door's definition, rather than relying on separate trigger mechanisms.

example:

if( SomeThreshholdValue < KVelDropBelowThreshold )
  gotoState('DoorLocked');

or some such approach. using this variable (KVelDropBelowThreshold) from KarmaParams, this condition could also call Actor.KVelDropBelow() automatically, so the if() statement may not even be necessary.

 

[jc!]

But I don't want the door to lock when its velocity drops below a certain threshold. I just want it to lock when it's shut.

Is it possible to define, via UnrealScript, a Karma actor's state by its physical orientation? Is it possible define a subject-to-Karma door—not a Door mover, unless there’s a way I’m not aware of to subject a Door mover to Karma physics—so it knows whether it's shut or not?

 

[BinarySystem]

Yes. That sounds like it should be very simple.

You can compare it's rotation to the rotation that it has when it's shut. IE, the door is closed when it's rotation is (yaw=16384,pitch=0,roll=0) - whenever it's rotation is within a certain threshold of that, you can lock the door.

But make sure to have something in there so it doesn't lock itself immediately upon being unlocked, as it would of course pass the rotation check in that case.

You might have to define the "closed" rotation in the editor, or if the doors are always going to start closed, you can just use the rotation in PostBeginPlay().

 

[chip]

But I don't want the door to lock when its velocity drops below a certain threshold. I just want it to lock when it's shut.

my example was just that -- an example of using inherent actor properties to determine conditions and set states for the actor. it wasn't intended as a literal solution.

BinarySystem's explanation is helpful. you may want to include other parameters besides Rotation, e.g., Rotation within certain limits AND Velocity at zero (or really close). then maybe a timer function to delay the locking a tad so the door can "settle" into the condition for locking. it all depends on how you define "shut" for your particular type of door.

btw, your description of a team forcing its way past a blocked door may exceed the Karma engine's current capabilities. according to UDN players directly affecting karma actors (as by pushing) isn't yet implemented, though the converse is -- karma actors can affect players.