fireundubh

I updated the raw data. Probably not going to update the tables because that takes days manually.

There are some conversations that will trigger only when certain companions are in your party.

Awesome find!

Yeah, I'm aware of this but sadly, this mod needs to change "MaxLevelAdjustment" value for each character, that is 1748 modified objects in total. It would be pointless to create a separate file with so many modified objects so I need to find a way how to extract just the "MaxLevelAdjustment" object. I was not successful yet. MaxLevelAdjustment is a property of the CharacterStatsComponent. You can't extract just that object. I'd just copy over the 1,748 modified CharacterStatsGameData objects to a new file. There's a lot more data in characters.gamedatabundle than just CharacterStatsGameData, so you're overriding all these: Game.GameData.AmbientAnimationGameData Game.GameData.BackgroundGameData Game.GameData.BaseStatsGameData Game.GameData.BestiaryEntryGameData Game.GameData.BloodGameData Game.GameData.BoneMapperGameData Game.GameData.CapeCharacterCollidersGameData Game.GameData.CharacterClassGameData Game.GameData.CharacterStatsGameData Game.GameData.CharacterSubClassGameData Game.GameData.CompanionGameData Game.GameData.CompanionManagerGameData Game.GameData.CreatureRigTypeGameData Game.GameData.CreatureTypeGameData Game.GameData.CultureGameData Game.GameData.DebugPartySetupGameData Game.GameData.DestructibleGameData Game.GameData.EquipmentSetData Game.GameData.GenderGameData Game.GameData.MoverGameData Game.GameData.NPCAppearanceOptionsGameData Game.GameData.OVSGameData Game.GameData.PaladinSubClassGameData Game.GameData.PersonalityGameData Game.GameData.PriestSubClassGameData Game.GameData.RaceGameData Game.GameData.SigilGameData Game.GameData.StealthDetectionGameData Game.GameData.SubraceGameData Game.GameData.TopicGameData Game.GameData.TopicWeightGameData Game.GameData.VisualStateAnimationGameData Game.GameData.VisualStateNameGameData

Hate to cross-post, but this mod needs to be repackaged. There's no reason to distribute the entire characters.gamedatabundle. Place the modified objects into a new .gamedatabundle file. Otherwise, this mod is incompatible with every mod that changes any of the objects in characters.gamedatabundle, as well as future patches. There's no way to manage load order, currently, so it's also needlessly difficult for other modders to check for incompatibilities.

No, both 1.0.2 and the CDP set the Minor change strength value to 1. The CDP does this in data while the 1.0.2 patch hardcodes it for dispositions only. However, as Josh noted in a recent livestream, the CDP also slows down reputation gain and relationship gain because the disposition, reputation, and relationship systems all use the same Minor, Average, and Major change strength data. This thread is about hopefully convincing OEI to make these systems use different Minor, Average, and Major change strength data, so they can be properly tuned and balanced separately.

My approach to circumventing the work required to execute #4 would probably look something like this. Code: private static readonly IList<KeyValuePair<Guid, Guid>> ChangeStrengthMap = new List<KeyValuePair<Guid, Guid>>() { new KeyValuePair<Guid, Guid>(new Guid("54772c0d-cf3f-4589-8cab-9f3601d575c2"), new Guid("d41180a5-fb16-4b07-996c-dc73ea45ca2c")), new KeyValuePair<Guid, Guid>(new Guid("71c858fe-7c4b-432a-a105-c518319eaed7"), new Guid("122f590f-e442-4919-a247-454158c99032")), new KeyValuePair<Guid, Guid>(new Guid("e19a6f92-2165-4e34-be10-c65e8de970eb"), new Guid("933f3c6c-813a-45f3-9d05-0e3137a8380a")), }; public void ChangeDisposition(DispositionGameData disposition, ChangeStrengthGameData strength) { // ... Guid strengthNewGuid = ChangeStrengthMap.First(l => l.Key == strength.ID).Value; ChangeStrengthGameData strengthNew = ResourceManager.GetGameDataObject(strengthNewGuid) as ChangeStrengthGameData; int changeValue = strengthNew == null ? strength.ChangeValue : strengthNew.ChangeValue; Dictionary<DispositionGameData, int> dispositions; (dispositions = this.m_dispositions)[disposition] = dispositions[disposition] + changeValue; // ... } GameDataObjects: { "$type": "Game.GameData.ChangeStrengthGameData, Assembly-CSharp", "DebugName": "Minor Disposition Change", "ID": "d41180a5-fb16-4b07-996c-dc73ea45ca2c", "Components": [ { "$type": "Game.GameData.ChangeStrengthComponent, Assembly-CSharp", "ChangeValue": 1, "DisplayName": 1782, "FormatString": 1297 } ] }, ... You leave the base ChangeStrengthGameData objects alone; add 9 more objects for Disposition Change, Reputation Change, and Relationship Change; and map the base object UUIDs to the new ones when calling DispositionAddPoints, CompanionAddRelationship, and ReputationAddPoints. OEI wouldn't have to change any dialogue options or modify the OEI Tools editor, and designers (and modders!) can modify point gains for dispositions, relationships, and reputations individually all in data, which allows designers/modders to maintain separate progression curves for each system. I have the disposition component of this approach working in a Patchwork mod, but I have no idea how to modify static constructors in the Patchwork framework, so I can't build the mod with support for the Game.Scripts class. In any case, this would be better done on OEI's end given the internal value.

