Vanilla modkits not working on certain vehicles
I've just noticed that the tuning menu for the Kuruma is no longer working in my game. I've isolated the problem to somewhere in my DLCPacks but I can't isolate it further than that. Deactivating the whole folder allows the modkit to return, but having any half of the mods active removes the tuning parts again. I started activating dlcpacks one by one until the tuning menu broke again, isolating two of the folders, continued on with the menu working until another group was activated and it failed again.
Given that multiple different unrelated mods seem to cause the issue I'm skeptical that the issue is in the mods themselves?
Has anyone come across a similar issue, if so, how did you get around it?
Sounds like a ModKitID conflict, basically, two or more of your add-on vehicles are using the same ModKitID.
That, or an outside chance of one of your '.rpf's being corrupted somehow (had that before, was a pain in the hoop to solve, random as hell, each time I loaded the game it would mess with a different vehicle's upgrades. Finally solved it tho, & rebuilt the 'dlc.rpf' from scratch to fix it. )
I'm not 100% sure anyone truly understands how Rockstar logic works regarding ModKitID's (seems to me that there is a hard limit on just how many the game can use & once you get past that, up into higher numbers, they end up repeating (of a sort) & causing conflicts with lower numbers even though the values appear different in carcols/carvariations).
Refer to my post here & the links there-in for a place to start looking for a solution
The less add-on vehicles you have installed the easier it will be to find a modkitID that works.
Setting a vehicle's modkit to '0_default_modkit' in:
<Kits> <Item> <kitName>0_default_modkit</kitName> <id value="0"/> <kitType>MKT_STANDARD</kitType>
<kits> <Item>0_default_modkit</Item> </kits>
Note: You need to set '0_default_modkit' in both files for each vehicle you test for it to work.
That will disable that vehicle's default modkitID (no visual tuning, but extras/wheels/engine upgrades etc still work) & can be useful for diagnosing modkitID issues.
If you think a vehicle is conflicting with another use '0_default_modkit' on one of them & see if the other's upgrades suddenly start appearing. Obviously, gets a little tricky if you have 3 or 4 vehicles all conflicting with each other (sounds like that might be what you are experiencing. Just do what you have been doing & remove dlc's to limit the variables while you test a couple of vehicles at a time).
Hopefully, that gives you a place to start anyway, & if modkitID's get a little confusing at times, know you are not alone in that, best of luck to ya
@a63nt-5m1th Thats a big help, thank you, I'm slowly working through my list. I have 98 Add-on packs installed, at the time of writing I have confirmed 38 as working okay together, 4 do not work, 3 are potentials and the rest are yet to be tested.
I did think it would be something to do with the modkit IDs clashing, I am going to look at the rpfs of each mod once I've confirmed which ones definitely cause the issue.
Sound, let us know how you get on
@a63nt-5m1th So I've finally gone through the whole list and have isolated 14 mods as problematic. I've checked the modkit IDs and they are all different. I noticed in one of the threads that IDs over 255 are useless and get truncated to 8bit anyway, but even after converting them they still differ.
I'm not sure where to go next with it, going to try re-downloading the mods individually to see if that changes anything, as bizarrely some of the folders seem to be missing their dlc.rpf file, yet load into the game just fine.
Re-installing the mods didn't do much, one of the mods stopped clashing, but everything else still doesn't work. None of the modkit ID's match (I know realise the IDs were increased to 16bit so the truncation doesn't matter now). I'm not sure what else it could be?
bizarrely some of the folders seem to be missing their dlc.rpf file, yet load into the game just fine
Just had a similar issue to that helping some one diagnose Albo1125's Modding DLC Pack V 1.2.
Run a diskcheck on the hard drive if ghost dlc issues continue
My Computer > Right-click Hard Drive/SSD > Properties > Tools > Error-checking > [Check now] & then just tick only the 'Automatically fix file system errors' tickbox (OS hdd with require reboot to run it).
Probably worth running that no matter what, might be related to the ModKitID issues you are experiencing.
Worth ruling out
@a63nt-5m1th turns out it was just a display glitch in OpenIV caused by undoing a folder move in file explorer. Restarting OIV restored the ghost dlcs.
For any ModKitID conflict issues, you're best bet is to try different ModKitID numbers at random, if it's not playing nice.
ModKitID Conflict Instructions:
All three of these values (936) below need to be changed to another number (the same number):
<kits> <Item>936_raptor2017_modkit</Item> <!-- change '936' to another number --> </kits>
<Item> <kitName>936_raptor2017_modkit</kitName> <!-- change '936' to another number --> <id value="936" /> <!-- change '936' to another number --> <kitType>MKT_SPECIAL</kitType> <visibleMods> <Item>
This post is deleted!
^Not sure how that happened, forum somehow logged me in as a different user. Second time this has happened now, going to report on the tech issues subforum.
Aye, it's been a site issue for a while . Hasn't happened to me for ages tho, I think since I started logging in on the main site & then heading to the forums, rather than logging in here directly. Might have something to do with it? Maybe.
What happens (if anything) to the Kuruma upgrades/tuning menu if you disable only the 'patchday2ng' 'dlcpacks' dlc?
What happens (if anything) to the Kuruma upgrades/tuning menu if you disable both the 'mphiest' & 'patchday2ng' 'dlcpacks' dlc?
Also, has there been any variation in what does & does not conflict with the Kuruma?
Say, one dlc conflicts with the Kuruma in combination with certain other dlc, but doesn't conflict if the group is changed to some other group of vehicle dlcs & then when you go back to the first group combination you tried the results are different again?
@a63nt-5m1th The dlc packs have remained consistent, with the 13 I have found deactivated the kurumas tuning works fine, if any one of them are moved accross the menu fails again, then works as soon as the problematic pack is removed. I'll try disabling the two packs you named and report back
Just realised there is a Kuruma in 'patchday9ng' too.
Use 'Ctrl+F3' in OpenIV to search for 'kuruma.yft' & double-check there aren't anymore hanging about. Disable them in a logical order (highest patchday#ng > lowest patchday#ng etc).
Temporarily disable them in this order & see if there are any changes to tuning:
- Disable 'patchday9ng' > Check tuning.
- Disable 'patchday2ng' & 'patchday9ng' > Check tuning.
- Disable 'mphiest', 'patchday2ng' & 'patchday9ng' > Check tuning.
Basically, this will allow you to check that an error hasn't snuck into the kuruma files the game is loading by dropping back to previous older versions of the files.
The vanilla kuruma uses ModKitID =110
...\mods\update\update.rpf\dlc_patch\mpheist\common\data\carvariations.meta (Note: 'update.rpf\dlc_patch' not dlcpacks )
<kits> <Item>110_kuruma_modkit</Item> </kits>
...\mods\update\update.rpf\dlc_patch\mpheist\common\data\carcols.meta ('update.rpf\dlc_patch' also)
<Item> <kitName>110_kuruma_modkit</kitName> <id value="110" /> <kitType>MKT_SPECIAL</kitType> <visibleMods> <Item>
Make sure that is the case in your game too
All problem packs disabled, Patchday2ng Enabled, MPHeists Enabled - Kuruma mods working fine
One problem pack enabled, Patchday2ng Disabled, MPHeists Enabled - Kuruma mods working fine
One problem pack enabled, Patchday2ng Disabled, MPHeists Disabled - Kuruma is gone
All problem pack enabled, Patchday2ng Disabled, MPHeists Enabled - Kuruma mods working fine
I guess that means there is something in Patchday2ng causing problems.
All problem pack enabled, Patchday2ng Enabled, MPHeists Enabled - Kuruma mods working fine
Doesn't that^ mean that the issue is fixed?! (check that's right, no typo's & whatnot).
What are your results for:
- All problem packs enabled, Patchday2ng Disabled, MPHeist Enabled?
If that's what you meant to type, then yeah, looks like the issue is in 'patchday2ng' (otherwise, let me know the results of that?)
Full Patchday2ng Vanilla to Mods Folder Replace:
If that's the case & you have no other edits in 'patchday2ng' you want to keep, you should be able to fix it easily by replacing the 'patchday2ng' 'mods' folder 'dlc.rpf' with the vanilla one from the game folder.
Even if you do have other 'patchday2ng' edits you want to keep, I would still use this method initially (after backing up 'mods' folder 'patchday2ng' obvs) just to confirm vanilla files actually fix it. That way, if you follow the 'Keep Your Other Patchday2ng Edits' process below, but still have issues, you know you probably have a corrupt 'patchday2ng' 'mods' folder 'dlc.rpf' (or possibly some other issue/complication) & you don't waste a heap of time on manual file edits to find it out .
Keep Your Other Patchday2ng Edits:
If you have edits in your 'mods' folder 'patchday2ng' you want to keep (& once you've confirmed vanilla files fix the issue), just move only the Kuruma files & '.meta' data over from the vanilla game 'dlc.rpf' replacing the equivalent files/'.meta' data in your 'patchday2ng' 'mods' folder 'dlc.rpf'.
Be careful when manually editing the '.meta' files & copying the Kuruma data over. Make sure you get everything.
Let me know how you get on
Yeah that was a typo on my part, I meant to say it works with Patchday2ng disabled! Its completely untouched, the only update folders I have in my mods folder are Patchday1ng and Patchday22ng, everything else in the dlcpacks folder is addon material
Ah, so this is the vanilla 'patchday2ng' 'dlc.rpf' that's doing this.
You have a few options:
- Delete 'patchday2ng' & then start/verify the game to download a new fresh one (instructions for that depend on what version (Steam/Rockstar etc) of the game you have. Google's your best bet).
- If the Kuruma is the only thing affected, copy the vanilla 'patchday2ng' 'dlc.rpf' over to the 'mods' folder & then remove the Kuruma from the 'mods' folder 'patchday2ng' 'dlc.rpf' & fallback to using the 'mpheist' version of the vehicle.
- Take the Kuruma vehicle files from 'mpheist' dlc & install them to the 'mods' folder 'patchday22ng' (or the highest 'mods' folder patchday that is set up to contain vehicle files).
Early in the morning for me, there may be a few other ways to do it too.
Unknown had some code to figure out the file + game mod kit IDs:
Might be interesting to re-use that to have some modkit id generator, though I do wonder how it'd deal with kits that already conflict.
On a semi-related note, while merging DLCs I had an occurrence of light id matching modkit IDs, causing neither to work. So not sure if that's also a thing to keep in mind.
oh my god I'm a moron. I did that testing forgetting to actually move the files back into the dlcpacks folder.
So with patchday2ng still de-activated, the Kurumas tuning parts do not work with the problematic mods activated. As before, the Kuruma disappears completely if the MPHeists pack is deactivated. Fully at a loss on this one. For the sake of 14 actually pretty decent mods, I think I can live without being able to modify one car lol
Out of interest, what are those 14 mods (& have you edited them in any way)?
If you can, give me download links to them & I'll take a look at them in my game
roadking has since been removed from the site
flash has since been removed from the site
I'm not too bothered about the real cars, but I would like to be able to retain the lore friendly mods without losing the Kurumas modkits
@ikt the code that Unknown used, how would I use that in the game? Just save it as a certain file type and drop it in the game directory?
Download this DisplayVehicleModkitID.cs & place in 'scripts' folder.
Edit: Confirmed script works. ModKitID appears at bottom of screen when get in vehicle but need to go to modification menu/or apply some upgrades etc to display real number.
As you can see in the tests below, there's a lot the whole community doesn't know about the intricate nature of ModKitID's & how exactly they work Just forget the carvariations numbers, they really mean nothing as far as a correlation between them & the actual used ModKitID in the game.
Perhaps two identical numbers do always cause a conflict, but after that there's no predictable way to choose a safe number utilising the carvariation/carcols numbers.
I also didn't get a single Kuruma ModKitID conflict with any of the vehicles mentioned below.
'Actual in-game ModKitID' = ModKitID displayed in-game by 'DisplayVehicleModkitID.cs'
'No Kuruma Conflict' = No Kuruma Conflict in-game. Upgrades/Visual Tuning Working.
Vanilla Test (mods folder renamed):
'kuruma' > carvariations ModKitID = '110' > Actual in-game ModKitID = '115'
So even with vanilla the carvariations ModKitID don't match up to actual used in-game ModKitID.
Note: All tests below this are using the 'mods' folder.
(all my add-ons activated & testing only one dlc below at a time):
'kuruma' > carvariations ModKitID = '110' > Actual in-game ModKitID = '142'
'admiral2' > carvariations ModKitID = '5854' > Actual in-game ModKitID = '127' = No Kuruma Conflict
'jackgpr' > carvariations ModKitID = '4579' > Actual in-game ModKitID = '127' = No Kuruma Conflict
'ssc_sentinel2' > carvariations ModKitID = '3760' > Actual in-game ModKitID = '127' = No Kuruma Conflict
'ssc_tempesta' > carvariations ModKitID = '3768' > Actual in-game ModKitID = '127' = No Kuruma Conflict
'vincent2' > carvariations ModKitID = '1231' > Actual in-game ModKitID = '127' = Instant crash after adding highest upgradable exhaust = Bad Mod/Exhaust Upgrade. No Kuruma Conflict
'vincent3' > carvariations ModKitID = '1232' > Actual in-game ModKitID = 'No Upgrades Appeared. ModKitID conflict confirmed with Unknown Vehicle' = No Kuruma Conflict but changed Kuruma 'DisplayVehicleModkitID.cs' ModKitID to '141'
Shame Stephen Hawking died in 2018. Maybe he could have figured out wtf is going on with ModKitID's
It's definitely not as simple as just picking a ModKitID that doesn't appear in your carcols/carvariations.
To have any chance of accurately predicting safe numbers to use, there is at least one other hidden variable/process/procedure that needs to be taken into account too.
At this point, to me it looks like the game assigns a pool of numbers somehow & is counting up & down (in some sort of pre/self determined assigned hierarchy/priority) as vehicles are added & removed or as ModKitID conflicts appear/are fixed etc. ie Remove '127' (with a separate modkitID conflict perhaps) & all vehicles above that slip down one (Kuruma going from '142' to '141' etc in the 'vincent3' 'No Upgrades Appeared. ModKitID conflict confirmed' case above).
Gonna have a little play around with things at this point, see if it'll allow even a glimpse of it's inner workings to be known by us mere mortals
(all non-essential (crash if deactivate all vehicle dlc so some (dispatch etc) left active) add-ons deactivated & testing only one dlc below at a time):
'kuruma' > carvariations ModKitID = '110' > Actual in-game ModKitID = '113'
'admiral2' > carvariations ModKitID = '5854' > Actual in-game ModKitID = '106' = No Kuruma Conflict but changed Kuruma ModKitID to '114'
'jackgpr' > carvariations ModKitID = '4579' > Actual in-game ModKitID = '106' = No Kuruma Conflict but changed Kuruma ModKitID to '114'
'ssc_sentinel2' > carvariations ModKitID = '3760' > Actual in-game ModKitID = '106' = No Kuruma Conflict but changed Kuruma ModKitID to '114'
'ssc_tempesta' > carvariations ModKitID = '3768' > Actual in-game ModKitID = '106' = No Kuruma Conflict but changed Kuruma ModKitID to '114'
'vincent2' > carvariations ModKitID = '1231' > Actual in-game ModKitID = '106' = No Kuruma Conflict but changed Kuruma ModKitID to '114'
'vincent3' > carvariations ModKitID = '1232' > Actual in-game ModKitID = '106' = No Kuruma Conflict but changed Kuruma ModKitID to '114'
(all non-essential (crash if deactivate all vehicle dlc etc) add-ons deactivated & all dlc mentioned below activated all at the same time):
'kuruma' > carvariations ModKitID = '110' > Actual in-game ModKitID = '119'
'admiral2' > carvariations ModKitID = '5854' > Actual in-game ModKitID = '110' = No Kuruma Conflict
'jackgpr' > carvariations ModKitID = '4579' > Actual in-game ModKitID = '112' = No Kuruma Conflict
'ssc_sentinel2' > carvariations ModKitID = '3760' > Actual in-game ModKitID = '113' = No Kuruma Conflict
'ssc_tempesta' > carvariations ModKitID = '3768' > Actual in-game ModKitID = '114' = No Kuruma Conflict
'vincent2' > carvariations ModKitID = '1231' > Actual in-game ModKitID = '115' = No Kuruma Conflict
'vincent3' > carvariations ModKitID = '1232' > Actual in-game ModKitID = '111' = No Kuruma Conflict
I do see alot of symmetry there, stuff like the Kuruma being +4 over it's assigned carvariations ('110') if a vehicle taking a lower ('106') slot is also activated & then also being +4 over the highest exampled ModKitID ('vincent2' '115') in Test 03 (ie vincent2 = '115' = highest number in tested cars ('115' +4 = '119' = ModKitID Kuruma was pushed up to in that test). Like the test add-ons are taking slots & pushing up the kuruma one.
There's also a Kuruma = '113' (Test 02) + 6 working upgradable cars = '119' (Kuruma Test 03)
My subconscious defo see's something in all of this, but conscious mind can't quite formulate & piece it together as of yet .
F**k it, gonna break out my crystal ball & get Hawking on this. One advantage to clairvoyantly contacting Steven, as opposed to anyone else (you know, like trying to contact your dead gran or some shit), is that when he answers, you know it's definitely him
I just used the modkit ID code and interestingly with the mods inactive the kuruma shows 113 as expected when the problem mods are disabled, but shows 65535 with them enabled, telling me that the mods are somehow wiping the kurumas modkit completely .
I just read through your monster post and it looks like you're getting different results to me in that case. I guess I have something else that is working in tandem to break the modkits? I'm trying to think what scripts or otherwise I might have that could potentially cause that conflict