BMac

The patch notes that were released should be comprehensive or very nearly comprehensive. We only integrate very specific fixes into the hotfix patches to avoid causing new problems. It would take me a bit of time to track each change and see if anything else was integrated, which I probably won't do since v2.1.0 is coming out soon as you said. Strings are an exception. There may be a number of changes to strings in any patch, including v2.0.1, but I also don't have a good way to track those and list them out. I imagine you could diff the stringtables from the previous and current versions against each other if you needed that information.

It looks like it's because you've put "{0} Health" inside a link, but the {0} can also contain a link (to trigger the breakdown tooltip). Links inside of links cause either TextMesh Pro or the glossary link inserter to break. You should make sure the {0} part is not inside your manual glossary link, or use to disable the glossary link inserter inside your manual link.

That's pretty cool. Both of those should be pretty straightforward (though they probably won't be a high priority).

I didn't post patch notes here for 2.0.1.0044 because there are no modding or data changes in it. That patch was only a hotfix to address important bugs.

I don't think you'll be able to add a new race or subrace at the moment. There are a number of things that are based on the enumeration, which you can't easily modify.

You should be familiar with the Modding Basic Concepts tutorial before following this one. In this tutorial, I'm going to show you how to use a ModScriptHookGameData object to add a new item to a store or other inventory in the game. ModScriptHookGameData is a new game data type that was added in v2.1.0. It contains a set of scripts that will be run each time the player enters a scene in the game. This is a good way for a mod to make alterations to the contents of scenes with your mod. Here's an example game data object I created for this tutorial: { "GameDataObjects": [ { "$type": "Game.GameData.ModScriptHookGameData, Assembly-CSharp", "DebugName": "Metalworks_ItemAdd", "ID": "417f4f5e-7d01-4cd6-aa9d-1f0b1d0b4be2", "Components": [ { "$type": "Game.GameData.ModScriptHookComponent, Assembly-CSharp", "RunOnlyOnce": "false", "SucceedOnlyOnce": "true", "Script": { "Conditional": { "Operator": 0, "Components": [ { "$type": "OEIFormats.FlowCharts.ConditionalCall, OEIFormats", "Data": { "FullName": "Boolean IsInActiveScene(Guid)", "Parameters": [ "3f84e9ad-761d-47fa-9e38-7a492ff24b95" ] }, "Not": false, "Operator": 0 } ] }, "Scripts": [ { "Data": { "FullName": "Void GenerateLootListInto(Guid, Guid)", "Parameters": [ "3f84e9ad-761d-47fa-9e38-7a492ff24b95", "f3a0a676-c69c-46b2-9a9e-8bae94fae19a" ] }, "Conditional": { "Operator": 0, "Components": [] } } ] } } ] } ] } This is a pretty straightforward object, with only three properties: RunOnlyOnce - if "true", this script will only be run one time ever in a player's game. SucceedOnlyOnce - if "true", this script will be run on each scene load until the Conditional component of the script succeeds, then it won't be run again. Scripts - a Conditional to check, and Scripts to call if the Conditional passes In my example object, I have one conditional IsInActiveScene(3f84e9ad-761d-47fa-9e38-7a492ff24b95), checking if a certain object is in the active scene, and one script GenerateLootListInto(3f84e9ad-761d-47fa-9e38-7a492ff24b95, f3a0a676-c69c-46b2-9a9e-8bae94fae19a), which generates my custom loot list (not shown) into that object's inventory. I've set it to SucceedOnlyOnce, so once my items have been generated into that inventory, they won't be duplicated if I come back to the scene later. How can you find the GUID of the object you want to modify? If the object is visible in the scene, hover your mouse over it and enter "PrintInstance oei_hovered" into the console. This will print the GUID in the combat log and copy it to the clipboard. If the object is not visible in the scene, you can search for it by name with the console command "FindObject". For example, "FindObject Store" will output to the combat log all objects with the string "Store" in their name. You can then copy down the GUID manually or copy it to the clipboard with PrintInstance (e.g. "PrintInstance Store_05_Marihi"). That's all it takes to insert your custom items into the game without fear of conflicts with other mods. For a list of available scripts and conditionals, see the documentation: scripts, conditionals.

