Application Launcher

Launch Application

Launch Applications and initialize the Shotgun Pipeline Toolkit.


By: Shotgun Software
Latest Version: v0.9.4 (prod)
For our version numbers, we follow the Semantic Versioning standard.
System Name: tk-multi-launchapp

Table of Contents:

Overview Summary

Documentation

      How It Works

            Use Command Line Arguments at Launch

            Set Environment Variables and Automate Behavior at Launch

            Launching Applications that do not have an Engine Yet

      Technical Details

            3DSMax

                  Extra configs

            Hiero

            Maya

                  Extra configs

            MotionBuilder

                  Extra configs

            Nuke

                  Extra configs

            Photoshop

                  Extra configs

Installation, Updates and Development

Configuration Options

Release Notes History

Overview

This document describes functionality only available if you have taken control over a Toolkit configuration. Please refer to the Shotgun Integrations User Guide for details. The Launch app makes it easy to jump from Shotgun or other environments right into an application. It supports a number of common applications such as Maya, Nuke, Photoshop etc. - see the documentation for the full list. We are adding support for new applications regularly as we build engines for them. When an application is being launched, the Shotgun context (the current Work Area) is set and the Shotgun pipeline toolkit is initialized and launched. It also handles folder creation on disk if you are using a user work sandbox. When the app has launched you will see a Shotgun menu, focused around the context you selected in Shotgun, ready for you to start work right away in the right part of the file system.

Documentation

This app provides a shortcut to make it easy to jump from Shotgun to any supported application. It registers a Shotgun Action entry called for various entities in Shotgun according to your configuration choices.

How It Works

Depending on your configuration options a menu entry will appear in Shotgun when right-clicking entities or using the Shotgun actions menu or gear menu.

For example, this screenshot comes from a site who's configuration uses this app three times to implement menus for Maya, Nuke and Photoshop.

Tank Actions Menu

Currently supported applications and engines are:

  • 3DSMax
  • Hiero
  • Maya
  • MotionBuilder
  • Nuke
  • Photoshop
  • Mari
  • Houdini
  • Softimage
  • Flame

Use Command Line Arguments at Launch

Many applications have command line options that can be called to choose a different edition of the application (ex. Nuke vs. NukeX) or to specify other various usage aspects. The launcher app has an 'args' setting for each OS that can be configured for this purpose. For example if you put '--nukex' there, it will add that to the command line launch and NukeX will run instead of regular Nuke:

Launch NukeX Example

launch_nuke:
  engine: tk-nuke
  extra: {}
  hook_app_launch: default
  hook_before_app_launch: default
  linux_args: '--nukex'
  linux_path: '@nuke_linux'
  location: {name: tk-multi-launchapp, type: app_store, version: v0.2.15}
  mac_args: '--nukex'
  mac_path: '@nuke_mac'
  menu_name: Launch Nuke
  windows_args: '--nukex'
  windows_path: '@nuke_windows'

Set Environment Variables and Automate Behavior at Launch

Applications often require certain certain environment variables, plugin paths, etc. to be set in order to properly function in a studio pipeline. The launch app helps cover this case via the 'before_app_launch' hook, which allows you to define a snippet of code to run each time an application starts up. By default, the 'before_app_launch' hook is a simple pass-through that does nothing, but it can be overridden by following the instructions in this doc.

For example, if you use Zync Render, the Zync Maya plugin directory needs to be part of both $PYTHONPATH and $XBMLANGPATH. To have the launch app set these environment variables, update the 'before_app_launch' hook with a few lines of code, as follows:

Set Environment Variables Example

def execute(self, **kwargs):
    """
    The execute functon of the hook will be called to start the required application        
    """

    # Example to show how to set env vars on Maya launch

    # Append the desired path to the existing $PYTHONPATH to ensure
    # everything upstream still works
    os.environ["PYTHONPATH"] = os.environ["PYTHONPATH"] + os.pathsep + "~/Library/zync/zync-maya"

    # Set $XBMLANGPATH to the desired path, may need to append it as
    # with $PYTHONPATH if already defined in your pipeline
    os.environ["XBMLANGPATH"] = "~/Library/zync/zync-maya"

