When I pick up a sword, the boolean is right hand busy is set to true, but it does not prevent me from picking up another object. I can continue picking up stuff into my right hand socket for some reason (i.e. i can proceed to the switch node).
Why?
Because you have check inside your intractable, not your character. That means every intractable have their own bool that has nothing to do with the right hand of your character.
1 Like
But it should have the same effect right? If the attach actor to component happens, then the bool is set to true, and then we should not be able to continue to the switch, and hence we could not execute another attach actor to component?
Well clearly my logic is wrong because it does not work. Could you specify how would I have to do it?
Not only this, but I’d actually question the location of this script. We sure this whole thing should be in every item in the game rather than only once in the character that is supposed do the picking up thing? That’s what we’re doing, right? We are picking this item up?
But it should have the same effect right?
No, you never ask the character whether their hands are full. You’re asking the item itself. And each item has its own bool. This bool should be in the char.
1 Like
This master blueprint serves as a parent to all the interactable items, so I do not see what is wrong with having the script here, could you explain the problem of this method?
Also, now I understand what you mean with each item has its bool, ofc they inherit from this.
Also, maybe having all this logic inherited by each child (item) is unnecessary code since a child only needs the code that applies to her type, not all the code for all types of items. I guess composition makes more sense? Although I still have to manage to make that work…
For me it’s a red flag because the item is allowed to modify the character. Would this make sense in your case:
The player attempts to pick up the item 
, the item tells the player what it is 
If you wanted to use your method (it’s your game), perhaps it’d be enough to pipe in the player’s data into the interface message - you are already doing it with the mesh:
So the items know if the player can handle them:
But then you’d need to set the character’s bool somehow.
1 Like
It does make sense. Since the function that you have pick me up will be used in all the items that can be picked up, do you think it should be a component added to each item (child of actor) or should this be a function implemented in a master component from which each item inherits?
Also, do you think that my switch on type is the correct way to mount this system?
Right now the character BP looks like this:
Line trace while holding “E”, if the hit actor implements BPI Interact then request info (the interface is in the previous screenshot in the master BP). The we get the info that sets the struct with variables name, type, actor ref.
Upon releasing E, execute the pick up logic (ignore the is weapon unsheathed branch). If the reference to the object is valid, depending on the type add the object to the array “current object” if there is not one already.
I know this is messy, maybe you know of a better way to do an interact system that allows for many types of interactables?
edit: this sytem prevents picking up two obects of the same type, but not other objects of other types that share same socket. I guess I could add a AND bool to the types of weapons that are supposed to share socket in the branches after the switch on type.
I think your system creates unnecessary steps, that overcomplicates your code.
You already have a neat enum for weapon types ==> use it in your map. This way you do not need to switch, and do not need to risk mistyping strings:
1 Like
Seconded. Things will be only getting more and more convoluted.
I agree with both of you, but I’m having trouble ideating a method that allows me to carry out different logic upon interaction, for example pick up weapons, open doors, place things in inventory if they are miscellaneous. I’m trying the one you said before in your second answer.
Considering that each weapon will have stats, should I be using enums and switch by type? Or it does not matter for this interact logic and I should only differenciate the socket that it gets attached to (or inventory)?
You’re using inheritance. You have a master item. You’re on the right track. Override the interface function for items that need to behave differently.
for example pick up weapons, open doors, place things in inventory if they are miscellaneous.
- you have a master item which can dictate default behaviour:
- you have a vase that is pickable but breakable; it also can, optionally, respect default behaviour and add its own:
- and you have a door that is not pickable, but plays a timeline only it knows about:
The player just fires the same message at them:
The items choose how to respond to it.
Also, a long post that goes into lots of details:
1 Like