Hey, sorry for taking a while to respond to your request, I just haven't had the time to really get a good reply until now. There's a few things you'll need to do if you want to make the sidescrolling setup like I did, and it does get a bit complicated.
First, you'll need to open your data editor and duplicate one of the actors in the Site Operations (Explicit Rotation) folder (a search for Explicit will find it). This actor has two values you can mess with to get different rotations, Actor - Forward and Actor - Up. You might need to tinker around with the values for a bit to figure out what corresponds where, but the defaults I used to rotate the Reaper to face left and right were "Forward: -1.00, 0.00, 0.00" and "Up: 0.00, 1.00, 0.00" to face Left and "Forward: 1.00, 0.00, 0.00" and "Up: 0.00, 1.00, 0.00" to face Right, and those two should probably cover most of the rotations you will use.
Second, you will need to work with your actual unit actors for a bit. I was pretty sloppy when I did this and you can put a bit more effort in making it orderly if you wish to. To set your newly created rotation actor to your unit actor, you'll need to edit the value "Hosting - Host Site Operations - Operations" and find your rotation actor and add it to the list. The actor will only accept one host site operation, and it's really tricky to get it to switch to a different one (I imagine its probably somewhere in the actor events, if you care to find it) so what I ended up doing is duplicating the unit, creating a "placeholder" unit for a duplicated actor, and gave the second duplicated actor the other site operation. Then, set up an actor event that makes it so when something specific happens (In my case, it was setting the scale of the unit) the current unit's actor is destroyed and the duplicated actor is created. Then whenever I need to reverse the unit's facing, I send the actor message that would trigger this event (By setting the unit's scale to 100% of it's original size, effectively doing nothing). This system is incredibly sloppy, but it does work. If you want to make it more orderly just create a custom ability that you can order your unit to do and have the actor event check to see when that ability is used.
Third, if you've managed to stay with me so far, is to create your game physics through triggers and point updated velocities. Essentially, you'll need to give your unit four variables, an X value and a Y value for the unit's velocity (I have a lot of units affected by the game's gravity, so I used the unit's first two Custom Values as the X and Y), and an X and Y value for the unit's acceleration. In a periodic trigger, create a local point variable with it's initial position set to your unit (If you have a lot of units, then you'll need to use some strategic loops to make sure this point applies to each of them individually each periodic trigger). Then to account for gravity move the point a certain distance downward from its original location. Then account for the current unit's accelerations (For my setup, if one or more of the arrows is pressed, its a constant acceleration in whatever directions are pressed.) and add them to the unit's current velocity. Then add the unit's current X and Y velocities to the point variable, updating its final position. But we aren't done yet...
You'll also need to account for obstacles and other things that may block the unit's movement, as the default response for the unit would be to walk around these obstacles, but we need them to land and move correctly. To do this, we need to set up a velocity "cushion" that constantly checks along a straight line between where the unit actually is and where it is trying to go, and "correcting" itself when the path is blocked. To do this, you'll need a few For Loops and another temporary point variable. The temporary point variable will start positioned where your unit is and for each loop iteration, will move out horizontally a small increment and check its current position to see if it is pathable. If it is, then the loop runs again until it has reached the current unit's X velocity, then another For Loop checks the same thing vertically. If the point is unpathable, then the Unit's original velocity point's x value or y value (depending on the loop) is set to match the temporary checking points x or y value. Finally, the last step is to check the distance between the unit and the unit's velocity point, and if its large enough to warrant movement, then tell the unit to move to that point. The distance check is there so if the unit isn't being told to move anywhere it won't constantly be told to move to the same spot its in.
So yah, take of that what you will, its really difficult to explain correctly. Take a look through the triggers I used to maybe sort of get some idea of what I did a little better. I will say that it is a finicky system, and there is definitely room for improvement, but I'm focusing on getting the rest set up before I revisit this part, so if you would like to take a second crack at it it would really be a good thing. It won't be easy, nothing I can tell you will make it a simple thing to get working, but if you still feel like using it then go ahead.