You can also use the 'before_app_launch' to automate other behavior, including Shotgun updates. For example, you can configure the launch app to update the Task status (in this case, to "in progress") each time it's run (as long as the launch is from a Task, of course), as follows:

Automate Task Status Update Example

def execute(self, **kwargs):
    """
    The execute functon of the hook will be called to start the required application        
    """

    # If there is a Task in the context, set its status to 'ip'

    if self.parent.context.task:
        task_id = self.parent.context.task['id']
        data = {
            'sg_status_list':'ip'
        }
        self.parent.shotgun.update("Task", task_id, data)

As you can imagine, there are many possibilities here, and the launch app aims to provide the flexibility your pipeline needs.

Launching Applications that do not have an Engine Yet

You can also use the launch app to start up applications that do not have a Toolkit engine yet. In this case, folders will be created on disk for the shot, task or asset you are launching from and the application will be launched, but no code will run after application startup and no Shotgun menu will appear inside the application. This means that you can launch applications that are not yet supported by Toolkit from within Shotgun.

In order to do this, configure the app with paths to the application you wish to launch, but leave the engine option as an empty string.

Technical Details

3DSMax

This app automatically adds a MaxScript, init_tank.ms, to the 3DSMax command line that 3DSMax will run as part of its boot process.

When 3DSMax is booting, the following will happen:

  1. 3DSMax will run init_tank.ms upon starting
  2. init_tank.ms makes sure a Python interpreter is available and runs tank_startup.py
  3. Using the Shotgun Toolkit Context API, the entity id passed from Shotgun is converted into a Toolkit Context.
  4. Start the appropriate Engine (via tank.system.start_engine()) and pass in the Context. The engine will take care of the rest.

Extra configs

No extra configs are necessary for the 3DSMax engine

Hiero

Maya

This app registers a userSetup.py auto start script with Maya which Maya will call as part of its boot process.

When Maya is booting, the following will happen:

  1. Maya starts execution of the userSetup.py startup script
  2. Using the Shotgun Toolkit Context API, the entity id passed from Shotgun is converted into a Toolkit Context.
  3. Start the appropriate Engine (via tank.system.start_engine()) and pass in the Context. The engine will take care of the rest.

Extra configs

No extra configs are necessary for the Maya engine

MotionBuilder

This app registers a init_tank.py auto start script with MotionBuilder which MotionBuilder will call as part of its boot process.

When MotionBuilder is booting, the following will happen:

  1. MotionBuilder starts execution of the init_tank.py startup script
  2. Using the Shotgun Toolkit Context API, the entity id passed from Shotgun is converted into a Toolkit Context.
  3. Start the appropriate Engine (via tank.system.start_engine()) and pass in the Context. The engine will take care of the rest.

Extra configs

No extra configs are necessary for the MotionBuilder engine

Nuke

This app registers a menu.py auto start script with Nuke which Nuke will call as part of its boot process.

When Nuke is booting, the following will happen:

  1. Nuke starts execution of the menu.py startup script
  2. Using the Shotgun Toolkit Context API, the entity id passed from Shotgun is converted into a Toolkit Context.
  3. Start the appropriate Engine (via tank.system.start_engine()) and pass in the Context. The engine will take care of the rest.

Extra configs

No extra configs are necessary for the Nuke engine

Photoshop

This app will use the Adobe Extension Manager to install or make sure the Tank plugin is installed.

When Photoshop is booting, the following will happen:

  1. Photoshop will start the execution of the Tank Plugin
  2. Using the Shotgun Toolkit Context API, the entity id passed from Shotgun is converted into a Toolkit Context.
  3. Start the appropriate Engine (via tank.system.start_engine()) and pass in the Context. The engine will take care of the rest.

Extra configs

