The Flame Launcher aka bringing back switchable user Profiles for everyone

Flame Python
1

Autodesk took away our selectable users during project launch.

So I finally went ahead and made a custom launcher for macOS , should work on linux with some adjustments but untested , dont want to deal with roaming profiles and Active directory? me neither.

image
image410×282 20.9 KB

super barebones stuff, but should get you up and running rather fast

what it does:

→ Scans all installed flame versions and lists them with the newest installed version on top
→ Lists all available users and sets “DL_USER_HOME”
→ launches flame in a terminal so you can see logs if it crashes
→ Can be expanded to set more environment variables

it saves the last used user and flame version to your OS accounts library so it will always default back to it.

How to make this work for your studio:

  1. Change the line 23 in the .py file (open with a code editor or… textedit) self.user_profiles_path = “/Volumes/stone/central/user_profiles” to a folder containing subfolders for all your users

Step2: create the subfolders mentioned above /my/profiles/location/finn/flame and /my/profiles/location/bernd/flame

Step3: click on launchflame.command

use a single word nickname for the subfolders, I do not
think my code support “the Master of the Universe” subfolder names…
you can make that a location on your NAS of course.

You can now copy your own local profile (~/Library/preferences/Autodesk/flame) to that location or just start flame with that user home and flame will create a brand new profile.

if this gains more traction and people want to use it I am happy to throw it in the portal or make the repo on github public, just lmk, hope it helps :slight_smile:

grab it while its hooot: rpb_flamelauncher.zip (2.4 KB)

15 Likes
2

Thanks dude! Can’t wait to try it

1 Like
3

I can report that it works on linux, without any extra packaged needed. Tested on a fresh new Rocky Linux 9.3 installation.

Thought the tkinter UI is ugly. Maybe it could be adapted changing tkinter by this nice resource written by MikeV for QT and get flame’s UI

1 Like
4

yea sure I just dont know QT and wouldnt that make it less portable across systems? seems like a large overhead getting QT in there for a simple launcher

1 Like
5

awesome … :grinning_face:

6

Made one for myself when we switched to 2025.
In Python. Made sym links to a repository user settings folder that will switch the user and start flame. However
Still can’t do it while Flame is running, which is a drag. Mabey yours does?

7

sadly no it cant, same idea as yours, sets a env variable on launch, cant change i mid running / i mean you can but i dont think its evaluated

8

Yeah, one can only hope that changes in 2026, Not sure it will.

9

Improbable

1 Like
10

I totally get Autodesk’s vision and the direction Flame is heading. That said, it would’ve been super helpful to still have the option to use the old user-switching method. For more than 20 years, Flame has been a high-end, rock-solid, and reliable tool — perfect for both big VFX studios and small creative shops like mine.

The move to Mac? Genius. And let’s not forget the amazing community that’s grown around it, led by passionate people like Randy, Andy, and so many others.

We’ve got tutorials on YouTube (with the iconic voice of Jeff K), the Logik forum (featuring some of Alan’s magic threads), the Matchbox collection (./var and all the wizards), the Portal, the Logik Academy, Logik Live, and more — all signs of a tool that’s adapted to every kind of creative.
Some are super technical, others are pixel wizards just winging it in magical ways.

I know for some this might seem trivial or easily solvable with AD or LDAP, but for others, it was a key feature.

Let’s not overlook any of them.

@finnjaeger And once again, thanks for the script . I tested it, and it seems to work on both Mac and my Linux machines! Amazing.

To me, Flame is first and foremost a creative tool — it just happens to live inside a computer.

Merci a toute la communauté Logik

4 Likes
11

i do agree, i think there should be the option of running AD-less by default. this extends to the horrid licensing scheme adsk uses.

scenario:
I sit on my flame on my desk but I have a issue so I call over @hildebrandtbernd to help me, i use flame hkeys and he uses smoke hkeys..

What autodesk thinks one should do:

  1. close flame on both mine and his machine
  2. log out finn user
  3. log in bernd user
  4. sign in to autodek account on my machine
  5. launch flame, fix issue
  6. close flame
  7. Logout bernd
  8. login finn
  9. launch flame

While in reality we would just want this..)

  1. bernd sits down, picks his user from the settings
  2. fix the issue
  3. switch to finn user

As you can see nobody is going to do what autodesk wants here, its insane.

another scenario, lets say you have 3 flame seats in a open office space and a client-suite

“Should we review these shots in the suite really quick?”

Adsk way:

  1. close flame on my machine
  2. login to suite-flame
  3. login to suite-flame adsk account
  4. start flame, review shots
  5. close flame
  6. logout from OS
  7. start flame on my machine

