Worst-case scenario: the UEd Goblin wipes the map and burns down your house.

Legacy:Mover

From Unreal Wiki, The Unreal Engine Documentation Site
Revision as of 12:34, 9 April 2015 by SeriousBarbie (Talk | contribs) (deleted invalid link)

Jump to: navigation, search
UT2004 :: Actor >> Mover (Package: Engine)

A StaticMesh actor that can move between predefined key positions and rotations.

See Mover (UT) for the UT version of this class, which uses a brush instead of a StaticMesh.

In UT3 movers have been replaced by InterpActors in combination with Kismet for activation control and Matinee for movement path definition.

Properties

Main

name AntiPortalTag 
Tag of attached AntiPortalActor.
bool bDamageTriggered 
Triggered by taking damage
bool bDynamicLightMover 
Apply dynamic lighting to mover.
bool bOscillatingLoop 
Goes from 0 up to X then back down to 0
byte BrushRaytraceKey 
Raytrace the brush here.
bool bSlave 
This brush is a slave.
bool bToggleDirection 
If this Mover is in the RotatingMover state, toggle directions between "Triggerings".
bool bTriggerOnceOnly 
Go dormant after first trigger.
name BumpEvent 
Optional event to cause when any valid bumper bumps the mover.
EBumpType BumpType 
Determines what actors can bump-trigger the mover (see declaration for EBumpType below).
bool bUseShortestRotation 
Rot by -90 instead of +270, etc. If end key was 360 and start key is 0, this means it won't have to rotate at all.
bool bUseTriggered 
This Mover is Triggered by any Touching player who presses the "Use" key.
float DamageThreshold 
Minimum damage to trigger
float DelayTime 
Delay before starting to open
int EncroachDamage 
How much to damage encroached actors. Note: This damage is taken by encroached actors before any MoverEncroachType reaction is applied.
byte KeyNum 
Current or destination keyframe.
EMoverEncroachType MoverEncroachType 
Determines how the mover reacts if encroached by another actor (see declaration for EMoverEncroachType below).
EMoverGlideType MoverGlideType 
GlideByTime will interpolate between keys by starting out slow, building speed to the halfway point, then slowing down until stopped at the next key. MoveByTime will interpolate linearly, at a constant speed between keys.
float MoveTime 
Time to spend moving between keyframes.
byte NumKeys 
Number of keyframes in total (0-3).
float OtherTime 
TriggerPound's StayOpenTime.
name PlayerBumpEvent 
Optional event to cause when the player bumps the mover.
float StayOpenTime 
How long to remain open before closing. (unless TriggerPound is used, see OtherTime)
byte WorldRaytraceKey 
Raytrace the world with the brush here.

AI

bool bAutoDoor 
Automatically setup Door NavigationPoint for this mover
bool bNoAIRelevance 
Don't warn about this mover during path review

MoverEvents

name ClosedEvent 
Event to cause when closed
name ClosingEvent 
Event to cause when closing
name LoopEvent 
Event to cause when the mover loops
name OpenedEvent 
Event to cause when opened
name OpeningEvent 
Event to cause when opening

MoverSounds

sound ClosedSound 
When finish closing.
sound ClosingSound 
When start closing.
sound LoopSound 
Played on Loop
sound MoveAmbientSound 
Optional ambient sound when moving.
sound OpenedSound 
When finished opening.
sound OpeningSound 
When start opening.

ReturnGroup

bool bIsLeader 
This Mover is the leader of a return group of movers.
name ReturnGroup 
The return group this mover belongs to. All movers in a return group form a linked list of "followers" with each mover's Leader pointing to the main mover that should be triggered, bumped, or otherwise activated. The leading mover will tell its Follower to open/close whenever it opens or closes itself. The follower in turn will do the same with its own follower, and so on. Make sure only one mover in a return group is flagged as the leader, otherwise you might experience weird stuff including "Infinite Script Recursion" crashes.

Hidden

