Page MenuHome

Update Steam/Windows Store to use blender-launcher
Closed, ResolvedPublicTO DO

Description

in rBf3944cf50396: Win: Add launcher to hide the console window flash we added a new executable that launches blender without the annoying console window flashing in the users face.

When 3.0 gets released we need to update steam/windows store to launch blender-launcher.exe rather than blender.exe

Event Timeline

Ray molenkamp (LazyDodo) changed the subtype of this task from "Report" to "To Do".
James Monteath (jmonteath) changed the task status from Needs Triage to Confirmed.May 27 2021, 7:13 AM

I was able to add a new Launch Option for autotest-vdev branch so we can test.

But not sure how we can target all the other branches and the default.
It seems that updating the current Launch Option 0, we would have to ensure the executable is deployed on all supported branches first.

Or I would hope it is smart enough to try multiple options in a specified order.

I will see if I can override this in the vdf at build time.

It would be great if we can also create Blender LTS apps instead of branches.
Then we can modify future short term releases without affecting LTS configurations.
We currently have LTS app Windows Store.

The new option is shown to the user.
I will rename the 2nd option for now so we can test.

We will have to deploy this change to all supported branches, unless I can override per steam branch during build.

I pushed build to steam in autotest-vdev branch.
Works as expected, no pop up.
Seems quick to start also.

The MSI package looks good.

Since this is marked as planned for 3.0 and assigned to @Philipp Oeser (lichtwerk), are we actually going to do this in the next week or leave it for later?

My understanding is that we have not tested this entirely, and it's also not clear to me how we intend to configure it. I'm guessing we would make blender-launcher.exe the default, and then add an entry for every older Blender steam branch with blender.exe too fall back. And hopefully there will be no popups then.

If we are going to do it, I think it should be done before release day, since there's nothing stopping it and we don't want problems while everyone is trying to upgrade. I don't think it's super important and we could leave it for later too.

I'll try to figure out the remaining questions tomorrow and arrange a "dry-run" (if at all possible).
Will get back with what I have by then (then there should still be enough time to decide if this should happen -- or pushed back).

Just to give you an update: to properly test this, I have set up a Win VM with Steam running (which took longer than expected for various reasons), so will continue tomorrow...

Really sorry, looked into High prio bugs on thursday, but was also sick since Friday (still am), so time might be running short:

  • Windows Store:
    • would have no idea how to do this there
  • Steam:
    • new launch option is set up for the devtest-3.0 daily-3.0 & autotest-vdev branches now
    • so if I understand correctly, this just means
      • 17 new launch options [set to blender.exe] (one for each of the 2.77 2.78 ... 2.83 2.83lts 2.90 ... 2.93 daily-2.83 daily-2.93 devtest-2.83 devtest-2.93 branches)
      • blender-launcher.exe goes to Launch option 0 (default)
      • [this is just hope] expect the 17 branches to not act up and automatically jump on the fallback option

I think it's totally reasonable to leave this for after the 3.0 release if there's already too many things to deal with.

  • Windows Store: I think we change release/windows/msix/AppxManifest.xml.template in the Blender repository, replacing all occurrences of blender.exe by blender-launcher.exe. And then we'd test if installing the msix package generated by the buildbot (vXXX-code-store-windows) is working correctly.
  • Steam: yes, that's what I would try doing.

Will have to concentrate on triaging for a while (and step down).

3.2 won't receive any updates so moving this report to 3.3 project (or just keep BF Blender?)

The (fallback) launch options are now created for each of the branches < 3.0, will now test switching the Launch Option 0 over to blender-launcher.exe and see if everything still works properly...

OK, so turns out versions >= 3.0 would work just fine with blender-launcher.exe as the default Launch Option 0, but versions < 3.0 would (while giving you the option to launch with console) give an error complaining about missing blender-launcher.exe.

I left the alternate launch options in place in steam for now but switched back to the old behavior of just having blender.exe the default launch option.

Any ideas?

To clarify, the option for Blender versions < 3.0 is there, but the user would need to explicitly select the fallback (with console) option otherwise they get an error mesage.

Does there have to be a default launch option, or can we make a single launch option for every branch?

Does there have to be a default launch option, or can we make a single launch option for every branch?

OK, that seemed to have worked :)
So we now no longer have a default launcher option on steam, each branch has its own launcher option.
note to me and @Thomas Dinges (dingto) : we have to document this in the updated release checklist ("make sure to add a steam launcher option for a new steam branch")

Great.

The Windows store changes should also be quite simple? The main work is for someone to test the msix launches Blender correctly.

For the Windows store we need to test this somehow. The .msix cannot be launched locally due to missing code signing. So I guess we need to make a "test" product to upload it to? Need to check this further.

