FAQ 

    Is there a CCU (Concurrent User) limit? Probably not. As long as you're not using it in extreme use, it should be fine.

    Service Usage Limitations

    SynicSugar Prefab Issues In most cases, prefabs break due to updates that change the internal structure of script from when the GUID was cached. When serialization fails, the script will appear as "None."
    To resolve this issue:
    1. Navigate to Packages > SynicSugar > Prefabs, locate the broken object, right-click on it, and select Reimport. Alternatively, you can use the top menu: Tools > SynicSugar > Reimport to reimport the relevant package.
    2. If the issue persists, close the affected project, open the project folder, and delete the .csproj file for the assembly where the object is located. If you have not defined an AssemblyDefinition, delete Assembly-CSharp-Editor.csproj. The file will be regenerated automatically when you reopen the project.
    3. If these steps do not resolve the issue, please report it on GitHub as an Issue.

    Where can I find the DevTool for DebugLogin? It's included in the SDK, which can be downloaded from the "Download and configure EOS SDK" section after creating a product page in the Developer portal.
    Register test accounts in the Organization section of the Devportal, then launch the Devtool. You need to log in with each account and keep the Tool open in the background during testing.
    The DeviceID is the same for both the Editor and built versions, so use DebugDeviceID + DevLogin or similar for debugging.

    What does SourceGenerator do? It adds classes based on attributes at compile time. The example is such this.

    GenaratedSampleNetworkplayer.

    About Transport of P2P. EOS uses DTLS (Datagram Transport Layer Security), which is an encrypted version of UDP packets. In addition to this, the EOS SDK has an internal mechanism to resend packets based on factors such as order and reliability. When reliability is enabled, packets are generally guaranteed to be delivered successfully.

    Can the transport of p2p be changed? Currently, it cannot be changed. It's only EOS (Epic Online Services).
    However, SyicSugar will make it possible to change the backend server and the transport by modifying the Core before logging into the server. This feature is not implemented in v0.8.1.

    Why shouldn't user attributes in Lobby be used as user information for P2P? There are two reasons. First, the Lobby has a lag of up to 5 seconds before information is reflected. Second, due to this lag, I decided to use the user attributes as a heartbeat for disconnections in SynicSugar now.
    In EOS, there can be a lag of up to 30 seconds in recognizing a disconnection. This is because the SDK's heartbeat for recognizing EOS's own connection depends on user actions. While the lag is often shorter when communication is frequent, if there's no activity, the SDK checks for disconnections at specified intervals. This typically takes about twice as long as the time it takes for P2P disconnections to be notified.
    Therefore, when there's an anomaly in connection, I decided to take action to check the connection status. I chose to use the Lobby's user attributes, which already had a lag in data reflection, were not originally recommended for use, and only provided a method for updating during matchmaking.
    SynicSugar has shortened the time to check communication status by having the Lobby host and the top two users in the user list update the P2P communication user list. During this process, the user information is overwritten with data used for the heartbeat.
    As a result, it has become practically impossible to use the Lobby's user attributes for these purpose.

    How is reconnection implemented in SynicSugar? Reconnection is achieved by saving the LobbyID locally or in a specified location, and then searching for the Lobby using that LobbyID.
    In SynicSugar, once matchmaking is completed, the Lobby is closed and hidden from the search. At this point, the lobby can only be searched using the LobbyID or through an invitation from users already in the Lobby. When matchmaking is completed, the LobbyID and the session start time are saved. These details are then used to log into the closed lobby.
    Typically, locally saved data is used for the session start time. However, when the Host synchronizes UserIDs or disconnected users within the Lobby, it simultaneously sends a timestamp (uint) of the elapsed time. If there is no local data regarding the session start time, an estimated start time is calculated using this timestamp. Using this, it's also possible to save the LobbyID in the cloud and join that Lobby from a different device.

    How many P2P connections can be made with SynicSugar? Up to 64 players are possible, but 16 or fewer is recommended.
    In SynicSugar, after closing matchmaking, the host synchronizes the user list to sync information about Lobby users. (The user index may differ locally for each user when retrieved from the Lobby information.)
    During this process, three things are synchronized: a list of UserIDs (32 characters * number of users), a byte list of disconnected user indexes, and a timestamp expressed as a uint. These are compressed using MemoryPack and Brotli compression set to Fastest mode before transmission via sendpacket(packet limit is 1170). This is to keep the matchmaking time as short as possible.
    As a result, depending on the UserIDs, it may not be possible to start connection. It will likely succeed with up to 45 users by default compression quality.

    Large Packets in SynicSugar. While the EOS SDK can only send packets up to 1170 bytes, SynicSugar divides packets into 1166-byte segments and attaches its own unique header before transmission. On the receiving end, these segments are stored in Dictionary, organized by CH (Channel). Once all segments of a packet have been received, they are combined into a single byte array and executed as an RPC. The system can send up to 256 packets. If this limit is exceeded, an error is thrown.

    Is it necessary to differentiate between large packets and normal packets in RPC? Yes. If we don't use large packets, we can't send packets exceeding 1170 bytes due to EOS SDK limitations. We might think that all packets should be large packets, but in reality, we should usually send a packet as standard RPC for the performance.
    When large packets are enabled, SynicSugar adds a header and internally sends packets in ReliableOrdered. On the receiving end, packets are stored in a dictionary, and when all necessary packets for reconstruction are received, the original data is deserialized and the RPC is triggered.
    The reason for using Reliable transmission is that if some packets can't be sent, a large number of packets would be wasted. Also, if we don't use Ordered, data could become corrupted if packets from the next RPC are received before the current one is complete. That's why these settings are used.
    On the other hand, standard packets are sent with just the channel and payload, without additional headers. The packet reliability is determined by the method specified in the P2P config. This means no extra processing is done.
    In the EOS SDK, reliably ordered packets are sent and verified by the SDK internally, even if the client hasn't sent packets for an extended period. This should also be kept in mind when considering performance.
    Therefore, I recommend using them appropriately based on your needs.

    Can not sync Class or struct specified for Synic. Synic is converted to a string in JsonUtility before being serialized into bytes, which are then grouped into SyncedItems in ConnectHub. Therefore, it must be serializable in JsonUtility. Synic class needs [System.Serializable] attribute.

    About Mobile Store Reviews. Mobile store reviews (for both Android and iOS) can be passed even using UDP alone. In the notes section of your review application, please mention that UDP is used and that online features may not function in the review environment. If you're concerned, it might be a good idea to add a tutorial using an SynicSugar Offline Mode.

    What entitlement dose need for macOS notarization? When using VC (Voice Chat) and network features, add the following permissions and notarize the app: 
    <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.cs.disable-executable-page-protection</key>
    <true/>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-only</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.device.audio-input</key>
    <true/>
    <key>com.apple.security.device.microphone</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.network.server</key>
    <true/>
</dict>
</plist>

    Even if the app passes notarization with these permissions, there will be a one-time confirmation prompt when the app launches, asking for permission to access the DeviceID key from the Keychain.