vehicles.meta changes only affect addon vehicles

[rxyyy]

I seem unable to edit any existing vehicles' fields in vehicles.meta. I'm unsure if I did something wrong, I was unable to find any information on the forums about it, but using the same resource setup for an addon vehicle works fine.

Here's an example resource for reproduction. It changes the sultanrs and banshee2's vehicleClass from VC_SUPER to VC_SPORT, and should display Sports instead of Super in the bottom right corner once inside one of them.

[blattersturm]

Some R* DLC loaders don't support overwriting existing data, whereas others do. The vehicle one is even more peculiar as for some reason it is obfuscated with Arxan all over the place as it is used as a trigger point for a last-minute entitlement check, so may be more difficult to reimplement easily.

[rxyyy]

Does that apply to vehiclemodelsets.meta as well? It still spawns the vehicles specified in it if overwritten, but it has the weird side effect of completely ignoring vehicle mods when doing so, so i.e. gang cars spawn stock.

[blattersturm]

Is this one of the 'SP DLC' related loaders? Those are always a bit weird with partial loading.

Another notably weird case is how carcols doesn't load the entire file, but only merges some specific types.

[rxyyy]

I think so, it's only present in common.rpf and update.rpf. I suppose dispatch.meta can also go in that list, sadly it doesn't even partially load.

[blattersturm]

A thing to note is that data file loaders for DLC despite sharing an enum with the 'base' data file types, have an entirely different set of valid entries.

I don't think 'dispatch' is a valid entry at all, even for SP DLC leftovers.

[rxyyy]

Thought I'd share some more about what I've discovered regarding this if anyone encounters a similar issue.

It is possible to change data in vehicles.meta if the file gets loaded by a resource that has a custom level meta using replace_level_meta. However, this will only correctly apply changes if the vehicles included are part of the base game.

        <Item>
            <filename>resources:/fifty-level/data/levels/gta5/vehicles.meta</filename>
            <fileType>VEHICLE_METADATA_FILE</fileType>
        </Item>

You're able to change just about anything I've tried. (handlingId, vehicleMakeName, vehicleClass, wheelType, ...)

Doing so with DLC vehicles also "works", depending on what you're trying to achieve and weirdly enough, which DLC they're part of.

Going back to my original example with mpjanuary2016, I was able to change vehicleClass for both banshee2 and sultanrs using the method above, however upon attempting to change data in their handling (separate resource containing a handling.meta), they kept using their original data from mpjanuary2016/common/data/handling.meta. Removing their entries from the new vehicles.meta resulted in them correctly using the new handling.

Other DLCs I've tried have had other weird side effects. Namely...

• Pasting all DLCs' vehicles.meta into 1 file resulted in just 2 cars spawning on the map with wildly incorrect textures.
• Pasting just mpbusiness's vehicles.meta resulted in the turismor spawning, but not being enterable.

[ghost]

Not a fan of bumping but this issue was lost in time

[rxyyy]

I haven't done any more research on this since my last reply. Gave up once I realized the side effects of replacing DLC vehicles' vehicles.meta files produces completely random side effects.

[gottfriedleibniz]

Some R* DLC loaders don't support overwriting existing data, whereas others do.

Looking through the disassembly, this seems to be the case. CVehicleMetaDataFileMounter checks whether the archetype already exists and will not add/initialize CVehicleModelInfo it does.

A workaround here, if possible, would be quite tricky without fully knowing all second-order effects because many of the archetypes wanting to be replaced are permanent (e.g., connect locally > load modified data > connect elsewhere with changed data would be a possibility).

It may be possible to hijack rage::fwArchetypeManager, replace the data with our own, and restore on disconnect (or delete if replacing a streamed archetype). Will require some research/testing to ensure no dangling pointers, double-frees, etc. arise from this. Note, this would be a low-priority task at the moment.

however upon attempting to change data in their handling (separate resource containing a handling.meta)

Did you experiment with <fileType>HANDLING_FILE</fileType> in your replace_level_meta tests?