Mover attached Actors move delayed

[Barbie]

Crossposting from 10 May 2015 in another forum where I got no answer. But I'm sure that here is the UT99 knowledge concentrated!
---8<---
I spend several hours on this but could not solve it: In a map I have a subway train as a LoopMover. It moves from one side of a long and straight tunnel to the other side, rotates there at 180 degrees, moves back and finally rotates back to original position. Until here all works fine. Then I added some Lights, a SpecialEvent and Decoration (LightBox, ScaledSprite) to the train and connected it with Movement->AttachTag. If played locally, everything works as expected. But if played on a server, the mover and the decoration run out of sync - the mover is faster than the connected parts.

Even if all their Actor->Network properties are the same, it does not work.
---8<---
On the screen shot below you can see that the front lights of the train are too much in the front. The sync broke seems to happen after the first rotation.

The map MH-AutoRIP(SB) (Rev 2) is playable on Barbies Monsterhunt World and downloadable here.

Thanks and cheers,
Barbie

[Red_Fist]

I think it has to do with "no delete" in the properties, and "always relevant".

Not sure, but it has to do with actors being ticked, by the server tick rate.

Must be some setting, but that's my first ideas, and some actors won't work online, others know more than me on this. Or the movement settings of the actor.

[Higor]

For smooth results, you need to:
- Set bNoDelete on all attached actors.
- If the actors are going to change in some form during play, RemoteRole ROLE_DumbProxy otherwise ROLE_None

That's nice and all, but actors will look joggy.
Simply try slightly different move timers until you get one that looks identical on both client and server (stupid replication issue).


Regarding accurate attachment and smooth moving, something like the below is needed (this is for serverside or simulated attachments).
You'll be needing a new actor to make stuff sync...

Code: Select all

//=============================================================================
// XC_ActorAttacher.
// Manual attacher, because engine can't be trusted
//=============================================================================
class XC_ActorAttacher expands Actor;

var rotator LastRot; //Base rotation
var bool bCorrectRot;


event PostBeginPlay()
{
   LastRot = Rotation;
   SetTimer( 1 + FRand(), true);
}


event Tick( float DeltaTime)
{
   local rotator aRot;
   local vector aVec;

   if ( (Target == none) || Target.bDeleteMe )
   {
      Target = none;
      Destroy();
      return;
   }

   aRot = Target.Base.Rotation - Rotation;
   if ( (aRot == rot(0,0,0)) || (LastRot == aRot) )
      return;

   if ( TimerRate > 0 ) //Complex attacher, disable timers
      SetTimer(0.0, false);

   aVec = Location >> aRot; //CHECK HERE
   aVec += Target.Base.Location;
   if ( bCorrectRot )
      Target.SetRotation( Target.Rotation + (aRot - LastRot) );
   LastRot = aRot;
   if ( VSize( Target.Location - aVec) < 1 )
      return;
   Target.Move( aVec - Target.Location);
   if ( VSize( Target.Location - aVec) < 1 )
      return;
   Target.SetLocation( aVec);
}

event Timer()
{
   if ( (Target == none) || Target.bDeleteMe )
   {
      Target = none;
      Destroy();
      return;
   }

   Target.SetLocation( (Target.Base.Location + Location) );
}

/////////////////////////
// Created in r1
// Changelog:
//
// r2:
// Added complex attach method for rotating actors
//
//
//

[sektor2111]

I'm guessing you can use other "Lightning" actors rather than a normal light. Actors (decorations-like) supports lightning and attaching to movers but they won't run smoother as presumed because is almost the same thing as Players in Lift (if you have some ON-Line Gaming Experience). They need DumbProxy and still might look a bit glitchy.
However

