Using v4.7.5 on Windows 7
–
Currently I’m running into a frustrating amount of differences between the functionality of my project in PIE, where everything seems to run as it should, versus Standalone tests or Shipped project tests (where it breaks in different ways).
Just today I added to my game a way for widget parts to be added to a horizontal box, displayed above my character (via widget component) to indicate how much the player is afflicted by poison/etc.
This works perfectly in the PIE tests (running “New Editor Window”), however when playing it via “Standalone Game” none of the widgets are appearing. (note I already have functional widgets showing when player takes damage that do work in Standalone).
So I had hoped that maybe it would work in a Shipped game.
Sure enough when I built a game for shipping that showed up…however now all of the enemies I had moving around my environment seem to be stuck (though my player still moves-even though it’s using the same method for movement).
Because of this I now have no way to record and show current progress on my game, because playing in the “New Editor Window” can’t reach 60fps like it can in Standalone or Shipped.
Additionally because it all works in “New Editor Window” but is broken in different ways in Standalone and Shipped, and there’s no way to debug blueprint with those I am completely stuck right now which as one could imagine is incredibly frustrating, especially without any indication of when or how any of this could be fixed.
If there was any way you could declare known inconsistencies anywhere or solutions or workarounds or some way to test any of this or just get it functional I’d be incredibly grateful.
Obviously this doesn’t SOLVE the problem, since PIE and Standalone/packaged should not BE inconsistent (otherwise what’s the point of a WYSIWYG editor like that?) but for debugging, if you have a general idea of where the problem is, I would try just using a shitload of PrintString calls attached to various events and branches.
Just stack them all over the place (in a duplicate of the project if you can, so you don’t have to go back and find them all t remove them) and just have them print what they’re doing when they do it. This may at least help narrow down where the issue is (you can see when functions are called in a different order, for example with initialization of things, or where functions aren’t called when they should be, etc).
This is how I debug interactions between multiple blueprints; a call prints on one BP “[whatever]Sent!”, then the other prints “[whatever]Received!”, and then maybe I print the value that should have been sent or print success and fail messages after a branch or switch that relies on it, etc. Usually this enables me to pin down when the problem is an incorrect reference or one object begins play after another rather than before, etc.
For example, with stuck enemies print their capsule collision hits, print whenever their AI is instructed to move, print when they’re possessed, etc. You can then tell if it’s a collision issue in PIE, or if your navmesh is improperly generated, oe if enemies are spawning without their AI controllers, etc. Obviously those things SHOULDN’T happen if it works in PIE but it would at least get you closer to a useful bug report for AnswerHub if you can’t work around the issue…
Yeah that’s how I feel, Unreal Engine is an incredible WYSIWYG editor…except, it doesn’t really hold true to that when it breaks inconsistently when trying to share the project.
Thanks a lot for your response, I have used print strings to debug things when developing the game inside the editor too, however as mentioned it doesn’t really solve the issue regrettably, especially when I would have to test both the standalone game, and the shipped game, and then I wouldn’t even know if a workaround I might have been able to come up with would work, and if I spent time developing it-I would then have to retest it both in standalone and shipped, and I can’t even imagine how long that would take when the game has longer content that needs to be tested.
The problem also extends to the fact that some of these bugs seem to be inconsistent, for example the enemies in the first room seem to at least see me and attack, but when entering more rooms some of the enemies don’t even rotate towards me-though they are playing the run animation so their behavior tree should have triggered for them to turn towards me. (It’s nothing to do with navmesh as I don’t use that for my AI).
I just really really wish that I could develop a game and test it and expect as I should that I could at any point share what I have working with others, but that doesn’t seem to be the case and it’s incredibly demotivating to not even know if or when I could ever expect my game to function for others as it does for me, can’t exactly ask anyone that may want to try my game to download Unreal Engine and send them a copy of my project especially when this is the first I hope to develop commercially.
Hence my feedback hoping they’ll put more focus into making their engine export what you expect it to export as functional.
The problem, of course, is that PIE and Packaged are SUPPOSED to be identical; any time they aren’t, it’s not a problem that can be declared to users, it’s a bug that has to be diagnosed.
I too am fairly disappointed by the issue since it really drags out that last phase of final bugfixes, but unfortunately the only solution is to try as best as possible to figure out what’s going on, report it, and wait for a fix If Epic could list all of the incongruities between PIE and packaged, they would just fix them.
It’ll never be completely fixed, simply because there are a LOT technical limitation. One example, is that in order for PIE to be as fast as it is, it has to share objects that exist in memory with the editor in the game world. If it didn’t, you’d double your memory usage for each instance of PIE you create, and double the workload - and you’d also have to wait to load all that stuff into memory (which is what Standalone tries to simulate). Widgets seem to suffer the most inconsistency so far, from my experience. You should also NEVER assume that Multiplayer code that works in PIE will work in Standalone. That kind of stuff you should always be testing properly in a packaged version of the game across multiple PC’s, with latency too.
It’s a fact of life really, if you want to test the final product, test the final product. It’s never a good idea to assume that everything that happens in PIE will happen in Standalone. Build a shipping game every few days and test new functionality as you add it, THAT is the version you’ll be deploying to customers, not the Editor version.
I would also encourage packaging/building ‘Development’ versions of the game too. If there are issues between Development and Shipping, you can usually narrow down that it’s an engine bug causing the issue, or some missing code.
If Epic could list all of the incongruities between PIE and packaged, they would just fix them.