Verse compiles but fails validation

me tooooo.

this problem

https://forums.unrealengine.com/t/me-too-verse-peristable-data-not-backward-compatible-after-v38-00/2670986

Same problem on our end. Our code is 0367-6091-0083.
I have initially changed the name of result constant in the script => still wasnt able to launch an session until i changed it in the ValkyriePublishedVerseFiles folder. Then everything was okay until i tried to publish the version.

1 Like

Thanks a lot, but do you have and ETA about when the publishing will work again? There is a lot depending on the success of our project.

Thanks and thanks for understanding!

1 Like

(post deleted by author)

it’s the same error that occurred for the ambiguous identifier, in this case “result“

No, it is not. The appearance of result in our code has nothing to do with verse persistence.
This was our only ocurrence of the result - i have now changed it to res.

if(res:=NumOfLevels / LevelsInRow):
                set NumOfRows = Ceil(res)
2 Likes

hi @mysakcreative

Thanks for that!. Works now

Workaround

These steps unblocked our team.

  1. Navigate to AppData\Local\UnrealEditorFortnite\Intermediate in Explorer.
  2. Delete ValkyrieUploadTemp and ValkyrieValidationTemp
  3. Open ValkyriePublishedVerseFiles and navigate to the .verse files that contain the issue. In my case, I found the file here: ValkyriePublishedVerseFiles\Candy\sys\versions\365\Content\Verse\Snowfall\Devices\codes_device.verse
  4. Modify the code, changing the variable name that conflicts. In our case this was result.
  5. Launch the session from UEFN; it should now pass validation.
1 Like

Thanks Snowfall_jaden I had to change both the ValkyriePublishedVerseFiles and the ValkyreTempFiles… basically everywhere where there was the variable named result

1 Like

(post deleted by author)

This will just fix the launch session thing but you still can’t publish the update

Feedback: While this is a fair suggestion, it’s actually not acceptable in many cases. It can’t be that every time Epic Games introduces new APIs that all new identifiers are burned. This is a terminology used when a programming languages requires to introduce for example a wide spread keyword which would result in breaking changes for its clients. However in this case, Epic Games is introducing just APIs, not new language keywords, but all terms are burning client (creator’s) custom APIs.

In my particular case v38.00 introduced (Session: session).Environment<native><public>()<transacts>: session_environment and burned a totally unrelated class private var Environment: vz_environment stored property. Why? Because Verse prefers it like this instead of applying local reasoning and permitting shadowing for that matter.

I am also against (local:) and (fully_qualification_path:) usage as I’m a human reading my codebase, not a parser. I don’t want to read and type full mechanical qualification paths or polluting the code base with (local:) which is just a quick workaround for the big problem in the room.

TLDR; I want to re-iterate that it’s unacceptable that native APIs are burning client identifiers.

3 Likes

Here is a link to the same issue that occurred a few months ago during the XYZ to LUF conversion.

Hoping to finally get this fixed because I haven’t been able to update my map in over 3 months.

I think it was after the 37.10 update, I started getting validation errors on launch pointing to files in ValkyriePublishedVerseFiles, where I would have to correct the code there in order to pass validation and launch session. Still have been unable to publish though.

So, not even deleting the whole verse script and device worked.
What should I do now?

FORT-1006728 has been ‘Closed’ as a duplicate of an existing known issue. Origin Issue: FORT-1006738, Origin Topic: [CRITICAL] After 38.00, it is not possible to launch the project

Thanks everyone who worked for the fix, publishing works now!!

1 Like