I agree. That would be very useful.

Instead of adding a ton of options for spawning object; when object referencing to behaviours is added, the spawn object behaviour returns the object it spawned, and then you can set and manipulate stuff with the object using regular behaviors.

@Thecheater887 ok, I have the newest(2 gen) Pro, so I can spawn a bit more.

@Aidan-Oxley Sort of. Most forums exist for reasons relating to conversational discussion of ideas and specific subjects. It's right there in the name: "forum". It's kind of what the word means. The problem with using a forum for a "Known Issues" repository, without a specific thread, is that everyone coming to the app needs to know what issues they're looking for... when they DO NOT KNOW what are the KNOWN issues, so are unable to search for them. If they are new user, this is made worse because they don't have the lexicon of the app, either. So even if they might know about something they want to do, and want to check if there's any problems before making an effort, they might not know how to search for it. Which leads to the most significant point: The entire purpose of a Known Issues LIST is to put everything into one space/place in a manner that's easily digestible and can save new and intrepid users from wasting time trying to do things that are impossible, and to help them find a path to completion before they venture off. I realise consideration of new users is not something at the top of your list of things to think about. That's fine.

@Thecheater887 Tim Cook single handedly destroyed the relevance of controllers and Apple when he insisted the first generation of Apple TV with apps/games must have ALL games be playable with just the Siri Remote. The moment this was announced, every game developer working on Apple TV games simply dropped their projects. And the Apple TV is what it is today (ignored) because of this insanity. He backtracked (quietly) a year later. But, much like Microsoft and their disasters with the Xbox-Plus-AlwaysOn-Surveillance ... As A Feature , the damage was done. The Nintendo Switch seals the Apple TVs fate as an also ran. It solves the problem of lounge-to-road gaming in ways Apple could have done with an Apple TV and iPhone/iPad. But didn't. Not the first time Apple has misunderstood gaming, gamers and game developers. Deliberately. Won't be the last.

@Aidan-Oxley Correct. The locations are inconsistent between spawn and move.

@Aidan-Oxley Why am I not surprised?

@Aidan-Oxley by interdependencies, I mean the second object in a relationship looks to the first for transform information, whilst they're both children of another. And a third looks to the second. etc. This can be done for all aspects of transformation: scale, rotation, position and skew. The results are fantastic. From about 2 minutes into this video, you can see some of the results:

@Kamdroid No, I'm changing behaviors and actions in each scene; parameters would not make sense, and neither would prefabs.

Guys, we know! We needed this feature yesterday. All I can say right now is soon.

@Thecheater887 Yes, there's some inconsistency, missed opportunities for logic coordination/creation/condensation and poorly communicated/expressed conventions/processes and other issues being ignored in the way "Behaviours" have their states changed and are utilised. Listing things, for clarity: Behaviour On should simply turn a Behaviour On, not execute it. This permits the subsequent executions of a branch of Behaviours to perform differently than in prior runs, and is an incredibly powerful feature. Oddly, this is the default way in which this works if there's Behaviours above the behaviour being turned on, but not if the Behaviour is parentless. Parentless "on" state changes, without execution, require the use of Receive Message, which requires the use of a broadcast and further branching. Behaviour On, ideally, should never execute a behaviour, simply change its state from off to on. Execute Behaviour should only execute a behaviour, even if it's off, without otherwise changing its state to on. It's a function call, in this sense. Ideally, then, both Execute Behaviour and "Behaviour State" are the two terms that should be used, and can be combined into a single block. Behaviour Control Within this, a behaviour can be chosen to be executed (activated or invoked) and/or have its state changed (from off to on and vice-versa). Done with the ability to operate on more than one behaviour, and this becomes a gate and state tool of significance to the usage and capabilities of visual logic within hyperPad, and a meaningful gateway to understanding how to best structure visual code. This opens the gate to considering the path to switches and a better branching system(s).

@Kamdroid I second your sentiments. There should be named command creation (functions/methods): Functions should take inputs Functions should return results Methods should be encapsulated/invokable within objects Functions should be accessible globally or within scope Functions should be passable as parameters objects should be referenced, and this be passable and shareable And... The Behaviour Editor should have UNDO, REDO and a listed history of modifications made to all behaviours within any object. ;)

@Aidan-Oxley @Thecheater887 https://www.shadertoy.com/results?query=mandelbrot

@Thecheater887 Not if the loop is connected underneath another behaviour, and the Begavior On has Skip Events turned off.

@Murtaza @Hamed just wondering if you ever found what was wrong. @Deeeds said his Apple Pencil works fine. The only workaround is to turn on touch accommodations in iPad settings. which I don’t like🤣