Wasteland 2: now with improved modding capabilities!

[Executor_]

To increase Wasteland 2's modding support requires editing the game code, specifically the Assembly-CSharp.dll file found in the "Wasteland 2 Director's Cut\Build\WL2_Data\Managed\" folder, which will in most cases be in the "C:\Program Files\Steam\steamapps\common\" directory.

I will NOT, however, be distributing the entire modified Assembly-CSharp.dll. Instead, I will be issuing an XDELTA patch, which will merely contain the changes necessary to transform the original DLL into the new, improved version. Hopefully, this will keep inXile's lawyers off my back (though if they forum ban me anyway, I'll likely head over to RPGCodex.net).

DOWNLOAD
XDELTA patch download: https://www.dropbox.com/sh/x36syu96ku75 ... g80ka?dl=0
Filename: patch_v0.9.4zy.xdelta
(If running Linux, instead go into the 'Linux' subfolder and download that patch.)

You will need a program to apply the patch to the original Assembly-CSharp.dll. Already in that Dropbox folder is an XDELTA patcher (DeltaPatcherLite.exe) that will work with Windows, originally from http://www.romhacking.net/utilities/704/. A Linux patcher called YADP is available at http://www.romhacking.net/utilities/1159/, a copy of which is also in the 'Linux' subfolder. A Mac OS X variant can be downloaded from http://www.romhacking.net/utilities/746/. Or Google "XDELTA patcher" if you don't like these, there seems to be a lot of them.

Also, from that same location, download the Localization.zip file.

INSTALLATION INSTRUCTIONS
If you're not already there, go to the "...\Steam\steamapps\common\Wasteland 2 Director's Cut\Build\WL2_Data\Managed\" directory. Before applying the patch, make a folder named "Backup" and copy the original Assembly-CSharp.dll there. This and any future XDELTA patches I create will be relative to the original DLL, so you always want to keep a copy of it. If you should lose the original DLL, you can restore it by going into Steam, right-clicking on "Wasteland 2: Director's Cut" in your Library and selecting Properties. Go to the "Local Files" tab and click on "Verify Integrity of Game Cache".

For Windows, verify that the size of the Assembly-CSharp.dll is 19,246,592 bytes before trying to administer the patch, as it won't work otherwise.

For Linux, size should be 19,247,104 bytes.

