Sensing when people leave an area, dedi save/load

[Mr. Wallet]

I didn't know there was such a function.

I guess it serves me right for not doing it properly and just tracing a load, but I didn't want to launch BL yesterday lolol

[Ad Bot]

[Mr. Wallet]

In my new gamemode, I want to load a .bls as soon as possible when the server is starting. However, I don't know which file until the server starts up and reads the path from a file.

Hypothetically when the scripts are loading up I could just take the entire save file and write the contents to Add-Ons/GameMode_My_New_GameMode/save.bls, but this is slow and kludgy, and gets even worse if I ever .zip up the gamemode.

So I figure either there's a variable I can set before it actually attempts to load save.bls that I can change so it loads something else, or otherwise there's some callback I can do so after it loads the empty save.bls, it immediately loads the file I want. Unfortunately BL is crashing before it gets to mission setup when I turn trace on, so finding a good insertion point myself would take oodles and oodles of probing.

As a last resort I can just set a global boolean on the first ServerLoadSaveFile_End() when starting up or changing the gamemode, so that when save.bls finishes loading I automatically start off loading mine because the boolean's not set yet.. I suspect this is not the best way to do it, however. Any ideas?

[Greek2me]

Use onMissionLoaded(). There are no arguments.

[Mr. Wallet]

edit: disregard this I think I finally figured it out

Basically I am frankensteining the entire save/load and gamemode systems and BL is barfing all over itself at every turn

It still doesn't work but I'm making progress

[Mr. Wallet]

OK I am really stuck for real again.

I couldn't get the thing to load when packaged from onMissionLoaded(), nothing was happening. I figured out that onMissionLoaded() is called within createMission(), so I have a package with

Code: [Select]

function createMission() {
Parent::createMission();
my_initialization_function();
}
That at least gets the bricks loading, so something happens between onMissionLoaded() and the rest of createMission() to let loading work. But then BL freaks the forget out, and I think it's because multiple loading commands are overlapping, either temporally or just in terms of variables being changed. It gives an error of how the loading bricks brickgroup doesn't exist, and then the next load doesn't work right, but then other loads do. I think.

Well, I don't actually have any idea what's happening, but obviously I am short-circuiting some kind of global boolean or repeating scheduled process, or otherwise cutting in on initialization somehow.

So I thought, OK, I'll let the save.bls load completely finish before I start my first load. It wouldn't try to load the gamemode's save.bls before it's possible, right? So after that's completely done has gotta be safe.

So when I package ServerLoadSaveFile_End() to wait for save.bls to finish, nothing happens. Apparently as far as I can tell, the automatic load of save.bls isn't calling ServerLoadSaveFile_End() at any point, either because the file is completely empty or because loading is different for gamemode initialization. If I just stick an echo in ServerLoadSaveFile_End(), it echoes for all loading except for that automatic one.

So I have a special case where I think I need to wait for loading to finish, maybe? but once again I don't know when it's finishing.

[Greek2me]

Oh, sorry. You have to set a schedule of 0ms within onMissionLoaded.

[$trinick]

This probably isn't the answer you want to hear, but why are you opposed to creating a gamemode and using that to load your save on start?

[Mr. Wallet]

Oh, sorry. You have to set a schedule of 0ms within onMissionLoaded.

Is that after parent? Or should I not call parent?

[Port]

Is that after parent?

Doesn't matter, considering the schedule would run in the next frame anyway. No matter what, it'd be after the parent.

[Mr. Wallet]

1. If I don't call the parent then it won't be after the parent, because there won't be a parent. If the parent is doing something that would break this I need to not call it.

2. If the parent sets up any 0 ms schedules for exactly the same kind of reason I am, then the order that they run depends on whether I call the parent first.

[$trinick]

1. He didn't say not to call the parent.

2. No it doesn't, they would both be scheduled for the next frame and there's no guarantee either will run before the other.

[Mr. Wallet]

1. He didn't say not to call the parent.

He didn't not say to not call the parent.  

Also I thought the BL engine was bad, but not having first-in-first-out on identical-time schedules is pretty awful.

[Greek2me]

He didn't not say to not call the parent.  

Also I thought the BL engine was bad, but not having first-in-first-out on identical-time schedules is pretty awful.

Yes, call the parent.

It actually does have first-in-first-out, so you should call the schedule after the parent.