Hello all,
I’m coming over from Unity and I’m trying to add the ability for players to carry objects to my game. I created the following setup on one of the blue default cubes in the FirstPersonSample Project:
Additionally I have added a PhysicsHandle to the BP_FirstPersonCharacter. (more Info but most likely irrelevant: I shoot out LineTraces and Invoke an Interact function on them, when the Player hits “E”, this works, as Interact is Invoked on the correct object, and the CarryCrate and DropCrate Events are also correctly triggered)
Now I don’t know why my ChamferCube is not moving to the Players PhysicsHandle component, when the isCarried bool is true.
In most tutorials I was able to find, they have all logic for this on the Player, e.g. when “F” pressed → LineTrace → Grab the Component you hit. This is an undesirable implementation for me, as I will have different Objects that can and cannot be carried when interacted with.
I’d be grateful if I was shown a way to move the ChamferCube to the Players PhysicsHandle when isCarried is true.
Cheers!
Thanks for the input. Having generally carryable objects is not my objective though. I am making an interaction system, where any object can have multiple possible interactions.
An example:
I have a Crate:
It has 4 possible interactions: Carry, Drop, Break, Throw.
Carry & Break is possible by default, not when Carried
Throw & Drop is impossible by default, possible when Carried
The player interacts with “E” and cycles between currently possible Interactions with “F”. So when the player has “Carry” selected and hits “E” the Crate should be carried by the player.
I have looked into my Blueprint and checking if I get a valid Class PhysicsHandle is returning true, but the ChamferCube still stays where it is.
I’d approach it quite differently in order to keep things tight. Do note this is 100% pseduoscript that was never run. It’s more of a logic flow at this point. But it looks as if it could work which I know I say too often.
One thing that could be worked in at this point is mode exclusivity; as in, you cannot switch to throwing mode unless you’ve grabbed something. It’s more of an optimisation I’d tackle once I’ve had the whole thing behaving roughly as desired. It is handled below, though.
the logic flow would revolve around the above-mentioned enumerator and Interface messages firing at the world entities:
In case you’re unfamiliar with interfaces in UE. It’s like a blank function whose implementation is present on the target actor. If there’s none, nothing happens. It’s the target’s job to define what that message means.
I did not set up the physics handle, It seems you’re more after the logic itself at this point.
Thanks for the very thorough reply. It’s certainly another approach for handling carrying objects that allows for more options than just pickup and drop.
But I am already handling the logic for the interactions in a different way, as I don’t want the player to be concerned with the internal state of an interactable.
I have set it up like this for the CrateInteractable currently:
BaseInteractableNew implements the BPI_Interactable interface:
And this is all working as I want, I checked with printing strings on every event, etc. The only part not working is that a Crate should be carried by the player if he has “Carry” selected and invokes “Interact”.
The problem seems to be that I want the carrying to start from the Crate and not the Player and somehow Unreal doesn’t let me
Sorry that you wrote such a thorough reply on the logic, when I really need just the carrying to work.
The problem seems to be that I want the carrying to start from the Crate and not the Player
I personally think it’s the player who should be the instigator and handle its own logic flow. Not the other way around.
Have the item query the player for the status. But then it gets really strange from here on… Or have this part implemented in the player, as in my example - top row.
I find it somewhat awkward like so, I must admit - rubs me the wrong way But it does not mean it couldn’t work, of course. Since you’ll be maintaining it for the foreseeable future, it’s equally important that you have it your way.
Unity
I’ve been reading a lot recently since it’s a hot-topic. Dev atrocities aside, it seems that the general consensus and advice for Unity refugees (the name sticks ) is to not fight the engine. People are trying to re-write movement components and controllers all of a sudden while UE provides fully-blown-over-the-top solutions out of the box that one needs to only alter when pursuing the uncanny.
My advise is: do not fight the engine.
You’ll see this Instigator quite often. The general idea is to have the player controller act as the will of the player while the pawn (or a fancy character) is the puppet that interacts with the world.
It seems like a missed opportunity to give up on this level of control and let the items query the player.
Controller / Pawn asks the item what it is
the item handles the request and does as its told, obediently returns pertinent data
But it does not mean it couldn’t work, of course. Since you’ll be maintaining it for the foreseeable future, it’s equally important that you have it your way.
) is to not fight the engine. People are trying to re-write movement components and controllers all of a sudden while UE provides fully-blown-over-the-top solutions out of the box that one needs to only alter when pursuing the uncanny.