old mods and mod folder

[Longshot308]

a lot of old mods have the "zzz." and ".pak" to them and go in the data folder.

Before 1.41 seriously messed up my game these older mods still worked and work until the game locked up my computer.

My question is can the "zzz." part be dropped off then they get put in the mod folder or is more needed?

 

I noticed the mods that were made after the release of the use of the mod folder have a data folder and maybe a couple more files. Are they needed by these older mods that are just ".pak" files to go into the mod file?

 

Edit: found one of the lock up causes is the mod Cheat for console commands.

author updated to 1.40. then 1.41 kicked in and still locks up the computer on the tutorial

some one posted a fix but I don't know what to use to do it and another claims the fix nerfs the rest of the mod.

 

still have some minecraft plants. tho I hafta see if another mod is doing that.

[NunoMG77]

How about you Pak your group of mods yourself?

here's some info:

http://wiki.tesnexus.com/index.php/Modding_guide_for_KCD

I personally opted for a do it for me because mod mergers are too much of a trouble for something so simple as merging folders and solve minor conflicts between XML files.

i installed winmerge, have it on my right button menu.

Simply copy the PAKs you wanna use, change format to ZIp, extract to folders, merge all once you got the folder structure right by reading the link i put above.

when merging do not EVER overwrite files, windows will add numbers to distinguish so keep em in the same merged folder.

Once everyting you want is in the same folder structure, go folder by folder and check for xml doubles :). if any exist, select Two at a time, right click winmerge and you'll be able to spot differences (careful with the file you're going to keep, don't leave nothing useful from the other one behind).

You have to know before what each file is doing, taking out or adding to the game, this way you'll be able to understand empty lines or overwrites.

Once you're done with merging your preferences you may want to create a mod.manifest ( copy it from one of your used mods, add a new line with every add to keep track and save it).

Time to select all the forders created in the merge and ZIP 'em, again when in doubt the link is there to help. now .PAK it, rename to ZZZ_Merged and launch the game.

Have fun.

[BurningFalcon]

How about you Pak your group of mods yourself?

here's some info:

http://wiki.tesnexus.com/index.php/Modding_guide_for_KCD

I personally opted for a do it for me because mod mergers are too much of a trouble for something so simple as merging folders and solve minor conflicts between XML files.

i installed winmerge, have it on my right button menu.

Simply copy the PAKs you wanna use, change format to ZIp, extract to folders, merge all once you got the folder structure right by reading the link i put above.

when merging do not EVER overwrite files, windows will add numbers to distinguish so keep em in the same merged folder.

Once everyting you want is in the same folder structure, go folder by folder and check for xml doubles :smile:. if any exist, select Two at a time, right click winmerge and you'll be able to spot differences (careful with the file you're going to keep, don't leave nothing useful from the other one behind).

You have to know before what each file is doing, taking out or adding to the game, this way you'll be able to understand empty lines or overwrites.

Once you're done with merging your preferences you may want to create a mod.manifest ( copy it from one of your used mods, add a new line with every add to keep track and save it).

Time to select all the forders created in the merge and ZIP 'em, again when in doubt the link is there to help. now .PAK it, rename to ZZZ_Merged and launch the game.

Have fun.

Doing this by hand... the struggle is real.

 

I'm trying to merge 2 different xmls, and while you'd think it is quite easy, it's actually quite the hell, since one of those xmls has many more entries then the other, and I don't even understand why, since both should only change some values (one for durability, one of herbal-weights).

I'm now controlling 2070 vs 2224 Lines....

[Lieste]

For rpg params, there are a variety of changes, additions and deletions. You should consider what the impact of a change might be and keep/remove the changes of each file accordingly.

For items, it is nearly always that the additional lines control added items from patches and dlc, and it is the absence of these which causes the bulk of "my game doesn't work" errors. (E.g. chicken feed added to 'pickables' with 1.9/A Woman's Lot, doesn't exist in your modded 'pickables' from a mod built on even something as recent as 1.8, and there will be even more missing items if the build was 1.4 and hasn't been properly updated).

I copy and past the rows from two files into excel with text-columns as appropriate to give decent 'first pass' outcome. (skip the header), and tidy up the columns if needed - then sort by item_id (or the equivalent which links the file *If a re-order is necessary, for example for a 'sorted' pickables list, then I will first add an index column to resort the list if I want to do so) - I copy both tables into adjacent sections of the same table and then set a conditional formatting on the item_id columns to flag mismatch between the two lists.

I insert rows into the 'short' column where there is a missing entry, and reapply the conditional format the the column.

At the end I will have two broken tables of data, with gaps where there are differences.
I can also compare the other columns using the same concept of conditional formatting, so I can tell at a glance where I need to consider how I merge the tables, and then complete whichever table is the most convenient to work with.

At this point I might edit the xml, adding a few rows to it, or use a concatenation within excel to recast the rows into single cells, and then copy the entire edited list into the xml in place of the original rows. I do whichever I think will be easiest.

This isn't an ideal way of working, but it is fairly robust and avoids glazing over when looking for differences in some of the huge tables.