fireundubh

Inventory sorting should persist Merchant buy screen should display item quantities (regardless of item types) in inventory Ability to throw melee weapons Ability to disarm, pick up, and lay mines Ability to toggle off companion helmets while not in combat Ability to slide by running and then crouching Ability to climb ladders at any point on the ladder Ability to toggle dynamic tessellation/LOD/texture resolution (sounds related to InstaLOD or DX11 distance-based tessellation; the distance is too short so you get obvious pop-in issues) Ability to configure the quality of individual screen effects Smoother movement over rocky terrain 21:9 support (without zooming) and 21:9 performance optimizations Windows Store version: Support for ModifiableWindowsApps folder Modding support: more exported JSON bundles please Modding support: uncompressed PAK files

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...

To rank up a disposition, the player must achieve the following number of points: Rank 1 = 4 points Rank 2 = 12 points Rank 3 = 25 points Rank 4 = 45 points These thresholds are far too low relative to the number of opportunities to receive disposition points. In conversations, there is an average of 233 total calls to DispositionAddPoints for each disposition. Using the change strength values in the related issue linked below, those calls roughly offer an average of 952 total points for each disposition—not excluding branching/closed-off choices. (These averages are based on raw totals.) Given the number of these opportunities, the change strength values, and the low rank thresholds, the player easily and quickly levels dispositions to max rank early on, which cheapens the disposition system. The player could very well max out every disposition by the end of the game. Related issue: Minor and Average disposition choices reward same disposition points

When choosing dialogue options that reward disposition points, the player receives the same amount of disposition points regardless of whether the choice should reward a Minor or Average number of points, ultimately rewarding more disposition points than intended. This issue is the result of the Minor and Average change strength components having the same value (4). The Minor change strength value should probably be set to 1. { "$type": "Game.GameData.ChangeStrengthGameData, Assembly-CSharp", "DebugName": "Average", "ID": "71c858fe-7c4b-432a-a105-c518319eaed7", "Components": [ { "$type": "Game.GameData.ChangeStrengthComponent, Assembly-CSharp", "ChangeValue": 4, "DisplayName": 1783, "FormatString": 1298 } ] }, { "$type": "Game.GameData.ChangeStrengthGameData, Assembly-CSharp", "DebugName": "Major", "ID": "e19a6f92-2165-4e34-be10-c65e8de970eb", "Components": [ { "$type": "Game.GameData.ChangeStrengthComponent, Assembly-CSharp", "ChangeValue": 8, "DisplayName": 1784, "FormatString": 1299 } ] }, { "$type": "Game.GameData.ChangeStrengthGameData, Assembly-CSharp", "DebugName": "Minor", "ID": "54772c0d-cf3f-4589-8cab-9f3601d575c2", "Components": [ { "$type": "Game.GameData.ChangeStrengthComponent, Assembly-CSharp", "ChangeValue": 4, "DisplayName": 1782, "FormatString": 1297 } ] },

No, the results would not be skewed. The IsAttributeScoreValue function requires a character parameter (GUID). These tables break down checks for the Watcher and other characters. The IsSkillValue function requires both a character parameter and a party assist parameter (bool). These tables differentiate between Watcher-only and party-assistable checks. IsAttributeScoreValue checks do not support party assist.

I don't understand what you're asking. How would I get the data without mining the tables? As for completeness, the answer is no and that's intentional. You can find a complete table of script calls with parameter substitutions here.

I created a unique dialogue options report/statistical breakdown for Deadfire: https://wiki.fireundubh.com/deadfire/dialogue-options This is a follow-up to my Eternity/White March breakdown from last year.

I'm reading a GDC postmortem of Pillars of Eternity by Josh Sawyer. One of the slides says that the "stronghold had limited time for content" and another slide about game mechanics lessons for the future says "focus on stronghold content and integration." So, here's hoping they do that for Deadfire; after all, Deadfire starts out with Caed Nua obliterated. Unfortunately, I don't think they'll be doing any big content updates for Pillars of Eternity since the majority of the team is on Deadfire - despite the post-launch support slide saying one of the goals is to "focus on restoring some of the lost ingredients," including "stronghold content." Maybe they already did and I'm late to the party?

Well, 12 of the 15 in Eternity are part of the Cilant Lîs brazier-trap puzzle: "Flames kindle swiftly in the brazier, winding their way upwards." "[Touch your fiery hair to the brazier.]" And I believe you see that dialogue only once (<Persistence>MarkAsRead</Persistence>). Another node is shared with Moon Godlike, Nature Godlike, and Snow Elf. So, subtract 11+1 and you get a number that's in line with the others.

Added IsCompanionActiveInParty checks! A few temporary "companions" are included because they're classed as companions in the decompiled sources. Fixed an issue in the XML-to-JSON exporter where nodes were not properly grouped by file, resulting in duplicate data structures and inflated counts. The counts should be as accurate as possible at this point. I say "accurate as possible" because some conversations where checks appear in search do not have corresponding string tables, so they're not counted. The assumption is these checks are either unused or don't contribute to the "unique dialogue" experience. Aside: There is an IsCompanionActiveInParty check for Calisca much later in the game, but the conditional also checks for other companions as well, so that dialogue will always be shown. This really only means Calisca has one more IsCompanionActiveInParty check than she should. Also, here's a funny thing: when you escape the biawac at the start of the game, if only one companion survives, "there is a deep resonance to the wind," but if two companions survive, "there is a deep resonance to the swelling wind." Big difference! ... Don't get too caught up in the numbers when creating a new character. I plan to add support for a few more conditional functions and break down the parameters further, so you can see things like how many options grant Major disposition points or require different attribute scores, and then I'll move on to exploring the possibility of a visual conversation editor.

I'd like to have been able to recruit various unique characters throughout the Endless Paths to work in the keep. Bring them up from the depths as allies who either add security or prestige, defend the keep during invasions, or offer services as either merchants or companions. The "capture prisoner" system could have used some love, too, and along those lines above, it would have been cool to capture some unique side-quest NPCs and release them with an offer to work off their (very long) sentence in the keep. And perhaps an arena system where you could capture animals and creatures, and send prisoners to fight in battles for their freedom - or entertaining and profitable deaths. So many possibilities for the stronghold... but the stronghold and Endless Paths were mostly stretch rewards and not enough money was raised to fully build out either the stronghold or the Endless Paths. I remember the 99-level "Ancient Cave" in Lufia II. That was amazing. I was somewhat disappointed the Endless Paths spanned only 15 levels, but at least the Endless Paths are more featureful with non-random levels and a bit of story.