DM-BombingYard][.zip

(420.49 KiB) Downloaded 82 times

this is an experiment the mostly, not really best stuff, but is playable, here I did some A.I. tests in my custom DM game. There is a plane bombing up yard cycling, I was intended to test more but I got busy with other things letting it as it is...
You can deal with stuff like this making actor to have a light - or add a custom lightning manager replicating Lighting to player.
Yes, these kind of ideas need the hacky way to get them well.

[Barbie]

Thanks, I did as advised and it works: I set RemoteRole to ROLE_DumbProxy and bNoDelete=True for all Actors of that moving group (including the Mover itself) and now all Actors stay together while moving. But as predicted, moving looks joggy, especially on rotation. Can this be avoided by XC_ActorAttacher? Then I need a hint how to use that Actor...

Cheers,
Barbie

[Higor]

XC_ActorAttacher works mostly on actors where the local machine is the authority.
Also, XC_ActorAttacher won't rotate the component.

Maybe it's time I made XC_Siege_r4 package with better attachers.
The best way to handle a mover with preset attachments (IN CLIENTS THESE MOVERS MAY SPAWN IN A DIFFERENT LOCATION!!!) is to create client authoritative events.

Process:
- Enhance XC_ActorAttacher to rotate attachments.
- Make an attachment dispatcher that initially assigns each attachment an offset (offsets sent by server)
- Make attachments bNoDelete, RemoteRole=ROLE_SimulatedProxy, Physics=PHYS_None on attachments that may change state (by server)
- Make attachments bNoDelete, RemoteRole=ROLE_None on attachments that won't change over time (client authoritative)

I progress way faster when I can do trial and error in quick successions, can I have the test box you have the mover and attachments on?

[Barbie]

I didnt't get what to do now. If XC_ActorAttacher does not support rotation yet, its ok: I would not spend too much time in this this, because the "turning Area" where that joggy rotation effect occurs might not often visited by players. The players main interaction with that train is in the straight tunnel that connects the turning areas, and there the visual effect is ok now.
But if you want to improve - the download link for the map is given in first message of the thread. I tagged all concerning Actors with "trainstuff" so that it can be handled by UnrealEds "Group Browser" easily.

[Higor]

Warning: Failed to load 'Ambient': Can't find file for package 'Ambient'

[Barbie]

Can't find file for package 'Ambient'

Whow, I failed on checking if used packages are stock ones, sorry...
Either download the compressed version or wait a few days, until I release MH-AutoRIP(SB)-Rev3 with the changes above. There I will include that file.

[Barbie]

Version 3 of MH-AutoRIP(SB) is now released: contains the jerky but synchronous moving train and the non stock file "Ambient.uax".

(9 MB for a few used sounds only, omg. But I don't want to break the concept of shared resources.)

[sektor2111]

A little bumpee

Some XC map by FraGnBraG (lord of mapping after all) EpicTown or such (MapRaider might have it) has... a train (I used that to travel - was cool). So... that train seems to have a good looking On-Line. It's just a good example.

[Barbie]

Ah, thanks, I've found the map and even a rating of it in this forum. Nice looking one
But the differences of the trains are, that EpicTowns train is symmetrical in driving forward and backwards and so the mover has 2 NumKeys. In AutoRIP(SB) the train is asymmetric: the front looks different from the back and it has white headlights in the front and red back lights and so it should move only in one direction. I solved that by rotating the train at 180°in the end positions and here the problems begin. It seems that the Unreal Engine doesn't like rotations.

[papercoffee]

Ah, thanks, I've found the map and even a rating of it in this forum. Nice looking one
But the differences of the trains are, that EpicTowns train is symmetrical in driving forward and backwards and so the mover has 2 NumKeys. In AutoRIP(SB) the train is asymmetric: the front looks different from the back and it has white headlights in the front and red back lights and so it should move only in one direction. I solved that by rotating the train at 180°in the end positions and here the problems begin. It seems that the Unreal Engine doesn't like rotations.

Oh yes rotations are bad ...if you don't transform permanently. I don't know what it is with mover but did you try to build the train as mesh with the lights build into it and attach it to a mover?

[Barbie]

I don't know what it is with mover but did you try to build the train as mesh with the lights build into it and attach it to a mover?

If I knew how to build meshes...
Is the idea behind it putting all visible stuff together and attach it to a Mover that moves at an invisible trace? Some AmbientSounds, Lights and LightBoxes have to move, too. Can they be included in Meshes, too?

[papercoffee]

Well you have to fake the light with light cones, I suppose.
How to make a mesh http://wiki.beyondunreal.com/Legacy:MeshMaker
And for the attached mover thingy viewtopic.php?p=55124#p55124

Should the train be ridable??