UT99.org | Unreal Tournament Community

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.

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

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.

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.)

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.

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.

Barbie wrote: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?

papercoffee wrote: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?

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??

Oh, that's a problem i've also encountered some time ago, and couldn't solve it. Actually not necesseraly the attached decos are out of sync, but the 'visible' part of the mover. The mover and it's invisible collsion hull is where it should be, but the movers visible hull is late on client side.
This is some ut bug, but this comes significan when the movers are covering a HUUUGE distance. You can hardly notice it on regular lifts and other movers that just travel 1000-2000 uu distances.
I had a map, DM-XMC-Alkalo there is a train dashing thru the arena... And i couldn't solved this problem, so i made two versions of it, and the multiplayer version is not havning the movign train. And it is a pity, becouse i spent a lot of time makeing the trains . But it had to be cut out, for it was quite annoying, for when one player on the server just witnessed a proper run-over, the player on the client side just experienced being hit by some invisible train.
So if there is a solution for this, i would some time implement it into this old map, and could finally release a final version.

This all has to do with how movers are replicated from server to client. When you have a mover that is going from A -> B then all you really need to do is tell the client "OK, the train has now left A". Because the client has the map it knows to begin the mover, how long it should take, and where that mover should be at any given time. This lets the client perceive the mover as being smoothly going from A to B. Rotation values however are periodically updated by the server sending this out to the client and since it happens at a tick-tick-tick rate then you perceive the rotating mover as jerky because the client won't simulate that rotation and waits for the server to say "OK, the earth ball has rotated 2 degrees on the X axis, 1 degree on the Y.

If all that is kinda technical bullshit then consider the guided redeemer versus the non-guided. Because the guided needs updates from the player and it has to send those out to the clients it appears to be herky jerky when the non-guided one is smooth and clean.

You won't fix this behavior, it's part of how the engine works. You'll need to figure ways around it.

The other thing with the collision is rotating he mover the collision don't for offline. Like a angled board on a floor. So the collision never changes, so I wonder if this don't happen online if a move only moves in a straight line only.

Well the original problem is that mover is actually not simulated the same way on client side as it is going on server side...

That's because of what I was explaining. The mover doesn't replicate from server to client in an updating way. Once it begins to move with an attached actor it will continue on that path through it's keyframe.

A workaround that comes to mind is to have a trigger set up to trigger the attached mover. It won't have movement keyframes since it is attached (I think this is how you have it? I probably need to see the map). Triggering it would cause the server to update to the clients about it and location/velocity data is part of that. I'm curios if that would work. If it does you might set a dispatcher to trigger the mover every so often so it replicates again.

Damn, now I need to go test this. I give it 25% chance of working but if it does then that's a mod that could silently run on servers to keep all the movers synced.

What about a timed trigger, and match the tick rate.