Jump to content

Milan Kolar

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Milan Kolar

  1. Your best bet is probably task templates. They are additive, so if you make templates with just one task, you can have good control over adding them to multiple entities then.
  2. Another useful hook with this. Start timer automatically with app launch. Now we need to figure out how to stop it automatically and there will be some happy producers walking around here. import logging import ftrack import ftrack_api logger = logging.getLogger() def start_time_on_launch(event): '''Modify the application environment and start timer for the task.''' data = event['data'] username = event['source']['user']['username'] session = ftrack_api.Session() # Get user from username user = session.query('User where username is "{}"'.format(username)).one()
  3. So I had some time to play with this a little bit and came up with compact and quite efficient way of dealing with environments using launching events. Technically all that is needed is one hook that listens to the launching events and appends environments from simple .json config files based on app identifiers. The hook looks for .json files in 'FTRACK_APP_ENVIRONMENTS' and tries to find 2 configs. One that is version independent i.e. 'maya.json' and one that is version dependent i.e. 'maya_2016.json', then it adds both into the environment. Config file names mus match the app identifier
  4. This is getting very close to a simple a straightforward system. I have however ran into some issues. The most prominent right now is the fact that I have no way of finding out what task/entity was the source of this launching event. It's not included in the event data and because it seems that this event precedes the ftrack addition of env variables the environment is missing the 'FTRACK_TASKID' key too. It's important to be able to tell what originated the launch event because the enviro usually changes based on what project or task we're launching (different plugins for example.
  5. Sounds great to me for unofficial "holy crap where's this button I certainly saw yesterday" type problems. I'd certainly be on on it happy to chat about ftrack with other users.
  6. That would be lovely addition. Currently we practically don't use the planning because people feel that it's a bit of a double work. Even such simple thing as task inheriting start and end dates from their phase in planning upon creation would help.
  7. Hey Mattias. Yes that should absolutely do the trick.
  8. Maybe these will help someone. 2 Actions we use regularly. When ran on an entity (single or multiple selection), they push it's thumbnail to it's direct parent or all it's children, depending on which one you run Works asynchronously as a job so even running it on big numbers of items shouldn't be a problem. Action - thumb to children Action - thumb to parent
  9. It looked promising, but I'm afraid it doesn't work. The customised action runs first, however, stopping the event propagation kills off all the other actions, so you end up with only this one in the list. Not stopping the event, of course doubles up the action in the UI and runs it twice.
  10. Isn't that what the included task attribute 'worked hours' or 'worked days' (depending on your settings I believe) does? I believe it just calls {self.worked} in an attribute. EDIT: sorry I just re-read your question and realised you're asking for a sum of tasks on the shot... Very good question. I can't find anything about accessing children attributes on in the docs. It would however be most useful.
  11. I think this is expected now considering that every thumbnail is technically a component since one of the last updates.
  12. For a quick start it would help if any plugins on custom paths, that have the same name as the default ones, would override the defaults. Right now I have to delete the ones I'm tweaking from the connect's resource/hook, so it doesn't appear twice in the actions. I don't want to be tweaking them there directly purely because I want to keep any custom code separate. Simplifying this workflow is absolutely essential at this point. Having to extract all of the application launchers from connect and tweaking each of them just to add a few environment variable across the board is a bit of an over
  13. I'll put a good word for this. Toke did great job at making it very easy to run any event based script. We've been using it for months now and it works like a charm.
  14. I believe that's a number of comments. However it doesn't seem to always correspond. Many shots that we have with 3-4 comments only show number 2, some even 1. But in general it should mean, there are comments on the task
  15. We're doing Episodic work too and this would be really helpful.
  16. This!!! Something along these lines would be really great. I've been toying with the idea of creating a separate project for exactly this purpose, but it would be a bit clumsy to find things quickly. Preview playback while hovering over the thumbnail, would pretty much solve this right away.
  17. I second this. A finer control over filtering in reports would be greatly appreciated. Currently we only use it to get a rough idea, but can't get much concrete data out of it.
  18. Milan Kolar

    Change schema

    Hey guys. One thing I'm dealing with right now and it appears I'm stuck. We have 2 shows using the same schema. However midway through production one of them started changing a bit in terms of requirements from client, director etc. So I need to tweak the schema for this one a bit. Different statuses, plus some other config differences. The question is. Is it possible to change the schema after the project is created? I didn't find a way, just as well as I didn't find a way to duplicate schema. That would be super helpful too considering how annoying it is to keep creating new ones all the
  19. For quite some time now, It's become clear to us that we need a bit more detailed task templates for shots. In particular we'd like to be able to have more than one task of the same type on the shot and ability to give the task custom names in the templates. This is especially important on episodic projects, which have tons of shots and due to production speed often split shot into smaller chunks done by different people. For instance we might have someone do the main animation and someone else do background characters at the same time, hence two animation tasks which need to be named accord
  20. As a very first step I'll just say what we are doing now, to make it a bit easier to manage. Instead of treating actions as a standalone piece of script we only ever run them as connect hooks. So we have a directory with all our actions in it and this directory is set in the `FTRACK_EVENT_PLUGIN_PATH`. That way every machine running connect has access to all the actions straight away. There is a small difference when writing action for this workflow as it has to include register function for it to be picked up by connect. Here is the boilerplate code that let's you run action as standalone o
  21. I have to agree with Henrik. It's nice that we can run actions when we want. But for most of the studio that don't have any developers, these things could simply be included as hooks in ftrack connect, so as soon as connect is installed, Actions get loaded as well, rather than having to run them as a separate python process.
  22. Your particular problem might be due to many things. If you post some more info, maybe someone might be able to help you here, but certainly get in touch with thinkbox support. They are responsible for deadline-ftrack integration. To be honest I had the same experience with their submitter from houdini (didn't work at all) and nuke version works, but it's practically unusable in production. I had to spend some time working on a almost ftrack deadline integration, rewriting the submitter and heavily tweaking their event plugin to be able to use it at all.
  23. I've been planning on doing something similar for a while now as an action. You just reminded me so I'll have a look if I find time for it anytime soon. If so I'll share it in the Actions part of the forum
  24. I ended up doing this as a script running on our ftrack daemon that's taking care of changing statuses and similar things. easy code, but would be nice if it was implemented as core functionality.
  25. After using it with multiple clients now I have some more comments. 1. comments section should be expanded by default when they open the session. You'd be surprised how many people never find it, hence don't read comments of others, or don't realize they can comment. Even though we always send an e-mail explaining that it's all there. They need to see it all right away. 2. Description of version. We'd like to be able to write a basic description to versions that appear somewhere very visible. For instance "Matte paint and snowing final". The point it, that now we have to write it separatel
  • Create New...