KeyRot[24] 
KeyPos[24] 
array<AntiPortalActor> AntiPortals 
vector BasePos 
rotator BaseRot 
bool bClientPause 
bool bDelaying 
bool bOpening 
bool bPlayerOnly 
int ClientUpdate 
Mover Follower 
Next mover in the linked list of movers belonging to a "return group".
Mover Leader 
The primary mover of a "return group".
NavigationPoint myMarker 
int numTriggerEvents 
Number of times triggered ( count down to untrigger )
vector OldPos 
vector OldPrePivot 
rotator OldRot 
float PhysRate 
Interpolation rate per second.
byte PrevKeyNum 
Previous keyframe.
vector RealPosition 
rotator RealRotation 
vector SavedPos 
rotator SavedRot 
Actor SavedTrigger 
The Actor that triggered this Mover.
vector SimInterpolate 
vector SimOldPos 
int SimOldRotPitch 
int SimOldRotRoll 
int SimOldRotYaw 

States

OpenTimedMover 
Master State for OpenTimed mover states (for movers that open and close between two keys)
StandOpenTimed (extends OpenTimedMover) 
Open when stood on, wait, then close.
BumpOpenTimed (extends OpenTimedMover) 
Open when bumped, wait, then close.
TriggerOpenTimed (extends OpenTimedMover) 
When triggered, open, wait, then close.
LoopMove 
When triggered, the mover keeps looping through each of the keys until it gets untriggered. It will go to the first key after the last key.
TriggerToggle 
Toggle between two keys when triggered.
TriggerControl 
Start opening immediately when Triggered, begin closing immediately if UnTriggered. Keep a constant speed, which is based on the MoveTime and the distance between the two keys.
TriggerPound 
Can be thought of as acting like the "Ring The Bell"] carnival attraction. You "pound" (trigger) it to the top (open key) and it will fall back down. (closed key) When triggered, begin to Open immediately, and if left alone, Open completely and stay open for OtherTime, not StayOpenTime. If Untriggered, begin to Close immediately, similar to TriggerControl, and as if the "pound" didn't have enough strength to make to the top and ring the bell. Unlike TriggerControl which keeps a constant speed, TriggerPound will always use the MoveTime no matter where the Mover is between keys. So, if Triggered while closing or if UnTriggered in the midst of opening, it will reverse direction and move more slowly to the next key. (Note: Although the code appears to indicate that a TriggerPound Mover can loop from a fully Closed key after StayOpenTime if more Trigger events have been sent to it than UnTrigger events, it doesn't appear to loop in any situation tested.)
TriggerAdvance 
(UT200x only?) When Triggered, move toward the Open key. If UnTriggered, stop moving.
BumpButton 
Open when bumped, close when reset.
ConstantLoop 
Loop this mover from the moment we begin. It will go to the first key after the last key.
LeadInOutLooper 
A Looping move that goes from 0 to 1 when trigger, loops 1-x then returns to 0 when triggered again.

(For Scripters: Goes to state LeadInOutLooping when triggered and back to LeadInOutLooper when triggered again.)

RotatingMover 
Uses Movement -> RotationRate. It rotates when triggered and stops rotating when untriggered. If bToggleDirection is true, it toggles rotation directions when triggered.

Enums

EMoverEncroachType

ME_StopWhenEncroach 
Stop when the mover hit an actor.
ME_ReturnWhenEncroach 
Return to previous position when the mover hit an actor.
ME_CrushWhenEncroach 
Crush the poor helpless actor.
ME_IgnoreWhenEncroach 
Ignore encroached actors.

EMoverGlideType

MV_MoveByTime 
Move linearly; a constant speed determined by the distance between the keys and the MoveTime.
MV_GlideByTime 
Move with smooth acceleration; starting out slow, building speed towards the half way point, then slowing down to a stop at the next key, all within the MoveTime.

EBumpType

BT_PlayerBump 
Can only be bumped by player.
BT_PawnBump 
Can be bumped by any Pawn.
BT_AnyBump 
Can be bumped by any solid actor.

