Upside down
OK I've looked through the forums and I've seen questions close to this but not this specific one.
I have a button on the bottom left that when clicked, spawns actors at the top of the screen. They span off the screen on the left or right side randomly and then slide in screen across to the opposite side.
So when the actor spawns on the left and moves to the right... it's good. But when it spawns on the right and moves to the left, the actor is upside down. I can't figure out how to fix this. I've tried rotate to angle, and some other things but nothing has worked so far.
Any ideas?
Thanks.
I have a button on the bottom left that when clicked, spawns actors at the top of the screen. They span off the screen on the left or right side randomly and then slide in screen across to the opposite side.
So when the actor spawns on the left and moves to the right... it's good. But when it spawns on the right and moves to the left, the actor is upside down. I can't figure out how to fix this. I've tried rotate to angle, and some other things but nothing has worked so far.
Any ideas?
Thanks.
Best Answer
-
Socks London, UK.Posts: 12,822
I'm not trying to start an argument. I'm just saying one should be efficient. If you are trying to argue with that... hmmm.
Life's always good when you get to write your own reviews.
Like I say, if you feel the suggestions are overly complex I wouldn't give up on your turning an actor upside down as a way of changing direction, you just need to work out a way of turning the upside down actor's image back the right way - I've given you a suggestion in my post above.I tried your idea "1024 minus self position". Although it makes sense, it dosen't seem to work, at least not in this situation.
It should work fine, you've probably not implemented it properly, if you post your rules I'll take a look at where you might be going wrong.
Answers
This is not aimed at you per se, you get so many questions framed in this way - and they simply defy logic from what I can see - they may as well read: 'I have created some rules that produce a certain result, you don't get to see these rules, but I will describe the result and then ask you to guess what the rules are and then ask you to suggest a solution'.
Or put another way:
Hey, I've just done a calculation and I keep getting 17 as the result but I was expecting 12, anyone know why ?
[/Rant Over]
8-X
You are absolutely right. I don't know why I didn't think of that.
OK so here are the rules I am using:
I have a few custom attributes:
cloudNum: integer 0
randDirection: integer 0
On the button instance:
*Actor receives touch is pressed and cloudNum < 3
*Change attribute randDirection to random(1,6)
*When attribute randDirection < 5
*Spawn actor:direction 0, relative to scene, position -35x 295y relative to scene
Otherwise
* Spawn actor:direction 180, relative to scene, position 580x 295y relative to scene
*Change Attribute cloudNum to cloudNum+1
On the actor prototype:
Change Velocity: direction 0, relative to actor, speed 30
So... any ideas?
Great! I'll take a look in a bit, not at my computer right now (on iPad).
Basically you are turning the spawned actor upside down.
Try this:
Spawn actor:direction 0, relative to scene, position 580x 295y relative to scene . . .
Yes I know it's turning it upside down. But if spawn an actor off screen on the right, and the direction is set to 0 (facing the right), then it never comes on stage.
So how would I spawn an actor on the right and have it move to the left with out flipping it?
Direction, should be just that, direction; not the orientation of the actor.
Hi @belotte
To clarify even more what @Socks said, and what's been discussed so far:
You're correct in saying that the direction value in a Spawn Actor behaviour is the orientation of the actor - the rotation direction - and not the movement direction. (Perhaps it should be relabelled, but its always been that, so I guess as long as you know what it does, its OK...)
Anyhow, so as not to rotate the spawned actor, just keep it to 0 as has been said. And to affect the direction of the spawned actor, use the Direction in your Change velocity Behaviour which does affect the actual direction - as an attribute if you wanted - where 0 is right, 180 left, 270 down and 90 up (as you know).
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
The problem with that is I have the prototype with a generic speed of 30 with no direction other than along the x axis.
what I wanted to do was have one proto type with the base speed and no direction. Then one rule that would either spawn the actor randomly on either the left or the right, and go in the proper direction based on that. The way you are suggesting mean I have to have 2 prototypes, one for each direction. This increases coding, complexity, and file size. That's not good.
By the way, I didn't suggest having two prototypes, although that's one way to do it, but it seems that way would upset you to do.
Why not use a boolean or even an integer "switch" with two sets of rules in your one prototype actor's rules that's to be spawned; one for moving it left to right, one for right to left.
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Increase in complexity ? . . . . I'm guessing that extra actor will make your project an impenetrable mystery.
Increase in file size ? . . . . one extra actor uses up a few kilobytes.
But you can avoid this unbearable workload 8-X by having your actors (all of them, regardless of where the are spawned) share a common move, I wouldn't tie yourself to the idea that actors are like wind up toys and only move in one direction regardless of where they are placed (the corollary being a need to turn them upside down to get them to move in the opposite direction).
For example (on a landscape iPad) a single common rule that interpolates an actor's position to [1024 minus self position] would see actors spawned at 0 move right to 1024 (1024 - 0 = 1024) . . . and actors spawned at 1024 move left to 0 (1024 - 1024 = 0).
Well Socks. That last trick may be the one, I'll have to try it.
In regards to the excess code, etc complaints... I've worked in the IT market for over 17 years. One should always strive for clean and simple code. On one actor maybe not a big deal... but if the only solution is a complicated one, and it has to be done multiple times... then you start to have problems.
But if you feel these suggestions are overly complicated then I'd carry on with the idea of the actor having a fixed unidirectional movement and flipping it over as your preferred method of changing direction (the wind up toy approach) - you just need to work out a way of flipping its image - you might be able to unlock the actor in the scene and flip its image in graphics.attributes?.
[EDIT - just checked, yes you can unlock the actor in the scene and use flip horizontal and flip vertical to correct the orientation of the rotated actor, maybe this is a happy compromise as it allows you to avoid any complicated coding]
In any even. I tried your idea "1024 minus self position". Although it makes sense, it dosen't seem to work, at least not in this situation.
Sincerely though, thank you for the ideas though! It's good to get a diffrent view on things.
*Interpolate
*From self.Position.X to 580- self.Position.X
Duration: 30, Function: Linear
I tried this with "move" and "move to" as well.
I actually had created a "switch" of sorts. I used random (1,6).
if < 5 go left otherwise go right.
But that's the rule that's not working.
Hi @belotte I've done a little test, hopefully it'll be helpful for you. (Replace the change velocity behaviours with interpolate behaviours, if you want):
https://dl.dropbox.com/u/14060718/Rand spawn LorR.gameproj.zip
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Link: http://www.mediafire.com/?c6ga9aogjagpmfr
Well Socks and gyroscope... thanks for all your help. I am retarded though, I cant get either solution to work for me for some reason.
In any event, thank you. You guys have been very gracious in your efforts.