Streamed assets can be inaccessible to Rockstar Editor through regular use.

[Lucas7yoshi]

https://github.com/citizenfx/fivem/issues/1366#issuecomment-1086719744 for better repro

Description

If you record a clip using rockstar editor with streamed assets in it, clear cache, and open the rockstar editor from a script within that said server it will fail to download streamed assets.

Note that this doesn't inherently seem to need to clear cache, this can occur with unloaded map assets if you position you camera from within the rockstar editor close enough to what would trigger a download that didn't occur in gameplay. (This is more of a concern)

Reproduction is easiest done with clearing cache, but is conceptually the same issue.

Repro Steps

1. Join a server with some amount of streamed assets, and have them present in the area around the recording.
2. Start recording with the rockstar editor (Run StartRecording(1) )
3. Stop recording and save the clip ( StopRecordingAndSaveClip() )
4. Close game
5. Clear cache
6. Join server again with atleast some of those streamed assets not present
7. Open Rockstar Editor from within the server. ( ActivateRockstarEditor() )
8. Create new project, add clip, add your clip and open it
9. Observe failure to load or possibly it spamming F8

This is quite possibly NAB or not resolvable but in the off chance it is i thought i'd submit this. Worst case it could probably be handled by the client more gracefully than the 15k log lines that were printed in about 10 seconds.

MainThrd/ Failed to request compcache_nb:/civpack/f82_memblem_2.yft: Failed to fetch: Failure downloading f82_memblem_2.yft: HTTP 404: Not found. (missing requested file: civpack/f82_memblem_2.yft?hash=00fab4f6d546874c94f12405dc894691cb1adb87).

[blattersturm]

Opening the replay editor while connected to a server is the exact same as opening the replay editor when not connected to a server: the process of opening the editor actually disconnects from the server.

Since content in a server may have changed since a clip has been recorded, or a server may even have become inaccessible, it doesn't make sense to expect a clip to always require a particular server (at a particular point in time, even!) be accessible, so the clip saves a reference to the content manifest at the time of recording. Note that this indeed differs from a reference to any valid content at the time of recording - it is still a pending work item to only attempt to register content that actually exists at clip load time, but this also relies on a 'fallback' system as well as some sort of clever logic for map data/types overrides.

The idiom of 'clearing cache' is done out of the game UI and this can't check for any clips that will be invalidated as a result of this action, and therefore also not warn for such.

As such, the only case here that would require further investigation or reproduction steps (including actual assets involved!) is this:

if you position you camera from within the rockstar editor close enough to what would trigger a download that didn't occur in gameplay. (This is more of a concern)

[Lucas7yoshi]

Opening the replay editor while connected to a server is the exact same as opening the replay editor when not connected to a server: the process of opening the editor actually disconnects from the server.

My belief of their being a difference stemmed from the handling of escrow encrypted assets when launching the editor from within a server (that being that they actually load).

I guess the ending part of my original issue comes in with the log file getting filled very rapidly being probably the only "resolvable" minor issue

[Lucas7yoshi]

I'll look to capture a clip that reproduces the map asset streaming in Rockstar Editor but not gameplay but I do warn it'll be finicky and may take time to do consistently

[blattersturm]

My belief of their being a difference stemmed from the handling of escrow encrypted assets when launching the editor from within a server (that being that they actually load).

I guess this would actually be a bug, implying that such asset keys aren't cleared when disconnecting from a server.

Fixing that bug however would require some case of embedding referenced entitlement keys in a clip, first, as otherwise a workaround for that functionality being missing would be broken.

[Lucas7yoshi]

So an easy way to reproduce this is to utilize NoEditorRestrictions to move the camera all the way to a map asset, however im not sure if that would be of concern considering that well, removed all restrictions.

I am already attempting to consistently repro it done without it though.

[blattersturm]

is to utilize NoEditorRestrictions

Not a supported scenario, indeed.

[Lucas7yoshi]

As such, the only case here that would require further investigation or reproduction steps (including actual assets involved!) is this:

Reproduced reliably without the use of NoEditorRestrictions

Edit: an additional note, my assumption that NoEditoRestrictions would make repro easier was wrong, as mentioned below it only occured if the ytyp was streamed in gameplay.

In the test resource i created with a cube, the streaming attempt only occurred when the .ytyp definitions for the model had been loaded but NOT the drawable itself.

This occurs in a very small region between when the ytyp is loaded and the model is "preloaded", but i believe this range would be stretched wider for SLOD's which was the original situation that occurred without clearing cache (however was with a escrow encrypted resource that i do not have access to)

Video:

https://user-images.githubusercontent.com/28872095/161400501-e9faefab-2221-4af9-86d4-224004e1c161.mp4

Resource (Includes rockstar editor commands): https://sx.l7y.ca/repro1366.7z Edit: realized i had tacked in some random mrf test stuff in there. commands of relevance are shown in video: /rsstart, /rsstop, /rsopen

For ease of direct comparison these are my distance scaling settings

And for formality:

Repro steps

1. Add repro1366 as a resource and ensure it
2. Enable minicon so you can watch for streamed asset requests
3. Slowly follow the runway as shown in the video until you see repro.ytyp get streamed
4. Begin recording with /rsstart
5. Wait atleast 3 seconds and save it with /rsstop
6. Open rockstar editor with /rsopen
7. Open the clip, and move the freecam as far forward as possible
8. Observe failed streaming attempts.

[Lucas7yoshi]

Additional note: this situation would be immensely easier to cause if more than 1 prop is in the ytyp and some models are spaced out, which is quite often.

[amantu-qbit]

Tested with multiple scinario. Only happens when I have encrypted resources on my server. But whenever I turn off those resources and record it'll work just fine!