Got this action to attach one object to another’s point, but for some reason having the action occur under these conditions is setting the one object’s position to 0, 0. I tried having a simple “press the space bar” condition, and the action occurred just fine under that, but putting any of the variable or timer conditions in place makes the object go to 0, 0 instead of the point. There’s other stuff I could show or specify, like how these are external events, but that shouldn’t matter considering that the conditions are definitely being met, it’s just the event that’s not doing its job.
I can’t figure out how to reproduce the bug. I tried throwing together a project with similar events and it worked fine. I’m guessing 0, 0 is a default coordinate for if the game can’t find where to send the object, but what would make it not know where another object’s point is?
If all else fails, I’m sure there’s a hacky solution on the table, but I’d rather figure out what the deal with this is.
GDevelop sets the object to 0;0 if the coordinates defined are not available anymore, like davy said. For example, this used to happen to me, if I deleted the object and then told something to go to the object’s position, it would bug out and send it to 0;0 since it had been deleted
Adding a screenshot of the other events, like davy said, would help us figure it out.
Is there anything else that could result in the default coordinates? The popo definitely isn’t being deleted, and the points stay the same throughout the animations.
That wouldn’t make sense because the conditions are being met and the action is occurring. I even copied and pasted the action from the event that works, and it’s still bugged.
Is pop_toss_take a group and is popo in that group? If so, the conditions might be preventing popo from being picked. It might works in other events bc the popo status is the same as the group. You might need to use pick all popo or some other conditions depending on if there are multiple popo instances.
Check if there are any picked popo. Add an action (in the event that sets the position) to display the number of picked popo objects or maybe the popo object position. You can add the result to the console. I like to add a text object for debugging instead of using the console so I don’t need to uncover or switch to the console tab.
popo_toss_take is a group, but popo isn’t part of it. The “pick all popo” action Seems like it fixed the problem, but I’m concerned about the usefulness of this event for objects that there are more than one of. Changing conditions around the positioning action seem to make the bug appear again.
Another seemingly glitched part of this positioning stuff is that when I set the position to the point and then use a condition for if the point is inside the object, the condition isn’t being met somehow. The popo point is definitely inside the popo_toss_take collision mask.
If using pick all fixed it then somehow popo isn’t being picked. Double check that popo isn’t part of the group. Unless there are more conditions not in the screenshot.
We are talking about this event? Or am I confused?
All of the objects are used unless a condition sort of filters the picklist. So, unless there’s a condition that I’m not seeing or it’s in the group then it should work without the pick all.
Yes, that is the event I meant. Double checking popo’s groups, it looks like popo’s not part of popo_toss_take, but is part of toss_take. Removing popo from toss_take seems to fix the bug, so perhaps there’s an event affecting toss_take objects that’s interfering with the picking…
I searched for toss_take events, and disabling them didn’t seem to make a difference. It really seems like it’s just the positioning action in that one spot that’s botched. Putting other position actions there, such as “move toward a position”, botches those too.
So after even more testing, it seems like it just refuses to do the positioning action no matter what if popo’s status variable changes to anything besides the default 0.
It looks like I was able to fix it by adding a new “would your status be 7 right now if not for the bug” boolean instead of setting the popo’s status to 7. That’s probably gonna be annoying and awkward to work with, but better than nothing, I guess. Maybe playing with this new boolean will give me some more clues as to what the deal is.