If you intend to use this app to launch Photoshop you will need to supply four config values in the extra section. Here are the configs and sane default values which you would need to adjust for your system and installation locations:

mac_python_path: "/usr/bin/python"
windows_python_path: "C:\\Python27\\python.exe"
mac_extension_manager_path: "/Applications/Adobe Extension Manager CS6/Adobe Extension Manager CS6.app"
windows_extension_manager_path: "C:\\Program Files (x86)\\Adobe\\Adobe Extension Manager CS6\\XManCommand.exe"

Related Apps and Documents

Launch Published File

This document describes functionality only available if you have taken control over a Toolkit configuration. Please refer to the Shotgun Integrations User Guide for details. This app works in conjunction with the launcher app and lets you right click on a published file in order to launch it in its host application. Shotgun will start up the relevant application and initialise the Shotgun Pipeline Toolkit via a launcher app and then finally load the file in.

Admin Guide

This is the Admin Guide for Shotgun Integrations.

User Guide

This is the User Guide for Shotgun Integrations.

Installation and Updates

Adding this App to the Shotgun Pipeline Toolkit

If you want to add this app to Project XYZ, in an environment named asset, execute the following command:

> tank Project XYZ install_app asset tk-maya tk-multi-launchapp

Updating to the latest version

If you already have this item installed in a project and you want to get the latest version, you can run the update command. You can either navigate to the tank command that comes with that specific project, and run it there:

> cd /my_tank_configs/project_xyz
> ./tank updates

Alternatively, you can run your studio tank command and specify the project name to tell it which project to run the update check for:

> tank Project XYZ updates

Collaboration and Evolution

If you have access to the Shotgun Pipeline Toolkit, you also have access to the source code for all apps, engines and frameworks in Github where we store and manage them. Feel free to evolve these items; use them as a base for further independent development, make changes (and submit pull requests back to us!) or simply tinker with them to see how they have been built and how the toolkit works. You can access this code repository at https://github.com/shotgunsoftware/tk-multi-launchapp.

Special Requirements

  • You need Shotgun Pipeline Toolkit Core API version v0.18.74 or higher to use this.

Configuration

Below is a summary of all the configuration settings used. These settings need to be defined in the environment file where you want to enable this App or Engine.

linux_args

Type: str

Description: The arguments to be passed to application on Linux, as a string.

engine

Type: str

Description: The name of the Shotgun engine to start. This is typically the application name prefixed with tk, e.g. tk-maya, tk-nuke, tk-photoshop etc. If you set this to an empty string, no toolkit engine will be started, meaning that you can launch applications that do not have toolkit engines set up.

mac_args

Type: str

Description: The arguments to be passed to application on Mac OS X, as a string.

windows_path

Type: str

Description: The path to the application executable on Windows.

group

Type: str

Description: The name for a group this command should be considered a member of.

hook_before_app_launch

Type: hook

Default Value: before_app_launch

Description: This hook is called just before the hook_app_launch is used and can be useful if you don't want to modify the way applications are being launched (which is advanced usage and can be done by overriding the app_launch hook), but merely want to modify the environment before app launch. You may want to add additional pipeline paths, APIs or other things to the setup, or specify additional scripts etc to run.

linux_path

Type: str

Description: The path to the application executable on Linux.

mac_path

Type: str

Description: The path to the application executable on Mac OS X.

extra

Type: dict

Description: Shotgun engine specific extra values. These are defined per Shotgun engine. Please look in the app documentation for more details.

defer_keyword

Type: str

