filtering joinRandomRoom fails

edited April 2013 in Native
Hello,

I'm trying to join a random room based on some properties using opJoinRandomRoom with a hashtable, but Photon fails to join my game.

[code2=cpp]void PhotonClient::joinRandomRoom()
{
ExitGames::Common::Hashtable roomProperties;
roomProperties.put("map", "aap");

client->opJoinRandomRoom(roomProperties, 2);
}

void PhotonClient::hostRoom()
{
ExitGames::Common::Hashtable roomProperties;
roomProperties.put("map", "aap");

client->opCreateRoom(ExitGames::Common::JString("myRoom"), true, true, 2, roomProperties);
}[/code2]

If I leave out the roomProperties in my joinRandomRoom() function it joins just fine.
Interestingly, if I use the following the game will always join (regardless of the property's value):

[code2=cpp]roomProperties.put(0, true);
roomProperties.put(0, false); // doesn't make a difference[/code2]

Is this a known issue, am I doing something wrong?

This is using the LoadBalancingClient version 3.2.0.0

Comments

  • Found the answer in the forums. It will only check through public properties. Fix:

    [code2=cpp]ExitGames::Common::JVector<ExitGames::Common::JString> publicProperties;
    publicProperties.addElement(ExitGames::Common::JString("map"));

    client->opCreateRoom(ExitGames::Common::JString("myRoom"), true, true, 2, roomProperties, ExitGames::Common::Hashtable(), publicProperties);[/code2]
  • Yes, correct, filtering will only be done on properties, that explicitly have been specified to show up in the lobby. Other poperties won't be known outside of the room and matchmaking of course happens outside of the room. Speaking about public and private properties of a room in this situation actually is quite a good choice, as one could indeed compare it with private and public members of a class.

    Just for your information:
    The internal representation of JString is wchar_t*, not char*, so if you are passing a string literal, a widestring literal L"string" instead of a narrow string literal "string" will save you a conversion on the string construction and therefor give a better performance. This performance difference shouldn't normally be relevant for the overall performance of the game, but still code like roomProperties.put(L"map", L"aap"); should be preferred over code like roomProperties.put("map", "aap");, as long as no other code needs the same strings to be represented as char*.
Sign In or Register to comment.