I also look forward to finding a solution to this problem 
1 Like
A little bit of a status update:
We’re wrapping up the 1.2.150 release now (for Monday). It will contain the synchronous raycast btw!
For 1.2.151 we plan to finish the Facebook upgrade and a bunch of other things (flipbook animation cursors!).
Aaaaaand then for 1.2.152 we plan to do a physics focused sprint where we’ll expose more physics settings and work on things such as physics shape scaling and running the physics simulation in a separate thread.
13 Likes
Woooow! 
All those features seems to be kind of a small revolution Waiting for cursors, ofc! So with physics in other thread we would be possible to create even more collisionobjects without carrying too much about performance, yep? If it comes to exposing physics setting, actually there is only damping of a collision object actually changeable, so I think exposing more of the settings to change could allow us to perform a lot of dynamic things. Or do you mean adding even more settings??
1 Like
You should always care about performance 
The main idea with this is to get a much more consistent physics simulation where each physics step is of equal size. The problem right now is that if the game lags for one reason or another the physics will suffer since the dt varies so much.
Well for starters it’s really weird that Gravity is hardcoded into game.project from start. It should be possible to change at run-time. There are probably a lot of other properties that can be read and maybe in some cases also manipulated at run-time.
Oh, and we’d like to release the first version of the physics joints system!
9 Likes
Why didn’t you manage to solve the problem in the new version? 
Defold 1.2.156 has been released
1 Like
Because we finished the work on joints instead. And we added support for programmatically changing the gravity.
Solving physics scaling is next on our list though. But it is dependent on another engine change where we need to make it cheaper to know when a transform hierarchy has changed. We really don’t want to poll for scale changes every frame but rather have a system where we have some kind of dirty flag or similar.
2 Likes
I guess recreating physics bodies each frame is not the best route. Maybe add a message or a call to reapply scaling? So the developer chooses when to update.
2 Likes
I am really looking forward to this fix! It has been a pain for a really long time.
1 Like
Any updates on this? This is very useful feature
1 Like
+1 For this feature. Need to create objects with variated col box sizes in my game, dynamically.
1 Like
Definitely collision objects should follow the transform of game object as well as sprite component does. I have a ton of multiple game objects with different collision objects just as a workaround, it’s not convenient.
+1 for this!
(EDIT: I already +1 it earlier! 
)
I keep bumping into this one. Destroying and recreating the game object would be fine; that’s how it’s usually done in Box2D. That doesn’t work because factory.create() doesn’t support arbitrarily scaled collision objects.
Any update on this?
You mean non uniformly scaled objects?
Ja. 
+1 over here XD 
Still encounterd this bug today.
I thought it was something wrong with my script.
I think we should be able to pick this issue up again very soon though.
7 Likes
I’m testing non-uniformly scaled collision objects now with Defold v1.2.174. It still seems to work only when uniform. What did the “solved” refer to?