As for the example: well... not really... I picked up this task because there were a TODO and a feature request about it... So there probably are people looking for it... I think the main idea is to be able to check if a feature is available or not, etc. But of course, if Blender's version is lower than the current one, this function won't be present either. :-/

Maybe you should ask @Marcin Nijaki (marcino15) directly.

It looks ok to me

In D1348#26839, @Porteries Tristan (panzergame) wrote:

but do you have an example of his usage ?

An example would be: when a game has been deployed and you need to update blenderplayer for bugfixing purposes then a simple way to know if it is necessary to update your blenderplayer executable is to compare which blender version you have installed against bugfixing version.

Game developpers use at least the lastest blender version, no ? so they don't need this check if the bug is fixed in lastest versions. And if is a lambda user who only play the game, the blender and blenderplayer are generaly provided with the game.
Althoug this patch can be useful, but in very unusual case and not recomanded (for me).

I mean: a gamer launch his BGE "AAA" game :-), then the game connect itself to a server to check for updates (blends or executable). Then a way to know if you game needs to be updated is to know which version your game is.

@Porteries Tristan (panzergame),
blender version is nothing to do with logic really.

Suggest to have bge.app.version for application level info.

Check how bpy.app is implemented. source/blender/python/intern/bpy_app.c

This revision now requires changes to proceed.Jun 14 2015, 10:42 AM

Ok.

Should we agree on other elements to port from bpy.app? Like all three bpy.app.version_*, some of the bpy.app.build_*, etc.?

if there are others that make sense to add, you could suggest - but dont think this is a requirement. (others can be added as neeeded, as we did for bpy.app).

Note, dont think this should fully duplicate bpy.app, a lot of vars there dont make sense for BGE.

Updated the diff to reflect changes that have been asked for. I implemented following attributes:

version (tuple of three ints)
version_string (str)
version_char (str)
version_cycle (str)
ffmpeg (bool)
sdl (bool)
bullet (bool)

Notes:

maybe names ffmpeg, sdl, bullet should be changed to something more explicit, like "use_ffmpeg", etc. not to mix up with same attributes of bpy.app and to show these are no modules but simple booleans.
bullet refers to the build option (WITH_BULLET), not to the one specifiable in the UI (panel World). That last one isn't found in bge AFAIK - should it be? (like in www.blender.org/api/blender_python_api_2_74_release/bpy.types.SceneGameData.htmlbpy.types.SceneGameData.physics_engine)

Also updated Revision title & summary.

Added new bge.app.rst doc file.

Campbell Barton (campbellbarton) added inline comments.Jun 15 2015, 6:27 PM

source/gameengine/Ketsji/KX_PythonInit.cpp
2027	these lines changed in master. (trivial to update)
2588–2608	suggest `has_` prefix for compile time options.

note on sdl/bullet/ffmpeg... it could be nicer to check feature support.

EG: has_joystick has_physics has_texture_video

Could you add an atribute for audaspace ? like : bge.app.(has_)audaspace

Yes, next update will have has_sound option. Coming soon!

Quentin Wenger (Matpi) updated this revision to Diff 4405.Jun 15 2015, 7:21 PM

Note, not sure about has_sound, Its currently impossible to compile BGE without WITH_AUDASPACE.
(unless someone added ability recently).

Campbell Barton (campbellbarton) added inline comments.Jun 15 2015, 8:16 PM

doc/python_api/rst/bge.app.rst
31–35	Is this really needed?

About has_sound: you're right as for the current status, but I have seen many checks for WITH_AUDASPACE in the BGE code. Is is such a problem to have an attribute (currently) always set to True?

doc/python_api/rst/bge.app.rst
31–35	No strong opinion, I can delete it if you wish. I first thought it would be a convenient way to check for release status, which is maybe not that useful?

would just avoid adding useless options here.

anyone who reads API docs may investigate when has_sound needs to be checked... only to find never. Simple rule - only add useful attributes.

Deleted both version_cycle and has_sound (useless atm).

Campbell Barton (campbellbarton) added inline comments.Jun 15 2015, 8:41 PM

source/gameengine/Ketsji/KX_PythonInit.cpp
2027	This still needs updating to match master.
2558	should be "bpy.app"
2574	This is left over from old days where we could do `import GameLogic` This line allows for `import Application` But I think we should only have access via `bpy.app`
2609	style.

Quentin Wenger (Matpi) added inline comments.Jun 15 2015, 9:07 PM

source/gameengine/Ketsji/KX_PythonInit.cpp
2027	Will be done, sorry.
2558	No, "bge.app". ;-)
2574	Didn't know this was not meant to be kept as a feature. Will update.
2609	Sorry, don't get what's wrong with it?

Quentin Wenger (Matpi) updated this revision to Diff 4408.Jun 15 2015, 9:13 PM

Campbell Barton (campbellbarton) accepted this revision.Jun 15 2015, 9:19 PM

Campbell Barton (campbellbarton) edited edge metadata.

This revision is now accepted and ready to land.Jun 15 2015, 9:19 PM

Closed by commit rB1c707a239258: BGE: Fix T43918: adding submodule bge.app including attribute version. (authored by Porteries Tristan (panzergame)). · Explain WhyJun 15 2015, 9:47 PM

This revision was automatically updated to reflect the committed changes.

BGE: Fix T43918: adding submodule bge.app including attribute version.
ClosedPublic
Actions

Details

Diff Detail

Event Timeline

Revision Contents
Changeset List

Diff 4409

doc/python_api/rst/bge.app.rst

doc/python_api/sphinx_doc_gen.py

source/gameengine/Ketsji/KX_PythonInit.h

source/gameengine/Ketsji/KX_PythonInit.cpp

BGE: Fix T43918: adding submodule bge.app including attribute version.ClosedPublicActions