I’m setting a variable on initiation (based on a switch case), but for some reason that doesn’t seem to be registered first, and looks like when something doesn’t go right, the instance either spawns at 0,0,0 position and doesn’t move, or crashes the engine if it’s really bad logic of sorts. And yes, I have the initiation done and THEN do the switch case, as needed, it’s a Switch on String slot. I have it set up like this:
This obviously doesn’t work, but I cannot have the two SET vectors both attached so that only one works depending on the switch condition I created earlier. But how should I then set this up here instead?
I am trying to set a variable once the instance is created.
After initiation, a switch statement determines wether to set x vector to 20 or -20 from the current position.
The tick event meanwhile should take the variable with the value and move the Actor by the amount set. But it doesn’t.
It does move when I’m connecting one of the Add pins directly to SetActorLocation, but not when I have a get of the variable that I set with the switch statement, but I need to so that the switch statement has impact on the vector variable’s value.
Okay, technically it’s possible that the first (or a few) tick fires faster than all the functions after Begin Play are executed; what I can suggest here is set a gate after Tick and open it when Return Vector is set.
Second, you’re setting Speed Proj to -10 in both cases, I don’t believe that should be that way. Moreover, just for convenience, you can feed both Set Speed Proj nodes into one and the same Set Return Vector node; it’ll work just fine with less nodes in the screen. Provided that you set X to 10 and -10.
Third, why would you use tick there? It will only work once, since every subsequent tick will do absolutely the same, placing the actor at the same point, because you only do the math once at Begin Play, the Return Vector won’t change anymore; if you want you move your actor by 10 units every tick, the math has to be placed after the tick itself.
So what you can do on Begin Play is only determine the sign, and do the rest by tick.
Actor will spawn wherever you gonna spawn it, if you didn’t define it during the spawn it will be 0,0,0. BeginPlay runs always first before the Tick, so actor on first frame is in it’s initial position that it’s being placed before the Tick.
As mention your tick also just gonna set same position over and over again and don’t move, his circuit is right but only missing thing is multiplying Delta X by Delta seconds, without that moment will be frame dependent not time dependent.
Also actor it self dont have any positional data, it’s location is defined by location of root component (in your case DefaultSceneRoot), so if root component is not movable it the entire actor wont be movable.
You can actually skip all that and just use Projectile Movement Component, component that will move actor for you depending on it’s parameters, it a lot more performance friendly then ticking in blueprint as it will be done on C++ side and you dont need to mess blueprint with movement code
Also one node, instead of using String, you could use enum, also more optimal choose as it only one CPU instruction to check enum (which is integer in memory) state then process entire String.
Seems like an additional step I would never have figured out I need to use, but makes sense. Though, the results are still the same and there is neither left or right movement. This is currently my set up, am I wiring something incorrectly here, or do I need something else added? I wasn’t sure whether to wire the float value SETs with vector SETs, but either way it’s the same result. I added a string print to see if the Event is actually firing, and it seems to print, the intended message, so it is running. It seems even setting a default value to the vector doesn’t make them move.
And I noticed AddActorLocalOffset has 3 float values in your example, where as mine, even when it’s the same action module, has one vector one, do you use an older version or? For some reason using SetActorLocation instead I at least have them spawn where I want to, where as with AddActorLocalOffset or AddActorGlobalOffset, they spawn some place else, odd, and it does not have any physics collision set to break position as far as I’m aware.
Every pin that has more than one value in it may be split, just right click it and you’ll see that option. As for movement, @anonymous_user_f5a50610 had set out good points below.
First sentence is what was the issue with my system, I’ve changed some things around and now it works like a charm. Odd that it worked just fine with having everything wired without the switch case before.
I’ll take a look at more complex stuff later, right now I just want to make sure things work the way I intend, too early to think about how to minimise processing.
