Please Improve Your Systems or At Least The Documentation Epic Games

Dear Epic Games,

This is not a question, this is a feedback letter for you and I’m making it public so that community can see it as well.

Today, through this error, I have learned that structs have a max size, if you have a struct with a size larger than the max, you encounter this error and a launch crash when launching a session.

Error Log In Question:
“LogWindows: Error: appError called: Assertion failed: GetIntNum(Property, IntType) < MaxZeroComparisons [File:D:\build++Fortnite\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\UnversionedPropertySerialization.cpp] [Line: 166]
Unexpectedly large property type encountered $ExprResultStack_17”

Message to you Epic Games, here is what you could do instead and become a proper company:

    1. First of all, if there is a hard size limit for structs, how the hell am I even allowed to compile the script without any problems. Compile should give me a clear error, instead of an ambiguous server launch error.
    1. I do understand the needs and requirements of having max memory allowed for scripts, and the total of the map. But having a limited size for a property is just lazy. I should be fine as long as my total memory consumption is ok.
    1. Or if you’re so defensive about you hard size limit for structs you can at least let me have 1byte, 2 byte short and 4 byte integer and float (which is what they should be named, what was your idea on making the INT and FLOAT as 8 bytes, when almost everywhere else it’s 4 bytes. You could have just named them something else if you really wanted to make them 8 bytes, for example: StupidEpicGames8ByteInt and StupidEpicGames8ByteFloat), so that I can have more members in one struct without you changing the max struct size.
    1. The Documentation, You have a hard size limit on your structs and it’s not mentioned anywhere, not even once, are you serious! Even if you are lazy enough to not add it as a static check to the compile process, at least write the useless documentation properly.

Thanks for the report. There isn’t a limit on the size of structs, and it’s a bug that you get that error.

We’ve fixed one bug already that triggered this error for large optional structs (e.g. ?my_large_struct), but that fix is not yet in the public release of Fortnite. I believe that’s what you’re seeing here, but can you confirm that you’re hitting this bug for a large optional struct, and not simply for a large struct?

2 Likes

It’s not an optional struct just a plain struct

What about a function with the <decides> effect that returns the “large” struct?

I ran into the same issue today, and was able to resolve it by removing the effect from a function that returned the impacted struct.

The problem can also be resolved by changing the impacted structs to classes. I ultimately opted for this approach, as it does not require changing any other parts of the codebase.

1 Like

I ran into the same issue today, and was able to resolve it by removing the <decides> effect from a function that returned the impacted struct.

The problem can also be resolved by changing the impacted structs to classes. I ultimately opted for this approach, as it does not require changing any other parts of the codebase.

The fix is in the 26.00 build of UEFN that is now live. Please let us know if you see the problem again.

2 Likes