@Aidan-Oxley the sunglasses are nice, but they don’t look that great on him. Is that actually his picture? It’s not how I imagined he looked. The smile was the first hint.

@Deeeds Lol zooming with multiple behaviours selected is crazy. Also, dragging two or more behaviours around that both have the same behaviour connected underneath them is pretty crazy.

@Kamdroid I’ve kind of found ways around this, but they are really confusing and involve turning on and off an Ignore Collisions behaviour lol. So yeah this could be good.

@Deeeds This. Totally forgot about listing stuff, would love to see this implemented.

@Kamdroid Yes, you've got that right. I think Codea might be able to export to Mac and Apple TV as well as iOS, but haven't used it for a while. I used to like browsing its documentation and trying out things that caught my eye. It's an incredibly polished piece of work. Two Australians, I believe.

[image: f63ef19b-e86b-4c46-beb0-c02a3c49c3dc.jpeg] [image: 87876493-a7b7-4f2c-bb5e-24c8f5cd969c.jpeg]

@Aidan-Oxley Ideally this also be independent positioning, so the polygons of the quad that make up the sprite can be used as a surface extents mask.

@Hamed Thanks for this insight! I used a Pin connection, but it's kind of wonky. Spins when it shouldn't and locking rotation ranges doesn't work properly. The motor, also, is weird, simply acting like a weld rather than as a motor.

@Deeeds Ohh, I see. This hasn’t been a problem for me, I actually don’t use physics too much other than for detecting collisions, most of my changes are in behaviours.

@iTap-Development Even cooler would be using hyperPad as an audio mixer and funneling it into garageband in real time :wink:

Yeah, this is pretty annoying. Will see what I can do!

[image: display_cdfr6ol.gif] All joking aside. I appreciate your input. Just want and see what we come up with. The majority of things you brought up we've already discussed months ago. The new ideas I've added as notes. We'll go from there.

@Murtaza That would be cool. But at the moment it’s sort of possible to already make them using a dodge blending mode, but that would be laggy. How do particles really work? Why can particles load so many objects without being too laggy but making particles with objects would be super laggy?

@Deeeds Lol I don’t really like how animations work, so I do it the long way and use a chain of Set Graphics 😝

@Murtaza @Jack8680 @GameCRAZY @iTap-Development I think all of this is pointing at a bigger, fundamental problem in the current structure of hyperPad: A lack of proper instancing and references. The single best thing about classes and OOP. Fix this problem and everything on this list (and much more) becomes possible, and you get the biggest single benefit of programming, the creation of infinite replicants, communication between them, unique identifiers of each instance, accessible, storable references to each and the ability to uniquely change any of them. Having done this, any "thing" can point to any other "thing", even if it isn't known about at runtime. This is the greatest benefit that Objective-C has over C++, that it first seeks a responsive object, then gracefully fails if/when it can't find an object that's supposedly there and able to respond to the method call. It doesn't do this through every class in a project, only up the hierarchy. If it seeks unsuccessfully, it doesn't crash, it just returns a nil. The Apple SDK/API and Frameworks designs/architectures have relied heavily on this capacity of Objective-C. Very heavily. The wrapping (please excuse the pun) of Swift's language design around Optionals is another way to provide this flexibility, from an architectural and language design point of view, without the losses in speed prevalent in the way Objective-C handled hunting hierarchies. Sadly Swift is not nearly as freeform and carefree for the coder. Dealing with Optionals is a pain in the arse. But it's better than crashing when something that's sought isn't there, solving this problem by putting the burden of discovery and ascertainment of validity on the programmer. The same concerns must be addressed in hyperPad. What happens when something is asked for or expected that isn't there? With the very literal and predefined (and exacting) way relationships are handled now means there is no chance of this. But the moment you permit dynamic addressing you're going to get failures to find the object, address, property, attribute or whatever it is that's predicted to exist but may not. So you now have to come up with a way to elegantly fail, or provide a completely bullet proof way of dealing with the failure to find something. Creating the complexity of optionals in a visually coded language/environment is not something good for those allergic to spaghetti. Going the way of Objective-C is even weirder because it's almost an old trick from an old world problem. Dealing with a silent, graceful return of Nil (exceptions) isn't something many people are really good at doing in Objective-C, and they're real programmers. At this stage there's no debugging in hyperPad, and that might be the biggest problem. Tired. Nap time. Thinking language Code hurts.