I'm seeing a timing issue with loading a .sav file and when the player logs in.
The load proc gets called during world New() and it restores a global list from .sav file which if the .sav file is null, it gets initialized.
In the player Login(), I add a new item to that same global list but I'm finding the item gets blown away some amount of seconds afterwards.
If I add a spawn(30) to the start of the Login() so everything in Login (including ..()) is called 3 seconds later, the problem is avoided.
Is this a design problem on my end?
I do have an SSD. Could that be a factor?
ID:1288423
 Jun 9 2013, 2:56 pm (Edited on Jun 9 2013, 4:45 pm)
(See the best response by DarkCampainger.)
|
|
Yeah, I started working on it because I think it's a little odd. Execution of world/New() should always finish before clients are allowed to Login().
The easy repro is to add a sleep in world.New() and then make a any proc call afterward and you'll see that the client connects and Login() is processed while world.New() is still processing. 1: world/New() - Start: 92224 connected 2: Login(): 92225 3: world/New() - End: 92325 | |
It shouldn't matter what the call is (sleep or otherwise) provided it doesn't spawn off another thread. In my case, I was trying to load a swapmap template and then load the world saves files.I can add the check, just doesn't seem like I should have to.
I'm sure there's some reason although it seems like it would be a lot safer if the world finished initializing before clients were allowed to connect. | |
You can log into a game before world/New() is completed as far as I understand it.
This can be avoided by refusing to allow clients to connect until it is finished. (I've had similar issues with the way ss13-TG initializes its sql stuff.) I'd assume if this is going to be an online game you'd want to have admin-tools such as forbidding/allowing people from joining anyway. Just have that variable set to forbid, and toggle it to allow once world/New() is finished. Other games tend to have something like while(cant_join) sleep(10) in their Login() procs | |
Yeah, sounds like you should be refusing connections until you're ready for them, and you're assuming that it's doing this for you.
| |
I did a quick test, and it looks like so long as you don't sleep in world/New(), it should be called before Login(). However, it's possible any IO operations will cause an interrupt in the current virtual thread...
If you can't get the call order you want, you could always use a temporary "queue" list if the global list isn't initialized, and have world/New() add any items in the queue to the global list once it's done.