• JonB

    I think it should be self.t.
    it is an instance attribute, not a class attrib, if memory serves -- the time is incremented in the running scene only.

    posted in Pythonista read more
  • JonB

    Are you using the beta?

    posted in Pythonista read more
  • JonB

    dont use time.process_time. instead use scene.t -- scene includes t which is the time since the start of the scene, and dt, which is the time since last update.

    posted in Pythonista read more
  • JonB

    you mght try installing the beta

    posted in Pythonista read more
  • JonB

    Take a look at the Game Tutorial in the examples folder... I think the second or third installment, where it shows how to animate walking. As stated above, it should be called from update -- or, you could create an Action.sequence consisting of ab Action.wait, and an Action.call, which calls a method you create that sets the texture to the next one. (add a texture_idx and texture_list as attributes of your SpriteNode, so you can easily cycle through them). Then wrap the sequence in an Action.repeat, set to repeat forever.

    Or, you could simplify even more, and have a single Action.call (wrapped in a repeat), where you include the duration parameter. The duration would be the time it takes to execute the entire sequence -- within the call, you'd check if progress*len(textures) is different than your current index, and if so, you'd set the texture_idx to that value, and then set the texture . That eliminates the wait, and might allow you to use different timing nodes (though maybe not)

    posted in Pythonista read more
  • JonB

    Fxcmpy uses pandas, which is obviously not supported on pythonista. Not sure about socketIO.

    This failure happens during the install? Or when you tried to use it, later?

    posted in Pythonista read more
  • JonB

    If the SpriteNodes always move together, you could have them all as children of a dummy Node that you move around.

    Or, you could do
    [N.run_action(A) for N in list_of_nodes]

    posted in Pythonista read more
  • JonB

    Do other methods on aSkinner also crash?

    Looking at the docs, it's not clear doing an alloc/init is legal. It looks like you either need to create the Skinner from a scene, or use the long form constructor:

    Creating a Skinner Object

    • skinnerWithBaseGeometry:bones:boneInverseBindTransforms:boneWeights:boneIndices:
      Creates a skinner object with the specified visible geometry and skeleton information.

    posted in Pythonista read more
  • JonB

    If you store the last volume, then the volume change would let you figure out if you went up or down...

    posted in Pythonista read more
  • JonB

    That shouldn't give you the ctypes error. The ctypes error is because it is still trying to create a custom structure rather than using the argtypes you provided.

    Can you print out .encoding for the method in question?

    posted in Pythonista read more

Internal error.

Oops! Looks like something went wrong!