Known Subclasses

Related Topics

Discussion

EricBlade: A question. In Land of the Dead (UE 2226, roughly UT2003 base code, it seems), movers do not replicate properly. I see there is a bunch of code in Mover, ActionableMover, and DestructableMover to accomodate replication, but it all doesn't seem to work. Would anyone be interested in taking a look at the code, to see if there's something that can be done to fix it without subclassing and reworking every single mover in the entire codebase?

SuperApe: From what I know, it seems that the bNoDelete setting is the primary reason for proper Mover replication. This sets the Mover object itself to replicate to all Clients. So besides the replication block in Mover, you may need to confirm that your engine version is set up to act the same way in that regard.

EricBlade: It turns out, that apparently the actual location/rotation of these movers is not replicated properly.. what the effect is, say you have a door that opens and closes. If the door's normal state is closed, but you open that door .. then another player logs in, they get the door in the original position on their client, even though it is in the open position on the server. This gives you a door that appears open, but is actually closed. Except that it's actually appearing in a third position, the exact opposite of it's normal rotation. It's very weird.

Xian: Well bNoDelete Actors will not be Spawned or Destroyed by the script. It is not responsible for replication DIRECTLY, as is bNetOptional for example, or Role/RemoteRole properties, but apparently the server will delete Server-Side only actors from the Client on game start (not sure if in the PostBeginPlay() session of Engine.GameInfo or earlier. bNoDelete will make the Engine assign the necessary Role/RemoteRole value on Client and Server. Yeah I guess I see what you mean now, you can say it is responsible for replication, but wouldn't say it's the primary reason. You can just as well use bStatic I guess, although apparently Movers don't seem to want it (even though a Brush is bStatic...)

What EricBlade said makes sense, but I am curious how long it takes. I am not that interested in UE2, but in UE1 Timer() is responsible for updating the Client to the Server position, so the first few seconds you join will have a wrong position, although it should be updated later on. Perhaps doing a ClientSetLocation() where you set the position and rotation would be helpful in this case, but I do admit I am too lazy to test, and since I don't have an UE2 dev folder it will be kinda difficult, but I suggest you try it :)

SuperApe: Thank you for elaborating the long answer for me. :)

EricBlade: Not to bring up an oldish subject, but I didn't notice there were some answers here. Although the code for Mover says "Movers default to bNoDelete==true", that was not the case in my actual code. I set bNoDelete=true to the Door movers in the game, and now they appear in the right place when you load the level, but then a few moments later, they either completely disappear, or jump to FSM-only-knows where in the world, apparently on the timer when the position is replicated. Weeeeird.

Sweavo: "Pound Open when triggered. Pound Closed when untriggered." what on earth does it mean "to pound"? There is no other reference to pounding in this context on the wiki

Tarquin: yeah, the TriggerPound stuff is a mystery

Xian: Rough skimming tells me that one difference is that there is no Trigger notification (i.e. calling EndEvent() on the triggering actor) and that the movement loops. Also, you can see that there is no Stop command after Open, but there is, however, a Sleep, and there is a GoTo command after Close which calls the Open label (making a looping session). Although I am really lazy to make a test map (or edit one) to check it, to me it seems like once a Mover with this state is triggered it will cause an Open-Close, Open-Close, Open-Close loop "animation". Considering it belong to UnrealI, I never played it, but I assume one use could be, for example, in a factory, where you have those crushing thingies, f.e. a conveyor belt, and at a point stuff on the belt gets smashed by this, then incinerated or whatever, like a trap-quest, and you'd have to find the right timing to get past it (which explains the name Pound). Just a thought, but if any of you kind people would test, I might get a confirmation :) I'm not sure but these are all assumptions after checking the code.