Description: Advanced parameter. This allows for advanced customization around deferred folder creation. Deferred folder creation allows for the creation of partial subfolder structures depending on a specific keyword (see main documentation for details). Before an app is launched, folders are automatically created and by default (e.g. if you leave this setting as null), the launch app will pass the name of the engine as the deferred folder creation keyword. This makes it easy to set up deferred rules in your folder creation config for tk-maya, tk-nuke etc. However, if you for example wanted to set up specific deferred folder structures for Nuke and Nuke X (both running the nuke engine), you need a finer granularity. This setting can then be used to override the default behaviour of just passing the engine name. Instead, you can pass any string into the deferred folder creation (for example 'nuke' and 'nuke_x' in the case above). This parameter is also useful if you want to use deferred folder creation in conjunction with launching of apps which do not have a toolkit engine defined - for these app launch instances, the engine setting is left blank, and therefore no engine name is passed into the deferred folder creation. In such cases you can utilize this parameter to control the deferred folder creation. You can specify multiple keywords using a comma as a delimiter (eg. 'nuke, nuke_x'). This will trigger folder creation for folders in your schema that have any of these values in their deferred folder creation setting.

menu_name

Type: str

Description: Name to appear on the Shotgun menu.

hook_app_launch

Type: hook

Default Value: app_launch

Description: Called to launch the application. This hook contains the code that does the actual execution of the launch command and parameters. If you have a custom launcher system in your studio, it can be handy to override Tank's default launch behaviour.

versions

Type: list

Description: A list of strings that will be used to substitute for the {version} token in the values for the other settings for the instance of this app. For example, a value of ['2012', '2013', '2014'] for this setting and a value of 'Launch Maya {version}' for menu_name would result in the following command menu names being registered: Launch Maya 2012, Launch Maya 2013, Launch Maya 2014. The first version in the list will be considered the 'default' version if the engine running the app supports the concept. You can use pieces of the version if you wrap the parts in parenthesis like ['(7.0)v3', '(8.0)v1']. These pieces of the version string are available in the other settings via the {v0}, {v1}, {v2}, ... replacement tokens.

scan_all_projects

Type: bool

Description: When true, and when use_software_entity is true, launchers will be registered for all projects instead of only the current environment's project.

windows_args

Type: str

Description: The arguments to be passed to application on Windows, as a string.

use_software_entity

Type: bool

Description: Whether to use Shotgun Software Entities to register launch commands for available DCCs.

group_default

Type: bool

Description: Boolean value indicating whether this command should represent the group as a whole. Setting this value to True indicates that this is the command to run and display in applications that show a single button for each named group.

icon

Type: str

Default Value: {target_engine}/icon_256.png

Description: The path to the icon to appear for the application. If the value starts with '{target_engine}' then the remainder of the path will be relative to the root of the engine's install. If the value starts with '{config_path}' then the remainder of the path will be relative to the root of the configuration. The path should use forward slashes which will be replaced with the correct operating system separator when used.

Release Notes

Welcome to the release notes for the Multi Launch App. Below you will find an overview of all the changes we did for each release. We try to be as detailed as possible and include all bugs we have fixed, features we have added and things that may have changed. If you have questions about a particular release, don't hesitate to contact our support team!

v0.9.4

2017-Jun-29

Tweaks to debug logging.

v0.9.3

2017-May-17

Minor adjustments to logging output

v0.9.2

2017-May-16

Fixed issue in shotgun version detection check.

v0.9.1

2017-May-16

Incremented minimum required core version

v0.9.0

2017-May-04

Support for software entity based launching.

Details:

  • When connected to shotgun 7.2 and above, adds support for the software entity. This is disabled by default and can be turned on via a use_software_entity setting.
  • Adds parameters needed for the upcoming websockets integration
  • Adds support for better grouping and group defaults. If used, these will propagate to the register command call and will be utilized by engines that implement command grouping.
  • Support for automatic software scanning interfaces. Used in conjunction with the software entity, allowing a setup where the launch app reaches out to an engine and requests that the engine reports which software installations are detected on the current machine.

v0.8.2

2017-Mar-15

Removes problematic profiles from png files used as icons.

Details:

This will silence libpng warnings from Qt when the png files are loaded as pixmaps. This is a second attempt as this profile stripping, and uses ImageMagick's "mogrify" command to achieve the desired result, which maintains color consistency.

v0.8.0

2016-Oct-06

Removes Maya 2012/2013 specific SSL patching.

Details:

