Packaged Projects behaving differently than in-editor

I’ve found, in several cases, that my packaged projects don’t function the same way they do in-editor. What is a good way to troubleshoot this, considering we don’t have the tools that are in the editor when the project is packaged? Has anyone come up with techniques to help track problem areas and maybe some best-practices for alternatives methods of doing various things in Unreal that do work post-packaging?

Packaged projects load actors in different order than when running in editor.

Best way is some logging, print is poor`s man logging, you should do your own logging function in C++, and log to file or even better use websockets to see it realtime on different PC.

So i would add log/print to every actor for event begin play, write down together timestamp, name of actor, and class of actor. Then after all cast to, if its fail or succeed.

Is there a way to know what order packaged projects load actors? Do you know of an order of precedence or any such documentation? Maybe I could compare that to the order in-editor to restructure for packaging?

First i am not 100% sure that load order is reason for all of differences.

And yes there is a way, i described it.

At event begin play write name of actor class and name of actor to log, and write all casts if they were sucess or not. Then read the log. Eliminate all failed casts, or causes for it.

There is PRINT node, then visual logger system, but imo best is small C++ function that writes toy local file or websockets (this way you can debug process running on android, or PC).

So for now add print nodes with name of class and actor name to every actor class on event play. You can make custom print node that logs it.

Most errors I have seen are just due to bad coding.

Usually FPS driven stuff. Like forgetting the fact that PIE runs at a certain amount of fps while the actual packaged project can potentially reach 120fps.

Generally speaking, even when actors load in different orders you should not have issues.

The obvious exception is when you are doing something you shouldn’t, like checking for other stuff existing on BeginPlay in an actor.
The normal/easy way is to just not do that in begin play.

The complex fix is to move the code you need into a custom event, hook it up to an interface. And then call the interface once the game’s loading screen is almost finished…

With all that in mind.
What differences are you noticing precisely?

So, my solution was to put a 0.0 second delay before anything which was not loading. My issue was with Widgets which were supposed to be in place at the beginning of the level. Some of them had features and input which was not working. The 0.0 second delay was enough to let them load after whatever it was that was messing them up.

I know this is an old thread but currently best way I find is to run game in Standalone mode in editor and enable -log option. I am able to reproduce most of my packaged game issue in this way and see the error logs.

1 Like

Careful with that, there is cleaner node they have in the engine to do this. Its called “Delay Next Tick” and its way more efficient and safe than adding 0.0 delays and stuff. Delaying a tick will usually fix the issue as what happens is when starting a “widget” the actual creation process cant get to an update process in the same tick depending on how you have it setup. However delaying anything sometimes wont fix the issue. Its best to check the order everything is made, from game mode to controller to widget and so on. Everything has to be in perfect chronological order and trust me, i have issues constantly with this but that “next tick” node should help keep things safer for you with that one scenario. On the other side, i have had terrible luck with things that should work, work fine in PIE and standalone but once in ship build, bricked… Its very frustrating so i feel your pain there, i’ve made splash widgets that display the actual errors to help with this in shipped versions. Literally just making your own in game print string basically.

1 Like