Run the DeltaPatcherLite.exe (or whichever patcher you're using) and select the non-copied Assembly-CSharp.dll as the target, and the patch_v0.9.4zy.xdelta file you downloaded from the above Dropbox link as the patch file, then apply the patch.

After patching, the Assembly-CSharp.dll will actually be smaller, but that won't matter, as only some useless padding is removed.

Extract the contents of the Localization.zip file into the "...\Steam\steamapps\common\Wasteland 2 Director's Cut\Build\WL2_Data\StreamingAssets\Localization" folder.

Since this is still a beta version, I recommend verifying everything is working correctly with the patched DLL. First, start Wasteland 2 like normal and exit at the main menu. Open the output_log.txt file, typically in the "...\Steam\steamapps\common\Wasteland 2 Director's Cut\Build\WL2_Data\" folder, and search the text file for "exception". Hopefully, you won't find any, in which case start the game again and load a save, then exit. Check the output_log.txt file once more for any exceptions. If no exceptions, everything should be working fine.

NEW CAPABILITIES
***lots of outdated information in this post now, check the changelogs (particularly 0.9.3 onwards) for further information***

IMPORTANT: Gamepad support is currently bugged, so you must use a mouse.

LINKS TO PATCH NOTES
0.8.2
0.8.3
0.8.4
0.8.5
0.9.0
0.9.1
0.9.2
0.9.2b
0.9.2c
0.9.2d
0.9.3
0.9.3b
0.9.4
0.9.4b
0.9.4c
0.9.4d
0.9.4e
0.9.4f
0.9.4g
0.9.4h
0.9.4i
0.9.4j
0.9.4k
0.9.4l
0.9.4m
0.9.4n
0.9.4o
0.9.4p
0.9.4q
0.9.4r
0.9.4s
0.9.4t
0.9.4u
0.9.4v
0.9.4w
0.9.4x
0.9.4y
0.9.4z
0.9.4za
0.9.4zb
0.9.4zc
0.9.4zd
0.9.4ze
0.9.4zf
0.9.4zg
0.9.4zh
0.9.4zi
0.9.4zj
0.9.4zk
0.9.4zl
0.9.4zm
0.9.4zn
0.9.4zo
0.9.4zp
0.9.4zq
0.9.4zr
0.9.4zs
0.9.4zt
0.9.4zu
0.9.4zv
0.9.4zx
0.9.4zy

In the Options menu, there will now be a new Modding tab where you can adjust additional mod-related settings. If you see a mention of a settings.ini, just go to the Modding tab instead, as the INI file is no longer used.

• Export object data: "Export All Objects" in Options-->Modding tab. Game objects like ItemTemplates, NPCTemplates, DropSets, StatusEffects, etc. will all be written to the "Export" folder to assist with modding. 'Scene' (map) specific objects will be written the first time the scene is loaded.
• Allows applying override files to more object types: Traits, CNPCTemplates, DropSets, SpecialAttacks, AIWeightTemplates, WorldMapRandomEncounters, etc. previously could not be altered via MSON files.
• All fields are now writeable to: the base game has issues with properly reading MSON files in certain circumstances, and hence fields like validMods in ItemTemplate_Weapon could not be modified.
• Improved object referencing: the base game has only a limited capacity for finding and linking to other objects, therefore many fields that require a reference to other objects cannot be changed. Currently, the modified game only allows linking to objects already loaded by the time the main menu is reached after starting the game, which includes:
  • all: ItemTemplate, StatusEffect, JournalEntryTemplate, WorldMapRandomEncounter, WearableInfo
  • many: AIWeightTemplate, DropSet, MobTemplate, SpecialAttack
  This will eventually be expanded so 'scene' (map) specific objects can reference other scene-specific objects (non-scene-specific objects will never be allowed to reference scene-specific to avoid problems of inconsistent availability). Note that if a MSON override provides an object name the modified game can't find, it'll leave the field unchanged, so if there was already a valid object reference there, it'll stay that way.
• Expanded support for enumerations: enums can now be used as array/list indices, while for fields expecting a certain enum type, the enum name can be optionally provided. Enums are NOT case-sensitive.
  
  For example, the modClass field in ItemTemplate_Weapon is of type WeaponModClass enum. All the following are equivalent:

  Code: Select all

  modClass : SHOTGUN
  modClass : WeaponModClass.Shotgun
  modClass : 5

  Both the following are equivalent, altering only the 8th-element in the array.

  Code: Select all

  equipment :& [ EquipmentSlot.WeaponR : Energy_Toaster_Gamma_Ray ]
  equipment :& [ 7 : Energy_Toaster_Gamma_Ray ]

  Refer to the enums.txt file created in the "Export" folder after running the modified game for the first time for a list of enumerations and their constant names.
• Set custom mod path: The game can be redirected to search for the "Mods" folder anywhere on a hard drive. The default "Mods" folder location is in the "Wasteland 2 Director's Cut\Build\WL2_Data\" directory (eg. "C:\Program Files\Steam\steamapps\common\Wasteland 2 Director's Cut\Build\WL2_Data\Mods\"). Since Windows doesn't normally like filepaths of more than 260 characters and some objects are heavily nested, you can create a folder like "C:\WL2" and then enter that path into CustomPath in the settings.ini to point the game to it.
• Enable/disable the inXile logo movie: PlayLogo option in settings.ini. If you're tired of clicking through the logo movie for the millionth time.

MODDING
inXile has a handy modding tutorial on their website, which will help familiarize you with the MSON format.

The modified game behaves just like the base one. MSON override files go in the "Mods\Import\" folder, and the same nested folder structure is used. You can find out where to place files by looking at the directories in the "Export" folder if the FullExport option in settings.ini is turned on.

Any messages concerning the loading of MSON files will be outputted to the debug_import.txt file in the "Mods" folder, so if a change doesn't seem to be working, check for any error messages there.

Note that even though the MSON files written to the "Export" folder will have a lot of data in them, the MSON overrides in the "Import" folder need only contain the field(s) that you wish to change. For instance, if you have FullExport turned on, then the AZ0_AngelaDeth_PC.mson file will be written to the "Mods\Export\MobTemplate\PCTemplate\CNPCTemplate\" folder. Yet if you only want to change her portrait, then a file called AZ0_AngelaDeth_PC.mson in "Mods\Import\MobTemplate\PCTemplate\CNPCTemplate\" containing the following is sufficient:

Code: Select all

{
	portraitTexture : wl2_portrait_kekahbah
}

For portrait object fields, don't include filename extensions (eg. ".png"). The game will first look for any PNG/JPG/JPEG file that matches the name in the "Mods/Import/Portrait/" folder, then in "%userdata/.../Custom Portraits/" (eg. "My Documents\My Games\Wasteland2DC\Custom Portraits\"), then finally the game will check all the built-in portraits. A list of built-in game portraits will be outputted to your "Export" folder after you run the modified game the first time.

Bear in mind that some NPCs have multiple NPC_Templates and Spawners that are used at different times, so depending on what you wish to accomplish, you may have to modify them all.

If you're editing the validMods field on weapons, I recommend removing all mods from any weapons that will be affected first (including those in your storage locker at Ranger Citadel), because it's doubtful the game will appreciate you loading up a savegame containing a weapon with a no longer legitimate mod attached to it.

Please inform me of any other issues you may have.

[natty_dread78]

Nice, thxs a lot for sharing! I have downloaded the file. I will try the patch shortly and let you know how it works for me. I will be testing mainly the addition of status effects on shotguns.

[natty_dread78]

Hello,
I have successfully tested your patch. The application of the patch was done very easily (I directly used an xdelta.exe in command line).
I tested the addition of the "blocked" status effect on shotguns, and then the addition of the "blocked" and "concussion" status effects.
Then I just kept the "blocked" effect (feels a bit OP otherwise), and played for about 2 hours.
I had 1 crash, but I don't think it is related to your mod. It happened when I quick reloaded in the middle of a "cutscene" (specifically when the pods attack people at the east greenhouse in AG, when they say they are in love with Kathy). We'll see if I have other crashes.
Next, I will change the valid mods on shotguns. Until now, I used the submachine guns modclass on them.
To summarize, the patch has been very successful for me so far. Thanks again for sharing!

[Executor_]

If you have further crashes, try scrolling down to the bottom of the output_log.txt file in the "\Steam\steamapps\common\Wasteland 2 Director's Cut\Build\WL2_Data\" directory immediately afterwards and see if it mentions any errors.

Regarding StatusEffects, "Blocked" is a stackable -1 action point debuff, so it seems balanced. "concussion", however, is only -1 to Awareness, and I don't believe NPCs actually have attributes, so they're unaffected. Personally, I'd change "concussion" to something like:

Code: Select all

{
	expires : true
	duration : 1200
	
	statEffects : [
		{statName : actionRechargeRate,  amount : -2} // combat initiative
		{statName : actionPoints,  amount : -1}
		{statName : chanceToHit,  amount : -5}
	]
}

which should be fine since it wouldn't stack (unless you change the stackable field to true).

[natty_dread78]

Ok, I'll make a copy of the output_log.txt file next time I have a crash.

Code: Select all

{
	expires : true
	duration : 1200
	
	statEffects : [
		{statName : actionRechargeRate,  amount : -2} // combat initiative
		{statName : actionPoints,  amount : -1}
		{statName : chanceToHit,  amount : -5}
	]
}

That is a very good idea, thxs! I'll experiment with that later.

[natty_dread78]

I tested the modding of the concussion status effect (effect applied on all shotguns), as follows:

Code: Select all

{
   expires : true
   duration : 40
   stackable : true
   
   statEffects : [
      {statName : actionRechargeRate,  amount : -1} // combat initiative
      {statName : actionPoints,  amount : -1}
      {statName : chanceToHit,  amount : -5}
      { statName : chanceToEvade, amount : -5 }
   ]
}

Everything works correctly (duration, stackable, statEffects). No crashes so far (but only ~1hour of play).
Next I'll test the valid mods on shotguns, enabling barrels, chokes, underbarrels and magazines. Now the open choke will be useful since it will be possible to negate the range decrease by the long barrel.

[Executor_]

Hmm, I think I didn't put enough checks around the code that disables the inXile logo movie. Shouldn't cause any crashes, but if PlayLogo is false in the settings.ini, then all movies will auto-cancel.

EDIT: OK, problem is resolved with patch_v0.8.1.xdelta. You'll need to download it from here or the updated link in the first post. Remember to restore to the original Assembly-CSharp.dll before applying the XDELTA patch.

[Executor_]

0.8.2 released, link to download

• fixed a probably quite rare crash bug related to my object database
• improved method for bypassing inXile logo movie, before it was merely mimicking a button press, now circumvents playing movie entirely (I've tested this quite extensively, but if anyone has trouble reaching the main menu, let me know and I can revert to previous method)
• some enums listed in the enums.txt weren't actually available for use in MSON files
• the deserializer (import) now ignores the case of fields, so pretty much everything in a MSON file should now be case-insensitive
• colon/ampersand order now ignored, ie. "&:" and ":&" considered equivalent
• portraits.txt now outputted to "Export" folder, listing all the built-in portraits
• can specify the folder for built-in portraits, though I only noticed a single minor differences, with "NPC/Wrecking Crew 2" vs "Male/Wrecking Crew 2" one being slightly more zoomed in, otherwise the portraits with the same name seem to be identical
  • if no portrait folder is specified, will default to "NPC/" folder, so the following works fine:

    Code: Select all

    {
    	portraitTexture : "Wrecking Crew 2"
    }

I'm currently working on getting the object database to update probably after each 'scene' (map) is loaded. Was intending to finish that prior to releasing the next version, but noticed the crash bug so decided to make sure a fix was available in case anyone was affected.

[Felis7]

Hello.
First thank you for this amazing work.
I have a question about modding, is it possible to mod skills in this game? and to alter the way armor works, like in this mod "AlterativeArmorSystem" http://www.nexusmods.com/wasteland2/mods/12/?
sorry for bad english)

[Executor_]

The game logic that determines how skills, traits (perks), armor, and everything else works is in the Assembly-CSharp.dll and hence really difficult to change. MSON files only allow altering the input values that the methods inside the Assembly-CSharp.dll use to produce an outcome.

I'll eventually get around to re-balancing the game, but for now I'm just trying to get everything related to MSON files working properly.

[Felis7]

I see, but MSON files for perks are exist, aren't there files for skills?
The only way to change formulas is to hex-edit Assembly-CSharp.dll? There won't be easier method?

And one more question) You prevously posted "Massive data dump", are this data files outdated? DropSet files don't match newly created.

