and here is the variable in a different blueprint (I had to untick context sensitive to get this to show, which is probably an indicator that i’m going about this the wrong way)
Yep, when the context sensitivity option is ticked, it shows all the possible nodes you can attach to a pin (when you drag a pin out and release it on an empty space) and all the possible nodes you can use inside a given blueprint class (when you right click on an empty space)
To access a variable from another blueprint, you’d need to use the Cast To node. Simply right click on an empty space, type in “cast to”, and then type in the name of the blueprint that you wanna cast to. Once you have it, you can drag any variable that was created in that blueprint by dragging out it’s blue output pin (which should be named something like As Example_BP) and releasing it on an empty space. Then a menu should pop up where you can type in the name of the variable you wanna get, and click on it. Now, the Cast To node also has an input pin named “Object”, and what you should plug in there depends on what you’re casting to. For example, if you’re casting to the player character’s blueprint, you’d need to plug in the Get Player Pawn node in there. If you’re unsure of what to plug in there, you can just use the Get All Actors of Class node. Get that node, select the same blueprint that the Cast To node is set to from the dropdown menu under the purple Actor Class pin of the Get All Actors of Class node, then drag out the blue Out Actors pin of that node, release it on an empty space, search for the Get node, get it, and leave it’s index as 0. After that, you can plug in the Get node’s output pin into the Object pin of your Cast To node.
I’d strongly mildly recommend staying away from the Get (All) Actor of Class nodes, at least for now. While useful, abusing them or using them incorrectly leads to development of some bad coding practices.
I also don’t recommend it btw, just mentioned that since it’s currently unknown which blueprint class OP is trying to cast to. You’re right though that’s probably the case, that was also my guess.
I bet it’s just the player BP - the controlled character - but who knows. I have now edited my post to be less definitive ;p
here is the variable in a different blueprint
@TARS_Endurance Whenever you get issues with BP comms, do tell which BP communicates with which one, where they are and so on. Consider including why this needs to happen or what the scenario is. Often there are neater solutions that do not require hard casting like that. And you’ll get a straight answer rather than us trying to stumble in the dark .
thanks @Everynone@VisAgilis for your replies! It was my first post, and in the time it took for the post to get approved, I not only worked it out but ended up changing my requirements!
Perhaps you can answer this next (I assume) simple problem. I’ll try to give more detail as you suggested.
I have a third person camera line trace to the centre of my screen for a fixed crosshair (called Dynamic Crosshair because it changes size).
I have a line trace running from the gun to the centre of the screen for a non-static crosshair that will show the player that their bullet will be blocked by an object in front of them like so (a crossair will go where the green hit box it)
The bullet lline trace input for the end point takes the hit point from the non-static crosshair, then adds a clamped random range based on the character’s speed and stance to adjust acuracy.
Everything works exactly as planned except one thing. The random range affects all three axis, meaning sometimes the line trace falls short of the intended hit marker. (it moves the bullet slightly left, right, up, down, but also forward - not an issue - and back. This is in the picture below
I need to increase the distance of the line trace without affecting any other direction, and I can’t for the life of me work out how.
The start point it the bullet. The end point it the crosshair hitbox + random number multiplier and the random sometimes makes the numbers too a shorter distance.
Normalise the Make Vector in the 3rd pic and multiply it by a fixed (int or float) value, then add the other coordinate as you already do. You have the nodes sitting there already, it seems, twiddling their thumbs.
And here’s an alternative to making direction with some randomised offset:
.
