Hey all,
We have a small team working on a project. Our persistent level has several sub levels - let’s say one for art, one for design, one for lighting etc.
The problem is when I build the level to see my most recent changes, ALL of the levels are “touched”, and saving after a build will show changes to each sub level - regardless of whether they are locked or not. This means that while art is working on their sub level, another department could accidentally check in (to source control) an updated version of a sub level simply because I built the game.
Is there a way around this? I’m not sure what problems might be caused by reverting or discarding local changes (in source control) to sub levels - but ideally, there would be a way to just not touch locked files completely.
Many thanks!
Adam
Anyone have any thoughts on this? Maybe someone from Epic can comment on this, or link to an article explaining the thought process?
Just bumping this again. Our team is a little stuck on this and doing lots of reverting of files every time a dev builds the game. Any ideas?
Hello AdamGascoine,
Please allow 2-3 days without a response before bumping a post.
When it comes to building lighting for a level, due to process that is used, it is required that all levels must be built as well and have new packages created for them. This is intended behavior and is not a bug. Unfortunately the builds will need to be organized.
I’m not sure what type of source control you’re using, but with something like Perforce, you may want to look into using streams and having your different teams work in their own stream. You could do periodic mass integrations into your Main stream and have the Dev streams either mirror the Main stream after a while or keep them isolated, depending on what would be more useful to each team. This should help with this workflow problem as any builds done should only affect the stream the build was executed in.
Thank you for the response. Wasn’t aware of the 2 day rule 
We’ll make sure we only kick off a single build monkey in the future then. I think the tendency has been to want to force a build so things continue to look pretty as designers move geo around, but I’m assuming lightmap data and some other stuff is all saved in the umap files, and therefore every build will update all levels. Most of us come from using Radiant based engines, where the lightmaps are packaged separately, and therefore a build will only affect that package.
So, no building unless pre-approved it is!
Thanks for the heads up Matthew.