[Executor_]

I see, but MSON files for perks are exist, aren't there files for skills?

The latest version of the modded game does output the Skill class to the classes.txt. If you take a look though, you'll notice there's very few fields in there. Skills are mostly logic spread across hundreds of methods in dozens of classes. There are, however, several classes which I intend to make moddable eventually called Table_ChanceToHit, Table_SkillDifficulty, Table_XPFromSkillUse, etc. They just store arrays with various values. For example:

Table_ChanceToHit

Code: Select all

		Table_ChanceToHit.columns.Add("brawling", new int[]
		{
			25,
			65,
			70,
			75,
			79,
			83,
			87,
			91,
			96,
			102,
			110
		});
		Table_ChanceToHit.columns.Add("energyWeapons", new int[]
		{
			15,
			50,
			55,
			60,
			66,
			72,
			78,
			85,
			92,
			100,
			110
		});

Table_SkillDifficulty

Code: Select all

public static int[][] levelTables = new int[][]
	{
		new int[0],
		new int[]
		{
			0,
			0,
			1,
			2,
			4,
			5,
			6
		},
		new int[]
		{
			0,
			2,
			3,
			4,
			6,
			7,
			8
		},
		new int[]
		{
			0,
			3,
			4,
			5,
			7,
			8,
			9
		},
...

The only way to change formulas is to hex-edit Assembly-CSharp.dll? There won't be easier method?

There are tools to make editing the Assembly-CSharp.dll easier. I can insert a new class of my own design without any difficulty. Some of the simpler innate game classes can also be re-compiled without issue. However, not everything de-compiles properly. The classes in the Assembly-CSharp.dll are littered with IEnumerable and IEnumerator methods which end up as special compiler-generated classes with convoluted code. Most .NET IL viewers will not de-compile this.

There is a tool that will de-compile the IEnumerable and IEnumerator methods around 97% of the way. It makes a few obvious mistakes that can be corrected without much effort, but it also at times leaves the odd line of code out. This is extremely dangerous. Because even if you can successfully re-compile the class containing the IEnumerable/IEnumerator, you don't know for sure that it's behaving exactly the same way as the original code without painstaking analysis of the resulting IL assembly or lots of in-game testing.

That is why I've confined myself to mostly inserting IL assembly when editing the innate game classes. I try to call a compiled method in one of the classes I added as soon as possible, because adding IL by hand is mind-numbingly slow work. A few lines of code in Visual Studio can be 10-15 lines of IL assembly which can take 10 minutes or more to insert into the DLL. You have to link every method and field reference used by looking them up yourself. If the existing method already contains local variables, and you want to insert another local variable ahead of them, you'll likely need to modify all the existing variable references. If you're adding IL around the location of a branch/switch target, you need to verify that the branch/switch was properly updated.

Most mistakes will promptly crash the game. Much more serious are those that don't. Then you don't know what's really going on behind the scenes and have no idea of the long-term consequences.

I'm not going to do anything to encourage this. People will start releasing "mods", secretly broken versions of the Assembly-CSharp.dll which don't crash very often but are corrupting data. Then everyone's going to stop using all the modified DLLs, including mine. I spend an inordinate amount of time testing, and even I can't guarantee nothing will slip through. I don't trust others to put in the same effort.

And one more question) You prevously posted "Massive data dump", are this data files outdated? DropSet files don't match newly created.

