edit:Hm, looks like editing the title only edits what shows in the first post and not the actual title of the thread
And preferably be editable from any of them (with the changes being reflected in all of them) ?
Iām not sure if this is how most people do it; but so far, Iām mostly doing random proofs of concept to get the hang of stuff, and since I donāt quite know what Iām doing itās easier to create new projects than to risk wasting time with some mistake I made or some test I did that messed things up (not to mention, that if more than one idea takes off, it might be a little complicated to be able to develop them further without one getting in the way of the other) . But Iāve started to notice some things are being recreated in multiple projects.
I do not think you can make it work for all projects. You can migrate library to new project but it will be a copy.
Closest to what you want is making dummy project with that library only, then migrating your newest version to it. But when you migrate and change parameters of function it will mess up project with old version.
So best bet is to make it for one project then migrate to something empty so you can share with new projects.
All that is pay off for having big binary files everywhere in unreal. You link your function in bit different way and that makes it unique even if logic inside is exactly same as old version.
Itās possible, but itās a bit fiddly (and really not recommended).
You can create files in the engine content folder instead of your individual project (e.g. Epic Games\4.11\Engine\Content)
then access via: view options > show engine content (in the content browser).
To make it easy to move to new releases I make a symbolic link called āSharedContentā inside that folder pointing to a directory elsewhere (complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/)
That means I just recreate the symbolic link every time I upgrade and the files are instantly accessible to the engine and all projects.
BUT
You have to be VERY careful what type of stuff you include, because each project knows nothing about the others, so itās easy to mess up other projects creating dependency issues. I wouldnāt use it to derive classes from, because the chances are high of making a design mistake, and having to go back and change something in the shared base class. Then you might find yourself having to go through every single project that uses it, updating variables or functions. So that ends up taking up more time than you thought youād be saving. Iām glad I made that mistake early on, on a very small scale haha.
Basically, things have to be VERY general and completely encapsulated if you want to share them safely. So I just use it for blueprint functions/macros, and content like animations and sounds, i.e. content that a lot of projects can use, but wonāt be edited that much (preferably not at all). Another thing I just thought of: if you intend on changing engine version with shared content, there could always be some obscure change that makes content unreadable to other older projects, it hasnāt happened to me but itās possible. Just another reason to avoid projects depending on shared content. Having an unreadable sound or animation file is one thing, youād still be able to update your project and get things going again. But having an unreadable base class would really ruin your day. Good luck
Hm, what about having each project automatically get a local copy, with a way to manually sync with the original (both bring changes of the original in, and send changes of the local to the original) ?