SuperApe: Making a test map to test TriggerPound took all of two minutes. That and after looking through the code more carefully, I think the best way to consider this Mover state is like that of a carinval attraction: "Ring the Bell" or "High Striker". This is where you use a large mallet to strike a see-saw to propel a weight up a pole, trying to get it to the top to hit a bell. (thus, "Pound") When a Mover set to TriggerPound is triggered, it will Open and Close and stop (like you hit the weight hard enough to go to the top, ring the bell and fall back down). If it is Untriggered during this sequence is will begin to Close immediately, like TriggerControl (also like if you didn't hit the weight hard enough to go to the top of the pole). Unlike TriggerControl, TriggerPound will use the same MoveTime and alter it's Speed to travel whatever distance it needs to Open when triggered, or to Close when Untriggered. IOW, TriggerControl will always move at a constant Speed when Opening or Closing, no matter where it is in that movement between the keys, but TriggerPound will move more slowly to the Open key if it is triggered inbetween the keys, as if you added extra force ("pound") during it's Close movement and you interrupted it's momentum to send it back Open. TriggerPound uses a method of recording how many Trigger and Untrigger events it recieves.

Xian: Except that it loops (or should according to the code). What is IOW btw ? Well I am sorry if my description was not 100% accurate (except maybe 15%-20%), but it's better that you tested.

SuperApe: A Mover set to TriggerPound does not loop. It works as I describe above. It was tested as well as confirmed in the code. IOW = In Other Words.

Xian: According to this...

Open:
	Disable ('Trigger');
	DoOpen();
	FinishInterpolation();
	FinishedOpening();
 
	// If the next key frame is not the last, then
	// keep playing back the frames.
	//
	if (Keynum < NumKeys-1) {
		GotoState ('GradualTriggerOpenTimed', 'Open');
	}
Close:
	Disable ('Trigger');
	DoClose();
	FinishInterpolation();
	FinishedClosing();	// throw the current Event, if exists
 
	if (KeyNum > 0) 		// Still more key-frames to go through
		GotoState ('GradualTriggerOpenTimed', 'Close');
 
	Sleep(StayOpenTime);
	if( bTriggerOnceOnly )
	{
		AmbientSound = None;
		GotoState('');
	}
	if( SavedTrigger != None )
		goto 'Open';
}

... it does. At least in theory. As you can see, if the pointer to the SavedTrigger is still there, it loops to Open. Perhaps because it was not triggered using both params (Other and Instigator) it didn't loop in your case, but rest assured, it does loop. :) There are situations of calling Trigger(None,X) (where X is the Instigator) so I am not surprised if it doesn't happen in all cases.

SuperApe: We're obviously looking at two different versions of code. In UT200x, a Mover has no "GradualTriggerOpenTimed" state and the only time Trigger() is disabled is after a bTriggerOnceOnly check has been made. (Incidentally, I see minor differences between the code in UT2003 and UT2004 to accomodate a Reset() function, but it behaves the same way in both.) I found nothing in the UT200x Mover code that matches the code block you posted. But regardless, the SavedTrigger is simply allowing the Mover to keep track of multiple Trigger and UnTrigger events sent to it. When Triggered, SavedTrigger = something, when UnTriggered an equal number of times, SavedTrigger = None. But that does not seem to allow a fully Closed Mover set to TriggerPound to loop back Open in any case, whether Triggered by a NormalTrigger or via causeevent console command (which gives the Mover more Trigger events than Untrigger events). The description I state above is based on both my interpretation of the UT200x code and the results of an empirical test of the Mover state in Ued. It wasn't a guess or theorem. Didn't you ask for a confirmation of your intial assesment?

Xian: I did :) It was pasted from UT. If you'll check the code there you'll see that, as I pasted, the movement gets looped If the SavedTrigger is still referenced (as we both said via triggering). Unfortunately code changed a lot it seems over versions, though I appologize for the confusion.

