I think I figured it out - I had changed my working sets in that dialog - probably trying to figure out something else before in terms of referencing and attaching items to game objects. Not sure yet - but is this part of the file dialog well explained in the documentation? I changed it back to Window Working Sets and things got better… - still learning this all… 
Oh, I’ve never even noticed the Working Set drop down and I’m 100% sure I have never modified it. I don’t think you’re supposed to fiddle with the working sets
One thing I just noticed, and it’s the type of rookie mistake I’m making plenty of… For this page: http://www.defold.com/manuals/2dgraphics/ it might be good to add a note that says “SAVE YOUR ATLAS” first before adding images to a sprite as they won’t populate the dropdown list in the sprite properties box until you save the atlas changes. I know this is easily overcome, but small things like that in the documentation add a level of detail and support that can help n00bs like me.
I’ve already broken the first rule of Defold Club.
So I’ve got this all working. Not too difficult but now something more problematic - what is the easiest way to detect a touch on a specific sprite be it with the mouse or touch.? Is there no easy way to deal with determining an mouseover/touch event to any given sprint via the on-input? I see in other tutorials like the Magic Link tutorial, they’re just doing a quick grid calculation but that wouldn’t work for things no on a grid structure.
Good point. You’re not the first to forget to save first. @sicher, do we mention this anywhere in the manual? (I know it will not matter in the new editor, but until then it might be worth mentioning)
There is no out of the box detection of input on a sprite in the same way as there is gui.pick_node(). You can read the size of a sprite and bake the whole thing into a helper function of some kind, but it’s hard to make anything generic since you can modify the render script and set a totally different view, projection and other things you’d need to take into account. If you have a collision object on the sprite you could probably also do something with a collision object that you spawn/move to the position of the mouse and then check for a collision with your sprites.
Ok, that’s what I thought. For now I was just picking a target box within the general bounding box of the sprite and that may be good enough in terms of what I want to do. I had thought of using a collision object, but that might not work well for grabbing and moving an object on the screen. While it would help in some respects for irregular shaped objects, it seems like a lot of work for not much gain. What it might be useful for though is avoiding objects that when placed down are otherwise overlapping. I think what I’m building toward is a generic function that makes it possible to test for different things like this when moving around objects on the screen for drag and drop interactions. Food for thought… Thx.
1 Like