That approach is right. Yes, mods that alter the same loot list will clash and only one will win. That won't invalid any of the other loot lists you modified - they'll still have your item in them. I'm hoping to devise a way to allow lists on game data to merge and not clash, but we'll have to see what we can do. I've added a new structure for v2.1.0 that you'll be able to use to add items to particular inventories in the game (for example, a particular shop) that will avoid clashes altogether. However, you'd still want to modify loot lists in the way you describe if you were trying to add an item generally to loot throughout the game (for example, adding a new potion to the general potions loot lists).

We don't allow soulbound items to be enchanted at all. That's because all the mods on them are assumed to be from leveling up, and if you unbind the item, it wipes all mods and re-adds the default ones. Replacing the item with a non-soulbound one that can be enchanted would work. Some enemies can drop their inventory and equipment when they die (in addition to any loot lists they are assigned). That flag prevents certain items from ever dropping this way. I think it's mostly used for stuff like creature armor and weapons that the player isn't supposed to see, ever. That's a macro file that we use to run a bunch of BindCommand calls to do thing we use for debugging. It gets removed from the release build. I'll put in a bug report for that.

This is a list of changes from 2.0.0.0029 to 2.1.0.0034 that specifically affect modding the game. Thanks for your feedback and suggestions - we'll continue to implement more of these in the future. The patch notes for other changes to the game can be found here. Modding Patch Notes for 2.1.0.0034 Added a new game data type ModScriptHookGameData, which can be used make some modifications to scenes with a mod. For more information, see this tutorial. Mod data that doesn't affect gameplay (atlases, portraits, strings, images) will be loaded when playing God Challenges Mods will not be marked as Incompatible unless a game version since the mod's Max Version is marked as breaking Added support for loading portraits from mod override folders. The portrait images just need to be in '/gui/portraits/player/male' or '/gui/portraits/player/female'. Added support for uploading and consuming mods via the Steam Workshop. For more information, see this guide. The game will now load *.globalvariablesbundle files from mod folders. (Breaks Enchant UI) Added PrerequisiteItemMod, CostByValueMultiplier, Double2HIngredientCost to RecipeComponent Items no longer must have an existing item mod on them to be enchanted PrintInstance console command copies the printed GUID to the clipboard Added InverseHealth to StatusEffectValueType enum Added FogRevealRadiusBonus to StatusEffectType ProjectileCountMult status effect now works with the AttackFilter Added TargetType to StatusEffectAttackFilter Added conditional scripts IsUnarmed, IsEquipmentWearEnabled, IsImmobile, IsUnique Added scripts FadeInChildGameObjects, FadeOutChildGameObjects, EncounterStartWave Added BindConditions to SoulbindComponent Added CopyOwnerAbilities to AttackSummonComponent Added DualWeaponFullAttackDamageMultiplier to CombatSettingsComponent Added Prefab to CompanionComponent Added EnableEquipmentWear, FogRevealRadiusBonus, WellLitFogRevealRadiusBonus to GodChallengeComponent Added IsWellLit to MapDataComponent Added IsJunk to ItemComponent Added DurabilityDamage to ItemModComponent Added ItemRepairSettingsComponent Added ActivationPrerequisites, MustDieForCombatToEnd to SigilComponent (Breaking) Renamed MaterialReplacementComponent.OnlySkinnedRenderers to SearchSkeleton (Beta Bug) Fixed empty game version numbers in mod manifests breaking loading (Beta Bug) Fixed new game data objects from mods sometimes being incorrectly unloaded

It looks like there was a bug with how the character creator was fetching the sprite. That'll be fixed for v2.1.0. I don't think I'll be able to justify rearranging the flow of character creation for the sake of mods. It's a lot of work and I believe it was laid out that way for user experience reasons. That would be reasonably straightforward.

Yeah, that comment was out of date, I've updated it for v2.1.0. A better way to achieve this might be to create a global variable and set it when the player has acquired the item (via a SetGlobalValue script on a DataScriptEventComponent attached to the item's data). You can then check the variable to know if the player has got the item yet, no matter what they did with it. You'll be able to add new global variables in v2.1.0. I think it would be tricky to do this with global variables since they are, well, global. So you'll have trouble distinguishing whether one character or different characters are wearing the set pieces. The way we'd probably do it internally would be to have each set piece apply a hidden marker status effect, each with a unique custom keyword MySet_Helm, MySet_Armor, etc. Have one of the items grant a custom passive ability that applies the set bonus, with ActivationPrerequisites checking that the character has all the keywords (HasStatusEffectWithKeyword checking Owner).