The output should be pretty much identical, except for enums being outputted slightly differently. The base game's deserializer (import) doesn't accept the "EnumName.EnumConstant" format, only "EnumConstant" (eg. "WeaponModClass.Shotgun" vs "Shotgun"). The modified game supports both, and I find "EnumName.EnumConstant" easier to read.

Besides exporting additional classes like Drama_Vendor, the only other change I can recall is that there was a small bug in the output of CNPCTemplates in the old "Massive data dump". The data in the hateDisplayNames field wasn't always quoted when it needed to be.

The "Massive data dump" wasn't complete and only contained the output for several maps. I recommend using the FullExport option in the settings.ini, since then you'll get the MSON files for objects in every map you load.

[Felis7]

thanks for the detailed answer.

[Executor_]

Updated 0.8.3 version now available: link

CHANGELOG

• Skills can now be edited (will be exported to "Mods/Export/BaseStat/Skill" folder if FullExport option turned on in settings.ini)
  • associatedAttribute by default is always "AttributeEnum.None", probably intentionally to disable the skill limit system
  • Skills can be limited by attribute score, from my limited testing, seems to function
    example:

    Code: Select all

    	associatedAttribute : AttributeEnum.Coordination
    	intLimits : [
    		{ intLevel : 1, allowedSkillLevel : 2 }
    		{ intLevel : 3, allowedSkillLevel : 4 }
    		{ intLevel : 5, allowedSkillLevel : 7 }
    		{ intLevel : 7, allowedSkillLevel : 10 }
    	]

