No, not at all. I even don’t know what to do. Maybe copy build tools from distributed build, and use them instead of those which are downloaded by Setup.command.
are in ~/Library//… do not remember exact path, not where told.
According to mine UnrealPack hangs somewhere in middle of packing some Slate png’s. Some time after it is actually hanging in Editor.
Maybe it is some path related problem. I think what i’ll do tomorrow - try to replace standard distribution with mine and see what will happen.
We simply don’t have manpower to support everyone who has adjusted engine source. We can support vanilla versions of engine released officially, and we can investigate issues on our GitHub builds, but once source is edited we’re getting into an area outside our range, and if we can confirm that this does not occur in vanilla engine, there’s nothing we can do at that point.
Please feel free to discuss problems you are facing with each other; I hope you can resolve issue! But keep in mind that a fix for one edited source build might not work for another, and that’s basically where we’re stuck. Best of luck!
(in function ProcessCommandLine, UnrealPak.cpp line 482)
Don’t know why that line is failing – my guess is some kind of memory overwrite error. symptom of this problem was not a crash, but an infinite looping of “for” loop containing line. It’s a very simple piece of code. only way I think you would loop infinitely there is if something was slamming your memory. Perhaps it’s a buffer overrun because of a too-long string (printing out two long paths in a single log call). Or maybe it’s some strange utf8 vs utf16 issue.
It is not of buffer overrun of some long string as I can tell. It is constantly writing to pipe which is read by Unreal Editor. For some reason pipe breaks, and buffer became filled with data, which is not read out by an editor - editor thinks that it is empty, as read function returns -1 and errno 0x23.
You understand, though, , that we are not changing that part of engine? We are creating c++ projects way that your documentation instructs, building tools way your documentation instructs and running everything way your documentation instructs. No one is going in and fiddling with way that editor communicates with anything.
I see, so once pipe fills up, perhaps there is a timeout of some sort before next log call can be processed.
Definitely what I was observing was that there was no particular crash within fflush call – it just seemed to be taking an incredibly long time. I was blaming xcode, but perhaps there is a timeout coming into play that causes a long delay when we try to write to a full pipe.
, I build source code from 4.9 branch and it worked perfectly. And we found what was causing problem. But it is hard to tell which changes interfered with UE tools. There is definitely some bug hidden in tools-editor pipe communication. I’ve run UnrealPack with parameters supplied by editor from command line and it worked without an issue.
Thanks for additional info. Our tools are designed to communicate with our engine. If you change one or other and that doesn’t work anymore, it’s not really a bug on our end.
I understand, but if you have modified engine at all, it is no longer something we can support. If you find that there is a bug that occurs with an unchanged engine while resolving this issue, we can go from there. For now, if making a new project in your version of engine displays this issue but a new project in vanilla does not, we have to assume this isn’t something we can test for.
EDIT: please note that this policy does not include Epic GitHub commits. If all you’ve done is added an official CL from us, let us know which one and we can go from there. Keep in mind that many commits are not entirely inclusive, and some changes required multiple commits to be implemented.
I just want to add another voice here quickly: I am seeing same thing when porting a plugin from top down prototype to our real game, this happens in our real game with a large amount of content being pak’ed, but I did not get this hang when doing exact same build process on this Mac with top down small game. It seems to be a real bug in UnrealPak that maybe only shows up with a larger production sized game, or only with content with long names, or who knows what; but I concur, it’s a real bug and should be investigated. Maybe someone here can share their project to repro. it on your end, if not, I can probably do so on UDN to staff if that’s only way it will get attention here. Let me know. Thanks!
For those who are having an issue that is related to UnrealPak but it’s not due to an edited version of engine, please create a new AnswerHub post. 's issue was not on an original version of our engine, it was modified therefore, we were unable to help them.