((and then not even talking about additional tools like mocha, neat video etc)

Adsk licensing and user management does not meet the demands of smaller studios like us this way, what we want is floating licenses, just a pool of a number of active flames we can launch.. we dont need or want multiple user-layers (adsk account, system user , flame user..)

Licensing scheme tier list

  1. Floating network licenses, ideally cloud based , best implementation ive seen so far: Foundry ( cloud and RLM management are allright, just headless rendernodes are a bit stupid)

  2. Dongle Licenses, dongles are amazing. I love all my resolve and avid dongles..

  3. Serial numbers for node locked actiavtion with manual deactivation (needs cloud option to revoke license from machine) , good implementations include pomfort silverstack

  4. Login based licensing is the worst of them all, adsk, maxon, adobe .. they all have problems and are not fitting any business case I know of, so everyone and their grandma are setting up fake users for each machine to get around that.

Especially since larger cooperations will just get floating licenses, so smaller studios get forced into doing ldap/ad user management just for licensing more or less and large cooperations dont have to but they do AD anyways because they are large enough to warrant it ?!

nonsensical if you ask me, many larger studios move people around machines on a per project basis, maybe a animator needs to animate a heavy asset for 3 weeks so he gets a fast box, imaging having to deal with adsk login licenses with people constantly
moving around ..

anyhow I got my personal issues with licensing i think we shouldnt accept these unfriendly licensing schemes, i am happy
to pay the price for the software - no doubt i just expect to be treated better than a pirate with more convenience and less BS.

Remember when DVDs had a forced anti-piracy ads running before you could start the movie? And of course pirated content - did not… so the pirated copy wasnt just free it was also better in pretty much every way… just saying.

2 Likes
12

its a autodesk issue i assume.

They figured that with floating licenses, husinesses dont buy a license for each user but just as many licenses as are used in parallell. For logical reasons.

Moving to user based rather than seats based licensing kinda makes you buy a license for each user, so chances are you are heavily oversubscribing vs actual use.

its clever, they didnt just change how licensing works they also changed their whole license agreement and everything else to make sure it talks about users everywhere, its not allowed for licenses to be used by multiple users, so you cant have a license user A uses from
9am-12pm and then user B from 12-5pm …

(you can move the seat between users but youd have to do that .. manually)

so with that licensing in place - there is no need to have usermanagement in flame as you are supposed to have a machine user for each user that uses adsk software because then they can track system users vs adsk login users or something and write angry emails about license overuse .

Its really quiet not that nice , i am very much for fair licensing , its expensive enough.

totally not a lawyer but make sure to read the adsk licensing agreement..

13

We just moved from 2023.0.1 to 2025.2.2 not long ago, and honestly — Thx again to the dev team. Lots of cool stuff in there: new nodes, centralized components, and overall a solid update.

We’ve got between four and six Flames running daily (Macs and Linux), and our artists bounce between machines depending on the task, screen setups, comfort, etc. Even more so when freelancers are involved.

If I got @finnjaeger right, I didn’t realize how much this new user-switching flow could impact things.

So just to be sure — if we want to roll with AD/LDAP for smoother user switching, do we now need a license server? I’d be happy to use one again — that setup was way easier to handle for licencing.

But is it still an option for smaller shops ? I thought it had been discontinued. Anyone know for sure?

Thx again .

@Slabrie @fredwarren

14

There is no license server anymore. It’s fucking horrid named user licensing.

1 Like
15

I made a video about this awhile ago. We disconnect the linux user, from the license user.

For instance, my linux user is “Alan”, but I use “flare01” Flame license user. That license is not tied to me personally, but to an ADSK account managed by my company. We use an OTP Token generator self hosted, that is tied to the ADSK account. While I completely hate Named User, and it is a double kick in the balls to all studio operators, we have made it work with the minimal amount of pain possible in this scenario. If people want I can go over it again at some point.

16

afaik this is not ok reading through the license agreement.

Each user has to be a actual person, not a machine - idk if enforced but if flare01@company.com is used by multiple AD users that would probably give them grounds to send you annoying emails from what I understand, as that would mean 1 license is shared across multiple
persons.

its nonsensical af.

1 Like
17

Hey Alan, thanks for your reply. Could you please forward a link of the video you’re referring to?

I find it very concerning that even you have to find a workaround for this licensing issue, or at least the lack of options (Autodesk account vs. License Server).

I’ve heard that major companies like MPC, Rodeo FX, Framestore … for reasons related to TPN (Trusted Partner Network policy), were able to negotiate server licenses for their Flame software.
I must admit I’m quite confused about the purpose of these sudden changes in user functionality.

@Slabrie @fredwarren
With this in mind, could we at least get an option to enable/disable user switching?
I understand and agree with the software’s direction, but some decisions seem to ignore wider ecosystem considerations.

thx

18

we haven’t had any issue with this. Never got any warnings. You still can only use 1 license at a time, so no fuckery there. You can to try to get things done following their legal mumbo jumbo, or you can get things done. I chose to get things done.

This might be what they call:
america-hurricane

2 Likes
19
1 Like
20

magnifique
thank