Hi, I think this is a bug.
I have a simple sprite object with text on top. It’s like a whiteboard magnet. I am changing the width of the object based on the width of the text so it automatically fits.
The problem is, it seems to use the collision mask of the original sprite width. When I turn on debug mode to show collision masks, it looks like the mask has updated to the new width, but in reality, I can’t position the sprite properly because it runs into the barrier based on its original width. Here is a screengrab of the barrier and sprite collision masks. This is as close as I can get to the barrier (to the right).
Sprites that I don’t resize can go all the way to the barrier edge.
Is this a bug, or am I missing something? No custom collision masks.
Thanks.
How are you moving the objects? Are you using the physics behavior or seperate objects?
Hi. Not using physics. Just dragging them with mouse. Text position is linked to the tile position.
How are you detecting the collision? You say “it runs into the barrier”. Can you post a screenshot of the relevant events?
Yep. Single event. Simple collision.
I have multiple sprites and it’s only the ones that have the width adjusted that have the problem. Here is a screenshot with the width condition turned off
You can see the sprite stops in the same position when the sprite width is adjusted, even though the sprite is not that wide anymore. Here is the condition toggled off
Now I turn the condition on, and I get this.
Stops the same distance as it would be if the width wasn’t reduced. makes me think the collision mask isn’t updating.
The reason I suspect it is a collision mask update issue is that I get the same issue with the resizing of collision boxes for BBtext objects. Actually, the text in both these cases is BBtext. Maybe that is the issue? Although in the demo at the bottom of this post, you can’t see a collision mask error like you can in the text-only example.
I’ve had this issue for a long time, and my fix has been to move the object by 1 pixel each time it resizes, so that the collision mask updates. For example, the text in the following screenshot resizes when another bit of text is in collision with the base object. it resizes so I can fit more text on there. For this demo I have turned off the 1px nudge.
Here is a screengrab of the first BBtext object on the collision object.
Then I add a second object and notice the first object reduces in size (I’m making the font smaller) but the collision box doesn’t update.
I then drag the first text box and that movement updates the collision box of the first object.
Here is a quick demo of both issues, which might be easier to understand if you see it in action.
I also just noticed it only happens on the right side, again making me suspect it is a collision mask not updating because the width is reduced, meaning that the collision mask for that whole sprite length is sticking out to the right. This vid is two identical sprites, one with the resizing applied, and the other with it turned off.
I can work around this by using the pixel nudge on the text (even a 0.1 px nudge does it) and by swapping out to different-sized animations instead of resizing with the sprite cases, and that works, but it is a bit of a pain because I have to make 10 different sizes and detect the string length to choose.
I’m not necessarily after a fix right now but I thought it might be a bug 
.
If I’m understanding this correctly:
You have text objects
You are resizing them via events without changing the actual text.
The boundary box/collision mask does not change.
If the above is accurate, this is as expected. As far as I know, text objects (all 3 of them) are designed to adjust their size to the rendered text, they’re not designed to scale via boundary box size because you’re setting a fixed font size in the object/instance itself and it doesn’t want to render empty space.
The only thing that I know of around this is to give the text object a fixed size in the scene editor (custom size checkmark when selecting the instance in the scene, and give it height/width numbers), and change the width using that text object’s specific action. For BBtext you have to do both text width and text wrapping width though.
In all cases it is not designed to scale the actual visual of the object (unless you’re using the scale actions).
If I’m not understanding the above, then I’m not sure I connect to the issue.
Sorry, I conflated two issues thinking they might be related. You are almost understanding the text issue correctly. The collision box doesn’t resize when the font size is changed until I drag it. I’m not scaling the text boxes. I’m just changing the font size. So, in this case, the text objects aren’t adjusted to the size of the rendered text until I drag or move the text object. Thank you for your thoughtful responses!
I’m still experiencing this issue with objects. This time I am using text input to change the text of a BBtext object. It all works, but when I have finished creating the text, and I try to drag the text object I have just created, I have to click in the top left corner of it to do so - all of the rest of the text object doesn’t respond to being dragged. However, if I move it by one pixel after creating it (using a condition), the collision mask seems to cover the whole object, and I can drag it. I’ve seen this same issue in many different circumstances and projects now.
Can you post your events so other people can recreate it?
No problems. I’ve made a little demo game that shows the issue. https://dyslexicstrengths.com.au/gdevelop/textdemo.json.zip You can see the collision mask doesn’t update as the text is typed in. You must grab the initial empty collision mask and drag it before the mask sizes correctly.
The same issue applies to sprites resized by conditions as well. Also, with a sprite, if you resize the width, the mask doesn’t update, even if you drag it.
1 Like
Agreed. I tested the BBtext on my phone and the hitbox didn’t update like you said.
1 Like
@Silver-Streak, do I need to do something to submit this as a bug again? It’s causing me no end of grief.
The thread here is enough for most issue reporting, although if you want to fill out the github template it might get some more eyeballs on it
1 Like