I can't reproduce locally but both on chat and on BA people are complaining about not being able to start blender from steam

https://blenderartists.org/t/i-cant-open-blender/1417042

I can't reproduce locally but both on chat and on BA people are complaining about not being able to start blender from steam

https://blenderartists.org/t/i-cant-open-blender/1417042

Also on Steam forums: https://steamcommunity.com/app/365670/discussions/0/6118730946118330032/

This error does not happen if you're opt in to a beta branch. I guess there's some error in launch configuration for latest stable build (3.3).

Confirmed. Removing the default launcher option caused start issues on the main branch (when not opted in any beta / older release branch). I added the default launcher again, all older branches work fine but now show a dialog box with the "without console" option, which won't work for < Blender 3.0.

I don't see any good solutions on Steam.
Either we keep living with Blender > 3.0 opening with console or we remove all the old builds, keeping only 3.x ones (and the 2.93 LTS for the time being).

After further checking, I think we have the best solution now. Both the main option and all branches work. The only risk is that old branches (< 3.0) show launch options, where user can choose the "Without console" option, which then won't work and result in an error). But as long as people don't change this, it works.

The other two alternatives mentioned in my previous comment seem suboptimal to this. Since most people use new builds > 3.0 anyway, I think we should be okay.

So current situation is:

  • Blender >= 3.0 launches without console (no popups) >> good
  • Blender < 3.0 launches with popup (one working option [with console] one broken option [without console]) >> less than optimal

Would still vote for keeping it like this (since the userbase for < 3.0 seems to be very small?)

Just dropping here that there might be a problem left?

i can now use it through steam but steam doesnt seem to track time and not consider it an active game

https://steamcommunity.com/app/365670/discussions/0/6118730946118330032/?ctp=2#c3546050190319649233

Just dropping here that there might be a problem left?

i can now use it through steam but steam doesnt seem to track time and not consider it an active game

https://steamcommunity.com/app/365670/discussions/0/6118730946118330032/?ctp=2#c3546050190319649233

I assume to get rid of this, we might have to add the Launch Type Launch (Default) again which in turn would bring this back:

To clarify, the option for Blender versions < 3.0 is there, but the user would need to explicitly select the fallback (with console) option otherwise they get an error mesage.

So tradeoff between some nice (but niche? -- not sure if users really rely on their time being tracked, will ask in forums) bonus feature that steam brings OR a bit disturbing workflow [error by default] for a small userbase on blender < 3.0
None of the two seem like catastrophes, for now (until there are clear arguments for relying on the "steam-active-game-tracking") my vote would be to keep as-is.

The launcher exits as soon as blender.exe launches, so that's likely why steam can't keep track of the hours, we can likely add some code in the launcher to keep it around if it's steam launching it. there's already some code in it that keeps the launcher alive when you start it in background mode. shouldn't be too hard, the real question is do we want to?

The launcher exits as soon as blender.exe launches, so that's likely why steam can't keep track of the hours, we can likely add some code in the launcher to keep it around if it's steam launching it. there's already some code in it that keeps the launcher alive when you start it in background mode. shouldn't be too hard, the real question is do we want to?

Ah, thx looking into this, good that my assumptions were wrong.
@Ray molenkamp (LazyDodo) : why would we not want to keep the launcher alive then?

I created a patch for the WIndows store now D16589, but not sure how to get an .msix for this to test. Build a patch build and then let the buildbot create an .msix for that? Arnd wasn't sure if that's possible.

To test, just push the change to master and then test, it can't be done with a branch/patch build.

I couldn't verify the correctness of the change yet.

  1. The command mentioned there only works starting on Windows 11, I am still on 10. https://learn.microsoft.com/en-us/windows/msix/package/unsigned-package#installing-an-unsigned-package
  1. @Jesse Yurkovich (deadpin) tested it on Windows 11 (Thanks!), but got this error:

Add-AppPackage -Path .\blender-3.5.0-alpha+master.f4e1f62c62e6-windows.amd64-release.msix -AllowUnsigned
Add-AppxPackage: Deployment failed with HRESULT: 0x80073D2C, The package deployment failed because its publisher is not in the unsigned namespace.

@Sergey Sharybin (sergey) tested the msix here on Windows 11 (using local signing I think), and it seems to work as expected.

So now all that is left is backporting this to 3.4 and 3.3?

Great, thanks for that. I will backport it to 3.4 and 3.3 and then close this task.

Thomas Dinges (dingto) closed this task as Resolved.Thu, Nov 24, 3:34 PM
Thomas Dinges (dingto) claimed this task.