This should be dealt with later once the BGE is refactored.

So another idea I have is we could maintain a list of the non-culled items (i.e. visible) by adding objects to a list in the Physics callback e.g. m_nonculledobjects.push_back(KX_GameObject). We would clear it each frame before doing the culling check. Of course, it would be valid only for that frame.

Fix

As far as I can tell, GameKit development looks dead :/

Can this be merged?

Ah, awesome! This could probably be marked as resolved. Hmm, is it possible to use a default material if no material exists?

No issues here on Arch Linux 64-bit with Intel HD4000 or GeForce 610M.

I think this is the same bug based on the crash log:
https://developer.blender.org/T39056

Textures don't work on subclasses of KX_GameObject due to the way BlendType.h checks the class using strings. The problem is tp_name is returning the subclass's name instead of KX_GameObject. I think it would be better if the functionality was similar to KX_GameObject's ConvertPythonToGameObject function, which uses PyObject_TypeCheck (objects) instead of tp_name (strings).

Alright, I broke down the patch into 3 parts. To keep it simple, I'll only attach patch #1 in this task and create separate tasks for the other two, and keep the discussion of this task to patch #1.

The latest patch (v3) supersedes the others. v3 automates the adding and removal of layers since that was too much boilerplate code. I guess it is a refactor then? For future reference, I'll keep that in mind.

Version 3:

• BL_Action is now a game type (subclass of PyObjectPlus)
  • Methods: play, stop, isPlaying. The other former methods of KX_GameObject, i.e. getActionFrame, can be accessed through the attributes.
  • Attributes: name, layer (RO), frame, frameStart, frameEnd, priority, blendIn, playMode, layerWeight, ipoFlags, playbackSpeed, blendMode.
• Simplified the action related functions in KX_GameObject to only 3: getActionList, isActionValid, createAction.
  • getActionList returns a list of BL_Action objects. The name of the action is used as the name representation.
  • isActionValid checks if the specified layer is valid; could be removed as the user could just get the action list and check the length.
  • createAction is similar to playAction, without the layer argument and it returns a BL_Action object instead of a layer (layer can be accessed with BL_Action.layer)
    • It was renamed because it made more sense than playAction or addAction. To me, addAction implies adding an action object from a preexisting list of objects, like addScene.
    • How it works: The user calls createAction -> calls AddAction and then PlayAction -> returns newly created BL_Action object.
• To explicitly remove a layer, call BL_Action.stop() on the layer and it will automatically be removed on the next BL_ActionManager.Update.

Version 2:

• I removed the addAction and removeAction methods from the Python API as I thought this was cumbersome -> too much boilerplate code.
  • So like before, the user calls playAction which plays the action but it will also create the layer if it doesn't exist. Additionally, it will return the layer number in case the user needs verification. However, the other methods, e.g. stopAction, getActionFrame, etc. will throw an error if the specified layer does not exist, rather than create it automatically like playAction; there really should be only one way to create the layer. This is better than passively handling it so the user doesn't wonder why the animation isn't playing (because they didn't play/create it first).
  • I left isActionValid so the user can check beforehand if needed, otherwise the error will stop the script.
• I added getActionList(), to allow the user to retrieve the list of actions.
  • It returns a list of the current frames of the action for that layer (index). My preference is to properly expose BL_Action, which is my next task.
• When the update method of BL_ActionManager is called, it removes the layer from the list if the animation is done.
  • Some concerns remain about this. Another possibility is to have the user specify whether they want the layer to be automatically removed upon the animation ending, however I think the user need not be this concerned about memory management.

Linux 3.12.5-1-ARCH
Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz
Intel HD4000