@Hamed I don't think screen shots can help, because you can't see anything, which is the problem. When moving an object according to Screen Space, it should move to the position of the screen that it's being told to move towards. For this example, let's imagine the upper middle of the screen, in hyperPad units. Let's say that's x: 16, y 20 (4 units below the top edge, middle of the x range). If I tell an object from within the game world to move to this location, over a duration of 2 seconds, it should. Whilst the object is making this transition in location, regardless of where the Screen View moves within the game world, it should always be aiming for this position in the Screen View. This is not what's happening. Instead, at the moment the Move To Screen Coordinates Behaviour is called, the behaviour checks for the world location of that Screen location, and then uses that world location as the target destination. So if the Screen view moves, the moving object is no longer heading to the determined Screen Position, it's heading for where that Screen Position previously was in the world coordinate space. Assumes: Screen space is that space we can see on the iPad, it's the view's bounds, expressed in units (or percentages) from the left edge of the device's screen, to the right, and up and down. When using a Screen Follow "behaviour" on an object, it's acting like a camera in the world, moving the view of the Screen through the world with its subject, the target object. Move To Screen Coordinates is not respecting this, it's determining the world position of the targeted screen location at the time of command issuance.

@Hamed So you will have it delete all the objects and in a deleted scene and delete all the behaviours in a deleted object? One of the problems with the way it is now is that game files become larger than normal (my Meteor project probably has like 5mb of deleted stuff, it is a few years old).

@Thecheater887 no, arrays and dictionaries are supposed to be returned in json, so it should return: ["This is the value at index zero","This is the value at index one"] It works fine if I put the array output directly in the text input. If this wasn't a bug it'd be a huge inconsistency since it returns in json format all other ways except in a set input field.

@Jack8680 this helps restore some of my long lost sanity. THANK YOU!!!

@Jack8680 said in <null> from nonexistent dictionary entry does not satisfy "≠": This should be pretty doable with something like try/catch, right? I suppose so. I'm not really super familiar with (ab)using error handling. I tend to design around whatever I learn about a language and get vocal about what I don't like, or expect that isn't there ;)

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