Did anyone (else) notice a new LibFree/LibLoad issue with blender (2.74)? The difference with the old one is that this time it goes always south (at gpu_draw.c:1151, according to gdb).
I thought they finally fixed libLoad
I didn’t check if the old bug is still there, this one is different and quite nasty, I wasn’t able to create a test file, it only happens in my game prototype. Lucky me :D.
One thing I learned when working on Deep Space for four years was … I should have picked a blender version and stuck with it. I spent weeks updating from one version to the next (at that time the materials went through an overhaul, so I ended through each object/level/thing many times). I also find that the more blender versions you go through, the less stable a blendfile is. If you remake it from scratch (or at least open/save/close), you can often solve linking + libload problems
C’mon, where’s your spirit of adventure. Anyways, my way from now on will be to avoid LibLoad entirely :D. I’ll follow the way of the “link stuff from blender before to run the game”. Let’s see how it goes…
[update] Well, my guess is that linking stuff doesn’t really work that well with the game engine. One file for all!
I don’t know why they don’t debug libLoad and libFree, I is not possible to make big games (with lots of objects and textures) without it !
For me, blender 2.72 is still the last blender version where libFree doesn’t crash blender all the time. It is just necessary to sleep 1-2 seconds between each call (asynchronously).
To avoid the known crashes with LibFree you should disable “use material caching”. There is a bug - a dangling pointer in the scene converter - that causes pseudo-random crashes. I’ve submitted a patch for it three decades ago but there are like three different bugs on the same source file, the source code didn’t age very well, so the actual fix might take some time.
That LibFree bug doesn’t explain the other issues you are experiencing, unless they only happen after at least one LibFree.
Admittedly I haven’t played with libload on 2.74, due to not having enough time. But I haven’t had problems with stability.
I wonder if it’s platform dependent. I made Neon ball a while back, and it runs fine on my Linux machine, never crashes. But when one of my friends plays it on his Windows machine, it crashes after every level.
No idea what the difference is.
Planetside 2 crashed and ran crappy on my pc, until a recent windows update, now I am getting 60+ fps…
used to take forever to shut it down as well.
Disabling “use material caching” may solve some things, but overall, there’s still to much problems in the Lib family.
The BGE can still be used to create many intuitive games without it though, but as a programmer I’m just not comfortable with the alternative workflow. Using the Lib family is the obvious way to generate scenes, even for small games. So until this is fixed I’ve stopped using the BGE entirely.
for different reasons (i not get any crashes but i get a lot of mess with texture actions materials, using link group)
“One file for all” seem the unique effective way
EDIT:
Libload -> do mess with actions (all right with materials/textures)
link group -> do mess with material textures AND actions
so afaik the unique problem of LibLoad is about actions (but is not a little problem)
all these problems happen when there are 2 stuff with the same “NAME” .
if you give a name unique to anything (material,texture action blah blah) all work well both with LibLoad and LinkGroup.
just seem a “bit dirty” call a material “54564151”
In the end it’s a tradeoff, I’m still willing to deal with all the quirks because I don’t want to go down the asset pipeline hell that is working with some of the (many) alternatives. In the meantime I keep my fingers crossed and hope that, when this gooseberry thing is over, the foundation will start taking care of the game engine again.