Loading and Saving a YDR without changes in C#

[marviniwurscht]

Hey everyone! :)

Whats the goal? Im trying to Load() and Save() a YDR File without any modifications from a C# Program using the CW Libraries.

How to reproduce?

byte[] data = File.ReadAllBytes(filePath);
System.Diagnostics.Debug.WriteLine("start: " + data.Length);
YdrFile ydrFile = new();
ydrFile.Load(data);

Thread.Sleep(1000); // Just because

data = ydrFile.Save();
System.Diagnostics.Debug.WriteLine("end: " + data.Length);
File.WriteAllBytes(filePath, data);

Whats the problem? In theory start should be equal to end, right? But start is a lot bigger than end and when i try to open the YDR after it has been Loaded and Saved it has weird bugged textures. start: 6483546 | end: 3333128 Ive experienced bugged textures before (that looked exactly the same) with YTDs, that happened because i changed the data of a Texture without changing the texture.Width / texture.Height to "fit" new data. You can see the original textures here and the modified (bugged) ones here. But in this case im only loading and saving without modification. im not really sure what exactly is causing this issue but i think this might be a bug in CW.

Have you tried alternatives? I have also tried another method of loading the YDR (Copied from Umbrella.re's ToolkitV) but that didnt help either. https://github.com/UmbrellaRE/ToolKitV/blob/182bcd8dc39efd8730b1c0364a3ae20a0a42f95b/Application/Models/TextureOptimization.cs#L248 Line 248 (Modified to YdrFile instead of YtdFile of course)

Does it happen every time? No. That is the weird part. Some YDRs work just fine. I'll upload a not working file for reproducing my issue. https://workupload.com/file/SA6YNkKa9gJ

---

Update: The bug seems to only affect the argb8 textures.

Update 2: The same issue happens when trying to export the YDR in the CW RPF Explorer UI as XML.

[carmineos]

If I remember correctly CW always rebuilds any resource, as all the rebuild logic is written inside the Save method of resource structs. You have to either implement your own custom methods, wait for CodeX or workaround using something like rage-toolkit

Resource7<PgDictionary64<TextureDX11>> file = new Resource7<PgDictionary64<TextureDX11>>();
file.Load(filename);
// file.Rebuild(); // this will rebuild the resource 
file.Save(filename);

[marviniwurscht]

If I remember correctly CW always rebuilds any resource, as all the rebuild logic is written inside the Save method of resource structs. You have to either implement your own custom methods, wait for CodeX or workaround using something like rage-toolkit

Resource7<PgDictionary64<TextureDX11>> file = new Resource7<PgDictionary64<TextureDX11>>();
file.Load(filename);
// file.Rebuild(); // this will rebuild the resource 
file.Save(filename);

Hey thanks for your reply. :) Just not Rebuilding the file wont work for me, because in the end i do want the file to be rebuild (when i edited something inside of it) and then save it. I will look into rage-toolkit though, thanks!

Ive found out that this bug is only affecting the argb8 textures and the error also comes up, when i try to export the ydr as XML in CW RPF Explorer. I think this confirms that its actually a bug related to ARGB8 Textures in CW.

[marviniwurscht]

Import / Export in OpenIV works fine so there has to be something wrong in CW. Since im not experienced enough with C#, maybe someone else could look into this? ❤️ @dexyfex

[marviniwurscht]

Bump