Played around with it some more. The second the overlay is closed, the object destroys itself even though the object was meant to destroy itself like a minute ago, and did not trigger the destroy object behaviour when the overlay was closed.
@hamed I don't think there's any magic to reproducing this. Every scene loaded by another scene seems to default back to 60Hz physics.
If you want to see it for yourself, that project I sent you, that you pruned out all the suspended objects from, that does it. It's supposed to be at 240Hz, but the pruned version is at 60Hz.
The original, I sent you, runs at 240Hz when you run/play a scene from the Editor. When you use the first scene to load a scene, however, it runs at 60Hz physics. And the problems begin instantly.
@murtaza An enemy collides with player, player looses a health, enemy is spawned into a random area of play. That spawn does not exhibit original behaviors.
If the “spawn in area” behavior is used, how do you specifiy behavior for that spawn when it hasn’t been created?
@aidan-oxley I've seen a very similar "spawning" point for particles, behaving much the same as you're describing when turning them off. It's not in the top right for me, instead it's at the left edge of the default scene starting camera location, regardless of where the camera actually is at.
And, yes, all the issues of failed interpolation, too.
@deeeds said in Resolution bugs:
@gamecrazy said in Resolution bugs:
It would be nice if Hyperpad automatically switched between "absolute position" and "relative position". It is simple division, but it would have easily spared me 2 1/2 hours.
I have probably spent as long, maybe more... but not had any success converting these. I get objects flying in from miles away.
How did you get this to work?
In my game, I was able to convert from 4:3 to 16:9 by
Making every object's position a percentage. In behaviors, they don't automatically change, but at least for objects they do.
Convert every single "get position" into a relative position as well.
"Get screen" and then an "if" behavior would check every scene to see if the resolution was 16:9. If it was, I scaled by -12.5%. Default was 4:3, and if it was 4:3, I did not need to change anything.
Convert every single other "move by", "scale by", "scale to", "patrol" behaviors to percentages as well. Now, the annoying thing about patrol is that it does not work as a percentage (no relative position option). Eventually, I got really annoyed, and I did not touch the "patrol" behaviors, so hopefully they still work. (I just submitted to the App Store.
If you want to respect the original objects layer then don’t use spawn on object, instead use spawn.
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.