I find that, when I using import+ to add plugin depot into my project workspace. It seem that, it can’t get the file from changlist in plugin depot.
I’m facing the exact same quandry here… Are you supposed to add import+ on the game’s stream? P4 docs say to do so, but doesn’t that mean any artist who retrieves the project will also retrieve the full source code, even though they don’t compile the editor from source? (They’ll use the PCBs from Horde).
This seems to be the expectation, since in Ari’s slides about the Native folder structure, the Engine folder is expected to live next to all Project folders in the Perforce Workspace root. Implying that all team members who work on projects need the source code as well? Sorry if I’m not making sense I’m super confused.
Really wish there was a hollistic Perforce/Horde documentation from Epic…
It all depends on what you’re importing. We use “import” for the Engine stream but “import+” for our plugin streams (one for third party and one for studio shared). It does mean the artists sync the code, but compared to the art content it’s not a lot. All the stuff that contributes most of the space are intermediates that aren’t in perforce and that they won’t create if they’re not compiling.
If you’re really worried about it you could make a virtual stream that masks out code. Our artists have a virtual stream, but its purpose is to add an import of a stream that has all of the source assets for content. Content only has the imported version used by the engine.
1 Like
We use “import” for the Engine stream but “import+” for our plugin streams (one for third party and one for studio shared).
Thanks a lot for this.
I guess you use “import” for Engine stream just so that nobody accidentally modifies engine source from a project workspace?
Could you explain more about how you use “import+” for plugin streams? What file path do you import them to? Into each individual project’s plugins folder?
EDIT: After further thought, I realised this doesn’t really make sense. If you “import” the Engine stream into your game’s stream, doesn’t that mean if you have multiple game projects, each of them will have to import the Engine stream separately? So if I work on multiple projects, I will have multiple copies of the UE source code downloaded, one for each project. This seems quite unnecessary.
Furthermore, this is also different from the Native project structure in Ari’s slides, which shows you have 1 copy of Engine source and many sibling project folders that are tied to the same Engine source, which is the setup I’m looking for.
Yes
They’re imported to the project’s plugin directory where they would be expected to be found.
Okay there are a few different things going on here. Yes, each of the projects would import the engine separately so each one would have a copy of the engine source. And honestly it’s a bit worse than that because (at least how we have it set up) each projects has it’s own stream of the engine which they import. Project A and ProjectB wouldn’t even import the same stream of the engine (which isn’t actually that bad for perforce reasons). Both of those streams come from a common source though.
This is important in professional development because a) projects should be able to update engine versions on their own schedule and b) you don’t want engine changes required by Project B to affect Project A without A’s knowledge. But this can be too much in some cases. For experiments and R&D projects we have another depot with multiple projects all using the same engine code. For my hobby development I also only have one copy of the engine which is used across multiple game projects, but they’re just for fun. If any of them turned “real” and I was going to actually publish it, that game would get an isolated copy of the engine. At home I only have one stream with all my projects in it as well since I don’t want to switch workspaces or streams to switch projects.
Again a couple things going on here. The native project structure supports multiple projects per engine, it doesn’t require it. Secondly, the structure in perforce is only partially related to what it looks like on disk. Again, in our R&D case we have a stream with all the R&D game projects. That imports a version of the engine (another stream that is our common company version with modifications) and shares the game project directories in the right place so that when you sync that stream, everything is organized on disk exactly as described in Ari’s slides.
This is all to say that regardless of your scale or other needs, keeping the engine as a separate stream and importing it can work and can save you headaches. First because you can limit changes (even accidental ones when working solo). Second because you can organize multiple engine streams (again not so bad because of how perforce works) to main engine source upgrades relatively painless. It takes me a couple of days to do it at work:
Upload to a new pristine version stream (or reconcile the changes in existing stream for a hotfix update).
Copy to the stream that contains our latest pristine.
Merge to our company stream and resolve conflicts from our modifications.
Merge to a project staging stream and resolve conflicts & project issues.
Copy to project mainline to roll it out to the rest of the team.
It seems like a lot but it really does make working with the source engine easier. ‘Cause once you have source, you’re going to find a bug or 5 that you want to fix or an Epic change from the future you want to cherry pick.
A lot of this is also true for plugins. At work we have streams similar to the engine setup that contain all the third party plugins that we’ve sourced from github or FAB. And a slightly modified stream structure for the plugins that we’ve written internally that are meant to be shared across projects (we just omit the pristine versions since the studio versions are the pristine versions).
1 Like