Which move-related behaviours still work with non-moveable objects?

Hymloe

Hi,

In short:

If I make an actor non-moveable, I see I can still move them around using some rules, and not others.
Which behaviours work with non-moveable actors, and which don't?
Which behaviours relate to the physics objects, and which can still control a non-physics object?



In long:

I've come to realise that you can still move non-moveable objects around by using rules such as Interpolate.
I'm wondering can someone explain to me exactly what the differences are when an actor is marked as MOVEABLE or not?

I'm assuming that basically a MOVEABLE object has it's physics system activated. If it is also marked as collidable with other actors, then when they bump into it, it will be set in motion and move according to the physics system.

So, what can I do with a NON MOVEABLE object? Are all of it's "Motion" parameters turned off?

I assume I can move it around using fixed rules, like Change Attribute and Interpolate (for when I might want to move a menu button, for example, that doesn't need to be a physics object, but I still want it to move and be animated).

And I guess I could even make NON MOVEABLE objects that are still quasi-physics objects, if I just wrote my own collision-reaction behaviours, using Change Attribute and Interpolate behaviours. If I wanted to.

Could anyone clarify which behaviours work on NON MOVEABLE objects, and exactly what elements of Game Salad are turned on and off by ticking or un-ticking that box?

gyroscope

Hi @Hymloe

The two main advantages for non-moveable objects are as follows: firstly, it saves a tiny bit on loading time, so with many non-moveable actors (like backgrounds or text, for instance) it'll all add up to a noticeable (if small) shortening of loading time of the scene. Secondly, if it's a wall or similar as a non-moveable object, and another moving actor collides with it, it'll stay put.... (obvious, but that's the reason!)

jonmulcahy

moveable rules deal with physics
interpolate is purely the interpolation of a value of an attribute.

so if you disable physics, you can't move the object, but there is no reason you can't change it's x or y position.

interpolate is kinda like "change attribute" over time.

Hymloe

So would I be right in saying that these behaviours will only work if an actor is MOVEABLE...?

Accelerate
Accelerate Toward
Change Velocity
Move
Move To


While these will still work on an actor that is NON-MOVEABLE...?

Change Attribute
Interpolate
Rotate
Rotate to Angle
Rotate to Position


And that if I try to use Change Attribute on a NON-MOVEABLE actor, to try to change it Motion or Physics Attributes, that will do nothing useful?

Linear Velocity X
Linear Velocity Y
Angular Velocity
Density
Friction
Bounciness
Drag
Angular Drag

gyroscope

All correct! Except along with the others you mentioned: Rotate, Rotate to Angle and Rotate to Position won't work on a non-moveable actor.

Hymloe

I just built a blank project, with a square actor (NON-MOVEABLE), and...

Timer > Every 5 seconds...
Rotate to Position (Mouse Position X, Y)

And as I pass the mouse over it, it rotates a bit!
It doesn't do what it's meant to fully, but it rotates a bit every time I move the mouse over it. Just a bug I guess.

When I mark the actor as MOVEABLE, it does what it's meant to.

gyroscope

Interesting; I'll check that out. :-) (It seems mightily odd that it tries to work with a mouse inside.... without any mouse inside Rule, very strange....!)

Hymloe

On a somewhat related note...

If I make a MOVEABLE actor, and set it's DRAG to 100, and then give it a MOVE TO behaviour... the actor move that way for a bit, then slows, reverses, and goes the other way!

So I'd argue that you should not use the MOVE TO behaviour on anything that you want to use as a physics object.

Shame.

- Murray