UT99.org | Unreal Tournament Community

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.

That's way too much, it would flood the stream with pointless updates. You really only need an update every few seconds to keep things synced up.

Nobody puts a decent solution, here goes:

1- Put mover in location (0,0,0), with rotation (0,0,0)
2- Add all attachables there, RemoteRole=ROLE_None, bNoDelete=True, bMovable=True.
3- Give said attachables the same specific tag (ex: Mover2Attachables)
4- Create a custom actor with the following directives:
** RemoteRole=ROLE_None, bNoDelete=True
** Add this code: 5- Spawn the actor in the level, set AttachToName=(mover's NAME), set AttachTheseTags=(the attachable's tag)
6- Relocate the mover to it's old location.
7- Playtest on both client and server.

If a sudden mover teleportation on client messes this up, get back to me.

Aside I'm glad that I could see in my stupid "bombingyard" map that plane flying properly and firing projectiles attached on a moved rotating. OF Course it's added On-Line and It works without special tweaks. You might want a DumbProxy for actor attached and not a high mover speed + bNoDelete + bMovable and I think mover does it's job properly - I see also 0 troubles even in XC stuff loaded.

In that big city map train was cute with those flare lights. I really don't get if these are a hard management, here we go into techs rather than "brushing" into Editor. I might wanna test Higor's solution if I won't write a tick-ed one. Since my solution was working I think is about collision setup which not many people are able to get it.

My only nasty problem with Mover which is not giving me a rest is PATHING them. Imagine a platform (Bridge opening later or closing or such - a giant one). After doing paths by setting up "ShowTextures", in game I went stuck thanks to a render crappy bullshit (why this feature in Editor then ?). So without to screw paths created I was rebuilding map's geometry (with desired risks). Things were functional but... In Levels with brushes stripped I don't see a valid solution. That is challenge - attaching paths to mover not attaching actors - because you don't know to sort what actor is compatible to be ported replication based - I prefer "Book" changing Light, Mesh - hidden or not - Book was working as I wanted without writing other stuff. And you should avoid "ZoneChanges".

Higor wrote:Nobody puts a decent solution

JackGriffin wrote:I probably need to see the map

For my investigations I extracted the MH-AutoRIP-problem into the map TestLongTunnel.unr: that contains only the (long) tunnel and train plus attached stuff. Maybe it helps someone.

Yeah this helps a bunch. In simplest form Higor nails it from earlier in the thread. Your issue is that the different actors replicate at different rates so they update out of sync. Without letting the client simulate some of this in the way the mover class does then it's going to always be jaggy.

If you want, go ahead and finish your map. When you get done I'll create mover subclasses with the mesh, lighting, etc for all the things pertaining to the train and link them together for you. It won't be pretty in editor but it will look and play just fine with no jaggy. That way they can run simulated on the client to fill in the positional updates and it will go smoothly. I'd forgotten I did this in MH-Portals for the train that rolls in with the merc on it.

(Edit: may need to explain this more. Take for example the scaled sprite and lightbox that comprise the "headlight". You could subclass two LoopMovers and change their mesh, texture, etc to these two actor's defaults. Place them at the head of the train and when all the movers are placed then you move them all in keyframes at the same time. This will keep them positioned correctly and moving in sync. Do this for all the actors you need to keep together and this will fix your problem. It's just going to be ugly in editor, like I said.)

JackGriffin wrote:I'll create mover subclasses with the mesh, lighting, etc [...] for you.

Thanks for the offer, but as I wrote the visual effect is acceptable for me now and I published the map in Nov 2015 already. If you need a challenge and have time for it feel free to improve the map. (Download)

But maybe SzGergo is still interested in a functional multiplayer version of his map DM-XMC-Alkalo.

That's cool. If anyone happens along to this thread then I might remake the small demo map you made to show how to do what I was saying. Gerg, look me up if this is something you want to dig into.

If I set up a timed trigger and pulse a mover, will it work ? is the question.

This is not something the runs, it's only a mover that travels to end a map. So if that works, what should the interval be, it won't start until the maps end and not a long way for it to move ,not looping, it has 4 keypoinst, so it will work to trigger it then.

I attached 8 mover sheets not slave but attach tags, and 4 decos, is working offline and I can't test this stuff on the same machine as the game seems like I used to do that, but the last time I tried was only good for a small test.

and I might still need that pawn used only for kills, if you remember that but not right now but soon someday soon.