Just a small tidbit!
I’ve noticed that when you make different kinds of projects, they lump up the source code indifferent ways. For instance, if you do a 3rd Person Base game with C++, it makes the Public and Private folders for you and sorts the code appropriately. But if you do a Basic game, it just throws all of the code into the source folder and doesn’t divide it up at all. Would it be possible to get it standardized?
Thank you for your time!
I would like if you could make those divisions afterwards… YOu can create filters, but they reset upon restart, which gets kinda annoying as the project grows.
Thanks for pointing this out. We’ll get that fixed!
To do this, simply go into Windows Explorer (or Finder on Mac) and actually create the folder organization that you want. The next time to regenerate C++ projects, the same folders will appear in your code IDE. You don’t even have to have a folder called “Private” at all (that is not a ‘special’ name.) You’re free to organize your code in whatever directory structure you find the most fun.
There is only one special rule: A source folder called ‘Public’ will be exposed to modules that depend directly on your module, so that they can include your files. This is generally only needed for engine modules, or larger game projects that have multiple game and editor modules inside it.
–Mike
Mike, I wanted to jump in here with some related issues I’ve faced recently regarding content creation, and the consistancy of folder strucutres, migration etc.
I do realise that you guys work very very hard, and must get bombarded with all types of questions and problems!
However, myself and my friends all agree that clean project management and planning from the get-go helps to make a much higher quality workflow and end product.
The initial issues I experienced with the content browser became less of an ‘issue’ after I had worked out why copying and pasting content =/= Migrating content. After that had been ‘solved’ (I accepted the reasons behind this not being possible), I went on to further import assets from my previous non-UE4 projects.
I hit a snag when a bunch of textures (TGAs) I imported were corrupted. I was expecting this due to them being on a pretty old, and pretty full HDD.
The problem came when I attempted to multi-select and delete the corrupted textures…
I quickly discovered there isn’t any “Ctrl + Shift + Click” multi-line-addition select or whatever Windows calls it. Say I have a folder of 200 assets, I want to remove at least 125 of them due to whatever reason, but they aren’t all sequentially listed, randomised, with some of them clumped together, others on their own. In Windows, as most advanced Windows users are aware of, you can not only Ctrl + Click or Shift + Click, but combine those 2 key combos and functions. This is EXTREMELY useful for mass selection of items, and I was a bit taken back at it not being included as a feature in the editor, which revealed to me that the selection programming is done in-engine, instead of calling a Windows API to do so.
There is more;
Using “Migrate” seems to be quite risky with anything. I have had the most trouble “Migrating” Blueprints than anything else, simply because it doesn’t carry over the parent - child relationships, or at least, not all of them, when Migrating.
As I am still very new to this, there might be something I am missing, but from the looks of it, truly porting Blueprints across from one project to another is not possible as a whole complete thing, I have to reopen the Migrated blueprint, and fix any invalid references that werent ported across, compile and save, in order for it to be correctly ported yes?
I have also noticed issues with Migrating mesh assets. For some reason, approx 35% of your entire mesh library, even when Migrated individually, the Materials do not carry across actually Applied, the materials themselves and their linked assets are migrated, which is awesome (and probably enough for now), but as an annoyance factor, for about 60% of the models you guys have available throughout the many project samples, the materials have to be re-chosen after migration. Most of the time, not a big deal because the mesh and it’s accompanying texture or material are named similar, s_door_01 (mesh) is probably going to have m_door_01 or t_door_01 as it’s texture, however, not always the case, and a caveat of having such an extensive material system is that if a generic material is applied in Project A, even though that same material is carried over, it’s up to the artist to guess what it’s called when trying to fix in Project B, if it doesn’t apply itself after Migration (You end up with the default WorldGrid grey texture). Of course l know that you can reload Project A and see where it is or what it’s called, but doesn’t this defeat the purpose of “Migrating” the content?
Furthermore, even though the demo and example projects aren’t meant to be merged together, I’m sure I’m not the first person to try this, nor be the last. The problem I have with this, which has nothing to do with things not working or being overwritten, is actually the folder structure of each example. This relates back to the OP, but applies to more than just the Code example projects, it applies to ALL of them, including all the marketplace demos.
A shining example of this is the Elemental demo, which has it’s own Parent folder in the game’s Content folder, is set out beautifully. All categorised, all under the parent folder with absolutely no chance of conflict if someone, like myself, wants to try and “Merge” all the demo projects just for a learning experience and to consolidate reference resources to one place, instead of having to quit, load demo, read or decipher, quit, load mygame, actually do something, forget it again, quit, load the demo again, read again, etc etc, that was the short term goal of Migrating all 30 odd gb of content into the one project, using ShooterGame as a base. (Double instance of content being copied, first when the Create Project is used based on SGame, the second, after all other content has been ‘Migrated’, a second Migrate was performed to refresh the relevent content – This is also the only time when all content from a project was Migrated (BPs, Anims, etc).)
After discovering (pretty quickly) that Migrating everything from one Project to another causes some funky issues, I deleted everything, including a map I was working on and started again. This time, I deliberately didn’t touch the “Blueprint” folders in any of the projects, and tediously “Migrated” all of the art asset folders from each project, but into the ShooterGame base, as mentioned, only Migrating the “Mesh” “Material” and “Texture” folders, with the occasional “Sound” or “Audio” folder too. I didn’t want to migrate or touch a single Blueprint, although I missed a couple here and there, but ultimately not of concern.
The problem is, all of your example projects, and the starter projects, contain a different Folder Structure, and this really set my OCD off… Lol.
I attempted to clean this up, only to have the house of cards tumble down on me yet again, but, persevering I read more and got more info about Migration and such.
I guess my very long winded TL;DR point here is that I am in 150% agreeance with the OP, in fact I would go as far as to say, you need to address this Folder structure issue ASAP, because it will have dire consequences in the future if it is not addressed. Too many games, too many game developers and companies make an absolute mess of this, and I feel like you guys still have the time, resources and know-how to make this right.
Even though this doesn’t prevent me from creating something, it certainly makes learning about the ‘correct’ structure a nightmare, especially when you have made yourselves clear on the stance of wanting everyone to draw inspiration from, or even emulate, what you guys are doing as a company but also the boring stuff like File management and project management and theory are all important factors that I think aren’t given enough attention, and with an Engine and library this size, I’m amazed I haven’t seen a bigger focus on it from your end.
I am far from complaining, but I thought it best to bring it to attention of someone, also found this thread through Search and wanted to reply here instead of creating a new (possibly pointless) thread.
Loving everything else so far! 
Cheers,
Are you migrating to the content folder or a sub-folder? Coz sub folders break it
This should not be the case. Perhaps there is a code bug. Migrating any asset should bring over all of the dependencies of the asset, including parent Blueprints. Do you know of an asset in the sample content where this happens? I will debug it to find out why it isn’t working properly.