Editor hangs when playing more than one time

[nospoone]

Describe the bug
Hello! It seems that I can't play the game more than once in the editor. The editor will simply hang on subsequent plays, with either the indeterminate progress bar (Hold on...) or without any indications whatsoever.

To Reproduce
I've attached a minimal reproduction case, without my config:

• Open project
• Fill dev portal configuration (although invalid config will also trigger this)
• Open Scenes/SampleScene.unity
• Hit Play in the editor;
• Check console for initResult = Success;
• Stop, and hit Play again in the editor;
• Unity should be either stuck without a progress dialog, or showing the Hold on dialog with the indeterminate progress bar;

Expected behavior
Being able to hit Play more than once 😁

Desktop:

• OS: Windows 11 x64
• Editor only (works correctly in builds)
• 2022.3 (tried a couple of minor versions, the repro case uses 2022.3.11)
• 3.0.3, installed from the tarball (but using git also reproduces the issue)

Additional context
The plugin reports that it connects correctly the first time. While it doesn't show anything in the console for the subsequent times (since the editor never switches to actually playing,) the last line of Editor.log shows initResult = AlreadyConfigured.

For now, I'll install the package locally and try to step through Init to see what's going on, but still wanted to report in case I'm just doing something dumb!

[nospoone]

Here's my finding from spending a little bit of time on this:
It seems that execution stops here... I haven't worked with any of the Win32 APIs or even C in a long time, but it seems that FreeLibrary is somehow (as per Rider's debugger) never returning—which I'm not even sure how that works.

I ran out of time to dig further, unfortunately!

[paulhazen]

I'm installing that version of Unity in order to try and reproduce this bug. A few thoughts while that does its thing though:

1. It's possible that the issue is using a version of Unity that the plugin does not currently officially support.
2. The EOS SDK (and Unity) use both threading and the loading of libraries in ways that are not conducive to pause / play. I suspect that some of the threading that happens in the EOS SDK is unhappy with being paused.
3. Admittedly, I am less familiar with Rider than I would like to be, but there might be a complication with using Rider. While I'm uncertain if we have this documented, we primarily use Visual Studio. I would be curious to know if you experience the same issue using Visual Studio.

I'll get back to you once I have tested it myself.

[paulhazen]

Okay - I got to the bottom of it. The issue was that the plugin was not completely set up to function properly in your project. Specifically, the following steps do not appear to have been taken in your minimal example eos-hang:

The full document on configuring the plugin can be seen here.

Once I followed those steps, I was able to play, pause, play, pause to my heart's content :)

If, after following those steps, you're still running into issues, please feel free to re-open this issue. Having your minimal example was super helpful, thank you for that. If you have another issue, providing something like that again would definitely be awesome.

[nospoone]

Adding the prefab indeed fixes my issue! Thanks for taking the time to look into it, and sorry it was something as simple as not reading the instructions.

in case I'm just doing something dumb!

It was indeed the case ☝️

Having your minimal example was super helpful, thank you for that.

Least I could do!

[paulhazen]

Adding the prefab indeed fixes my issue! Thanks for taking the time to look into it, and sorry it was something as simple as not reading the instructions.

in case I'm just doing something dumb!

It was indeed the case ☝️

haha no problem. I tend to be of the opinion if instructions are not being read, they can probably be written better, so this helps us improve things :)