@murtaza you said... If you want to respect the original objects layer then don’t use spawn on object, instead use spawn. i said... this also disrespects the original layer of the spawned object. Common sense AND convention of spawning's uses in all other environments trump your anecdotal experiences with a dozen users and naive newbs, regardless of the timeframe. Particularly because they're going to move on from your app to the rest of the world's creative products, most of which use the following conventions. Spawn AT (doesn't exist in hyperPad, is a specific point. Requires user fudging in hyperPad) Spawn [with]IN (geometric space inside a shape, and what you call Spawn On) Spawn [up]ON (geometric space along the edges of a shape. Doesn't exist in hyperPad) None of these alter hierarchical structure, they always respect the editor layering (by user) where it's available. Layering, sorting and other hierarchical choices of a user are always presumed deliberate and therefore respected. Layering is a completely different type of sorting, in a different place, for different reasons, none of which pertain to geometric space, except Z-sorting in 2D, in which case the layer sorting becomes imperative to the user, and should be respected by the engine for this reason, alone. That should be reason enough to consider respecting layering choices of an end user. But I see it's not. So let me make other cases: Your app is a gateway drug to the worlds of digital creativity. If you want to be fondly remembered, referenced, revered and referred to, your best bet is to match your tooling, paradigms and processes to where your best (and most influential) users will eventually find themselves. Then those 6 years of users experiencing your product might actually mean something to others, and help create exponential user growth. Most obviously and logically important, when layering matters most (performance optimisation), the processes of manually moving newly spawned objects between layers will further hurt already tight performance constraints the user is deliberately using layers to attempt optimising around. So your current approach confounds the very best possible use of layers. I apologise if my making of more than one point is confusing, or bewildering. Also, sorry if my appeals to logic, rationality and reason distort your constrained perspective.

@GameCRAZY You've made it so by claiming he's actually addressing the problems. He's not. He's isolated a single way to do a single thing with a single object on a single spawn. That is the very opposite of the reason for the problem being a problem. And, like your other comments, this seems to stem from a desire to not consider anything that's not what you want added to the next release. IAP,, I gather.

Ahh I see. So, so you want a way to keep the existing x and y coordinates even though you select a new object. Hmm, it's definitely possible on a technical side. I just need to figure out how the UI and usability would work. At one point we wanted to separate selecting an object and visually selecting the position. But couldn't figure out a good UI paradigm for this. Need to find a way to make this optional as well for when you do want the positions to change when an object is selected. Just brain storming as I'm typing this. But a button that says select position. That lets you move the target only. Then if/when you change object A/B, it will prompt asking if you also want to change the manually entered coordinates. Yes reverts to 0,0 of the object No would maintain your change. Does this sound like something that would work?

There are some technical stuff behind the scenes, it's just easier to keep it this way. There is also help window the first time you open the scenes/overlays saying you must be pro to enable.