• Tables can now be edited (will be exported to "Mods/Export/Table" folder if FullExport option turned on in settings.ini)
  • contain lots of key values for skills, armor, experience/levels, etc.
  • best to test thoroughly if you change the size of the arrays (Table_Leveling should be safe though)
    • the UI likely only supports 10 skill levels, though I haven't tried increasing it yet
  • you can confirm changes have been correctly loaded by looking in the "ExportImport" folder, assuming ExportAfterMSONOverride option in the settings.ini is turned on
    • might want to set OverwritePreviousExportImports to true as well
  • note that you can use '&:' to make small changes easier
    • indices automatically incremented for succeeding values unless an index is provided
  • examples:
    Table_ChanceToHit.mson

    Code: Select all

    {
    	// will only change the first, second, and eleventh elements in the array
    	// (arrays/lists use zero-based indexing, so first element has index 0)
    	bluntWeapons &: {
    		columns :& [ 0: 30, 40, 10 : 120, ]
    		critMultiplier : 3
    	}
    	// will retain entire original columns
    	smg :& { 
    		critMultiplier : 7
    	}
    }

    Table_SkillDifficulty.mson

    Code: Select all

    {
    	// using enums as array indices
    	levelTables_3 :& [
    		SkillLevelCategory.Medium : 6
    		SkillLevelCategory.Impossible : 11
    	]
    }

    Table_Leveling.mson

    Code: Select all

    {
    	rows :& [
    		50 : 141000
    		51 : 146400
    		52 : 151900
    		53 : 157500
    		54 : 163200
    		55 : 169000
    		56 : 2147483647
    	]
    	ranks &: [
    		30 : "<@>2nd Lieutenant", "<@>1st Lieutenant"
    		"<@>Captain"
    		"<@>Major"
    		"<@>Lieutenant Colonel", "<@>Colonel"
    	]
    }