In v2.0.1, an item has to be Unique, have at least one item mod on it, and not be Soulbound to be enchantable. In v2.1.0, items will no longer need to be Unique to be enchanted; they'll just have to have an applicable visible recipe that can apply to them.

It looks like you're missing some closing brackets "]}" in your gamedatabundle. If you open up PillarsOfEternityII_Data/output_log.txt after launching the game, you might be able to find a helpful error message pointing out errors like this.

EnchantCategory is essentially irrelevant in Deadfire; it's left over from Pillars 1. The only one that matters is Quality - quality mods will remove any existing quality mods when applied.

Perhaps it should be noted here that you can add new languages via override folders in v2.0.0.

Yeah, that seems like a useful addition and not too hard to implement. Yay! As far as I know it should be doable right now to create custom summon attacks that summon existing monster prefabs. If you start or bump a thread for this with an attempt I might be able to investigate. That's another feature that I'd definitely like to have, but the data is in Unity files. It may be possible for us to write another system to allow insertion of objects into existing scenes, but that would be a moderately significant undertaking. Good idea, should be fairly easy to implement. Ditto. I'm not sure about the feasibility of this offhand. I'll have to look into it if I have time. Sounds like a bug; I'll report it to the appropriate person. Should be pretty easy to add. I believe you can approximate this now by setting IsQuestItem to true. Importing models from the previous game is still a decent chunk of work, since we've switched to a completely new PBR render pipeline; all the materials need to be recreated by an artist. Sadly, I don't think I'll be able to get any artist time for this.

Thanks for creating this thread, it should be very helpful to keep all these things in one spot! There's a lot here already - I'm just going to try to give my initial comments on each suggestion to set expectations. We could probably add this, I'd probably implement it as a StatusEffectType like BonusQuickSlots or BonusWeaponSets. This would of course be really great to get working, but the scope for us is pretty massive and I have to admit it's unlikely that we'll add any built-in support for this in Deadfire. This is coming in v2.1.0. The item 'Hunting_Bow_U_Animancer' summons hostile creatures, so this should be possible. Check out how that's working. This isn't really a caching issue, it's a side-effect of how vendor inventories are generated. It's probably possible for us to do something to make this workflow better. Unfortunately there's no data that controls when certain scripts can be used; it depends entirely on what that script decides to do behind the scenes. Someone would have to document them manually, which I don't believe we'll have to time to do. Hopefully it's usually pretty intuitive (ShipDuel scripts only work in ship duels, etc.) UIs live almost entirely in Unity data, so unfortunately it's pretty unlikely that we'll be able to easily expose the data. It could be done without our support, but you'd have to do some DLL rewriting like the IE Mod on Pillars 1. There's probably a way to extract those images from the Unity data with the usual tools. They're probably in the MasterUI data (PillarsOfEternityII_Data/level2).

The issue is caused by savegame file corruption. The original cause of the problem may have been fixed in v2.0.1. Unfortunately, the data on the affected companions is irrecoverable. I've added a fix for v2.1.0 that will recreate the affected companions from scratch, but you'll still be missing any items they had, and you'll have to respec to restore your build.

It looks like the files for those companions have been corrupted in your "B" savegame. The bug that caused the corruption was probably fixed in v2.0.1. In this case I can repair that save if that would be useful to you.

This is a good idea. I wanted to add in that you can also bind hotkeys in the vanilla game with the console command bindcommand "", where is any other console command and is a Unity KeyCode with optional prefixed modifiers (e.g. Ctrl+Y). You can concatenate multiple commands with & (e.g. "givemoney 3000 & giveitem Sword"). It can't do all the things you've done here, but it could help accelerate common tasks.

I got you after the stream yesterday: https://www.nexusmods.com/pillarsofeternity2/mods/189

This will be fixed in 2.1.0. Good catch!

I think I accidentally misled you. That particular event (OnInspected) doesn't fire when the attack is launched. It fires when the attack is opened in the inspection window. DataScriptEvent doesn't currently provide an event for when the attack is launched.

Yep, that looks correct from my cursory inspection.

No, that component can only trigger scripts on the events available in the DataScriptEvent enum (which would only be OnInspected for an Attack).