Ace Dragon: We shouldn’t limit improvements to the BGE based on maintaining backwards compatibility. If users who have existing logic setups don’t want to reprogram for the new API, they can finish it in the old version of blender. It’s not hard to install two versions of blender.
In the favor of improving the API, everyone is going to have to deal with script rewrites anyway. Especially with the new module names, and switching to Python 3.
-Sunjay03
I am completely against maintaining two separate APIs. I say just keep the same one but continue to expand it as is currently happening. Separating the APIs offers little to no benefits, and I’d rather not break scripts unless the gain is worthwhile.
Well, let’s try to understand the overall point:
In the framework of the logic brick system, the python controller represents a truly stunning break in consistency: The sensor->controller->actuator methodology is undermined by python scripts which can access and modify the overall game-state, independent of any actuator.
The distinction between controller and actuator is then lost.
So, I don’t think gomer is actually advocating for two separate fully-featured python APIs. I think he’s just recommending an overall simplification: python controllers should be lobotomized, to the point where they can only modify game state via actuators (iow: you can only write a controller, and nothing more, to activate actuators based on information carried by the sensors), whereas the full features of the core python API will be available for those who use a python class for the game object in question.
How this helps us:
- There is a clear distinction between the logic bricks system, and the python scripting interface.
- The consistency of the logic brick system is preserved.
- New users are not overwhelmed with complex python scripts which act as pseudo controllers/actuators.
- We can work on improving the python scripting interface without having to think about how it affects the logic brick system.
Hey Moguri, your patch works very well on Linux so far, thank you!
Do we have to implement all callbacks in C++ first? And when we derive our class from KX_GameObject we specify all the callbacks that we need? I think your solution is a much better approach then it is at the moment in the BGE.
Tested it with about 700 Cubes falling on a collision callback object thats prints the names of the cube. The (logic) performance is great!
I will use and test your code the next time. Hope this is going to be merged in trunk.
greetings, moerdn
Sorry to bring up an old thread, but is this going to be an addon? Or is it already in the Blender Trunk? I didn’t see it there.
Moguri’s patch is not in trunk yet, but you can apply it to your own builds and test it out.
Not sure how to do that…but will it be part of the trunk at all? I hear it has to have a certain number of downloads or something…