Hello! I’m currently trying to do a line trace for objects, allowing them to picked up. The branch’s true or false nodes work by themselves, The E keyboard event works, but when put through a gate it doesnt work. Any idea why?
The E keyboard event works, but when
put through a gate it doesnt work.
A gate always works as its job is to be either open or closed. So not letting things through is also OK!
It does not allow the execution chain to proceed because it’s closed when the button goes down. Print that AND condition and see that it’s False. Also, if you never execute anything in that Branch, the Gate will stay closed by default.
Seeing how this is a singular action event, perhaps you do not need a Gate to start with. Consider hooking up E to the Branch instead and execute the desired script on True.
Branch has to be connected to E Event to get fired before the gate
Input is not as easy as it seems, actually; that’d due to Consumption.
Blueprints will compete for input and Consume it in a very specific order and with specific priority. As a general rule of thumb, you should be handling input in as few places as possible:
- player controller
- player pawn
- widgets
Handling input in any other actor is asking for trouble. That’s unless you have special gameplay needs which is more than understandable, of course.
It goes something like this:
If you E in the Level Blueprint and E in the Pawn, the E in the Pawn will not trigger. This consumption can be overridden but it is not recommended unless you require specific functionality.
It may seem tempting at first to enable input on actors but it can open a, ehm, Gate to a little debugging nightmare 
Thank you so much, this works!
As an aside, my E key didnt work for ages until I just deleted some starter content and other stuff until it just worked. Is this a normal occurrence or…?
Yknow, for all the help, I’ll allow that pun. But that makes alot of sense now that I think about it, Although wouldn’t it make more sense to have E run in the level blueprint first, then like a delay of a frame or so for E to run in the pawn?
Thank you!
Not really.
Ideally you make an entire game without ever touching the Level Blueprint in the first place (I know, shocking; using LB is tempting). If there really is unique functionality that goes into that particular level, then that’s OK, I guess. But functionality should be tied to actors, not to the LB.
This way you can make a box and a player that can open it. Ensure the player has the functionality allowing them to operate on the box. You can now drop these objects into levels. But there’s no need for the level to participate in all this.
Although wouldn’t it make more sense
to have E run in the level blueprint
first, then like a delay of a frame or
so for E to run in the pawn
- what if you have 2 levels? Are you going to duplicate all your code twice? What if there’s 30 lvls?
- what if you have more than 1 pawn and each controls differently? A soldier running about is quite different from a plane flying around.
That’s why Pawn possession is a thing. You posses a Pawn, it has its own controls and can even work with what the Player Controller is requesting.
I’ll just add that if you’re creating an interaction system for objects, it might be worth looking into how Interfaces work. In short:
- the player pawn presses the generic E key
- each object implements an interface that allows it to interpret that action
- hitting E on a Bucket, a Tree or a Collectible Item yields a different result
This allows you to implement unique behaviour in the object itself. Behaviour that the player does not need to know about.
- E on a bucket flips it (animation plays in the bucket actor, set
isFlippedbool toTrue) - E on a flipped bucket, equips it
- E on a tree shakes it and makes it drop apples (play shake anim, fire up leaves particles, spawn collectible apples - all done in the tree actor)
- E on a Collectible Item (apple) adds it to the inventory (apple destroys itself)
- E on a Collectible Item if you have a bucket equipped - scoop all overlapping apples in a large radius
This way you do not need to worry about cascading Branches and checking whether the trace == apple string. You hit something with a trace and send it E, the item decides what to do with that action.
Wow. That would be so much easier. Although I’m kind of confused on how to implement it. I have a interaction system interface now, with an apple function. How would I link this to my currently existing system? I.E would I just plug the function directly to E, set the string to the currently traced object and then compare it directly in the apple bp?
Thanks again! I’m sorry to keep bothering you
Enjoy your day
set the string to the currently traced
object and then compare it directly in
the apple bp
Is there a reason you’re doing this? As in, is this a puzzle game with words where you must compare them? String comparison is generally frown upon: deemed unnecessary, prone to errors and very slow to execute; unless you’re chopping and reassembling sentences together that is. Then it’s a must.
have a interaction system interface
now, with an apple function.
Just to be on the same page. We’re talking about this interface, right?
Not really, It’s more of like a survival game, and tracing to see if an object can be picked up. Most of this blueprint is kind of hacked together, seeing if it works.Don’t really know how else to determine the object traced.
Yeah, that type. Although I know its simple, I’m still pretty confused on it, even after looking through the video. Tried looking through the source files they provided but they just lock up while initializing. I have a “interact system” interface. In it, what should I do? Put the trace compare in there, or put a “is berry ready” thing in there or just Booleans and things? And would I access that from the first person character, or the object?
Also, I’m sorry if i’m pestering you, I’m just really confused. Thank you so much for your help!
And would I access that from the first
person character, or the object?
- an interface has a bunch of generic functions that do nothing
- actors with this interface have access to those functions; think new, yet undetermined behaviours & results
- actors can interpret what each function does to determine the result
- when the player interacts with an actor, it calls those generic functions of the interface - and it is the actor’s job to do something with that call
The player does not need to identify actors via casts, string comparison or booleans. The player interacts in a generic fashion with objects around them and it’s the actor’s job to identify itself to the player and act accordingly. The stuff that is important to the player is handled by the player. The stuff that is important to the actor is in the actor.
(I’ll keep posting as I find time between other tasks, the examples will be somewhat crude but stay tuned)
- aBaseInteractiveObject_BIO (BIO for short) is a base class with 3 children (that’s inheritance)
- any variables or components you want children to inherit are in the base
- here, the base class has a Static Mesh (simulating physics), a Text Render and a couple of variables
- each child actor can add their own unique stuff; for example, the BerryBush has 6 additional static meshes
- Handle_BIOs above is the Interface, seen below:
- it has 5 functions, some of which have inputs and / or outputs
- this way we can send data to and get data back from an actor who implements that function
This is the base class:
- it implements the above-mentioned interface
- it also means, that all children have it now and have access to the functions inside
- Above, I’ve implemented the Talk function in the base class
- it’s an Event because this function does not return a value (this is automatic)
- since this is implemented in the Base, all children will do it and show whatever string they were given
- children can still override it if necessary (perhaps there’s 1 object that you do not want to have a voice)
Here’s how the player interacts with the world:
- notice there’s no casting, no comparing of anything
- we just ask to execute the interface function in an actor
- even though only the base class Event Talks, all children mimic that behaviour but use their own MyText variable for that. There’s no script for this in any of the children.
Which looks like this:
And if you ask an actor with no interface to Talk (click the ground, wall, water, etc…), nothing happens. Which is great.
tbc…
Here’s, ehm, a kicker:
The NotApple (and only this one child) actor overrides the Event Kick from the interface its parent implements:
- calling it will boop the actor up with physics
- but it will also change its behaviour; namely, what the actor says from now on
The player doing its thing:
- we Talk first and Kick later
- next time we Talk and Kick, the reaction is different
Interestingly enough, the Berry Bush is utterly unfazed by all this nonsense. It does understand kicking and could do something about it but has yet to implement a reaction.
tbc…
Here’s Apple collection with a bit more interaction:
- apples are slippery and not easy to pick up
- every time we try, the Attempts goes up by 25%
- if we fail to collect, the apple rolls away from the player (bottom bit), we show a message and return a
FalseLocal Success Boolean - if we succeed, we generate the weight of the said fruit, show a different message, and return a
TrueLocal Success Boolean
How it looks from the player’s perspective:
- if collecting resulted in a Success
True, the player accumulates apples in their own variable - the apple gets destroyed (or attached to a hand socket, or placed in the inventory array)
- and we display what we’ve collected so far
- nothing happens if the Success is
False
One note here:
- even though non-Apple children don’t implement this function, the function is still called
- it will return default outputs; in this case it is a
FalseSuccess, so nothing happens here
Harvesting Berry Bushes is next (not sure when, though)
tbc…
So here’s the Berry Bush situation.
It would be nice if the bush could communicate with whoever is picking the berries. So the player also has an Interface now through which they can receive messages from other entities in the world.
- we’ve got 3 functions, adding & removing stuff (not addressed here) and Sort Harvest
(this 2nd interface is not technically necessary but it does demonstrate a more in-depth 2-way communication setup)
The Berry Bush child implements a brand new Harvest function:
- it requires a Harvesting Actor input so the bush knows who is plucking it
- this allows it to call Sort Harvest (green frame) through the player’s Interface mentioned at the very top
- here the berries are static meshes with a tag to identify them easily
- when this actor receives a Harvest request, it checks whether it’s ready, counts the berries and sends call to the Harvesting Actor’s interface, we send the Amount of berries and their Type (perhaps bushes can grow all kind of stuff)
-
Then 1, we hide the berries (to regrow and show them later perhaps) and flag the bush as not Ready For Harvest anymore - the bush will also update its text
- the Begin Play bit at the bottom is a debug thing, we start the game with half the bushes Ready For Harvest (you probably have your own method to re-grow berries)
Here’s the player harvesting stuff from the world:
- the player has a small collision sphere
- after pressing 1, any actor of the specified class caught inside will be asked for its Harvest (see above)
- if the actor does not implement the Harvest function, nothing happens
- the Berry Bush does implement it and if it’s Ready for Harvest it will send the Harvesting Actor the Sort Harvest message, which is implemented like so:
The above is just an example, sorting can be done much better and inventories are another topic altogether.
Project link:
1 Like
My god, dude. You went above and beyond with this. It makes alot of sense now! I think I finally get it.
Only problem is, sometimes some of the interface parts are “not blueprint callable”. Any idea how to fix it?
Besides that, honestly I’d pay for this kind of help. Your a great teacher, atleast to me.
If this project goes anywhere, I’ll let you know!
Enjoy your day!
