Hi guys! We’d like to be able to collaborate on the same project with a team, so we’re thinking on using sublevels. However, we are a very small team and we don’t want to delve into source control solutions. The thing is, we were thinking on using sublevels so one person could be working on, let’s say, the props of a level, while another one is working on the vegetation. You can indeed do this with each person working on their own sublevel, but if someone has the main, persistent level open, they can’t save their work. Also, they can’t see the other sublevels while working on their own.
We thought the solution was to have everyone working on a sub-level but from the main, persistent level, so you can see other people’s work while working on yours. But, you also can’t save your work this way.
Is there anything you’d recommend for this scenario in terms of workflow/pipeline? Is it posible to have everyone working on sublevels from the main persistent level and saving their work only to the sublevel they were working on?
Using sublevels for project management like this is definitely an acceptable method. You should be able to have people working on their own sublevels and save them individually.
Trying to think out loud about what could be happening:
Users need to be absolutely sure that they have the desired sublevel active (double click with blue highlight) for any newly placed assets to go into that sublevel and not the Persistent Level.
What is specifically happening or popping up when “they can’t save their work [with persistent level open]”? Each sublevel exists as an asset in the Content Browser. Saving that asset is completely detached from saving the Persistent Level. One source of confusion I’ve seen is that Ctrl+S or “Save” only saves the currently active level. For many people that means the persistent level that opens by default. Users should get in the habit of saving their specific sublevel only, or saving the entire project with Ctrl+S (save all), in which case then they would just hand over the .umap for their sublevel to whoever controls the project.
How are you managing this source control? If you are all working off a network drive or using something like Dropbox or Gdrive, there is a chance that the files are set to Read Only or the OS thinks they are currently open somewhere else. That could produce a case in which the files can’t be edited if the first user has touched them at all in the current session. In this case, you should experiment with a more manual download and upload process like you’d have with real version control. Or have users go offline and then online to avoid the OS thinking that the same file is being accessed in multiple places.
Thank you very much for your thorough answer, Stephen!
1.- This is what we were doing, Users where on their desired active sublevel.
2.- This is a great tip, we were saving the current active level mostly, but it might have happened in some instances we didn’t do it right.
3.- This I believe might be the cause of our issues now that you mention it - we are all working off a network drive. Then if someone touched the file, the OS (Windows in our case) could be locking other users from accesing it later.
I think rather than trying to emulate a real version control we are just going to incorporate Perforce into our workflow and this issue will be a no-brainer. Although we’re a small team I think it’s for the best, even if there’s some learning curve to it.