That is right, I switched from ATI to NVIDIA. So that means the Method does not work at all because of the Graphicscard… then I guess it is not really a Bug in Blender/BGE… 
@ Moguri:
Just tried with the new build. But there seems to be a problem. I’m sorry to say, but your fix causes another issue. Try LibFree_crash_bug.blend in T40172 LibFree() crashes Blender.
The file frees one library every logic tic. But pressing ‘Spacebar’ causes all icospheres to disappear at once. Instead they should disappear one at a time. To see this more clearly, only after all libraries are freed an empty list will print to the Console.
Thanks a lot.
Edit: Unfortunately this fix also doesn’t work with LibLoaded objects. I’ve added a new bug report: T40199 LibFree() crashes Blender with LibLoaded objects. I hope this helps.
@Linkxgl and Mahalin
Yes, we need SDL2 for hot-plugging joysticks. This could be looked into, but not for the 2.71 release since we’re in BCon3 (bug fixes only).
@MarcoIT
What I was saying, is that your blend file might not expose all of the memory leaks. In other words, as you continue to use the NavMesh features, let me know if you find more leaks.
@C.A.ligári
Here is the bug report for VideoTexture (which has the same alpha issue): https://developer.blender.org/T32175
@Raco
All of the icospheres use the same material. And, when a material is freed, all meshes using it are also freed. When they were not being freed, you’d get NULL pointers since meshes were using freed materials, which caused the T40172 crash. I’ll look into T40199.
I understand. But when freeing LibNews wouldn’t it be better not to free the material at all? Then there’s no necessity to free all meshes with that same material. Only problem then is that freeing LibLoads would cause a memory leak. To avoid this I’m thinking that setting a condition could do the trick. If the library name ends with ‘.blend’ you’ll know it’s a LibLoad so then the material should be freed as well. Of course I know to little about all this so just take this as me guessing a way out.
Thanks. I’d like to say that this case is actually the problem I was facing from the beginning. But I tried to narrow it down to T40172. I didn’t know that this was a two-sided problem however.
I’ve fixed T40199, and by doing so also fixed T35845 (the other similar LibFree() bug). I can start looking into the issues with shared materials as well, but I think I might want to tackle some non-LibLoad/New/Free issues next.
Yes of course. With that what’s already done common use of the Lib family is possible. That should be enough for right now. The issue with shared materials can wait (in my opinion). So many thanks and compliments for your outstanding work!
So many thanks and compliments for your outstanding work!
I say even more: So many thanks for all your hard work and acomplishements!
Yeah efficient libLoad, etc is very important for large games, with dynamic loading bubbles etc.
Thank you again.
Was wondering if anybody has noticed large hitches when using LibLoad with async. I’m running on linux and the load time for a blend seems to be slower using async than without it.
I have a project on github that you can see this in. Use the run_blenderplayer.sh to start the game and press “numpad 7” to unload and load the level.
I think Asynch takes longer because it is still running the game loop, where as LibLoad loads first then continues, pausing the game loop while loading,
For anyone who will be using LibFree on LibNews I’d like to point to these two examples: LibFree_crash_bug.blend and LibFree_with_LibLoad_crash_bug.zip. Of course they don’t crash anymore because Moguri fixed those bugs. But as you can see there’s still a problem with materials in the first example. When an object is freed, all objects with the same material are also freed (which avoids the crash). Surprisingly not in the second, probably because the meshes are LibNews of a LibLoaded object, not of an object that was already in the scene. So, the combo with LibNew and LibLoad seems to work perfectly! I’m very happy.
When deactivating “Color Management”, the World Background Color still stays the same while other Colors change – would be no Problem, but the Colors of the Mist and the World Background do not match, and that is problematic. (Deactivating the Color Management increases Performance and is thus rather desirable for a User of the Game Engine.)
I just tried it in blender-2.70-07e8096-win64 from builder.blender.org and unfortunately the Bug has not been fixed, it still looks the Same.
Have you got a .blend file that Britaa/moguri can use?
@ Moguri & agoose: I have taken a Look at the .blend given in that T38051-Bugreport and that one worked for me – on closer Inspection, the Uploader had also set the Color Management in the Scene Tab to “None”. So in Render you have to uncheck Color Management AND you have to set Color Management in Scene to “None”, then it works and the Colors fit. But then again, you can set the CM in Scene to “None” and keep it in the Render Tab, then the Colors are yet again not matching.
Of Course, that makes Sense, even if it seems like a rather unnecessary Complication, though not quite a Bug then.
Sorry for yet another more or less false Alarm, and thanks for leading me to that more or less helpful Blend File. 
When adding 10+ unnamed (And, And1, And2 etc.) “and” controllers they start doing weird stuff, like linking up across states (when one deletes so does the other) and refusing to be moved up and down.
I don’t know if this is a bug,
but parenting compound physics bounded - rigid-bodies together, works in game, however
the item can be impacted, and deliver impact, but can’t receive impact, unless you hit the root parent,
Want a video?