For my first person aiming system the collision box is rotating when the player is looking up and down but only on the client side. I have it set so looking around changes the rotation of the mesh which is below the collision in the hierarchy. Does anyone know what could be causing this to only happen on the client side? (Also I had to set this aiming system like this to work with the smooth sync plugin)
1 Like
I dont think rotations are replicated by default. You should likely need to write your own character controller with replication if that is the case.
Control Rotation and Base Aim Rotation are replicated. Base Aim Rotation tends to be the more reliable.
1 Like
Why would this make it so aiming only changes the collision rotation for the client and not the server? If this was due to the base aim on control rotation being replicated wouldn’t it also rotate the capsule for the server player?
Base Aim is more of where is the character camera looking. Control rotation is the capsules rotation.
If you want a component to turn the same direction as the camera then use Base Aim.
What you are looking for is Aim Offset using an Aim Space.
You’ll use Base Aim Rotation for Pitch and Yaw.
your input actions are likely only being consumed by the client. The server doesn’t know about them so only your local client is updating your box. If you want the server and other clients to know about your box’s position, you need to RPC it to the server, then the server can set those replicated values and either multicast to the other clients or use a RepNotify or similar for other clients to update accordingly
Thank you this will help with setting the legs and arm animations for looking in different directions however. I am still not seeing how it will fix the collision box rotating. Right now I don’t mind the character mesh rotating as it makes sense that it is rotating now with how I have my hierarchy set up. But the mesh is parented to the collision box not the other way around. Rotating the mesh shouldn’t rotate the collision box. I have it set up so moving the mouse sets the relative rotation of just the mesh.
I am still confused as the problem isn’t there is something that I want replicated thats not replicated its that something is changing that isnt meant to change. The X,Y changes in the aim rotates the mesh of the character (Which has the camera as a child), however the collision box is not a child of the mesh and shouldn’t ever be rotating. Even if the client wasn’t updating to the server wouldn’t that mean when the client looks around the mesh would only be rotating on the client side and not the server, which is not what is happening?
No, like Rev explained above, the animations can be forced to replicate.
You are asking specifically about collision - on the default character that is a capsule - just what you expect to get from rotating what is essentially a cylinder?
Going back to the original post:
And my response:
The character capsule isn’t really built to move in a “space” like omnidirectional environment. You can force it to, but you are better off in just creating a custom player controller that replicates exactly what you need (and has it available to animations or whatever else).
The character movement component is actually locked in/hard coded, so it’s not even viable to create long things with - say a shark or a horse for instance - and often needs to be overhauled when working.
Not sure if “Control Rotation” like suggested by Rev is going to help in your case either.
RE:
Not sure, but Don’t think so because rotating a capsule is a “moo” point of sorts. You only care about it if your character is lying horizontally or something.
Anyway
You should describe in more detail what you are trying to achieve, or this isn’t going to get you anywhere…
may also be worth checking out if there is any plug in you can get that offers better Replication Ready “space” or 0G controllers?
Op is applying Roll (X) on the primary sk mesh. More than likely he’s applying Roll (X) on the capsule elsewhere in code…tick maybe. That’s a 100% no no with CMC. Even a prone / flying state doesn’t roll the capsule. it just scales it to a sphere (half height, radius etc). CMC’s capsule component has to stay in an upright rotation for it to work correctly.
Op just needs to use Aim offsets. If he want’s to go procedural, then he jumps into your world and uses control rig, bone modify etc.
@Muji17 Any Rotation you apply to the Arms mesh will be applied to its child components via hierarchy dependence. Character mesh, camera boom etc
I am not rotating the capsule anywhere in the code, I found that it is being caused by an addon I am using called smooth sync, you set it on a component and it will interpolate the replication on the server side making things look less jittery. I only attached it to the mesh that is a child of the collision but it is also affecting the collision. I am trying to ask people in the addons fourms for help. And as for the mesh rotating I am fine with that for now after I fix the collision component I will use the aim offset for handline the animations, thank you for informing me of that
Right now I am only focused on the collision box rotating. I am rotating the mesh, which is a child of the collision capsule, but it is rotating the parent collision when the clients aim. I have found that this is happening due to the Smooth Sync Addon I am using. I am asking in forums for that addon, how to solve this.
As for the custom controller I am pretty inexperienced with blueprints right now and just wanted to make a simple game, I am not sure if I would be able to set it up right. But for a game like this, you are just shooting the ground beneath people to make them fall, I would think the prebuilt controller should be able to handle this? In general should you always just try to make a custom controller for things?
In general the first thing you should do is create a new class for every major class in your game.
Your Game modes “classes” are a minimum.
Super technical, the base project should start out as a C++ project. Then create your parent classes as C++, then create a BP from them.
1 Like
First- collision is probably moving due to root motion or the root bone being rotated - the capsule usually follows that.
Second, not sure you need to worry about rotating the capsule at all.
For what you say you want, there seems to be no need to.
You just need to make sure the animations and aiming is correctly replicated…
Okay there was a misunderstanding from my part I already did that for the game mode classes and and was using a custom player controller class. When he said to create my own controller I don’t know why I took that as him saying write my own Player controller from scratch, as in not using the controller parent class when making the blueprint but creating it yourself with C++.
As for the second part I did not do that from the start, what is the benefit of starting the project as C++ if you are using Blueprints exclusively?
I think there is still a misunderstanding here I don’t care for now about the mesh I haven’t implemented it properly yet or even set up the rig properly, I am focused on the collsion box for now.
I want to stop the collision box from rotating as the game also has a projectile you can shoot at people to push them but it is very hard to hit someone when they look up or down as their collision box becomes flatter and smaller vertically
When you go to publish you need to build from source.
If you’re doing multiplayer, or wanting sell on Steam/EGS etc you need to integrate C++ implementations. Can’t do any of that with BP.
More control and access to the classes you create. C++ does a lot more than BP.
Overall it’s just good practice.
I see thank you I will do the C++ implementation from now on
Im unaware of anything anywhere in the default character or pawn that changes the collision sphere except for the proper functions (like to crouch).
If i had to guess, this is something you hooked in by miatake - but it could also be either an engine bug or a new feature im not aware of…