Binary content (uasset / umap) Separate to TextFile: ContentName.unreal_asset_type, ContentName.log, ContentName.bin, ContentName.multimedia_type
Or
Binary content (uasset / umap) Extract to Folder: ContentName.unreal_asset_type (.content, .log, .bin, multimedia files included)
For:
There is no reason to use binary content At Developing Time
(Edited)
I agree, if especially Blueprints were text files which could be diffed by git and whatnot automatically., it would really help out.
If text based contents there willbe no gap between:
Epic has been working on a way to diff BPs and (possibly)some other non-binary assets via traditional source control for a while now.
Someone talked about this feature was 3 years ago on the internet, I’m new to the unreal engine world, just ensure this feature is on the way, because it’s really important to me, i cannot imagine if i have to dealing with binary in the future no matter i’m a designer or coder
Maybe make it an option (first, made available using ‘experimental features’) to save everything in text file (this will be editor only and only for development). And after package, everything remains the same (binary files like now).
There are several good reasons
all very good reasons, and all of them still apply if the BP is only converted from text to binary after a BP compilation and/or cooking time 
The loading time point also related to editor load times really, but that’s a small price to pay.
Yes, but the binary superiority will be lost, when:
Well if not all of the issues highlighted above surfaces only during development - for this, I highly support text files. However, I do not think your comment being ‘binary is useless’ is correct - that is all.
So you can’t use source control for blueprints or what?
I edited floor one and limited the topic range to only at developing time
Let me say it more clearly, maybe Unreal Engine serialized contents for some reason, but That quite un-friendly to the coders (Edited)
Every function Unreal team has already been done (BuiltIn Content Controll, Debugging Tool, etc …), That’s good
We just only need to remove these serialization part, back to transparent content data again (when open / editing / save, not after compile / cook / run) (Edited)
This will Allow the coders to debugging & diff these contents directly through outter tool (IDE / Git),
The Designer / BluePrinter can still control these content through existing way (Build In Content Control / Debugging Tool on top of Engine)
The main reason doing this Is directly seeing content code (when using outside IDE) For complete team work (CPP + BluePrint + Design Content)
That why other engine using CPP + Script Code, BluePrint has it’s own advantage and can do the samething, but must based on Text format
Current team work model is only for: BluePrint + Designer / C++ Coders Only
Serialization != Encryption.
This whole thread assumes that the data stored by a .uasset is human-readable in the first place, which it most definitely isn’t in many cases. Not serializing assets to binary won’t just make them slower to load, work with and save, but it will massively bloat projects. Binary compresses nicely, human-readable text does not. Even if you could read the data, there’d be so much of it you wouldn’t be able to do anything productive with it.
I wouldn’t expect this to ever change, it would require a complete rewrite of several fundamental systems in the engine.
Jamsh explained almost everything here, so I’d add only a small thing.
You can already see “text version” of blueprint graph. Just select network of codes and simply copy-paste to any text editor. It’s not exactly human readable. The diff wouldn’t be human readable. That’s why Epic took an effort to build a visual diff tool, it’s the best way to compare changes. Yeah, I know, it can’t be used outside of the editor…
Unfortunately, we can’t expect the same level of simplicity in visual scripting as we have in text editors. At least not in this generation of Unreal’s visual scripting, data is messy.
Even if you could see a map in text format, it wouldn’t help too much. Tried to use it for checking changes in Unity scenes. It only usable if one person changes a single thing. But it’s enough to move few objects in the hierarchy and diff it’s a mess, unusable.
Yes you can of course. But it is limited that you cannot see what has been changed from one version to another (diff).
You can diff blueprints directly in editor.
Argument with diffing blueprints in text format is not that strong. You must consider that these are still assets. They contain a lot of meta data (like position of nodes), that will make text based diffing much harder.
Where I see main advantage of text assets, is that I can attempt manually fixing broken blueprints (ie, the underlying class name changed).
Diffing is very important to me (and I believe many others) as without it, you will resort to calling/texting the dev and ask…‘hey what have you changed to this blueprint?’
Yes, I have edited