Cooked build in Unreal isn't connecting to Mixer project
Closed this issue · 13 comments
Hi,
I just recently started prototyping some Mixer features. I've got everything working in editor, but now I'd like to distribute cooked builds to third parties. I've updated both initialize calls in MixerInteractivityModulePrivate.cpp, by adding the share code parameter, in the following way:
if (Microsoft::mixer::interactivity_manager::get_singleton_instance()->initialize(*FString::FromInt(Settings->GameVersionId), false, _XPLATSTR("SHARECODEHERE")))
When launching the editor project, my Mixer channel updates appropriately, enabling the project and its buttons to work with my editor instance. However, running the cooked build does not seem to update anything on my channel.
Do I also need to manually provide the VersionId? Is it not grabbed from Settings in cooked builds?
Any help is greatly appreciated,
Thanks!
TyphoonLex
It's supposed to pick those up from the settings. We'll look into it. But for now, it doesn't hurt to pass it in manually.
Actually, Win32 (aka. Desktop) uses OAuth. Xbox One and Windows Store apps (UWP) can use Xbox Live token authentication. Are you building for Windows Store (UWP)?
Sorry, I'm still wrapping my head around this for Win32. For the time being, I won't be able to create a UWP build.
From what I understand, the editor allows me log in with a Microsoft account, and so any time I run the game, it's using that to connect to my Mixer channel.
Is there a way I can provide a username and password, even hardcoded, into a cooked so that I can provide a Microsoft account?
No worries at all. Do you happen to have a Microsoft developer account manager? If so, they could set up a call. It might be easier to explain on the phone. If not, that's okay I can explain here.
Unfortunately, we don't have an account manager, so if you could explain it through here that would be great.
Can you explain to me how the authentication flow would work in a standalone, non-UWP (Win32/64 executable) build? Because in the editor, under the Mixer plugin settings, there's a button to login, which creates a window where you can provide your Mixer / Microsoft credentials. However, in the standalone build, from looking at the plugin code, there is no execution path where a window is generated for the user to provide their credentials.
Do you have a suggested way to implement an authentication flow for users when distributing builds? Do we need to call the LoginWithUI function somewhere in our code, as it's not a Blueprint function?
Thanks
Ah yes, thank you for explaining. I understand now. For Win32, the simplest way to go about it is to use our slate control that we use for the editor in your game. You can also copy the code that the plugin uses.
Authentication will work the same way as it does in the editor. The difference is when you're in the editor, the plugin does everything automatically. But for your Win32 build you will want to grab our slate control and then use it in the same way we are doing in the editor.
We are working to have a sample of this so it's easier in the future, but don't have one at the moment. Did that help?
Yeah, I had a feeling that I'd have to use the slate control. I'll try this out tomorrow morning, and let you know if it works out.
If you happen to have any sample work available, that would be great, otherwise I'll take a look at the plugin and just quickly put something together through the flow provided.
Unfortunately, we don't have it in a workable state right now.
Hey, so I made some changes to the plugin, which I'll place here for you to use as you see fit.
MixerInteractivityBlueprintLibrary.cpp
Added functions LoginWithUI() and Logout()
void UMixerInteractivityBlueprintLibrary::LoginWithUI(UObject* WorldContextObject, class APlayerController* PlayerController, FLatentActionInfo LatentInfo)
{
TSharedPtr<const FUniqueNetId> NetId;
APlayerState* PlayerState = PlayerController ? PlayerController->PlayerState : nullptr;
if (PlayerState)
{
NetId = PlayerState->UniqueId.GetUniqueNetId();
}
if (UWorld* World = GetWorldFromContextObject_EngineVersionHelper(WorldContextObject))
{
FLatentActionManager& LatentActionManager = World->GetLatentActionManager();
if (LatentActionManager.FindExistingAction<FMixerLoginAction>(LatentInfo.CallbackTarget, LatentInfo.UUID) == nullptr)
{
IMixerInteractivityModule::Get().LoginWithUI(NetId);
LatentActionManager.AddNewAction(LatentInfo.CallbackTarget, LatentInfo.UUID, new FMixerLoginAction(LatentInfo));
}
}
}
void UMixerInteractivityBlueprintLibrary::Logout()
{
IMixerInteractivityModule::Get().Logout();
}
MixerInteractivityBlueprintLibrary.h
/**
* Sign a local user into the Mixer service with UI. This operation is latent and waits for the request to complete before
* continuing.
*
* @param PlayerController Controller for the local player whose identity will be used for Mixer login.
*/
UFUNCTION(BlueprintCallable, Category = "Mixer", meta = (Latent, WorldContext = "WorldContextObject", LatentInfo = "LatentInfo"))
static void LoginWithUI(UObject* WorldContextObject, class APlayerController* PlayerController, struct FLatentActionInfo LatentInfo);
/**
* Sign a local user out of the Mixer service.
*
*/
UFUNCTION(BlueprintCallable, Category = "Mixer")
static void Logout();
MixerInteractivityModulePrivate.h
Added the following include statement as build errors were occurring if MixerInteractivityModulePrivate.cpp was not read-only (which doesn't play nice with unity)
#include "Input/Reply.h"
Generally, we got everything working. One issue we found is that if you attempt to logout and then login with a different account you have to restart the editor/restart the standalone executable after logging in with the new account. If not, it will still interact with the previous channel you were logged in with until you do so.
Thank you very much for all the help, it was greatly appreciated :)
We're glad to hear you got things working!
It sounded like you might not have a Microsoft contact. If you want to let us know what you are working on you can email Mixer Developer Info mixerdevinfo@microsoft.com. We're always interested in hearing about new interactive experiences.