libload and rigid body objects falling (need help)

Hi,

when using libload to load other blend files all the dynamic objects on those blend files sometimes load faster than all the other objects like the terrain ending up falling into oblivion. Is there a way to control how the objects on a loaded file appear or is there another way of doing this?

In my situation, I use a blend file with a libload script to load:- another blend file with a static object (the terrain) and some rigidbody objects(barrels)

  • even another blend file with 1 rigidbody(the tank)

Most of the times when I start the game engine, all dynamic object even those in different blend files fall before the terrain loads, very few times the tank loads after but the barrels no, and even fewer times every rigidbody loads in place or tumbling around.

I even tried to delay the loading of the file with the tank but no success.

The solution I have at the moment is to reposition the tank by pressing a key to it’s original position.

A way that I didn’t try yet was to load all rigidbody with physics disable and enable them after a certain time, but that will require a lot of work to do it in all objects so I wanted to ask here 1st if anyone has a better solution.

How the files load most of the times, see the small barrels at the distance and the tank falling


How the files load very few times


Thanks in advance,

Cheers

It sounds you are running several LibLoad sessions asynchronously.

Each single load will add it’s objects when finished. As you have multiple loads it depends on the load time when the objects appear the scene. They have no relationship to each other.

Just now I see two options:

A) ensure to finish loading the “framework” before start loading other assets
B) load framework and assets from one scene (single load call)

When you already use a single load, I would say it is a bug. Splitting the load into different load session (solution A) might be a workaround.

Instead of doing async libloading, use normal libloading.
The problem is likely this:

  1. You start the load of the tank
  2. You start the load of the terrain
  3. The tank finishes loading
  4. The tank falls into oblivion
  5. The level finishes loading

So you have to figure out what can be loaded when. For example, if there were multiple tanks you could load them all at the same time, but you have to load them after the level,

In the systems I build, I load everything on a hidden layer and use addObject. This way I can load things whenever I like, and then can add everything into the scene at the same time - starting the game.
This is also useful with things like enemies. You libload it once, and then use empties around the map to mark where you want the enemies to spawn.

Loading a game is suprisingly hard, and I’ll be interested to hear about the system you come up with.
If you want to see an example, have a look at the load script in CaveX16

Why did the multithreaded chicken cross the road:
"a man see to laying bricks "

duplicated post deleted

Thanks for the answer Monster, actually I gave up asynchronous LibLoad months ago as they randomly crash blender when loading with no feedback so it’s hard to track the cause.

So what seems strange is that the terrain (static) ‘framework’ is being loaded with the barrels (dynamic) from the same file and those barrels fall just like the tank that is loaded from a different file.

So I will try to separate the dynamic objects into another file and load that file from the terrain file and see what happens.
I will also separate the loading of the tank into another script with a delay instead of loading both files within the same script (I guess that the instruction on a script will only happen after the script runs fully and that is why it didn’t work before.

I’ll tell you later how it worked, thanks.

Thanks sdfgeoff,

I’m using normal libload this way:

  • a script loads the file with the terrain and barrels 1st
  • same script loads the tank 2nd

suposition:

  • becouse the same script is doing the loading of both files it’s doesn’t care for the order in which they are in the script, they both load at the same time or randomly in sequence (not sure what).
  • mesh of the terrain is much heavier with all the textures and takes longer to load or show and the barrels load faster and start to fall and the tank also lighter loads faster than the terrain mesh also and start to fall

I think this is what’s happening because I only started to have this problem when I created this much heavier terrain, with other simple terrains with also dynamic objects loaded the same way, this doesn’t happen.

I’ll figure a way from yours and Monster suggestions.

“Loading a game is suprisingly hard, and I’ll be interested to hear about the system you come up with.”
I subscribe to that :slight_smile: and I’ll keep you posted

“If you want to see an example, have a look at the load script in CaveX16
Really nice work on CaveX16 congrats, thanks for the script I’ll study it.

If you have a script:


libload(scene1)
libload(scene2)

it is the same as:


libload(scene2)
libload(scene1)

Because they happen in the same frame.

So try inserting a frame or two of difference between them for the scenes to merge properly. If you’re in module mode you can do:


def load1(cont):
    libload(scene1)
    cont.script = __name__ + '.load2'

def load2(cont):
    libload(scene2)
    cont.script = __name__ + '.load3'

def load3(cont): 
    ....

or what I do in CaveX16 is something similar to:



def load_function_1(cont):
    do_something

def load_function_2(cont):
    do_something_else
...

LOAD_MAP = [
    load_function_1,
    load_function_2,
    load_function_3,
]

def load(cont):
    for sens in cont.sensors:  # Stop execution on release of sensor
        if not sens.positive:
            return
    count = cont.owner.get('load_count', 0)
    if count < len(LOAD_MAP):
        LOAD_MAP[count](cont)
        count += 1

yes sdfgeoff that’s what was happening as you can see in the code below,


def load_library(lib):
    bge.logic.LibLoad(lib, 'Scene',verbose=True,async=False,load_actions=True) 
    load_actions=True


def init(cont):
    # verbose
    print("#######  MATCH FILE STARTED #######")


    path = logic.expandPath("//SaveLoad/")
    file = open(path+"match.txt", "r")
    line = file.readline()   #.replace("
","").split(",")
    bge.logic.globalDict = ast.literal_eval(line)


    ### load map
    if "map" in bge.logic.globalDict:
        map = bge.logic.globalDict["map"]  
        load_library (map)
        print ("map loaded:", map)    
    else:
        # load default map
        map = "//maps/testmap/testmap.blend"
        load_library (map)
        print ("default map loaded ...",map)
        
    ### load vehicle
    if "vehicle" in bge.logic.globalDict:
        vehicle = bge.logic.globalDict["vehicle"]  
        load_library (vehicle)
        print ("vehicle loaded:", vehicle)    
    else:
        # load default vehicle
        vehicle = "//vehicles/test_vehicle/test_vehicle.blend"
        load_library (vehicle)
        print ("default vehicle loaded ...",vehicle)

Changing that to load the files on different frames didn’t prevent the barrels on the same file as the map to fall and still needed to adjust how spaced the 2 files (tank and terrain) should load in frames.

So, the quickest solution I found that is working now is:

  • keep the code as it is but separate the barrels to another file and load them with libload from the map file. The result is: they load as they should with a 1 to 2 seconds delay after the map is visible and no more tumbling around :slight_smile:
  • For the tank the solution was different, just put a disable dynamics with logic brick on the tank and enable physics again after 120 frames

I could do this in so many different ways like loading the tank from the map file also but that would need me to change a lot of code in different files moving around variables and the way I made the system work as it needs to read files for preferences and configurations that I prefer to handle on the file that is loading the maps and vehicles.

It’s working 100% now :slight_smile:

But still, your suggestion is good sdfgeoff, i’ll keep in mind if I’ll need to get back to this.