• Deserializer (import):
  • fixed logic for whether to accept non-indexed values in arrays/lists
  • quoted strings could cause line numbers to be incorrectly tracked
  • fields of type non-UnityEngine.Object-derived class object that weren't arrays/lists of objects wouldn't actually get a value written to them as it was forgetting to update the field with a reference to the newly created object
  • deserializer should recover from errors better now
  • certain array/list fields now have a fixed-size based on what the base game expects
• Serializer (export):
  • Item property in structs now ignored (still have no idea where it comes from)
  • AIWeightTemplate layout and comments redone
    • if you have FullExport on, might want to delete the existing ones in the "Mods/Export/AIWeightTemplate/" directory so they get re-exported
• OverwritePreviousExportImports option added to settings.ini
• inXile log now outputted if DebugMode is true in settings.ini; contains messages from the base game
• loading portraits from the "Mods/Import/Portrait" folder wasn't working in 0.8.2 as it wasn't providing the full path
• very rare NullReferenceException should no longer appear in output_log.txt
  • eg.

    Code: Select all

    NullReferenceException
      at (wrapper managed-to-native) UnityEngine.Component:get_gameObject ()
      at CHA_AttributeEditor.OnDestroy () [0x00000] in <filename unknown>:0

  • at first I thought I might've caused it, so I re-inserted all my changes into the original DLL, yet still saw it happen once in a while
  • took a look at the CHA_AttributeEditor.OnDestroy() code, and it uses two fields (plusButton and minusButton) but only did a null check on one of them
  • inXile probably didn't bother to fix it since it happened only rarely and I think the code is only called when the game is being exited anyway

[spectrefps]

Awesome work! I have used this to make some tweaks to some of the Heavy Weapons and related perks to make them more competitive with ARs. However, I seemed to have hit a wall when it comes to implementing a custom StatusEffect (as opposed to simply changing/overriding a pre-existing one). The custom status effect is custom_MG_sap.mson (located in Import/StatusEffect) and is a full copy of AllTiedUp.mson with some specific stat value changes (for chanceToHit, combatSpeed, ActionRechargeRate).

I have the following lines in one of my Machine Guns that I am testing this with:

Code: Select all

percentToApplyStatusEffect : 99			// set high for testing purposes
statusEffect : [ custom_MG_sap ]		// custom status effect file located in the \Import\StatusEffect folder

This fails to apply the status effect to the weapon, and produces this line in debug_import.txt:

Error [Line 23 at 'custom_MG_sap'] Could not find an object of type StatusEffect named 'custom_MG_sap'.

I took a look at the custom object reference variations in the InXile WL2 modding guide and tried the following variations, with no luck:

Code: Select all

