Motion is BROKEN! - Actor will not rest at 0 speed?!
Two.E
Member Posts: 599
Hello All,
Attached is demo.
It seems that when motion is applied to an actor, it will never come to a stop dispute the DRAG variable being edited.
It looks like it will glitch out at around of 5.
In the demo,
You just have to touch the White Actor. It will move upwards and slow down due to drag. You will see that it doesn't stop, but starts going back the other way?!
I even constrains it's motion values to zero, and it still will slowly move.
Is anyone else having the same problem. It occurs on all versions including the latest.
I am literally finding bugs every day...
Best,
Two.E
Comments
@Two.E I noticed that if I display the self.Motion.Linear Velocity.X it changes too.. even though the behavior is only supposed to change the Y value. Strange.
@RowdyPants That is correct. It's for both variables. It is not even affecting the X value yet it never seems to stay at zero.
Hopefully the GS team will see the demo and can pin-point the issue.
GSLearn.com | Templates | Free Demos | Udemy Course
There have always been quite a few issues with low speeds (or maybe it's low values / rounding issues), for example below a certain speed Rotation just stops working (can't remember the exact speed, something like 5°/sec), so you can't slow a rotation to a halt (at least not smoothly) the Pin/COM also runs into issues with low values, as does collide (we've all had bouncing objects lock into a repeating pattern when the glancing angle gets too small), and of course there was the old interpolation glitch, again something that was operating on small values.
Maybe these things are unrelated, but GS has always been a bit hit and miss with this kind of thing.
A workaround for completely killing an actor's motion (I'm sure you already know this one), would be to destroy and spawn an identical actor with no motion (or Movable switched off).
When I need to bring an actor to a definite, complete stop I normally put a rule in that says
When abs(motion.linear.velocity.y) < 1
Interpolate motion.linear.velocity.y to 0 over 0.05s
That normally brings it to a nice stop. In most cases a change attribute will work too.
GS has tons of bugs. Just look at the bug tracker, and that's only the start
But the vast majority can be worked around. My favourite is how it will often offset the camera by 1 pixel, even when you've got camera origin set to 0.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Yes. Instead of using one actor with many states I would use destroy - spawn actor for each state.
When I found this 'bug' I later thought that no motion is a bit of an oxymoron to a computer.
I used Socks and Armellines work arounds. An Interpolate rule adds a feeling of real life friction which feels nice.
Like the Paleozoic layer GameSalad is built on a solid foundation of crushed bugs, to remove them all would likely cause GameSalad to collapse in on itself, some features like Tables are in fact just longstanding bugs that have, over time, evolved into what we now see as features (Tables was originally an early attempt at image asset folders). When new users ask what's the best guide for using GameSalad I'll often direct them to the bug tracker as it's more up to date than the GameSalad Cookbook.
Are you actuall serious about the tables?
But bug tracker is definitely the best guide!
Hey Two.E,
The gif makes it look WAY worse than it does in the actual file, as this gif adds an extra clip of movement when you first touch the block which does not actually happen. However, is this what you're looking for?
If so, I put it together using a custom DRAG rule. It's explained in the actual file. I never even use most of Gamesalad's default attributes such as drag, gravity, etc. because most of the time they don't work. It's better to customize as much as possible in my opinion.
Hopefully this is what you were looking for and again, please don't think it looks how it does in the gif. There is not extra little jump at the beginning of the launch.
I'm okay with a few not so obvious tricks to get the most out of the engine but the amount of workarounds needed in GS currently is bordering on deal breaker
Well... until we can code, Gamesalad is our best bet.
Hi mate - I think @RowdyPants issue is that we didn't used to NEED these, because it just, well, mainly worked... it's gotten worse, not better... :frowning:
...and I have to say, it really isn't our best bet - I love GS, but no, having looked around, it really isn't... trust me on this, I'm very happy with what I'm currently using atm, having had to resort to working in another DnD engine until/when they actually fix GS properly....
@Japster Motion has been this way for 10 years. It's not getting worse. Some things are, but the physics engine has never been perfect. Things have always been iffy once very low speeds were reached.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
In which case, I stand corrected, but I was using physics in Gravity Star, and my ship regularly hovers almost motionless (in fact it's required for the autotest challenge), and I didn't seem to have any problems at all when working on it almost a year ago...
Maybe as you say, it's always been this quirky, but tbh, if something's broken worse than it already was, how do we (or for that matter, GS staff!) really know for sure? - lately it's more likely than not, but I'll leave it there I guess....
It really is a bloody shame. But we've got time. We'll work this out.