Scripting API suggestions

[bburky]

• Add an easy way to get a path to the extension directory. It's not too unreasonable for users to rename the extension folder's name, so manually deriving this could be error prone. (__file__ should do this, but it evaluates to "\" in IronPython, not a path to it's own location. But that's a separate IronPython bug I think.)

• Maybe allow easier configuration of script extensions. I need to prompt the user for the location of their Steam userdata folder and save that location somewhere. (It looks like PlayniteApi.GetPluginConfiguration<TConfig>(IPlugin) is actually accessible in IronPython. Maybe just create an IPlugin instance for script extensions and reuse it?)

• A REPL with access to the PlayniteApi would be really nice. It would be nice to incrementally test things against the API.

[bburky]

Another:

Make PlayniteApi.ExpandGameVariables(Game, GameAction) also expand an any associated emulator profile's Executable, WorkingDirectory and Arguments into the new GameAction, correctly handling OverrideDefaultArgs and AdditionalArguments.

Currently I have to manually lookup the emulator. Look up the Profile (using Linq in IronPython, which is weird but works). Manually expand each variable from the profile with PlayniteApi.ExpandGameVariables(Game, string). And append AdditionalArguments myself. I gave up for now. Never mind, EmulatorProfileExtensions has ExpandVariables(..) but extension methods are mostly unsupported in IronPython. The type currently isn't exposed to IronPython, but I managed to call it directly using some horrible reflection. It would still be nice if there was a method that evaluates everything like Playnite does right before starting a game.

[JosefNemec]

How many of these are still needed?

[bburky]

1. Add an easy way to get a path to the extension directory – Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) and $PSScriptRoot cover this now.
2. Maybe allow easier configuration of script extensions – There's still no way to provide configuration to script extensions. They can't provide a GetSettingsView() or save/load settings.
   • If you're okay with this being a feature restricted to C# extensions, this is acceptable.
3. A REPL with access to the PlayniteApi would be really nice. – It might be nice to provide an interactive PowerShell console as a first class feature. For now though it's possible to debug a random PS extension and extract it's $PlayniteApi variable. This is hacky and not documented though:

   Enter-PSHostProcess -Name Playnite.DesktopApp
   $PlayniteApi = (Get-Runspace)[-2].SessionStateProxy.GetVariable("PlayniteApi")

4. Expand game variables – I think extension methods are accessible in PowerShell which covers part of this.
   • It is a still difficult to expand all the arguments for an executable or emulator in the exact same way that Playnite does. This is needed if a plugin wants to launch the executable itself in the same way that Playnite would. Something like this code: https://github.com/bburky/playnite-non-steam-shortcuts/blob/1235e43b213f7b7b31509198cc5082696d1c09ae/nonsteam.py#L431-L453
     • For my particular use case, it turns out DLL injection is probably a better design though because the original launcher can still handle it and the tool doesn't need knowledge of how the game is launched.

You can close this if you would like to though, or if you think any of these are good use cases I can create followup issues.

[JosefNemec]

1) Extensions can use $CurrentExtensionInstallPath and your GetExecutingAssembly example for plugins is imho pretty standard, I don't think we need to add special variable for that.

2) #1741

3) #1967

4) https://playnite.link/docs/tutorials/extensions/expandingVariables.html