Loader::addPlayer() would oftentimes fail because it mistakenly assumes that a player object will be created after it sends a finishing ResourcePackClientResponsePacket::STATUS_COMPLETED message. However if the server is brand new, or hasn't generated spawn chunks yet, PocketMine-MP may potentially defer on creating the Player object way after Loader::addPlayer() has returned.
And have addPlayer() return a promise that resolves with a Playerafter registering it as a FakePlayer, to be consistent with how the previous version similarly returned a Player after registering its corresponding FakePlayer.
Justification
FakePlayer is very useful for automated testing. Capital's suite tests rely on creating a brand new PocketMine-MP instance for its tests. For FakePlayer to work in that sort of situation, it has to handle the occasions where a player isn't created immediately.
Fixes Issues
21
27
Problem
Loader::addPlayer()would oftentimes fail because it mistakenly assumes that a player object will be created after it sends a finishingResourcePackClientResponsePacket::STATUS_COMPLETEDmessage. However if the server is brand new, or hasn't generated spawn chunks yet, PocketMine-MP may potentially defer on creating the Player object way afterLoader::addPlayer()has returned.Proposed Solution
Change
Load::addPlayer()'s signature to this:And have
addPlayer()return a promise that resolves with aPlayerafter registering it as aFakePlayer, to be consistent with how the previous version similarly returned aPlayerafter registering its correspondingFakePlayer.Justification
FakePlayer is very useful for automated testing. Capital's suite tests rely on creating a brand new PocketMine-MP instance for its tests. For FakePlayer to work in that sort of situation, it has to handle the occasions where a player isn't created immediately.