Issues in LoadBalancing
Options
Hi,
i have some problems with LoadBalancing and want to share it with public. It will be great to see problems fixed in next release.
1) Connecting closed room[code2=cpp]client.cpp:
343 if(mAutoJoinLobby)
343 {
344 opJoinLobby();
345 mLastJoinType = JoinType::AUTO_JOIN_LOBBY;
346 }[/code2]
After this mLastJoinType loses previous value and so onConnectToMasterFinished doesnt call mListener, but my photonclient still waits.
You can reproduce it by connecting to room, that just closed.
I fixed it by using this code:
[code2=cpp]client.cpp:
345 mLastJoinType = JoinType::AUTO_JOIN_LOBBY;
->
345 //mLastJoinType = JoinType::AUTO_JOIN_LOBBY;
...
463 if(mLastJoinType == JoinType::AUTO_JOIN_LOBBY)
->
463 if(mAutoJoinLobby)[/code2]
2) Room destroy crash
[code2=cpp]Client.cpp
621 for(unsigned int i=0; i<keys.getSize(); i++)
622 {
623 Hashtable val(ValueObject<Hashtable>(roomListUpdate.getValue(keys)).getDataCopy());
624 bool removed = ValueObject<bool>(val.getValue(static_cast<nByte>(Properties::Room::REMOVED))).getDataCopy();
625 int index = mRoomNameList.getIndexOf(KeyObject<JString>(keys).getDataCopy());
626
627 if(!removed)
628 {
629 if(index == -1) //add room
630 {
631 JString roomNameValue = KeyObject<JString>(keys).getDataCopy();
632 mRoomList.addElement(createRoom(roomNameValue, val));
633 mRoomNameList.addElement(roomNameValue);
634 }
635 else // update room (only entries, which have been changed, have been sent)
636 RoomPropertiesCacher::cache(*mRoomList[index], val);
637 }
638 else if(index > -1) // remove room
639 {
640 destroyRoom(mRoomList);
641 mRoomList.removeElementAt(index);
642 mRoomNameList.removeElementAt(index);
643 }
644 }[/code2]
Looks like a bug. I have crashes in my game with this code. I used this fix:
[code2=cpp]client.cpp:
640 destroyRoom(mRoomList);
->
640 destroyRoom(mRoomList[index]);[/code2]
3) Player name
There are some problems with changing player name by using standard function(viewtopic.php?f=8&t=3927):
mLoadBalancingClient.getLocalPlayer().setName(NewPlayerName);
So i added this function to Client.cpp and use it before connect() function(For some reasons i dont know playerName when LoadBalancing::Client init):
[code2=cpp]void Client::setPlayerName(const Common::JString& name)
{
mLocalPlayerName = name;
}[/code2]
4) Player properties
In my game i use player properties to store some player info. There are some properties that changes during a game(like player state). It was not working for me with standard code so i changed it:
[code2=cpp]Client.cpp
727 if(props.contains(static_cast<nByte>(Properties::Player::PLAYERNAME)))
->
727 //if(props.contains(static_cast<nByte>(Properties::Player::PLAYERNAME)))[/code2]
I dont know why props needs to contain PLAYERNAME.
i have some problems with LoadBalancing and want to share it with public. It will be great to see problems fixed in next release.
1) Connecting closed room[code2=cpp]client.cpp:
343 if(mAutoJoinLobby)
343 {
344 opJoinLobby();
345 mLastJoinType = JoinType::AUTO_JOIN_LOBBY;
346 }[/code2]
After this mLastJoinType loses previous value and so onConnectToMasterFinished doesnt call mListener, but my photonclient still waits.
You can reproduce it by connecting to room, that just closed.
I fixed it by using this code:
[code2=cpp]client.cpp:
345 mLastJoinType = JoinType::AUTO_JOIN_LOBBY;
->
345 //mLastJoinType = JoinType::AUTO_JOIN_LOBBY;
...
463 if(mLastJoinType == JoinType::AUTO_JOIN_LOBBY)
->
463 if(mAutoJoinLobby)[/code2]
2) Room destroy crash
[code2=cpp]Client.cpp
621 for(unsigned int i=0; i<keys.getSize(); i++)
622 {
623 Hashtable val(ValueObject<Hashtable>(roomListUpdate.getValue(keys)).getDataCopy());
624 bool removed = ValueObject<bool>(val.getValue(static_cast<nByte>(Properties::Room::REMOVED))).getDataCopy();
625 int index = mRoomNameList.getIndexOf(KeyObject<JString>(keys).getDataCopy());
626
627 if(!removed)
628 {
629 if(index == -1) //add room
630 {
631 JString roomNameValue = KeyObject<JString>(keys).getDataCopy();
632 mRoomList.addElement(createRoom(roomNameValue, val));
633 mRoomNameList.addElement(roomNameValue);
634 }
635 else // update room (only entries, which have been changed, have been sent)
636 RoomPropertiesCacher::cache(*mRoomList[index], val);
637 }
638 else if(index > -1) // remove room
639 {
640 destroyRoom(mRoomList);
641 mRoomList.removeElementAt(index);
642 mRoomNameList.removeElementAt(index);
643 }
644 }[/code2]
Looks like a bug. I have crashes in my game with this code. I used this fix:
[code2=cpp]client.cpp:
640 destroyRoom(mRoomList);
->
640 destroyRoom(mRoomList[index]);[/code2]
3) Player name
There are some problems with changing player name by using standard function(viewtopic.php?f=8&t=3927):
mLoadBalancingClient.getLocalPlayer().setName(NewPlayerName);
So i added this function to Client.cpp and use it before connect() function(For some reasons i dont know playerName when LoadBalancing::Client init):
[code2=cpp]void Client::setPlayerName(const Common::JString& name)
{
mLocalPlayerName = name;
}[/code2]
4) Player properties
In my game i use player properties to store some player info. There are some properties that changes during a game(like player state). It was not working for me with standard code so i changed it:
[code2=cpp]Client.cpp
727 if(props.contains(static_cast<nByte>(Properties::Player::PLAYERNAME)))
->
727 //if(props.contains(static_cast<nByte>(Properties::Player::PLAYERNAME)))[/code2]
I dont know why props needs to contain PLAYERNAME.
0
Comments
-
Hi Alexander.
Thanks for reporting this.
I will look into it.0 -
1.
Your fix will introduce issues with changing the autoJoinLobby flag while being in the middle of the process of joining the lobby. Therefor a correct fix will have to still cache the autojoin flag and check the cached state and not the current state later on. Also a correct fix will have to also care about explicit lobby joins. This can easily be achieved by introducing a second join type cache to cache game room join types and lobby join types independently from each other. An according fix will be released with version 3.2.5.3 of the C++ and objC Client SDKs.
2.
Yes, this is a bug . Your fix is correct and will also make it into v3.2.5.3.
3.
Your function will work for setting the player name before connecting, but not for setting it in an already connected state without explicitly disconnecting and reconnecting. v3.2.5.3 will include a fix to make mLoadBalancingClient.getLocalPlayer().setName(NewPlayerName); working in the first case, so that one can use the same function in both cases.
4.
I will have a look into this issue tomorrow.0 -
4.
After debugging this I have to admit: Me neither.I dont know why props needs to contain PLAYERNAME.
This will also be fixed in v3.2.5.3.0 -
1. It worked for me and i was needed to keep changes small(to make updates easier).
3. Again, fix for me. Not for everyone.
I think you can do fixes for everyone better then me, and its great to know about all this fixes in v3.2.5.3. Thank you!
Can you say estimated release date for update?0 -
Hi Alexander.
I did not intend to rate down your fixes, but rather just wanted to make you aware of potential unintended side effects of them that may effect other parts of your code or code that you may add later.
I think that we can release that bugfix update in February.0
