Stop change attribute from moving around a collision object
jsorr2
Member Posts: 279
My actor is 32x32 and my collision object is 32x32. My actor moves forward by this rule:
"timer every 0.2 seconds - change attribute self.position.y to self.position.y+32".
Also another rule inside the collision object, "if collision object overlaps/collides with actor, collide actor."
The logic implies the actor would collide with the collision object head on and not move, but instead if moves forward and to the left or right of the collision object. Is there anyway to stop this from happening?
Best Answer
-
Socks London, UK.Posts: 12,822
@jsorr2 said:
Socks If I allowed players to spawn actors into my game, I would need 4 different detectors (up/down/left/right) that restricted movement all around the spawned actor?I don't know, I've not given it any thought, at the very most you would need 4 actors, but you might be able to do all four sides with just one.
Answers
. . . . that's a bit of weird rule !? If I understand it correctly you are saying that the objects should only collide if they are in collision ?
As far as I can see you don't need the rule at all, you just need to use a simple collide behaviour . . . ?
Are the collision shapes both rectangular ?
@Socks
haha thanks for that, putting collision in a collision rule is actually retarded.
Both actors are 32x32, rectangle collision shape, alligned to move directly into each other, and have 0 bounciness.
as you can see below, if I move left, it moves into the collide actor, and then bounces downwards (bounce is set to 0 on everything) and ends up being underneath the collide actor. How can I make it bounce back into its original position?
When you say it then 'bounces' downwards, what does this 'bounce' action look like ?
@Socks If I press left, it looks like the actor moves into the collision object (i'll call it Wall), and then moves downwards. exactly like the picture. Its very fast though, considering i'm changing attribute every 0.2 seconds while left is true.
Does it matter if the Wall has movable to false, and the character actor has movable to true?
I see, doesn't really look like a 'bounce', it simply moves to the new position as far as I can see, so no use adjusting 'bounce' settings ?
When you press left, where should the actor move ?
No, it shouldn't effect how collisions work.
@Socks I want it to move into the rock, see if it collides, if it does, then move back to where it was. I dont want to move into the rock, realise its collided, then move into a random location next to the rock. As per the video, when i'm inside the 3 rocks and press RIGHT, It should move into the rock, then move back to where it was.
Sorry for so many questions ! But I'm not fully understanding (need more coffee!!) In what way does it move 'into' the rock - all these terms like move into something and bounce are confusing me a little as I can't see anything bouncing and actors can't move 'into' other actors ?
Well, I'm not sure what moving into a rock would look like, but whatever that means you aren't going to get an actor to > move to a new position > do something (whatever it is) > and then move back to the original position all with a simple change position +32 pixels rule !?
Unless I'm misunderstanding all this ?
For example, do you have a rule that tells the actor to move back to the original position once it has moved 'into' the rock ?
@Socks
My actor move rule:
If up is true
Timer (every 0.25 seconds)
change attribute self position -to- self position +32
so my thinking is, it changes its position +32 into a rock, realises it has to collide with the actor, and then 'bounces' into a new position.
That was what was confusing me. How do I construct the logic for the rule to tell the actor, if it moves forward AND THEN collides, to move back to original position?
I see, it's kind of your interpretation of what is going on !? I think you'd be better off sticking with standard GS terms, or at least with a straightforward description of what you see. If an object is set to collide with something then it cannot occupy the same space, so your actor cannot move 'into' the rock, it also doesn't 'realise' anything (you're anthropomorphising your actors !
They're just co-ordinates and colour !), nor does it bounce, it just moves, that's all it does.
If it is set to collide with something directly in front of it then it cannot move forward.
@Socks
As you can see, it moves into the gap between the two rocks when up is pressed (true).
ugh, how can I make my movement actor not move in between the rock. the behaviour MOVE TO works perfect with collision, but if its speed is over 150 it bugs out.
I like the graphics, looks nice !
@Socks Thanks
is there anyway though to not allow my character to go in between the rocks? The whole area of each rock is 4 collision walls, and the movement actor shouldnt be allowed to change its attribute to exist inbetween them
Absolutely, there are few things you are unable to do in GameSalad, there will likely be dozens of ways.
But the idea of your character going between the rocks is new to me, before we were discussing how to make an actor bounce back into its original position, so this new idea coupled with the fact that I don't really know anything about your project means I can't really help.
To be honest I'm terrible with vague terms, other people seem much more capable when it comes to interpreting this stuff, I'm easily confused, like a cheap computer
For example something like: 'The actor moves 8 pixels to the left and stops rotating' makes sense to me, I might be able to offer some input, but 'if its speed is over 150 it bugs out' just goes above my head, same thing with 'The whole area of each rock is 4 collision walls', it's almost meaningless to me, well to be honest it's more 'messy' as it sounds like at least 6 or 7 different things to me, anyone of which might be the right one, as for the idea that: 'the movement actor shouldnt be allowed to change its attribute to exist inbetween them' . . what is a movement actor ? You've not previously explained what a movement actor is, not even mentioned it, and 'change its attribute to exist in-between them' sounds positively metaphysical, you may as well say 'the direction colour shouldnt be allowed to change its angle to exist inside them', and then next time I respond throw in a question about (a previously unmentioned) 'physics detector'
Anyhow I'm sure you get the idea, I'm terrible at the vague stuff !!
I'm sure someone will come along with better input on this than me (not difficult to do !!
)
@Socks
Ok, let me give it another try.
Let me introduce two actors to you:
Actor 1: Its main objective is to change its Y attribute + 32 pixels, every 0.2 seconds, and to continue forever.
Actor 2: Its main objective is to stop Actor 1 from passing it with a collide behaviour.
the problem?
Actor 1 changes its Y position +32 pixels and collides with Actor 2. Then Actor 1 changes its X position -32 and then continues to change Y position +32 every 0.2 seconds.
Actor 2 fails its main objective.
How did Actor 1 change its X position when there is only logic to change its y position?
I hope you understand how ridiculous this is
Can you tell me the exact X position of both the main actor (actor 1) and Actor 2 (or at least the copy of Actor 2 it is colliding with) - including decimal points, if there are any.
Personally I wouldn't rely on a physical collision for this kind of thing - by physical collision I mean sticking something in the way, I'd be more tempted to work out some logic that prevented the actor moving when it is beneath an obstacle.
@Socks
Following template is exactly how my movement works and what happens.
http://www.mediafire.com/download/mz70p5k6diicapa/collide.zip
x coordinates are exactly the same. Sorry for the hassle
Are you able to tell me the exact X positions of both the main actor (actor 1) and Actor 2 ?
@Socks Ok somethings weird is happening.
Actor 2 X = 1216
Before collision:
Actor1.X = 1232
Actor1.Y = 1584
After collision:
Actor1.X = 1231.75
Actor1.Y = 1613.76
Whats up with that? (Rotation of all actors is 0)
It's ok, I downloaded your file . . . .
Maybe you could use a detector, like this . . .
https://www.mediafire.com/?yb8k1hspjamw4dn
You wouldn't need to place the detectors by hand, just get each rock obstacle to spawn a detector 32 pixels beneath it.
@Socks If I allowed players to spawn actors into my game, I would need 4 different detectors (up/down/left/right) that restricted movement all around the spawned actor?
@Socks Thanks for sticking it out. I'll just spawn 4 different detectors around every actor. Seems to work great. Love your work
Yeah, sounds straightforward enough, to could even throw in a rule that says when a detector collides with an obstacle (rock) then it should destroy itself, that way you can place obstacles next to each other without having more detectors than you need.
Just realised, could have 4 detectors around the main actor, and if they moved into an obstacle it would stop. Instead 400 actors around every obstacle on the map
Brilliant idea !