@Aidan-Oxley At the core of this problem is an issue with how cocos2D treats time. Even if you were to put aside or otherwise move around whatever issues hyperPad Timer Behaviour synching has, there are other issues with Actions (especially animations of transforms occurring over a specified duration with any ease curve) that stem from how cocos2D was designed and implemented around CADisplayLink without a proper respect for real time and an auditing of the game loop ticking by monitoring of a real unit of time to check to see what's going on, and release from an ever increasing hellhole once a disparity of sync occurs between attempts to update and redraw and what the system is actually doing and where it's at.. CADisplayLink is a message from iOS that's about when the screen will refresh, based on decisions the operating system is making about current situations the system perceives. Sometimes it reports at 40fps, which is horrific because it's not a divisor of 60, the game loop time just about all iOS game engines have wanted to run at prior to the arrival of the 120fps iPad Pros. Sometimes it reports at 30, 15 and other rates, which are less problematic, but still cause problems for anything naively believing CADisplayLink will always report at 1/60th of a second. In cocos2D, the problem goes further... CADisplayLink is also used for the timing of these Action based animations of transforms and the drawing loop. This was the simplest way to do this back in the day, but not wise, even then. Instead of basing the actions on this misleadingly presumed 1/60th notification, the notification should always be correlated with real time to see what rate of refresh and update iOS is trying to achieve. I've given @Hamed a couple of links to help him see how this can be rectified in cocos2D, and he seems quite sharp and diligent about optimisation and efficiency, so will no doubt realise he can apply the same thinking to how "Actions" use timing, and how he implements Timer Behaviours, and stalls rendering refreshes when there's no need for them. This will solve many performance and stutter issues, not just this particular one, and improve both editors and gameplay. And greatly improve the overall efficiency of hyperPad whilst significantly boosting performance after hitting the little blockages that this kind of reliance on CADisplayLink creates.

@Hamed @Murtaza And here's the most obvious thing I'm going to say today. When users aren't touching the screen in the Scene Editor or the Behaviour editor, deactivate this call: [self drawScene]; Do this and make the above changes (use mach time, though) and we'll all be able to charge our iPads from our computers, AND use hyperPad at the same time.

@Deeeds Yeah, this sucks when you have an object moving really fast. Why do particles get to move smoothly under a low time scale but Move behaviours don’t?

Was not aware of this feature. Guess I'm out of the loop. Thanks!

@Aidan-Oxley I used to do that. Might check my post history, some pretty bad things are probably on there. Four times as much on the old forum, I'm betting, too. Then I started programming. I need to invest in Raid library. Anyways, I understand where @Deeeds is coming from, his methods match how mine used to be, and probably still are - very defensive and willing to push back. That being said, no three-man team, all coders mind you, that I know could ever pull this off. Period. I'm rather surprised they made it this far, and root on any and all progress they make. In fact, if I ever manage to get my pea brain to understand C++ or Swift and get a (decent) Mac, I may apply (as a volunteer initially) to help them out. (Speaking of which @Murtaza, are you guys open to third party application development? I'm interested in trying my luck at a windows player, asset manager, screen mirror, game analytics, or anything else that may be of some help if apple and you guys are open to it, or have an API until I get a decent Mac.) I do have to side with the @administrators, though. I'm not quite certain how it descends to it, but the bicker and banter isn't helping anyone. The more time they spend here with fire extinguishers, the less time they can spend there with flashlights and bug zappers. TL;DR: When a community and team are this small, it's a LOT harder to manage and expand the people and the product, and that's before the blood moon rises. Sorry guys, had to have my daily dose of nosy :)

I don't know how I've never noticed this before, I'm having the same thing. I guess because of collisions and grid snapping I've just always used the same canvas size graphics when I use set graphic...

@Murtaza said in Else If behaviour child behaviours don’t follow when moved: We'll be changing if/else so they are a single behaviour with 2 sets of outputs. Left side is the IF, right side is the else. May I be so bold as to make a suggestion? Oh. You can't wait? Here it be: Bottom Out is If = true, right side is Else. Keep the left side of Behaviour nodes reserved for inputs (eventually), and the flow going down and to the right.

@Aidan-Oxley pretty normal!

@Deeeds Me too. Bullet hells are awesome. Phoenix 2 is my favourite game on the App Store, my best game is Meteor and it’s pretty much a bullet hell.

Because we're using realtime cocos2d for our scene editor, we can't use uikit gestures like you suggest. Use pan tool like @Aidan-Oxley suggests.

@Deeeds I do not

@Kamdroid This is a very cool cheat!

@Deeeds Same for me...also when I load the forum page it can crash two or three times every time I go on.

Yes, 100%, this is caused by screen pop-in during scrolling. Something isn't efficient in that system.