Kaiserludi admin


Last Active
Registered, Administrator
  • Re: Keep my player number after disconnection

    Interesting. That response seems to imply that UE4 uses widestrings not just inside the API and other code, but also as the format for transmitting the string over the network.

    This is different in Photon.
    Photon uses UTF16 (on Microsoft platforms) / UTF32 (on every other platform) encoded wide strings in the Client API, but UTF8 encoded narrow strings for the actual transmission over the network (Photon automatically converts all contained strings to and from UTF8 when serializing/deserializing data) as especially compared to UTF32 strings and with mainly Western characters UTF8 saves a lot (about 75% per character) of network traffic for strings. With East Asian (i.e. Chinese, Japanese and Korean) characters the difference naturally is a lot smaller, especially between UTF8 and UTF16, as most of those characters need 2bytes and can even take up to 5 bytes in UTF8.

    So why are we using wide string in the API, when we use UTF8 in the network anyway? Couldn't we then just use narrow strings everywhere ans get rid of those conversions?
    Well the main reasons against using UTF8 everywhere are a) that wide strings allow for much faster performance in practically all string operations, while the extra memory costs for storing the string variables are negligible (CPU cycles are expensive, RAM is cheap) and b) that on some platforms UTF8 support is (or was) rather limited.
  • Re: Matchmaking not working in Dubai, working fine in Turkey!

    One option for you to tackle this would be to self host you own Photon Servers in Dubai, Abu Dhabi or somewhere else in the Emirates or in general somewhere in the Middle East and let clients from there connect to those instead of connecting to Photon Cloud.
  • Re: Matchmaking not working in Dubai, working fine in Turkey!

    Hi @car_game_dev.

    Please note that Photon Cloud is region-locked.
    If two clients use RegionSelectionMode::BEST and end up with a different result for their best region, then they will connect to different regions and clients in different regions are NOT able to see each other or match with each other.

    Depending on the latency requirements of your game and then amount of players that you have around the world, it may be preferable to use RegionSelectionMode::SELECT and depending on the device location let all players connect to only a couple of regions.
    Using SELECT mode also makes sense if you need to guarantee that two clients from different parts of the world end up in the same region during development/testing.

    However this does not explain why two players in the same building can't see each other or have a terrible connection.
    It looks like the pings from your Dubai clients to two different Photon regions might be so similar that depending on timing, luck and the local connection (mobile vs. landline and which network provider) a different region might be the best one so that two clients from Dubai might end up in different regions.

    Also the consistent disconnects indicate a terrible connection quality to whatever region they end up with.
    This is not a Photon problem, but a problem with the local network of those devices.

    You could ping all available regions yourself and have a look at the results and then manually try out the most promising looking regions by specifying them with RegionSelectionMode::SELECT.
  • Re: Playfab integration

    Hi @MajinSephiroth.

    The AuthenticationValues are a parameter of Client::connect(), not of the constructor of class Client.

    Example code:
    mLoadBalancingClient.connect(ExitGames::LoadBalancing::AuthenticationValues().setUserID(USER_ID).setType(ExitGames::LoadBalancing::CustomAuthenticationType::CUSTOM).setParametersWithUsernameAndToken(PlayfabID.c_str(), token.c_str()), PLAYER_NAME);
  • Re: When should one set reliability to false?

    Hi @AnkitKushwah.

    A classic example would be position updates in a realtime game. Those might get send as often as 10 or 20 times per second or even more often than that. Now when a reliable event gets lost on it's way, the sender needs to repeat it (that's the whole point of the reliability). To actually know that a reliable event got received the sender needs to wait for the receiver to acknowledge the receive. So, when the sender did not receive such an ack for a certain event inside a certain timeframe after sending it, it knows that the event most likely got lost and needs to be repeated. However at the point in time when the sender would know that a position update likely got lost (it has waited so long for the ack already that with the given latency it does not consider it likely to arrive anymore), it will already have sent multiple other more up to date updates of the player position already, so that when the repeat would arrive at the receiver, it would only contain outdated data and would get thrown away anyway. Furthermore the repeat would mean that the receiver could not actually process any other events that were sent later than the original event, but already got through before the repeat, as those may depend on that lost event already having been processed (if processing that lost event would not be critical for processing later events, then why send it reliable after all?), so the repeat would postpone later events which in the case of position updates isn't what we want.

    Another classic example are voice and video chat: In case of network loss the quality of the transmission as felt by the user is a lot higher with some hear able / visible loss, than when the transmission hangs waiting for a repeat every second or so.

    Turn-data in a turn-based game like the results of throwing a dice in your ludo game of course should be sent reliably.