Side loaded config dll not loaded in editor?

[jollypunch]

I set up a side loaded EOSGenerated.dll to avoid having the config in plain text. It seems to be working correctly in builds, but the editor doesn't pick it up. Is that expected behavior?

Does the plugin need to have empty config files in StreamingAssets even with a config dll? It doesn't seem to be able to make a build otherwise, and the editor generates them on play.

[arthur740212]

Hi, we're here to help diagnose the problem.

Yes, the config is expected to be used by default, and it would prevent building on some platforms.
We could have a discussion internally about whether the config should be blocking builds, since not all platforms uses the configs during build time.

As for the side loaded dll, it might depend on how the implementation looks like within the project.
The EOSSDK dlls gets loaded/unloaded when running/stopping (the play button) in the editor.
(which is different than the default where dlls get loaded when launching the editor.)
That being said, make sure that EOSGenerated.dll is loaded before EOSSDKShipping.dll, and grab the right configs from the loaded EOSGenerated.dll

[jollypunch]

Hmm I don't have any implementation of loading the dll and grabbing the configs, isn't that handled by the plugin in the editor as it is in builds?

[secondimpactrob]

We're trying to implement this now also.

It seems there are multiple locations that read the config file. On the Unity side: in EOSManager.cs the Init function loads the json file, and is not configured to ask the separate dll out of the box. It attempts to load the json from streaming assets, and will error if it can't get it.

(Not yet sure what this part uses it for, versus the native code that's already set up to read the dll.)

However, because of how its written, it only tries to load the file if loadedEOSConfig is null. This means it's possible to add a partial class extension that lets you set this value (using your own data) before calling Init.

[secondimpactrob]

We got this all working with the following:

1. Built a DLL to supply the Json string
2. Added a new function to EOSManager (using a partial class file, rather than editing the actual file) allowing us to pass it a Json string (which we also get from the dll) and it populating its loadedConfig with that. We call this to set the config before we call Init(), which means Init() will not load the file from streaming assets.
3. Added a dummy empty file EpicOnlineServicesConfig.json in StreamingAssets to avoid the PEW Editor build-time checks from failing

[jollypunch]

So point 2 is already implemented by the plugin for builds but not for editor, is that correct?

[secondimpactrob]

So point 2 is already implemented by the plugin for builds but not for editor, is that correct?

I think actually in a build it's going to load it twice in two different places, and one of those is already configured. My point 2 covers the other one. I'm guessing you left a json file in place, since otherwise PEW won't even let you make the build (as per my point 3).

[jollypunch]

Yes, when you start the game in play mode in the editor it makes dummy configs files, so I left those in to avoid build errors. I'll have to look into where that 2nd loading point is and how to implement it.

[jollypunch]

We got this all working with the following:

1. Built a DLL to supply the Json string
2. Added a new function to EOSManager (using a partial class file, rather than editing the actual file) allowing us to pass it a Json string (which we also get from the dll) and it populating its loadedConfig with that. We call this to set the config before we call Init(), which means Init() will not load the file from streaming assets.
3. Added a dummy empty file EpicOnlineServicesConfig.json in StreamingAssets to avoid the PEW Editor build-time checks from failing

Unfortunately the latest releases removed loadedConfig, in favor of Config.Get. I'm not seeing a new way to override it with a partial class.

[paulhazen]

These are good solutions if that's the behavior that you want. I can tell you that we have it on our radar to make the configuration values not be stored in plain text, but due to a variety of historical reasons and to not break backwards compatibility with some of our users we are not ready to implement that change immediately.

Good ingenuity on finding a solution that works.

Because I think this thread is more appropriately a feature request / discussion, I'm going to convert it to a discussion. Don't let this dissuade you from bringing to our attention issues like this via the issues feature of GitHub - that is the preferred way. I'm just going to move it so we can more appropriately categorize the work.

[jollypunch]

Does this still work for you in latest releases @secondimpactrob ? I was using a partial class to fill EOSConfig on singleton creation, but on Windows it does not work anymore. It crashes if the configs are not filled in streaming assets, and then seems to use those instead if they are. On other platforms it seems to work still.

[secondimpactrob]

Does this still work for you in latest releases @secondimpactrob ? I was using a partial class to fill EOSConfig on singleton creation, but on Windows it does not work anymore. It crashes if the configs are not filled in streaming assets, and then seems to use those instead if they are. On other platforms it seems to work still.

Apologies, we shipped on plugin v3.1.3 so can't say whether my approach works beyond that. Does yours work with 3.1.3?

From looking at the latest code in the stable branch on github, it seems both relevant places still function as expected:

1. EOSManager.cs inside Init() it checks whether loadedEOSConfig is null before proceeding to load the json. Which should mean that if you've populated loadedEOSConfig before you call Init then it wont use the json file.

2. In dllmain.cpp (line 1538 at time of writing) it calls read_json_from_dll() first and only proceeds to read json from the file if that didn't work.

[secondimpactrob]

Another thing worth noting is that if you're launching a build on Windows via the Epic launcher it will pass overrides for sandbox & deployment id, that will override what's in your config. Could it be that it's using the values from that which is making you think it's using the json file?

[jollypunch]

Thank you for the info, I'm not using the Launcher and the Overlay is disabled so it's not included in builds.

Turns out it was an issue with the meta file for the dll. It stopped working for some reason, I guess it got corrupted because the settings in the editor would reset at every build/reopen. It only started working again after deleting it.