Linker fails to load asset of type "localize" from in-memory for T5, but loads fine from disk

[Hadi77KSA]

Using version v0.15.3, I was faced with the following error when attempting to build a fastfile for T5: Failed to load asset of type "localize": "en_zombie_cod5_factory"
This error wasn't limited to the en_ file, it also occurred for the other languages of the file I've tried. The following shows the error when using the Linker to build the fastfile and trying to obtain the asset from in-memory:

However, I bypassed the error by using the asset from the Unlinker. The following shows the result from the Linker while having the asset on disk:

To clear up a few points:

• The .zone files shown in the zone_source folder (aside from mod.zone) are taken directly from the output of the Unlinker without modification.
• mod.zone was used to build mod.ff, which just contains one asset that is an xmodel asset from ge_zombie_cod5_factory.ff. mod.ff was just used for swapping the xmodel asset from the original files of the other languages.
• I haven't tried this for other games, only tried for T5.

[Laupetin]

Hey, thanks for opening the issue :)

This has something to do with the way OAT does handle localize assets.
The game considers each string + translation to be its own asset.
Because that would fill up the .zone file way too much i made it so it instead contains the name of the .str file that the Linker should look for.

The issue is that when looking up assets in-memory OAT can only look up single assets of the specified type.
It cannot find an asset with the name because its the name of the file, not the localize assets themselves.

To handle this it would require to add a custom behaviour for looking up localize assets in-memory.
It would need to check whether there is a fastfile loaded with the same name and then just copy all of its localize assets.

That behaviour is also a bit limited though. It wouldn't work if the name of the localize asset does not match the name of the loaded fastfile anymore for example.

Would the described workaround work better as expected behaviour?

[Hadi77KSA]

Hi! Thank you for the detailed and insightful response!

This is one of my first fastfile modding experiences and I doubt I’ll work on something similar to this that would prompt this error, therefore I don’t feel comfortable with determining how a fix should be implemented. The behaviour you’ve suggested seems good for what I was working on, but it could be an unwanted behaviour to someone who is using the current loading with the .str file to modify some strings while also having a fastfile of the same name loaded.

I would say to do what you see fit. Even if a fix is not to be implemented, I’d say having a note written somewhere—which explains that the Linker looks for the .str file instead of the localize assets themselves from the fastfile when using localize,NAME—would go a long way.