In factions.gamedatabundle, the change strength amounts and disposition rank thresholds were unchanged. In fact, 1.0.2.89 did not change any game data except localization and some conversations. What the 1.0.2.89 patch did though was hardcode the Minor change strength value for ChangeDisposition. Disposition.ChangeDisposition() - 1.0.1.64 vs. 1.0.2.89 This value can no longer be overridden by mods (for dispositions), at least not without using the Patchwork framework. This isn't a major issue, but this approach makes changing this value (for dispositions) unnecessarily difficult. Changing the Minor change strength value to 1 in data would have the same result without the aforementioned consequences. edit: Actually, that's not correct because ChangeDisposition isn't called for faction reputation and companion relationships. Duh! A better approach would be to: Create disposition-only Minor, Average, and Major change strengths with their own UUIDs. Create faction-only Minor, Average, and Major change strengths with their own UUIDs. Create relationship-only Minor, Average, and Major change strengths with their own UUIDs. Update all instances where the old Minor, Average, and Major change strengths were used. This would give designers more control, allowing them to tune and balance disposition, faction, and relationship gains separately, rather than trying to find magic numbers that can be shared between all three systems. Alternatively, hope magic numbers work and set the Minor change strength value to 1 in data. edit: Thinking on it a bit more, to get around having to do #4, you could map the old UUIDs to the new ones for DispositionAddPoints, ReputationAddPoints, and CompanionAddRelationship, so that when each method is called with a particular strengthGuid, the game uses the right individualized change strengths. I know this patch wasn't the disposition rebalance patch, but I just wanted to point out that the rank thresholds still need to be increased. The Deadfire rank thresholds are around 50% what they were in Eternity 1 despite there being 200-300% more DispositionAddPoints calls in Deadfire.

https://www.nexusmods.com/pillarsofeternity2/mods/14

I don't know what they changed exactly yet, but they did not make any changes to the ChangeStrengthData or DispositionGameData objects, so the Minor/Average/Major change strengths and rank thresholds are unchanged.

Awesome! Thank you for the heads-up. edit: I see it now! case Portrait.Style.ConversationLarge: return (!this.m_textureConversationLarge) ? this.m_textureLarge : this.m_textureConversationLarge; case Portrait.Style.ConversationSmall: return (!this.m_textureConversationSmall) ? this.m_textureSmall : this.m_textureConversationSmall;

In PyCharm, you just press Ctrl+Alt+L. Note that some of the JSON files are not formatted correctly to begin with, so it's useful to have an IDE, like PyCharm, that will highlight the errors so you can fix them before trying to pretty print them. The JSON library that OEI uses is a lot more tolerant of these errors than pretty printers, so they're not issues in the game.

dnSpy.

Looking at how conversation textures are loaded: private void LoadConversationSmallTexture() { if (!string.IsNullOrEmpty(this.m_textureConversationSmallPath)) { this.m_textureConversationSmall = Portrait.LoadTexture2DFromPath(this.m_textureConversationSmallPath, 76, 96); } this.NotifyChanged(); } I'm not sure what happens when m_textureConversation[small|Large]Path is empty, but if it is empty, it would be preferable to fallback to m_texture[small|Large]Path, so that we can create large and small portraits without worrying about also creating large and small conversation portraits. In other words: private void LoadConversationSmallTexture() { string texturePath = string.IsNullOrEmpty(this.m_textureConversationSmallPath) ? this.m_textureSmallPath : this.m_textureConversationSmallPath; this.m_textureConversationSmall = Portrait.LoadTexture2DFromPath(texturePath, 76, 96); this.NotifyChanged(); }

Suddenly my threads were merged into this singular one, and this thread can't be found in the forum... Just set up an external bug tracker, Obsidian...