After the 40.20 update, we have been experiencing issues publishing our island. In the Verse validation section, an error message appears that points to a file that has already been deleted.
The deleted file did not include or implement any persistence. Before it was removed, it was already producing the same compile errors that are now appearing in the Creator Portal during the publishing process.
Currently, the project compiles successfully in our editor, and we are able to generate private versions without any issues. However, the Verse compile error continues to appear when attempting to publish.
Full error message:
Module 81985958-4adf-2c87-841c-a09dcc3d56f1 in candidate link 8725-2265-7526?v=1 has error: “This overriding data definition must be a subtype of the definition it tried to override: Verse.org.SceneGraph.basic_interactable_component.CanInteractMessage” in file: “C:/build/FortniteGame/Plugins/GameFeatures/81985958-4adf-2c87-841c-a09dcc3d56f1/sys/published/Content/VerseDir/daily_rewards_button_component.verse” at line: 46
verse_validate_publish_error
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Creator Portal
Steps to Reproduce
1 - Have a code that breaks on a UEFN update;
2 - Remove the breaking code.
Expected Result
After correcting or deleting the code that was generating errors, we expect no errors to appear in the Creator Portal when attempting to publish.
Observed Result
Even after deleting the problematic code, these errors still appear when attempting to publish.
As mentioned earlier, the code responsible for the issue has already been removed, since it is no longer used in the project. After removing the faulty code, the project compiles without errors in the editor.
However, the Verse validation error still persists for private codes generated after the removal. This is confusing, as the validation process is reporting an issue in code that no longer exists in the project. It appears that the Verse “state” on the server may be out of sync with the local version (or not being updated by it, otherwise).
The change you suggested has already been tried—namely, making the faulty code comply with the changes made to the basic interactable component in update 40.20 (that is, marking some of the member variables, such as CanInteractMessage, with <override>). Regardless, we can try this approach again.
Did you had custom CanInteractMessage prior to the recent addition of the same API by Epic? If you did, then congratulations, Epic burned a type member name that collides with your code. This results in a situation where the code of your previous game build is compiled against the new tools and bumps into this compiler failure. It’s not about your new game build, it’s Epic’s current way of determining verse persistence backwards compatibility that itself breaks when Epic does not provide backwards compatibility against our published games.
What you can do now?
Ping Epic possibly even Sabrina or Magnus to forward this issue to the right team. You will not be able to publish your game(s) until they deploy a proper patch on their end.
This is a similar situation where their tools nuked my game for an entire week after releasing v40.
Long story short, “verse validation” during publishing will fail if your old game build cannot compile against Epic’s new tools without emitting any errors.
This is a very frustrating developer experience!
Start
|
v
New game?
|-- Yes --> Compile with new tools
| |
| +-- Issue? ---- Yes --> Cannot publish
| |
| '-- No --------> Publish / No issue
|
'-- No --> Published game update
|
v
Compile update with new tools
|
+-- Issue? ---- Yes --> Cannot publish update
|
'-- No
|
v
Additionally compile old build with new tools
(verse persistence backwards compatibility check)
|
+-- Issue? ---- Yes --> Cannot publish update
|
'-- No --------> Publish update / No issue
This was pretty much what happened. We had a class that inherited from basic interactable component that had a private member called CanInteractMessage. Since the update introduced this same variable name in this component, a compile error was generated.
I guess we will be putting a “_” at the end of every function, module, class, struct, enum and variable name from now on
All my types are vz_* prefixed to avoid collisions (okay).
All my folders are VZ_* prefixed to avoid module collisions (ugly).
I don’t intend adding anything to avoid type members.
Epic should really re-do how they evaluate verse persistence, because all these collisions are not relevant to persistence backwards compatibility checking by any means.
Hello everyone! This issue should be resolved and you should not be getting blocked by backwards compat checks when attempting to publish. If that is not the case, please do let me know! Thanks!
