Hi there Turdle! I just finished putting something together along the lines of what you’re describing. The trick is to think of your character like an elevator rather than a standard player. You want to be able to press a button and get a single instance of movement done, and then once the movement has happened it should check and see if the button is still being held down to do the move again. Do I have that right?
In my case I only wanted the button press to move the guy one single space, so I use a DoOnce node followed by a Branch to double check that my guy has enough room to move. Here’s what that looks like:
When I went looking for these I knew them by the name “Conditions” or “Conditionals”. I’m thinking you’d want to learn up on these options to be able to do a check that your rotation has finished before you allow your Cube to move again, so here’s the links to the details on them:
The next thing you’re going to need is the ability to check your floor to find out if you have the room to move your cube on. That’s gonna take an array, which is basically a grid (it can be 2D or 3D) of any sort of data. It could be lines of text, or a set of blinking lights, or in your case a set of floor tiles. The array has all of it’s data/objects in an organized group and it can spit out information for how they’re arranged when you ask for it. The trick is knowing how to ask, but once you do there are all sorts of things you can do with them. I say it’s a trick by the way because only certain nodes have the right type of pin to connect to them. I’m including both the page on arrays and on the nodes you can use to talk to them:
Lastly you’re going to need a variable telling your block where it currently is, and you’re going to compare it to your array when it makes a move. That way your Cube will look at it’s current spot, and know it’s supposed to move whatever that number is plus however many spots away in a given direction. Look up again at the script I put together and check out the lower left hand branch of the SetActorPosition node. Follow that all the way to the end and you’ll see the part I just described. Start following it back up the line. The results of that variable and Math Add node will be compared to your array’s grid using a GET node. That combined information is then used to tell a GetActorLocation where it’s supposed to send your cube when you plug it into a SetActorLocation. Ignore that vector XYZ info block between the two. It’s forcing my actor’s Z coordinate back up because his origin is still inside his chest and I don’t know that you’ll have that problem.
Once you’ve moved your cube be sure to update it’s Current Position variable (whatever you end up calling it) so that the next time you try and move it anywhere it’s notion of where it is in space has been updated as well. If you don’t it’ll always think it was where it started and try and move from there again. I have no idea what that would do, but that’s probably not what you want to happen. Always update your variables when you change something in the game!
Depending on how your animation is handles you may or may not want to start looking up how to get your cube to move through space to reach it’s destination. Using the system I have set up your character will teleport wherever he’s supposed to be. Getting it to not do that is my next big adventure and is gonna take stuff like Delta Seconds and Movement Speed. The most important thing though is that with an Array of objects you can not only tell it to know it’s current location, you can also tell it to know what it’s destination is going to be after you set it. You can then tell the object to update it’s visuals during the move and how long the move should take, but those are hurdles for later.
Get your cube rolling man, and good luck!