[Bug]: Erroneous type 3 file links in a 3.5.4f1 project

[SNBeast]

Are you on the latest version of AssetRipper?

Yes, I'm on the latest release of AssetRipper.

Which release are you using?

Windows x64

Which game did this occur on?

Project Exonaut

Which Unity version did this occur on?

3.5.4f1

Is the game Mono or IL2Cpp?

Mono

Describe the issue.

Many YAML files in the exported project contain type: 3 file links, and in all such cases that I've checked, the GUIDs uniquely identify existing files. It is possible in this project to run a replacement changing all cases of , type: 3 to , type: 1, and all the file references I've checked will then be present and functional.

Relevant log output

AssetRipper.log

[ds5678]

I need specific examples of the files referenced by type 3 that you had to change. In other words, not the file containing type 3, but the file it references.

[SNBeast]

I need specific examples of the files referenced by type 3 that you had to change. In other words, not the file containing type 3, but the file it references.

Examples include Assets/Texture2D/armorUpEffect_texture.png, Assets/Resources/jetpack/jetPackIgnite1.ogg, Assets/Resources/fonts/Register-Medium.otf, Assets/Scripts/Assembly-CSharp/AssetLoader.cs, and Assets/Shader/GlowCompose.shader. Each of these files is exported with the main bundle, as is the file referencing it.

[ds5678]

Those files are supposed to be type 3 because they're not yaml files.

[SNBeast]

The 3.5.4f1 editor shows them as missing files when they're type 3.

[ds5678]

All type 3 or just some?

[SNBeast]

All type 3 or just some?

All.

[ds5678]

I have an idea of how to solve this, but I need to know where the boundary is. What version of Unity starts using type 3.