Hello,
We are having a problem while packaging our game for windows. In blueprint we use the functions GetSizeX/Y on a texture reference to a Texture2D. It works great in the editor but returns 0 for x and y while packaging which causes other downstream errors. It’s as if the texture is not kept around during packaging for some reason.
This seems to be a bug since we are not aware of any limitations of using this function during the packaging process.
Thanks for you time!
Steve
Hey Skellington,
Can you provide me with some screenshots of your blueprint scripting showing how you are using the GetSize X/Y for a Texture2D reference?
Are you able to reproduce this is a blank project using a simple texture and the same blueprint logic?
Any steps or extra information pertaining to this issue that you believe can help me reproduce the error on my end is going to be helpful. Let me know if you have further questions or need additional assistance.
Cheers,
Ok I’ve uploaded a picture of the minimal setup to reproduce the problem. Assign a texture to the BP instance in the world and then package a build (in my case Windows 64-bit).
In the packaging log I see:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.07.19-20.24.21:486][ 0]LogInit:Display: LogScriptCore:Warning: Divide by zero: Divide_IntInt
Because the size methods on the texture are not returning valid size values in the construction script during the packaging process.
Thanks,
Steve
So I am not too sure what you are attempting to do here when setting your ‘Var’ because anytime you divide into/by zero, you are going to get a zero in return. This warning message is telling you this.
I just ran a test on my end and this is true when I combine your setup with a print string. On the other side, as soon as your remove the divisors you get the sum of the two X and Y sizes for your texture.
Let me know if you have further questions or need additional assistance.
Cheers,
Let me restate the problem. I know divide by zero is an error this is simply a way to show you the error during the packaging process because the texture should never return 0 for size of X or Y. (I am dividing BY the texture sizes - the numerator happens to be zero which doesn’t effect anything.)
I have a valid texture assigned which returns non-zero values in the editor but during packaging GetSizeX/Y are returning zeros for the same texture sizes.
Thanks!
Steve
Can you then provide me with the exact set up you are using in your project, because using a zero as the numerator is still going to return a zero value (even with a valid resolution returned from Get X and Y).
I just tested this issue in a packaged build after removing the divide nodes and simply getting the Size X and Y of a texture and it worked as expected.
This is within an empty blueprint actor that I have simply placed in the level and consumes player 0 input by default. When I press the ‘T’ key, it returns a value of the sum of X and Y which was 4096. This means the sizes for X and Y are 2048 by 2048 in resolution.
Perhaps you can clarify what you are attempting with to do with your script, so I can get a better understanding?
Thank you,
It needs to be in the construction script. During packaging the GetSizeX/Y functions are returning 0 which is breaking other things downstream (causing divide by zeros). In the editor whenever the construction script runs it works fine.
I assume your setup is not happening in the construction script since it responds to user input.
I’m not trying to be difficult, but what I’m doing with the values doesn’t really change anything. They just need to be correct (not zero) during the packaging step. I provided the divide-by-zero example because it’s easy to find the warning in the packaging log so you can see that GetSizeX/Y are returning zeroes during packaging.
Thanks!
Okay, well in that case I have a theory that because it is within the construction script the texture has not had time to load and therefore returns null or 0.0.
I just tested your set up within Standalone mode and it returned a non-zero value as soon as the level opened and the blueprint was initialized within the world.
Would you also mind testing in Standalone to see if you get the same results?
Thanks,
Yes it works fine in standalone (I just tried it). We’ve only seen this problem during packaging. If you package your test setup you should find a divide-by-zero warning in the log.
Thanks.
So I am actually not getting the same results, but I do get a warning message. I have used the exact set up you provided, excluding the division, and it seems to return the correct value within the Output log when packaging, but it does not like the Print String. Below is is message I received:
As you can see, my output log is returning a 2048 value (the sum of Get X and Get Y) which is run on construct. The variable is also set correctly within the editor, but I warning message I am receiving is new to me. I also noticed the variable within the construction script never gets set to 2048, but is correctly applied when the instance is placed in the level. I will have to investigate further, but in short I am not getting the divide by zero warning message you are reporting.
Cheers,
Yeah, naturally you would only get the divide by zero warning if you were dividing by the return of GetSizeX/Y.
I’ve attached the minimum project that demonstrates the error.link text
In the editor if you move the ball around you’ll get nice log output “GETSIZETEST 2”. If you package the project somewhere in the log you’ll get:
LogScriptCore:Warning: Divide by zero: Divide_IntInt
(and no printstring output since the whole script fails at the divide by zero)
I did make a version that only does the printstring (no divide) of the texture size and it works in the editor, but nothing prints out during the packaging process as if the script is silently failing out.
The bug does seem sensitive to some unknown condition. If I do an add or something before printing it seems to work ok, but when I send the GetSizeX pin into the denominator of the divide block it doesn’t work. Very strange.
Thank you for the clarifications and your patience while determining the validity of this bug report. I was able to reproduce the issue on my end and went ahead and entered a report for this issue, UE-33631.
Once the issue has been addressed by our engineers, the fix will be added to the release notes for fixed issues within an upcoming full engine or hotfix release.
Let me know if you have further questions or need additional assistance.
Cheers,
Great thanks!