Support for Maya versions older than 2014 has been deprecated.

v0.7.7

2016-Sep-19

PATH environment variable fixes for 3ds Max 2017 compatibility.

v0.7.6

2016-Apr-12

adds support for version token replacement in args setting

Details:

  • This enables clients who use a wrapper to launch their DCC, take advantage of the version tokens in the *_args setting for launching multiple versions of their DCC.

  • Removed error when launching from a Task in the Shotgun web application without an associated Pipeline Step. It is completely valid to have a schema that uses Tasks that do not have an associated Pipeline Step. Previously, we would raise an exception when launching from a Task in the Shotgun web UI that had no associated Pipeline Step.

v0.7.5

2016-Apr-11

(NOT RELEASED) Removed error when launching from a Task in the Shotgun web application without an associated Pipeline Step

v0.7.4

2016-Apr-08

(NOT RELEASED) adds support for version token replacement in args setting

v0.7.3

2016-Feb-29

Remove warning about missing version tokens in menu

Details:

  • Previously when you specified versions in your launcher instance settings, but didn't use any version tokens in the instance menu name, a warning would be emitted: . This warning was misleading and unnecessary. So we've now removed it altogether.
  • Updated docs regarding using multiple defer_keywords

v0.7.2

Cleans up the bootstrap module after launch.

Details:

After a "generic" bootstrap operation is performed, the bootstrap module that was imported is removed from sys.modules. This allows subsequent launches that make use of a bootstrap module to function properly.

v0.7.1

Rearranges bootstrapping logic to fix bootstrapping for some engines.

Details:

Some engines have a bootstrap.py file included in their structure, but aren't setup for those to be fully standalone. In those cases, we need to let the launchapp bootstrapping code specific to that engine to run rather than relying on the generic bootstrapping behavior to handle everything.

v0.7.0

Favors bootstrap routines provided by the engine over those contained in the app.

Details:

If the engine contains bootstrapping logic it will be used. If it does not then launchapp will fall back on its internal logic.

v0.6.7

2015-Nov-04

Improved error message when flame is not found.

v0.6.6

app_path, app_args, and version parameters passed to both hooks

Details:

The before_app_launch hook now gets the same parameters as the app_launch hook which means you have access to the path of the application being launched and any arguments passed in. Also added a version parameter which will contain the version being launched if it was defined in the 'versions' setting in the Launcher instance (otherwise this will be None).

v0.6.5

add additional tokens to specify parts of the version string

Details:

Allows defining groups in the version string using ()s. You can then reference them in order as tokens in the icon, *_path, and menu_name settings. For example, if the version setting is ["(9.0)v4(beta1)"], the resulting available tokens would be:

{version}: "9.0v4beta1"
{v0}: "9.0"
{v1}: "beta1"

v0.6.4

Updated signature for the generic engine boostrap call.

v0.6.3

Pass multi-launchapp instance to the generic bootstrap.

v0.6.2

improved error when trying to run 3dsmax 2015 with the old tk-3dsmax engine

Details:

3dsmax 2015 requires the newer tk-3dsmaxplus engine to run. However, users may upgrade from older versions of 3dsmax and not realize this. Previously when doing so, they would get an unhelpful error message when the bootstrap script attempted to run on startup. This change catches the error at that point and displays a dialog explaining the need to use the newer tk-3dsmaxplus engine instead.

v0.6.1

App now backups the environment variables before launching an app and restores them afterwards.

Details:

sys.path and os.environ are now backed up before any app launch and restored after so that one app's launch environment can't leak into another's.

v0.6.0

Added generic engine launch logic so new engines do not need to modify this app.

v0.5.4

Documentation Update

v0.5.3

Update the project python bootstrap to reset PATH

Details:

Make sure applications are launched with the proper DllDirectory set.

v0.5.2

Minor adjustments to the Flame bootstrap sequence.

Details:

