Why does "move" not work in Arcade?
jb15
Member Posts: 602
When "space" key is down, the ship is supposed to rotate. It does, but it continues to move in the same direction--even though I've selected move behavior to be relative to actor axis.
It works in GS player but not in the Arcade upload:
Comments
//
Hmmm... That's ironic / Deja vu... another arrow-shaped ship in a cave! - I'm intrigued at how your game mechanic is going to evolve compared to mine... https://youtube.com/watch?v=HOJP-p7m0AA
https://youtube.com/watch?v=v0Bv5AehHsI&t=53s
https://youtube.com/watch?v=kYouKEif87c&t=208s
Sounds a bit harsh!
@KevinCross - Sorry! - wasn't meant to be harsh towards the poster, the videos were just to help point out why I did find it ironic, but I'm genuinely intrigued too - ie. the trailing dots, etc - for all I know it's an arena-based/maze game, but I was of course interested to see if it WAS going to be a gravity-based, cavern-themed, shooter like mine, ironic given I'd posted links to my WIP videos in another thread last week...
Maybe, if they've been seen, they've given some inspiration for a different type of game, I don't know, honestly, at this point - and hey, if it is going to be the same type of game, maybe it's just coincidence....
[EDIT] - I re-read about the rotation working, but not the direction... Can you adjust the Player's X/Y velocity to immediately change direction? - (or are you already applying forward velocity once rotated, to create inertia, and that's not working?.... )
There are no physics/gravity, I'm using only the Move behavior (stacked). I don't want physics--it's an arcade game. I've checked/unchecked the attributes you mentioned, to no avail.
I really don't want to use velocity, or any of the physics stuff.
Hmmm... Maybe it IS a bug then - moving relative to the actor should work - could you screengrab the rule(s) and we can take a look?
Died is of course false by default.
Well, it looks okay - i.e. as far as I'm aware MOVE is dynamically affected by adjustments to the rotation attribute etc...
But I notice that you've got it inside a condition, which will only re-fire (to my knowledge) if it changes in between checks (ie. I would have thought in this scenario it would only fire once initially, then once (depending on your 'dead' code order, and even if it does, obviously doing nothing noticable as you reset the scene when you're dead) when you hit the wall / set flag to true? ....try popping the top rule inside a timer, say .1 of a second, just to see if that is the case?
I'll have a play when I get home, and see if a quick test does the same, or a way around it...
You can try using self.rotation instead of zero and relative to scene instead of actor. It should have the same effect.
You can also structure your rules more efficiently by combining them, so it has less code to scan like so:
rule if game died is false
move
rule if space is pressed
rotate
Instead of two seperate rules, that way it only has to check for died is false once instead of twice.
Follow us: Twitter - Website
@jb15 The rotate behavior doesn't seem to function the same way in the Arcade as opposed to native preview, I see what you're referring to.
One method I found that works for the Arcade is using the constrain attribute behavior to change the actors rotation to it's rotation + x.
To get a similar rotation effect to 160 in the rotate behavior, you can constrain the actors rotation to its rotation + 2.667.
@ForumNinja That worked, thanks!
@AlchimiaStudios Sure thing.