NULL EOS Platform returned by native code: issue probably occurred in GFX Plugin! about eos_plugin_for_unity HOT 6 CLOSED

Hi @paulhazen,
The package is integrated using local packages, the reason for which will become clear next:

We're using an old, unsupported Unity version due to legacy reasons; 2018.4.13f1 to be exact. I appreciate this makes things more complicated.
I've backported the plugin (asmdef references and package manager hooks mostly) and obviously the samples don't work, but as a wrapper around the EOS SDK it seems to all be there. I've already successfully implemented most interfaces when running in the Editor.

I'm pretty confident I had a standalone running with the EOS platform initialised at an earlier point in the project, but without obvious changes it now seems it doesn't work anymore.

Any particular thoughts as to a likely cause that comes to mind?

OS: Win11

from eos_plugin_for_unity.

Hi @paulhazen,

This is great info, thank you. Which file in particular has the path improperly assigned?

EpicOnlineServicesConfig.json. Its path is constructed here.

Excellent that you've found a work-around, and I completely agree with you both on the need for it to report the path, and for the path to be correctly constructed. I'll look into this today and see if I can get a PR up.

Just so you are aware, it may take some time for that change to propagate through our development branch and into our stable branch and subsequent UPM releases.

Great news, I appreciate pushing for a PR. And of course no problem on the turn-around. While having the post-build copy of the files is perhaps not the most elegant, it's a cheap easy solution that does the job just fine.

I'd been wondering why this is a problem in our project and not for anyone else. Best I can tell, it's a change Unity made to their Plugins output.
Creating a build in our Unity 2018 has the plugins in the build output under
BuildRoot\UnityGame_Data\Plugins\*.dll, while building the same project in Unity 2020 results in
BuildRoot\UnityGame_Data\Plugins\x86_64\*.dll as the plugin root. One extra folder deep.

I'll look into these as well, but as those source files are provided by Epic, we try to keep them as un-touched as possible as a practice.

Ah gotcha - I'd ignore them in that case. The defines aren't causing any problems apart from being a red herring in my search.

Once I have the PR introduced, and it gets merged, I will close out this issue and mark it as unresolved until the solution makes its way into stable and subsequent releases.
Thank you so much for being such a rockstar about sharing your thought process, diagnoses, and conclusions!

Great! And thank you for your assistance in the matter!

from eos_plugin_for_unity.

Hi @DjPls, there are a few reasons this might be happening. To start with, can you clarify which method you are using to incorporate the plugin into your project (are you using a release upm?).

Also, if you could tell us what version of Unity you are using, as well as your OS those pieces of information will be helpful.

from eos_plugin_for_unity.

Hi @DjPls

My guess is that due to scripting defines, some part of the plugin (due to the old version of Unity being used) is not properly identifying which platform it should be using. Let me look into this a little more closely and I'll get back to you on the different reasons this particular error may be being thrown.

Not to throw the ball immediately back into your court - but what kinds of things do you think may have changed between when it was working and now? Are your configurations for the plugin still the same?

from eos_plugin_for_unity.

Edit 2: I've established the root of the issue. The path of the JSON config file is established incorrectly by the NativePlugin.
It defines path as
<location of GfxPluginNativeRender-x64.dll + ..\.. + StreamingAssets\EOS\
instead of
<exe_root>\ProjectWin64_Data\StreamingAssets\EOS\.
In our case the dll is sat in ProjectWin64_Data\Plugins. which results in the path being resolved to
<exe_root>\StreamingAssets\EOS\; up one directory too many.

In the short term I can get around this by doing a post-build copy of the JSON config to the path it looks for.
It would be great if the plugin reported the config path prior to failure, and ideally it would build the path for StreamingAssets based on the built Unity project structure, instead of where the plugin is running from.

Edit 1:
Making progress. Digging through the native dll source, At initialisation ddlmain.cpp (1372), the plugin doesn't find the json file at the path specified. We know read_config_json_as_json_from_path is never called, because the first line log_inform(("json path" + to_utf8_str(path_to_config_json)).c_str()); is missing from the log.

Original message:
Hi Paul,
Thanks for giving your advice on this matter.

Scripting defines was an interesting thought but I was unable to find a clear culprit. I thought it could be UNITY_64 and UNITY_EDITOR_64 as they are undocumented in Unity 2018, but the defines are active in the Editor solution. I stopped short of testing in standalone.

As a side note, I noticed PLATFORM_64BITS and its 32 bit counterpart are referenced in conditionals inside Config.cs and the binding.cs files even though those defines are never defined in those files files.

The configuration of the plugin is unchanged, There has been some build pipeline traffic, and further implementation of features/interfaces, but nothing to do with the initialisation of the plugin.

On further investigation I noticed this line in the log:

NativePlugin (WARNING): Failed to load a valid json config for EOS

I originally ignored it as I thought it had to do with EOSGenerated.dll, which has its generation commented out in the plugin code and is therefore expected to fail. However now I'm wondering if this is telling me it failed to load any valid config. If it
failed to parse the JSON config, it wouldn't have any valid config to initialise the platform with. I may need to look into the EOS SDK docs/source in the morning to see why the config file is considered invalid.
The JSON looks correct, and loads without error in the editor.

from eos_plugin_for_unity.

Hi @DjPls,

I've established the root of the issue. The path of the JSON config file is established incorrectly by the NativePlugin. It defines path as <location of GfxPluginNativeRender-x64.dll + ..\.. + StreamingAssets\EOS\ instead of <exe_root>\ProjectWin64_Data\StreamingAssets\EOS\. In our case the dll is sat in ProjectWin64_Data\Plugins. which results in the path being resolved to <exe_root>\StreamingAssets\EOS\; up one directory too many.

This is great info, thank you. Which file in particular has the path improperly assigned?

In the short term I can get around this by doing a post-build copy of the JSON config to the path it looks for. It would be great if the plugin reported the config path prior to failure, and ideally it would build the path for StreamingAssets based on the built Unity project structure, instead of where the plugin is running from.

Excellent that you've found a work-around, and I completely agree with you both on the need for it to report the path, and for the path to be correctly constructed. I'll look into this today and see if I can get a PR up.

Just so you are aware, it may take some time for that change to propagate through our development branch and into our stable branch and subsequent UPM releases.

As a side note, I noticed PLATFORM_64BITS and its 32 bit counterpart are referenced in conditionals inside Config.cs and the binding.cs files even though those defines are never defined in those files.

I'll look into these as well, but as those source files are provided by Epic, we try to keep them as un-touched as possible as a practice.

Once I have the PR introduced, and it gets merged, I will close out this issue and mark it as unresolved until the solution makes its way into stable and subsequent releases.

Thank you so much for being such a rockstar about sharing your thought process, diagnoses, and conclusions!

from eos_plugin_for_unity.