This changes the way the Flame family is being launched so that it gains greater control over the boostrap and launch process. The actual executable argument is being sent in to Flame so that this can be re-written by the engine at runtime, effectively allowing the Flame engine to run the DCC launch through its own wrapper script. This is to ensure that a particular environment is being set up where all library dependencies are working etc.

v0.5.0

Added support for the Flame Engine.

v0.4.1

Added support for the new 3DS Max Engine supporting MaxPlus and Max version 2015.

v0.4.0

Added support for launching Mari

v0.3.1

Improved error messaging when an application cannot be launched.

v0.3.0

Added a 'defer_keyword' parameter to support some advanced use cases.

Details:

This adds a new manifest parameter called 'defer_keyword'. Here is the manifest description: Advanced parameter. This allows for advanced customization around deferred folder creation. Deferred folder creation allows for the creation of partial subfolder structures depending on a specific keyword (see main documentation for details). Before an app is launched, folders are automatically created and by default (e.g. if you leave this setting as null), the launch app will pass the name of the engine as the deferred folder creation keyword. This makes it easy to set up deferred rules in your folder creation config for tk-maya, tk-nuke etc. However, if you for example wanted to set up specific deferred folder structures for Nuke and Nuke X (both running the nuke engine), you need a finer granularity. This setting can then be used to override the default behaviour of just passing the engine name. Instead, you can pass any string into the deferred folder creation (for example 'nuke' and 'nuke_x' in the case above). This parameter is also useful if you want to use deferred folder creation in conjunction with launching of apps which do not have a toolkit engine defined - for these app launch instances, the engine setting is left blank, and therefore no engine name is passed into the deferred folder creation. In such cases you can utilize this parameter to control the deferred folder creation.

v0.3.0

Added a 'defer_keyword' parameter to support some advanced use cases.

Details:

This adds a new manifest parameter called 'defer_keyword'. Here is the manifest description:

v0.2.19

Relaxed the error catching for the icon setting.

Details: Relaxed throwing an error if the icon is set to a '{target_engine}' replacement string even if the engine setting is empty.

v0.2.18

Support for the icon and versions settings.

Details: Added two new settings, "icon" and "versions". The icon can be used to define an icon that should be registered for the command if the engine has support for icons. The versions setting is shorthand for defining multiple applications where the only difference between the configurations is the version of the application being launched.

v0.2.17

Event log statistics now also tracks the core API version.

v0.2.16

Support for renamed env vars for photoshop engine.

Details: Added support for latest photoshop engine. Added readme for building linux Softimage dependencies. 3dsMax bootstrap handles _blurLibrary not being defined.

v0.2.15

Improved Softimage launching on Linux

v0.2.14

Fixed a bug that would cause launching to fail for 3dsMax and Motionbuilder

v0.2.13

Added ability to launch applications not yet integrated with Toolkit.

v0.2.12

Updated minimum required core version to v0.14.0

v0.2.11

Better support for review versions.

v0.2.10

Added logic for handling launching from review versions.

v0.2.9

Updated Softimage support

v0.2.8

Added exceptions for softimage.

v0.2.7

Houdini is not supported on osx due to Qt compatibility issues.

Details: Houdini is not supported on osx due to Qt compatibility issues.

v0.2.6

Added Houdini and ability to open hiero projects at application startup.

v0.2.5

Renames and support for the new name Sgtk.

v0.2.4

Added experimental support for launching softimage.

v0.2.3

Added a check so that Tasks that are missing steps cannot be launched from when launching from inside Shotgun.

v0.2.2

Adjustments to context handling and folder creation.

Details:

  • The context is now serialized and passed from the app into the booting application
  • Now correctly handles setups which are not task or file based
  • Added new interfaces for better preserving context state when launching from a publish

v0.2.1

Adjustments to context handling and folder creation.

Details: - The context is now serialized and passed from the app into the booting application. This means that any context can be transferred into a launching app. Previously there were some built in restrictions as to what was possible to pass. - Added a pre launch hook for easy addition of environment variables to the launch.

v0.2.0

Bug fixes and preparation for v0.13

