I was in the middle of typing a post on this then this thread came up under similar. The problem seems to be that the orange outline for the collision object does not scale up or down when the game object is scaled. However, when the game is run the collision object is scaled.
3 Likes
Any news on this? It’s pretty huge to not be able to scale the collider with the GO.
1 Like
No new news I’m afraid.
It was considered some time ago, but turned out to be more complex than what was initially thought.
Since the community is still requesting this, it will increase in priority.
However, I cannot give you an e.t.a. at this point.
2 Likes
This bug blocks fast prototyping, when you don’t want to use tile map. ):
2 Likes
I’m missing the ability to dynamically alter my collision object size too. For example i want to create a shockwave which expands and hits objects at it’s border.
1 Like
There is an existing workaround to get scaled collision. You must create new objects based on factories with a set scale. Then you delete the older. And need something to manage the creation / deletion based on scaling. Or keep the various scales and only disable / enable their collision sizes as they are needed if you have only so many possible scales. Obviously is messy, but if you need dynamically scaled collisions this is a way right now. Works with factory / collection factory.
collectionfactory.create("#groundfactory", go.get_position("."), go.get_rotation("."), {}, 2)
collectionfactory.create(url, [position], [rotation], [properties], [scale])
3 Likes
Regarding scaling of collision objects through factory.create;
Right now it appears that scaling is applied when using a number as scale parameter - but not when using vector3?
2 Likes
Yes. you can use vectors to scale. Collisions will not scale along unless the scaling is uniform though:
factory.create(component, p, nil, {}, vmath.vector3(8, 1, 1))
factory.create(component, p, nil, {}, vmath.vector3(8, 8, 8))
6 Likes
I understand not being able to non-uniformly scale spheres, none of the other engines I’ve tried have allowed that, but scaling boxes would be great. Or at least some way to create and add a new box shape of different proportions. That seems to be the one thing you can’t work around right now.
1 Like
The workaround is that if the scale-factor is uniform along all axes (x, y, z), then the collision object seem to scale correctly. I encountered the same issue with scaling sprites and connected trigger object.
This is mentioned by @sicher a bit down the thread, but not explicitly mentioned as a workaround for the issue, so…
Am I missing something?
2 Likes
I also bumped in this problem. Luckily, I could use uniform scaling.
I also noticed, that my particle.fx got scaled once i did uniform scaling.
FYI, I just bumped into this too.
What caught me was that the collision box that I was using appeared scaled in the editor pane, but then when I turned on physics debugging it wasn’t.
4 Likes
The exact same thing as described by @rantingbob happened to me today. Scaling the parent affects the box in the editor, but not in the game (as seen by turning on physics debug).
@britzl said it was moved to bugs in Jira two years ago. Is it still not done? Or has that one been fixed and this should be filed as a new one?
2 Likes
Although it took us a long time before we picked it up, the DEF-521 is actually in progress. It just needs some other tasks first, for us in order to make this a more solid solution. And I don’t have a definitive ETA yet. Sorry for the delay. 
Is this not fixed yet? I just encountered it now.
Parent go has multiple factory-created children go’s, each with its own collision. When scaling the parent go, the children go’s get scaled properly, but the attached collision sizes remain the same.
Sadly, no. Those other (required) tasks haven’t been prioritized during the year.
But I feel hopeful we’ll pick those up at the beginning of next year. (But again, cannot promise an ETA yet)
2 Likes
Having used Box2D a bit more directly through Löve2D, I have a better appreciation for why this “issue” exists — It’s simply the way Box2D works. It is not a bug, in Defold or anything else. Box2D does not allow you to change existing shapes, only to create and destroy them. I assume this is a performance optimization, so any “fix” will cause at least some performance hit.
The real bug I see is that the editor does not respect this. So your game objects can look one way in the editor but completely different in the actual, running game. There have been a few reports for this: here, here, and here.
6 Likes
Just started playing around with Defold and faced this issue, when I scale a GameObject with attached CollisionObject, in the Editor both sprite and CO look scaled correctly, but when I run the game then CO appears scaled incorrectly. I can rescale collision object manually so it will fit GO size, but again, now in the Editor CO looks messed, but at least it’s ok in the game.
Please, make it at least consistent, broken in both places, or fixed in both. Thanks!
2 Likes
The original ticket (DEF-521) is about scaling the game object at runtime.
Your issue seems different. Afaik, the scaling of game objects at edit time will be represented ok in the engine.
Can you give us a repro case to test with? E.g. zip up a small test project and share it here. (Exclude the build folder and any hidden folders)
1 Like