Closed 3ternal closed 1 week ago
I was looking at the config window under Tools -> EOS Plugin -> EOS Configuration, and it seems like the Sandbox and Deployment IDs are written somewhere and used privately during the initialization process. So, I was wondering if it's possible to change this at runtime when we're logging the player in?
Unfortunately, this is not something that can be changed when we're logging the player in - it can only be set when the platform (the EOS SDK) is being initialized.
The intent behind the Dev/Sandbox/Live (and their representation in the form of Sandbox and Deployment values) is to silo behavior into different contexts. In light of the intention behind this design, I believe it would be breaking with best practices to allow the ability to override this during runtime.
It's possible that in a future release we may implement a development-oriented capability to make switching easier during testing of the application (perhaps while running in the editor), but currently this is not something the plugin can do.
For the time being (and in light of my response) does this answer your question? If so, I will mark this issue as resolved and add a task in our internal tracking to consider enabling the ability to change these values during runtime.
If this doesn't quite answer your question, or you have follow-up questions, can you also provide the platform you are deploying to? I see that you are using the 3.3.2
, but it would be useful to know what platform(s) and what version(s) of Unity you are targetting.
Hey, thanks for the reply. This roughly answers my question, yeah. For what it's worth, I'm on Unity 2022.3.30 and I'm deploying to PC and Mac.
In terms of best practices, this link mentions that you can use the Sandbox ID and Deployment ID to make sure a single build can be used across multiple sandboxes: https://dev.epicgames.com/docs/epic-games-store/testing-guide#sandboxdeployment-id-handling-epic-games-store-publishing-tools-only
So, the functionality isn't unheard of, but you might be correct that perhaps it would go against the intention of the design.
Either way, I tried to do something similar to the first suggestion that the Epic staff gave me (calling CreateUser after receiving an EOS_InvalidUser result), so I'll push that to Stage and see if they accept it. If that doesn't work, then I might circle back to this, because their previous test of the achievements failed even though I think the build was made using the Live Sandbox/Deployment IDs (I'll try and test this properly if it fails again).
All right, I'll go ahead and close this one now - I followed Epic's first suggestion that I mentioned in the original post (call CreateUser after receiving an EOS_InvalidUser result), and the build got past their review.
Hi,
I'm running into an issue similar to the one described here: https://github.com/PlayEveryWare/eos_plugin_for_unity/issues/132
My achievements are working in the Dev sandbox, but I haven't been able to get past Epic's approval process to push the build to live. Apparently the achievements aren't being detected in other sandboxes. This was their reply:
Looking at the link in option number 2, it sounds like the cleanest solution would be to take the launcher arguments from the Epic desktop client and use them to dynamically set the sandbox and deployment IDs. That way, a single build can work in Dev/Sandbox/Live.
I think we can use
EOSManager.Instance.GetCommandLineArgsFromEpicLauncher().epicSandboxID
andEOSManager.Instance.GetCommandLineArgsFromEpicLauncher().epicDeploymentID
to retrieve these values, but is there any way to set them at runtime? I was looking at the config window under Tools -> EOS Plugin -> EOS Configuration, and it seems like the Sandbox and Deployment IDs are written somewhere and used privately during the initialization process. So, I was wondering if it's possible to change this at runtime when we're logging the player in?For now, I'll attempt a workaround with option 1 that the Epic staff suggested, and we'll see if they accept it. But it would be good to know if option 2 is viable too.
I'm currently on version 3.3.2.