I’m hoping someone has an idea for whats going on here.
I’ve got a camera component in my shootergame-derived codebase. I’ve set its relativelocation value to set where its being displayed. Only it doesn’t actually get set at the location I set. Instead it gets set at that location which is then offset by the half height of the character capsule (as far as I can tell anyway).
So my question is this. Why is the camera component relative location being changed? If I set a value on it, I kind of expect it to stay at that value you know? So what gives?
I’m pretty certain there’s going to be some dumb variable somewhere that will disable this behavior. But it really is beginning to annoy me how often there are dumb little variables everywhere to switch on/off relatively random behaviors that are built into ancestor classes. You know what I mean?
Can you share some code / blueprints? Maybe you attached the camera to the wrong component, maybe a spring arm is involved…
Welcome to imperative programming. I know exactly what you mean. Do you know Haskell? I urge you to learn it and maybe sometime in the future we can have a functional game engine.
Hehe… I’m not sure functional programming is the issue here. I think its just a by product of old school inheritance based engine design. The main gripe being that someone can have a variable effect major behavior in an ancestor class buried somewhere deep in the inheritance tree and its almost impossible to debug because those things are obscured by the inheritance itself.
InterpCameraOffset = FVector(0.f, 0.f, 160.f);
TargetCameraOffset = FVector(0.f, 0.f, 160.f);
CurrentCameraOffset = FVector(0.f, 0.f, 160.f);
Camera = ObjectInitializer.CreateDefaultSubobject<UCameraComponent>(this, TEXT("Camera"));
Camera->AttachTo(GetCapsuleComponent());
Camera->SetRelativeLocation(InterpCameraOffset);
Camera->bUsePawnControlRotation = true; // the arm is already doing the rotation
Camera->FieldOfView = 90.f;
The camera IS attached to a spring arm when it goes third person. But in first person its attached to the capsule theoretically at the given offset vector. Only that gets modified by some code (not mine), by the capsule half height somewhere. I’m just not sure where that modification is taking place, or why. I’m assuming its some conditional behavior someone at Epic needed at some point that is buried within the hierarchy of classes, but I’m ill and tired of trying to find these things so I’m hoping someone will take pity and already have seen it.
Thinking about it, I just realized what it is. When you attach the camera to the capsule. Its attaching it to the middle of the capsule, not at the base of it. So an attachment of 160 in the Z is actually capsule middle + 160 relative to the bottom of the capsule. So instead of attaching to the capsule, I need to attach to the mesh instead (as the camera arm does).
The code is not sufficient to help you. We need the whole component setup etc. Would you mind making a minimal working example?
How did you test the relative location? You are not mistaking the relative location with the absolute location?
The hierachy in this case is three levels deep (Character -> Pawn -> Actor). The problem is not deep hierarchy but that everyone can modify the state. (CameraManager, CharacterMovementComponent, SpringArm, …)
Managed to fix it now thanks. As I mentioned above, I needed to attach it to the mesh and not the capsule (because the capsules origin is in the center of the capsule and not at the bottom). I still think my comment about hierarchy is correct though. The chain was actually camera component->scenecomponent->actorcomponent which relies on character->pawn->actor->whatever else underneath. But you’re right in that its mainly the fact that almost anything in the camera chain can modify the state. As it is, the problem was more with the attachment rather than the camera per-se but I still balk at the whole convoluted camera chain. Surely there has to be a better way of architecting that kind of thing?