so i have a long standing project that is client/server. that part is going well, where the user connects and users can see each other moving around in the “world”.
the issue i’m having involves updating the “foreign characters” with their rotation. updating location seems to work fine via BetterCharacterControl.warp(), and they appear to be moving around fine. but when a given player turns (rotates), it works fine in their perspective (the camera pans while they spin in place around the Y-axis through their avatar center). but when the new direction vector comes to the remote players, and their client executes BetterCharacterControl.setViewDirection(), instead of pivoting around their center, they revolve around some external point.
as an assistance, i turned on the debug mode for BCC, and that appeared to show that their bounding shapes were not centered on the character avatar (the off the shelf ninja from the test-data). interestingly enough, the point of rotation (revolution) was somewhere between where the character is located and where the bounding shape appears to be located. i captured this in a short video:
Curious, is there a reason you are using a full-up physics control on a client that is neither running physics on them or controlling them?
Generally, in a networked game, if BetterCharacterControl existed at all then it would only be on the back-end. Clients are just putting things where the server tells them.
it’s not a “game” per se, so i don’t have to have all the “server prevents cheating”. the server is just an event hub so the clients can communicate without having to go the peer-to-peer model.
TCP or UDP? Or are you using some network sync library like SimEthereal? (Edit: I guess not because then you’d have a server.)
Edit2: Though you use the word “server” above. Is it true peer-to-peer or is one peer acting as the server? Even in peer-to-peer there is often the concept of a “back end”, ie: “the game objects” of which the visualization is just a “client”.
JME encourages (super incorrectly, in my opinion…I’m willing to die on this hill) Spatials to be “game objects”. There are many benefits to having separate game objects and just letting the Spatials visualize that.
In peer-to-peer, either no one is authoritative and everyone keeps track of their own “game state”/“back end”… of which the client is still a visualization… or one peer is authoritative and they all sync to it.
Just throwing messages around with no actual ‘state’ seems easier but will ultimately require man-years of work to be satisfying… and if it’s all done with TCP, there is likely lots of other future fun.
The above approaches won’t necessarily solve your current immediate issue… but will probably solve the next dozen issues.
Sounds like it’s interacting badly with another app state and by changing where it is initialised you are changing where in the order it gets updated (now either earlier or later with respect to other app states)