i just wonder where your blueprint is executed. I would just cut out all the other stuff and take the location transform directly to either the current ciphers or a copy of them, right when they’re colliding.
Those which have collided with the needle should apply the moving animation directly, so there can be a little randomness when it hits 2 or 4 cyphers.( It’s okay to have up to 4 cyphers moving.)
Well, It’s very obvious. I need the specific movement code that makes the letters move upward. Just the movement. So I can attach this movement after a simple Overlap-Event when the 3 arrows overlap with my ciphers.
Every cipher has a collision box. When it get hit by one of these three arrows sticking down, it will cause the affected cyphers to shoot up as shown before
Have to go again now, but I’m thinking about a vector from their starting position to the top of the circle. You can calculate a point on that vector over time and change the actors position based on this. Also, no doubt using a time line.
You have vector start and end points and you can calculate % along the vector given how far down the time line you are…
Requesting this in an example Blueprint… i fell asleep… otherwise I need to invest weeks, if not months, into learning all the math functions - but the clock could be finished through last step step today or tomorrow…
I think it’s the most practicable to place a destination point above the ring… this is the location we can specify where the letters move to.
Okay, here’s a little beginning, but it is far from correct with a few wacky nodes.
The problem is that this feature is rotating with the circle and I still can’t figure out how to make a Destination Point Mesh the target location. We’re almost there in its basics.
That’s why I had the 3 words that would travel up copy their text, and not be attached to the circle
Ah, and forget what I said about vectors and timelines there. You can just use the tick and a vinterp to move the words from where they are to the destination point, just like we did with the finterp above. ( vinterp is just a vector version of finterp ).
So I added this code to the component that moves upwards, basically it’s always trying to get to the top point on tick. It’s coordinates get reset by the transform ( in the 2 part BP I showed you further up ):
Where this says ‘Text’ initially is the component resting at it’s target. When I press O, it assumes the position of one of the other words on the wheel ( 2 part BP above ) and then the tick code here moves it back to the target spot, because that’s what it’s always trying to do, move to the target:
Alright! If the cipher movement is a bit random, which I can see, then it’s perfect!
As a side note i wanted to leave my funny other logic here. It’s as minimalist as it could get, but i might discard it if your example works. Gonna define “Up1” and highpoint locator now, which confused me a bit. Don’t they rotate with the ring?! It caused me worries.
Only the components that should rotate with the wheel should be connected to the wheel.
My Up1 component is a text component that gets a copy of the text from the one on the wheel ( which in turn is made blank ), it moves to the target point, which I called HighpointLocator.
Now I need to make exact sized replicas of the ciphers as “Up1”, correct? … hmmm…mind breaker…I might duplicate all of them and change the child actor to a duplicated cipher Blueprint…
Okay that might be a fast one. To make sure, i should duplicate all the ciphers and set them to FlyingCipher child actors (a duplicated Blueprint of the original one). They will shoot out. What happens to the original ones?