custom_MG_sap.mson					// error: cannot find object
@"custom_MG_sap.mson"					// error: cannot find object
@"StatusEffect\custom_MG_sap.mson"		// error: invalid character in name (assuming it's the "\") 
@"StatusEffect\custom_MG_sap"			// error: invalid character in name (ditto)
@"StatusEffect.custom_MG_sap.mson"		// error: cannot find object

Been at this for a few days now, no progress so far. Anything I'm missing with this? Your patches work like a charm for modifying practically ANY of the core assets. Could it simply be that the game just won't recognize any status effect files are not specifically overriding existing ones (in some hardcoded list)?

Id appreciate any insight you have on this, as your knowledge of the game's data structures (especially for modding purposes) is very impressive to say the least!

[sear]

I just want to chime in and say that I think it's super cool for you to be doing this. I'm not a programmer, so I won't pretend I know the details on that end, but we're always excited to see what players cook up with respect to mods.

[Executor_]

Been at this for a few days now, no progress so far. Anything I'm missing with this? Your patches work like a charm for modifying practically ANY of the core assets. Could it simply be that the game just won't recognize any status effect files are not specifically overriding existing ones (in some hardcoded list)?

Yeah, it won't work. It's actually something I've been working on since the initial release of the modded game, but I got distracted the past few days while I got the Tables editing working. The base game only supports adding new ItemTemplates and DropSets, as they're the only ones that have a FromString method written for them. Adding DropSets might still function in the modded game right now, new items probably not.

I intend to get ItemTemplates and DropSets working again in the next major release, as well as being able to add new StatusEffects and Traits. Although the latter two might be really easy to enable, so I might do an interim release just for them.

Also, this reminds me of one of the items on my long todo list: write an issues list!

NOTE: Full 0.8.3 patch changelog now available; post has been edited above.

[Executor_]

0.8.4 now available (link)

CHANGELOG

• new StatusEffects can now be added to the game
• new Traits can now be added to the game (screenshot)
  • good example of subTraits and requiredTraits usage can be found at "Mods/Export/BaseStat/Trait/Trait_CarefulHunter/Trait_PreciseHunter.mson" if you have FullExport turned on in settings.ini
• refer to mod-created objects like you would any other UnityEngine.Object, ie. just the filename, without extension (ie. ".mson") and no folder path, in quotes if there's a space in the name
• will need to provide a full MSON file for a new object, as every important field will need to be filled
• make sure new objects are placed in the correct folder, as the game will crash otherwise
  • I haven't written enough checks yet so it'll create a blank placeholder object then a while later try to override it and won't be able to find the MSON file if it's in the wrong directory
• Table_PCStats now also available for editing, will be exported to "Table" folder like the rest of them
  • has leadership, chaBonusPercent, and barterSkillLevelPriceAdjustment fields
• requiredStatValues field in overrided Traits probably wasn't doing doing anything before
• 0.8.3 likely wasn't exporting portraits.txt when it should've

[spectrefps]

Just read the update notes, amazing work yet again! And thanks for the fast response to my previous issue, read it at work but didn't get a chance to respond until now. Thought I was messing up the file/folder-reference syntax until I read your response. Now to get to work making some new traits for SMGs and Shotguns (to bring them to par with my machineguns of doom XD). Once again, amazing job with your updates! Definitely breathing new life into WL2 (and enabling so many modding possibilities)!

[Executor_]

Just tested and object inheritance (ie. copying an existing object) seems to work. It's an alternative to a MSON file for a new object with every field provided.

Examples:
Mods/Import/StatusEffect/adrenalineShot - Copy.mson

Code: Select all

adrenalineShot : {
	displayName : "<@>Adrenaline Shot II"
}

Mods/Import/BaseStat/Trait/Trait_AdrenalineRush/Trait_AdrenalineRush - Copy.mson

Code: Select all

Trait_AdrenalineRush : {
	displayName : "<@>Adrenaline Rush - Improved"
}

Sequence of events is:

1. Built-in StatusEffects/Traits loaded
2. Placeholder objects created for any StatusEffect/Trait MSON whose name doesn't match one of the above built-in ones
3. Object database created
4. MSON overrides applied

Since the built-in StatusEffects/Traits are added to their lists first, they'll get their overrides applied before any mod-created objects inherit from them.