Topics created by Deeeds

We're doing final testing on the update starting this Friday. Hoping to have it submitted to Apple by middle of next week. This took way longer than we wanted, and we're sorry about that. We got caught up working on some deals for the business side of things and this interfered with the update. Programmers are busy programming. They lurk the forums. If they want to introduce them selves they can.

@iTap-Development haters gonna hate I guess? Tell me if I’m wrong, I didn’t really follow from the beginning of all of this, and I don’t really know much of English since I’m french ^^’

I like it too! Cool!

@Hamed Question: Z_PK is a universal reference ID, incremented for every single thing created, be it behaviour, object, etc... forever (and never deleted)... in any given project?

I have finally finished the tool to clean up bloated projects. We're initially going to add a button to do this in the project options, and we'll do it automatically when we see that its safe to do so. For now, anyone that wants their project cleaned up, can send the project to contact@hyperpad.com and I'll email you back your cleaned project.

I’m at 34% so definitely over 1GB

@deeeds One of my games on my iPad used to ask for my Apple password every time I opened it, for no reason. I wonder if it’s something to do with iOS 11.

@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.

Tested it in like 3 mins, no you can’t reset it using behaviour on then off, you’d have to make a manual execute sequence with a stored number (the number you’re up to in the sequence) then set it to the start number when resetting. You could try enabling an object with Restart Behaviours turned on, but that’s probably not going to be useful since it resets all the behaviours, not just the 1 you want.

I agree. That would be very useful.

@gamecrazy @gamecrazy Not the point I'm making. I'm not discussing work arounds. I'm making a feature request for the reasons stated, and others.

Weird. Happens for me too (you gave me an example project a while ago).

Adding New Broadcast and Receive Behaviours that operate across layers massively increases build time. For me.

@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.

@Murtaza here's an example project: http://bit.ly/2rB7BMp (the behaviour is inside the thin white bar). I'm guessing it happens when the object is too thin to actually draw any pixels inside the preview. Maybe replace it with the "Object" text that appears when an object's asset is deleted.