Idea

Hello tmichael,

We will be exploring what we can do to solve this problem in future versions of the Editor Extensions, but for now, you can inspect how we are making Editor HTTP requests and extend that functionality for making your desired calls.

For reference, I would be interested in what types of tooling you are interested in.

Thanks,

Zac

My suggestion would be to have multiple distinct Unity projects.

1. Obviously your distributed game client
2. Optional game-server if your game needs one
3. Optional admin game-tools which is what you're describing

Personally, I'd never suggest to put ANY non-client code anywhere near a project that was a distributed client build. Anything could go wrong and that could get accidentally released.

Otherwise, I will point out though that anything in an "Editor" folder is automatically filtered out of any Unity build, and only exists in the editor. It's not the easiest way to do it, and again, I think a separate project is safer, but it can be done.

@Zac

the stuff I've been doing has been either just simple data requests from playfab for out-of-game testing on prefabs or more recently, building a tool that will move data between spreadsheets and playfab. I've just been forming my own calls to playfab using unity's www stuff... but it would be convenient if I didn't have to is all =)

@Paul

Thing is, it's extremely powerful to have the game code accessible for designer tools. But yes, your suggestion of using Editor folders is exactly what we've been doing.

This thread has recently been brought back into my attention.

I don't think there's any way that the Editor Extensions can do this for you, but I think you could do it yourself with a few steps:

Wrap your editor scripts with the following code:

#if ENABLE_PLAYFABADMIN_API && ENABLE_PLAYFABSERVER_API
// Your editor file that uses admin and server APIs
#endif

You can make it part of your build process to enable and disable the server/admin APIs, and with the compile flags, your editor scripts won't cause errors when the APIs are disabled.

string curDefines = PlayerSettings.GetScriptingDefineSymbolsForGroup(EditorUserBuildSettings.selectedBuildTargetGroup);
PlayerSettings.SetScriptingDefineSymbolsForGroup(EditorUserBuildSettings.selectedBuildTargetGroup, curDefines);

IMPORTANT NOTE: You can't call SetScriptingDefineSymbolsForGroup and then immediately build. There's a race condition in Unity, and the build won't be built with the updated defines. If you're building from the command line, you have to do three separate executions of unity-command line:

1. Call PlayerSettings.SetScriptingDefineSymbolsForGroup to disable server/admin APIs & exit program
2. Call BuildPipeline.BuildPlayer with your settings & exit program
3. Call PlayerSettings.SetScriptingDefineSymbolsForGroup to re-enable server/admin APIs & exit program

If you're doing it from Editor-drop-downs, you'll need the same three steps, as 3 separate drop-down options, and manually run through them one at a time, waiting for each to complete before clicking the next.

A large portion of our own scripts for building our automated test projects are open source:

https://github.com/PlayFab/UnitySDK/blob/master/Testing/Editor/PlayFabPackager.cs

The end result would be that your client build will fail with compile errors if you attempt to use server/admin APIs (something you should catch with your automated build process). But, your editor scripts can use admin/server APIs just fine, and they'll be hidden with #defines when you build your client.

More relevant source files:

https://github.com/PlayFab/SDKGenerator/blob/master/SDKBuildScripts/unity_SetupTestProjects.sh

https://github.com/PlayFab/SDKGenerator/blob/master/SDKBuildScripts/unity_RunAutoTests.bat

and the one I linked above:

https://github.com/PlayFab/UnitySDK/blob/master/Testing/Editor/PlayFabPackager.cs

Between the 3 of those files, you have all of the PlayFab source for changing around the #defines and building multiple projects with different defines. Your project would be similar, but you'd have just one, toggling them back and forth.