SuperApe: During a long drive, I had time to think about this and I was bothered by the code that seemed to loop, but didn't in my tests. Then I remembered the weird thing TriggerPound does with the timing properties: OtherTime is used in place of StayOpenTime with TriggerPound, and StayOpenTime is used as shown above, to sleep after the Mover is Closed all the way. I'm convinced you're right, it must loop. Although I am not at a machine I can test this, I'll bet I just didn't wait the default 4 seconds after it Closed to see it loop. However, it should only loop if the Mover was given more Trigger events than Untrigger events, either by causeevent console command, ACTION_TriggerEvent from an AIScript subclass, UseTrigger or the like. A single NormalTrigger will always give the Mover an equal number of Trigger and Untrigger events, so in that case it would never loop. I apologize for the confusion. I think we should be able to refactor this Mover state now.

Xian:

However, it should only loop if the Mover was given more Trigger events than Untrigger events

My point exactly :) Yeah np, I must have confused you a bit as well with the code above (forgetting to mention it is UT). Well trial and error is the key :) Hopefully we'll both get to the bottom of this.

SuperApe: Well, whattaya know. I did more testing, waited extra long times to be sure, but it actually never loops from the fully Closed key. Whether you give it more Trigger events than UnTrigger events, or not. Go figure. I am a little confused by the code now; it seems like it should loop in some instance, but it never appears to do so. So, I guess my analogy of the "ring the bell" carnival attraction describes the TriggerPound Mover state the best.

Xian: OK double checked both UE1 and UE2 and they are the same in the Close session. That is weird indeed. According to the code as long as one SavedTrigger pointer exists (as you said one extra trigger event, which most likely seems to be caused the easiest by CauseEvent) would cause it to loop. I do trust that you did it properly so I am confused as well now... the code makes my analogy correct but the way it works makes yours correct. I think I'll do some testing in UT once I get some free time... "this is too weird for school" as they say :)

SuperApe: I agree, the way the code makes it look, it is confusing. On the other hand, to me TriggerPound sounds like the way it is behaving, it sounds like a "ring the bell" attraction. BTW, it appears that a NormalTrigger is the only way to always get an even number of Trigger and UnTrigger events, but there are several ways a Mover can get just Trigger events along with the causeevent console command: ACTION_TriggerEvent, UseTrigger, other Mover Events, etc.

Sweavo: wow, great work guys! All I can offer is "is bTriggerOnceOnly set?" hope I'm not insulting you but it's all too common to miss something like that when you're too close to the task! I'm not able to get to the source at the moment to look for myself...

SuperApe: Not sure what you're asking, Sweavo. Anyway, this page has been refactored in terms of TriggerPound/TriggerControl (and TriggerAdvance), see above descriptions. We can probably remove this part of the discussion at least, if everyone is satisfied.

Xian: He's right. He means that if bTriggerOnceOnly was set then they won't react to other triggering effects. According to the code, if that is set it leaves that state completely. Would you mind testing with and without that var just to see why the code says one thing and the way it behaves is different?

Sweavo: You are saying "according to the code it should loop, but I don't see it looping"... so I added "the code doesn't loop if bTriggerOnceOnly is set," as Xian also said just there. Trouble is, I don't see bTriggerOnceOnly in the default properties for Mover or an of its super- or sub-classes. Weird.

SuperApe: My tests were with the default setting bTriggerOnceOnly=false. bTriggerOnceOnly=true does what you'd expect it to: that is, Trigger (and Untrigger, if Untriggered) once and immediately go to a dormant state no matter what Mover state you're using. Tests confirmed this.

Sweavo: OK so that's a blind alley then. As another aside I wonder why that default doesn't show up in my uscript refernece source tree.

SuperApe: Booleans are false by default. There's no need to declare that in defaultproperties.

Mychaeel: ...unless, of course, you're overriding the default inherited from some superclass (or making sure that you don't accidentally inherit some default other than false).

Xian: Unfortunately this is not the case since this is the parent/base class.

Kirk: Looks like ConstantLoop doesn't honor StayOpenTime :/

Category:Legacy Refactor Me

Retrieved from "https://wiki.beyondunreal.com/Legacy:Mover?oldid=46141"