burninrubber0
commented
1 week ago After some thought, the way to do this is probably by having an explicit field for the file name. This is technically redundant, but it provides greater flexibility and prevents any potential issues when determining the ID (any find-based alternatives would be costly). Determining how to name the files is still a complicated matter, though.
As mentioned in the follow-up to #1, it's also time to do away with type IDs in favor of names in the YAML output. There should probably be an inverted map for bundle creation for this purpose, for performance reasons.
Also, support for hex IDs for both resources and types will remain in place.
It should end up looking like this (TRK_UNIT0_GR.BNDL used for this example):
resources:
- id: TRK_UNIT0_Passby
filename: TRK_UNIT0_Passby
type: StaticSoundMap
- id: PRP_INST_0
filename: PRP_INST_0
type: PropInstanceData
# For example of an unknown ID. (This is TRK_UNIT0_Emitter)
- id: 0x9396DC24 # Used as a fallback when no filename is present
type: StaticSoundMap
- id: TRK_UNIT0_list
filename: TRK_UNIT0_list
type: InstanceList
- id: PRP_GL__0
filename: PRP_GL__0
type: PropGraphicsList
- id: gamedb://burnout5/Burnout/Content_World/Scenes/Backdrops/giant_water_backdrop.RoadScene?ID=546273
filename: giant_water_backdrop
type: Model
The resource IDs stored in bundles are CRC32s of an original string, e.g., "PUSMC01_AttribSys" converted to lowercase. It should be possible to store these strings in the metadata instead of the CRCs.
Resource ID strings never start with 0x, so there's no potential for strings and CRCs to conflict, but some strings do begin with digits (namely in shader and wheel bundles). During bundle creation, it's probably best to assume anything that isn't prefixed with 0x should be hashed.
Where this idea breaks down a little is with file naming. With the CRC gone from the metadata, using that as the file name is a bad idea, but the various intricacies of gamedb URIs means it would take significant effort to have every file named both as a user might expect and in a way that it can be retrieved for bundle creation. One possible solution would be to list the CRC alongside the string, but then you begin creating confusion for the user as to which one (or both?) should be changed when modifying metadata. The most likely outcome here is for a complicated per-resource-type solution to be implemented.
Also of note is the bundle debug data (aka ResourceStringTable). This should not be used directly as it is unreliable, and this is especially true in development builds, where YAP's focus is. That's not to mention it might not be present at all, even in debug builds. However, it can be used as a base for creating file with all known resource strings, preferably already matched to their CRC (for performance reasons), which YAP can use for reference with all bundles. In cases where the debug data's string and CRC don't match, it can typically be found manually or in a semi-automated fashion, thus filling in the gaps.