Details: - adjusted launch code for hiero to work with latest version of hiero - fixed a bug where opening nuke via a nuke file wasn't working - general prep for v0.13 - improved command metadata - polish on certain error messages

v0.1.0

Added documentation.

v0.0.2

Fixed issues with launching 3dsmax, removed the platforms parameter from the configs.

v0.0.1

Initial Release to the Tank Store.

Follow

8 Comments

  • 0
    Avatar
    Asi Sudai

    I got confused about what's this app do, maybe it's the main image:

    tk-multi-launchapp is a back-end framework that knows how to launch applications ( Maya, Nuke ) with the correct environment.

    tk-multi-launchapp is not a stand-alone GUI that allows to pick a context (task,asset,shot ) and launch an application.

    I hoped this app could be run from a Shell, so Artists could launch applications not from within Shotgun but still pick the Context they need and get Tank init with the correct environment and context. No worries, it gives me what to do...

     

  • 1
    Avatar
    Ryan Mayeda

    Hi Asi!

    The tk-multi-launchapp can actually be run from Tank's shell engine as well, as long as you have a project.yml environment that includes tk-shell and the corresponding launch path configuration for the relevant applications.  If you don't already have this, you can re-grab the tk-config-default, as that has a working base setup you can reference.

    If you run 'tank --help' it will give you the usage, but I'll copy and paste the relevant parts here:

    Examples:

    Show what commands are available for the current directory:

    tank

    Show what commands are available for Shot ABC123

    tank Shot ABC123

    Show what commands are available for Shot ABC123 in project Flash

    (In case you have several projects with a Shot ABC123)

    tank Shot Flash:ABC123

    Show a list of all shots in Shotgun containing the phrase ABC

    tank Shot ABC

    Launch maya for your current path (assuming this command exists):

    tank launch_maya

    Launch maya for a Shot in Shotgun:

    tank Shot ABC123 launch_maya

    Launch maya for a Task in Shotgun using an id:

    tank Task 234 launch_maya

    Launch maya for a folder:

    tank /studio/proj_xyz/shots/ABC123 launch_maya

    So, Tank can try to figure out your context based on your current directory when you launch something from the command line, or you can just feed it the context as parameters to the command line.  Give this a try and let us know how it fares for you!

    Ryan.

  • 0
    Avatar
    Asi Sudai

    Thanks for the feedback Ryan. I guess in my head Artists shouldn't deal with folder structures, that's why we're here :)

    for advance users that's great - just 'cd' to the right context and 'tank launch_maya' for example.

    But for the less technical Artists I'm thinking about reusing the "Pick Work Area" from "File Manager" - it let's them pick the Context based on Task assignments, then it's a matter of just adding a drop down menu to pick which app to launch and go.

    feels like an easy workflow for even none-techie artists and also making sure they work based on their Tasks.

    I guess my only question is should I write it or Tank have plans for something similar and I can wait?

  • 0
    Avatar
    Mitchell Lotierzo

    So, I understand the concept of substituting app version with the '{version}' key, but what happens when an app's path is more complex? For example, Nuke on Windows is usually found at 'C:\Program Files\Nuke8.0v3\Nuke8.0.exe'. If I use the version key here, how do I account for the 'v3' component missing at the end?

    Would this best be handled in a custom app launch hook?

  • 0
    Avatar
    Mitchell Lotierzo

    Seems I answered my own question :) I just made a custom app launch hook.

  • 0
    Avatar
    Rob Blau

    Hi Goertz,

    Thanks for pointing that out.  We've updated the docs that'll go out with the next release.

  • 0
    Avatar
    Daniel Goertz

    It seems that this documentation about the **versions **is not correct totally.

    It should be:

    menu_name: Launch Maya {version}

    versions: ['2013*'*]

  • 1
    Avatar
    Patrick Macdonald

    Hey Mitchell, can you share the custom app launch hook you used to fix the nuke versioning issue?

     

Please sign in to leave a comment.