Redirectors exist for a reason. If you’re working with a team larger than a few people and want to just move files around willy-nilly in explorer, then you’re causing your source control all sorts of headaches. Not only are you going to end up with a bloated repository because you’ve created copies of assets everytime you move them, but you also can’t change the references in a file if somebody else has it checked out. You submit your modified version and everybody elses project breaks.
This is where people start breaking projects or losing work and it’s a waste of time having to sort that out. In a large studio, it’s unacceptable - so redirectors exist so people can move files around without other files breaking. Since UE4 is aimed at large studios and Unity isn’t, it’s more fitting for it to have the redirector system even if it makes the lone-developers life slightly more difficult.
Generally speaking, it’s good practice to just NOT move files around anyway and put them where they should be their entire life of the project - especially if you’re using source control (which again, you should be).
Have you read what I wrote about unity’s way of handling files? File gets guid, guid doesn’t change, moving file does not affect guids, and last time I checked doesn’t break the references. Updating file doesn’t change guid either. References are done by guid.
Bloated repo means a problem with version control system. Git does not duplicate files, for example. One version - one blob in the repo. Move it around as long as you want, it’ll still reference the same original blob.
Also, UE4 is aimed at everybody at the moment, since it is marketed as free to start with.
That kind of approach is unrealistic, because most likely you’ll want to move something at one point, pretty much inevitably.
Software development is not an architecture and things change a lot, gets rebuilt, modified and rewritten.
So, most likely you’ll want to move something at one point, inevitably. And currently doing that may screw up half of your level.
Current way of handling file references is a big limitation of UE4, there’s no point in going on defensive, trying to sugarcoat the issue or make excuses. Also, I don’t see a reason behind defending 5-step complicated process, when references should be handled automatically without any chance of them breaking in the first place.
Software should make people’s live easier. If a user needs to do 5 things in order every time he/she decides to move a file (and restart editor in the process), it means the software should be improved.
In any case, alternative system could be made optional, for example, or work in parallel with current reference system.
Im afraid you never worked on big projects with other engines. You can move everything as much as you want with unity nothing will ever get broken.
And because unity engine shows that there are actually no obstacles to making efficient file tracking, your point is invalid and just protects old ue architecture that you are used to.
Sorry but its true, i work 4 years with unity, and its absolutely painless and straightforward.
Why then does Unreal have a MOVE function? I like my directory structure a certain way and when I import items from the martketplace I want to put them into a directory called MARKETPLACE. But, when I move them, and use the redirectors, it doesn’t always work. Either the move function works or not. If it “sometimes” works, then just ditch it…
I would never use Unity, but I must admit, that’s a cool feature… having a MOVE and COPY function that actually works.
Yeah this is the one single area of UE4 that can be troublesome- often folders that I had moved and fixed up and deleted, come back as empty folders on restart, and sometimes manually deleting or moving them within the project folder messes up the directory. It is very dependant on what you are moving, and seems to “sometimes” work correctly, as mentioned above. I’ve found the only method of keeping a clean directory is deciding on a hierarchy when starting a project, and stick to it, but sometimes if you have placeholder content, or you want to use some marketplace assets but not have them in the main directory, it’s a pain to try and correctly move them. Also I have found that batch importing textures only saved about 50% of the textures properly even after multiple saves, and on restart, the remaining textures were missing, so manually importing a few at a time and saving was the only method that reliably worked. The main problem seems to be using folders- I can usually move single assets around without a problem, but as soon as I’m moving a folder of assets (especially if that folder has more than a few assets inside or subfolders), things get slow, complicated, and rarely move cleanly. In comparison to everything else in UE4, where things just work without the user having to get too involved, this definitely seems like an area that could be simplified.
Well from what people said here, Unity’s version is way more resilient by design, because it ignores the very concepts of file name or path.
UE’s concept of redirector is not only confusing, but also forces the user to use the content browser for all filesystem operations. Merging branches, for example, will always be an incredible pain because of the redirector system.
Like I said, in order for those references to be updated the files have to be checked out and checked back in, which you can’t always do. Even if you can, you just end up resubmitting a changed file that only has a reference change. If you do it too often, you end up just filling up your source control repro with endless copies/revisions of assets that don’t have any real changes - nightmare if you ever need to revert for whatever reason.
Perhaps I’ve not experienced the same issues as you guys, but all I’m saying is I’ve worked across multiple UE4 projects in varying team sizes and not had too many issues with redirectors. I’m not saying they’re ideal, but I can see why they’re needed. If Epic come up with a nicer system then I’m all for it (though, I’d rather not have twice as many files in each folder purely to get around this) - but for the meantime my suggestion is to maintain a well organized folder structure and if you really have to move something, follow the process I listed.
Please, just stop. It doesn’t work this way you describe with sane version control. There really aren’t any possible sane excuses here you could think of.
I managed to nuke half the level with current redirctor scheme on first week of using unreal 4. And yes, I clicked “fix redirectors”. The level had to be scrapped and couldn’t be fixed, luckily I could reimport the whole thing in one click, but if I couldn’t that would royally suck.
This thing is broken beyond reason, and should definitely be fixed.
At the moment current advice is “you don’t want to move or rename anything, ever, otherwise you’ll have high chance of data loss”. Which isn’t good. See this blog post someone posted on those forums earlier.
Another separate issue that UE4 keeps paths very short and restricts you to very small subset of characters (ascii only with no spaces, IIRC). If your path goes over 100 characters, bake will fail (because bake will create temporary directory with a VERY long name AND name of that directory will fail hard-coded MAX_PATH length check). So here goes “organized directory structure”. Unity doesn’t have this issue either.
I’ve never used Unity - but by the sounds of it, the alternative going by their method is the have an additional file associated with every file in the content folders? Each time you moved something, you’d have to rebuild the DDC as well which can take hours on some projects.
Perforce, the industry standard, absolutely does work that way. You cannot merge binary files, therefore if you check in a file while somebody else has it checked out - one of you has to lose your changes. To make this easier to visualize here’s a scenario:
Somebody in Level Design checks out a map and starts working on it in their local Workspace. Say they’re working on it for a week.
I decide I want to move a Particle System or Material referenced by that level, so I move it. Without a Redirector, I would also have to check out the Level as well, and submit that once I was done.
I then check-in the level, and other people in the studio update to that version and uses the new particle system and material in various places around the project.
Person a checks in their level at the end of the week, but can’t because they don’t have latest. They either have to lose their work, or we have to spend several hours reversing all the effects of me moving that particle or material across several days worth of several peoples commits. Not only is it a waste of your time but it’s also a waste of others’, and you also risk ******* a lot of people off if they can’t submit their work for whatever reason.
Unreal’s roots are first and foremost, an engine for studios of that kind of size where things like this would become a big problem.
As much as I’m an Unreal fanboy, there’s a genuine reason for their existence. IF, there’s a better solution that fixes both sides of the problem then great - I’m all for it. Meh, I’ve made my point.
No, every time you move something, nothing happens.
Merging of binary files is not related to the issue in any fashion.
That’s completely incorrect and you don’t understand how that works.
You won’t need to checkout or even touch the level. When material is not referenced by path, but by guid, level doesn’t care where that material is.
So you can check out local copy, move things around as you’d like, and your level will not be changed in any way. The only change you’ll have to checkin “material was moved from location A to location B”. That’s it. The level will file remain completely unchanged.
Redirector’s however, are a good way to pollute repository with junk information.
You’re trying to guess how it would work based on your understanding of the unity asset system. Your understanding of the system is incorrect, because you never worked with unity. Either read “Asset Management” portion of blog post I linked, or give unity a whirl.
The reason for their existence is “the system originally used paths 10 years ago, and when we started to move things around, we needed a workaround that would prevent paths from immediately breaking”. That’s not a very good reason and the system doesn’t have any benefits.
Just put an unique, definitive ID, somewhere in each UASSET file, and use that instead of a file path when referencing other UASSETS. That’s it.
You can even have it both ways and keep using file paths when referencing from code. The only reason redirectors exist is to keep references alive when file paths become invalid, which is really a dirty workaround to a bad system.
I’m basing my understanding off of what was posted above me in the thread, where somebody mentioned having to move a .meta file around as well.
You misunderstood. My point was if there was no Redirector there and we still used paths for referencing, then I’d have to check the level out and change the path, then check it back in with a string pointing to the new path. Otherwise you open level, it looks for file at path ‘x’ and it’s not there. I had to deal with this ALL the time when the guy doing parts of our UI kept moving textures and materials around, but he couldn’t submit UMG assets for example because other people were working on them. As soon as he submitted and anybody else updated and opened their project, everything broke. Perhaps after spending so much time trying to fix broken projects because people couldn’t submit full changelists, I grew more fond of redirectors…
Sorry for the drama, but I get wound up when somebodies argument initially seems as thinly veiled as ‘Well Unity does it this way and I’ve had a problem with it in Unreal, so Unreal must be broken’.
Unique GUID in assets would probably be a good solution, I agree. Frankly until someone from Epic who really knows what they’re talking about comes and posts here, nobody knows for sure.
EDIT: One issue with storing the GUID in the .Uasset file is that unless you can specify a way to load only a small chunk of the file, you’d have to load the whole thing to get the GUID. This means every time you start up a project, all assets would be loaded into memory and 9/10 times, you’ll probably run out.
Not to say it can’t be done, but right now storing all this data externally sounds like this only option which is something I’d personally like to steer away from.
The reason why Unity even has .meta files is because Unity does not convert assets to internal format during import (well, it technically does, but it is hidden away from you). So, if you put *.tga into project content/asset it’ll stay as *.tga. Because *.tga can’t have extra metadata, the metadata is stored in *.meta file which placed near original file.
Since UE4 has everything in *.uasset form, guid for the file could be placed inside the asset. Meaning no *.meta files.
You’re repeating what I said using different words. Redirectors exist for historical reason as a quick and dirty workaround around limitation of path-based system.
However, path-based system doesn’t bring any benefit to begin with, and should obviously be replaced with something that doesn’t break and doesn’t need redirectors.
I advise to get rid of that habit, and listen instead. There’s no point in getting wound up. Both engines have superior features that aren’t present in another one, and both have weak points. When people say “it is broken” they are trying to improve your favorite software tool, so when you argue with them, you oppose adding new improvements to your favorite engine.
That doesn’t make much sense, don’t you think?
By the way, at the moment really weak points of UE4 is asset management handling - the one that is discussed in this thread, and animation retargeting mechanism (although animation system itself is better).
I absolutely wasn’t, and my reason for irritation is that lot of the time the attitude of those coming from a different engine is that Unreal should bend itself to suit (Often as if it should be an easy or priority task), rather than listening to folks who have a lot of experience with the engine advising them on a better overall workflow for these tools. Cueing the condescending remarks I’m stepping out of the conversation permanently now.
In the meantime, I would suggest waiting for an Engine dev to post their thoughts on the matter.