Fair point but as the server i move, it replicates fine, so things running on the server should auto replicate, i figured that the same mechanics would work for the client?
the client sends to the server, the server moves, it replicates down, same as the servers pawn did, is that not how it works?
^^ This ^^ is the stuff of nightmares (Pawn versus CMC)… What you’re doing @Saragan is calling out to the Server to do the movement, but since the Server isn’t actually the one receiving the inputs directly, it doesn’t have enough info to work. You’re RPC’ing all this on Tick as well, which may not end well. Three suggestions to try… But overall, I recommend reading posts by the @TheJamsh on CMC vs Pawn ‘movement replication’ as they’re super helpful.
Queue up events on the Client using Add-Movement-Input plus the Consume-Movement-Input-Vector node, and then send that info to the Server as a parameter. Outside of LAN, this probably won’t work well though (movement won’t be smooth). You’ll likely notice a severe lag between client / server in real world practice as it takes too long to replicate everything round-trip. Replicates-Movement isn’t suitable for client movement (its better for actors on the server).
Explore independent Client movement, and have that corrected / verified by the Server to avoid cheating. To start Untick ‘Replicates Movement’ and just do the movement separately Authority / Remote. Then the ship will move smoothly on both Client and Server. But you will need to add code to correct the client periodically if they differ (if the ship uses a lot of physics it will be essential).
What else… You could try using the CMC and see how that goes. Swap out the Character-Mesh for your spaceship, and add Floating Pawn Movement or disable gravity. Then switch out the capsule for some other collision. That may help smooth the movement and offer client-side prediction. But it may also lead to other problems too (unreliable collision detection).
Thanks @Rev0verDrive that sounds fair, assumed the server side was more magical seems i was wrong.
@EntrpriseCustomr Thanks for the details options, @TheJamsh has helped before on a different topic very knowledgeable, will find the post you are talking about.
as for the options, being a space game movement needs to be as fluid as possible across network so id imagine number 1 is out,
i will start will trying number 3 as that’s the quickest and easiest option to try out, if that works, i will see how it goes.
My ship i have rigged to have moving parts so its already a skeletal mesh, so should be straight forward to set up (except for the collision as you say, may have to play with that a bit)
if that cant work, then number 2/Pawn 'movement replication may be the final solution.
will have a play today and see what i can get working and get back to you with the results
Thanks guys, that was a big help clearing up a misunderstanding on replication
Ok so the character bp worked fine straight away infact, no need to even run on server, all replicated straight away,
quite straight forward but its annoying i cannot re-parent the collision mesh or anything on it, so might spend some time investigating the code for ACharacter and seeing what they do for their replication and doing a basic copy and seeing if i can get the same performance out of the pawn.
when im done ill post my findings here for reuse (it will be c++ but at least others might benifit from it
Yeah CMC’s Capsule collision component is the only collision that can actively “block”. All other collisions added to the class will only generate overlap events. You can use collision overlaps to disable input (pitch/yaw), but it’s a lot of work.
Yeah the Character Movement Component hides the very complicated network prediction/reconciliation away. It’s quite difficult to extend (requires C++ and a lot of prior knowledge of how the system works) - but this will get easier in the future.
Epic is working on a Network Prediction plugin that has very promising results already, but there is no ETA on when it might be considered production-ready and a lot of fundamental code is changing often, but there is IMO enough to get started if you’re feeling brave. Natuurally due to the inherent complexity of network movement, this is all C+±only for now.
Note, if you don’t need prediction or aren’t too worried about hacking/exploits for the time being - you can opt for a client-auth approach that simply sends your latest transform info to the Server, and have the local player ignore replicated movement.
i currently found a tutorial that extends the pawn movement component and sort of copies in the character movement replication prediction stuff (with changes), however i needed to use the floating movement component, so im applying the same process but using that as its base and see if i can getting it working, i have done c++ for about 15-20 years so not too worried about getting my hands dirty on this one, its just understanding the flow for the predictions, I am almost there, 1 issue atm that when the client connects it shoots off in reverse not sure whats happening there but will figure it out, assume i havent set an initial position and its correcting it to somewhere insane
Very interesting on the network prediction plugin, would be very interested in that do you know where i could find it unless its not freely available?
I did think about forwarding on the transform from client to server and back down utilizing repnotify, but i figured i would give this other one a go first as its early enough in the project will let you know how i get on and will share the tutorial and the code i did from it here if i get it working if i cant get it working the way i like i may just temporarily do as you suggest and let it be hack-able for the time being