I’ve been trying to use Libload to better organize my current game, since it has over 200 megs of content, only a fraction of which is needed at any one time.
However I’ve been having random crashes using 2.75 which seem to be related to Libload (they only started when I added the LibLoad code to the game).
I’ve tired updating my graphics card drivers in case that was the problem, but I don’t think so.
The game crashes directly to desk top with not warning, and just before it does, the libloaded assets seem to become corrupted:
On the right you can see the cockpit, which is a libloaded mesh, has stopped being shaded (the green computer screen in the cockpit is shadeless, so it’s not about lighting) right before the crash.
My questions are:
Has anyone else had trouble with LibLoad recently?
Does it matter where Libload is called from? Is the data connected with anything in the code or scene?
I seem to remember people talking about Libload troubles, but can’t find the threads. And in my project the LibLoad code is called from within a FSM state object which is later discarded, but it should be linked to logic shouldn’t it? not the python object?
The only LibLoad crash I’m currently aware of that’s new to 2.75 is this one. LibLoading objects that play actions also still causes problems at times.
Has anyone else had trouble with LibLoad recently?
I am about to stall bge because of that.
I have to load and free blends with the same name,same objects and slightly modified meshes.
At least one of those 3 parts is crashing blender with no error message.
Trying to fix it would mean redoing the whole project…
No actions on the loaded objects and I always use material cache option. After some testing it might be related to adding and removing an overlay scene, but I’m not sure if the libload is the cause or just making the problem worse. I’ve never used Lib load in a finished project before for exactly this reason. It always gets too unstable before the project is finished.
Well I’m going to try some more tests and see if I can find the problem.
The best way to track down the issue in a complex setup is to compile blender from the sources with the debug symbols on, then run the program with a debugger, wait for the crash and look at the debugger output. That should give you an hint on how to make a small test case, for the bug report.
Thanks for the replies,
I tried asynch loading at first but that crashed almost every time.
I’ve moved the code which adds the overlay scene and put the libload script on the main object. That seems to have gotten rid of the problem for now. Calling the overlay scene repeatedly and deleting it each time the camera view changed seems to have been the problem. Though I’m not certain of why… It didn’t crash every time, only sometimes.
Once I’ve got a working demo, I should be able to get some feedback from others to see if there’s still a problem or not. For now I’m going to call the problem avoided but not solved.
Were you removing the active camera? I recently noticed that ending the currently active camera causes Blender to crash, though I haven’t submitted a bug report for it yet. I believe it started occurring after version 2.72. Here’s an example file.
Wish I could help, but I’m out of touch with LibLoad these days.
However, I have had problems like that black shadeless one before. It’s happened to me when I’ve libloaded too many lights, or too many textures and the graphics card complains.
So:
Check that none of the blends you are loading have lights. Even in inactive scenes. Everything in the blend is loaded, regardless of if it is in the active scene. This means that lights for testing textures etc. cause problems.
Make sure that all blends only have the required textures in their texture manager.
I don’t think lights are freed properly from LibFree either. I think they hang around in the graphics card’s ram. I don’t have any data to prove this, but it is a suspicion I hold.
Thanks sdfgeoff I suspect thats the right answer. After clearing some junk from the libloaded blends and updated my graphics card drivers there’s no problem.
I noticed it crashes on my PC using big textures. I use many smaller textures under 1024 with no problems. Using 2.75
Also if you have logic that is missing something, like say something is looking for a property that isn’t there, it will crash. So make sure all your logic is correct.
I can libload actions, but no Armature actions. So you can libload simple actions.
(IPO?? what do you call them now?) IE a door opening, an elevator.
Lights also don’t cause a problem for me, I have a scene with 3 point lights, and 3 spot lights, that cause no problems.
I’m still experimenting with it, though.
I’m actually excited that this is working good enough for me, for now.
My graphics card is a Invidia GeForce GTX 965, if that matters.
I had planned to import some robots with armatures and actions, but I think I may just put them in the main blend and import only the different skins.
(I did try it with an old project that uses Libload of armatures with actions and didn’t get a problem. But if it causes problems on some computers then that’s not good for me, since I won’t be the only one who will be playing it.)
Yeah, since 2.75 is broken, I rolled back to 2.71. AFAIK that’s the last build where joystick logic bricks, libload with armatures and lights worked.
Still don’t know if it will work in runtime yet, haven’t gotten that far yet.
P.S. I tested removing libloaded lights with endobject logic bricks (Keyboard “K” — and — end object) In 2.75 it Worked OK while playing the game, but crashed to desktop on “esc”. Works in 2.71.
since libload, and joystick logic bricks don’t work, that ends 2.75 for me.
So you can libload simple actions.