Oh, one other thing I noticed is that the anchor input fields get set to the that last position you touched, even though the anchor snaps to the grid. But if you deselect the object, and then reselect, they show the correct position.

Okay thanks

This thread has more details: https://forum.hyperpad.com/topic/806/array-for-level-attempts/12

@Deeeds Tool is awesome.

@Hamed will do, to the point you regret saying this ;)

@Deeeds I just tried to focus on myself and my eyes got crossed🤨 Perhaps if I looked in a mirror I’d see what you mean, since everything gets flipped lol! Ok sorry that wasn’t funny.

@Deeeds Behaviour positions inside objects only save when you save and exit your project. If you close it or it crashes before then, then your behaviours will all load in their positions when they were first dropped into the object (making a mess).

@Thecheater887 Yes. One of the methods I used to confirm this in the above original post. I don't know of (or use) anything that captures at half frame rates.

@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 ;)