BMac

Attributes are capped at "MaxAttributeScore" (global gamedatabundle, default 35) after all bonuses. I don't believe there is any level cap for non-player characters.

There's a conditional called "Boolean IsCastingWithPrimaryAttack(Guid)" that might be what you're looking for. The parameter should be the attacking character. There's also "Boolean IsFullAttack(Guid)" (same parameter). I'll make a note to write up some more info about the available scripts and how to use them.

I think that conversion rates table only applies to focus granted by an AddResources status effect. Unfortunately, it looks like starting focus is hardcoded to 1/4 of the max, and the max is also hardcoded as 20 + 10 * Level. I'll note that we need to expose those numbers. You could increase the max Focus by a fixed amount, but you'll need to do something a bit more hacky. You could create a new status effect of type "MaxFocus" with the "Value" you desire, and add that status effect to the "Soul_Whip" ability (on its "StatusEffectsIDs" list). EDIT: These values have been added to FocusTraitComponent in v1.2.0.

To make party members always die immediately when downed, you can just change "MaximumInjuriesBeforeDeath" in the global gamedatabundle to 0. To add a random chance for this to happen, I think you'll have to get a little crazy. Our status effect system is very powerful and can be used to do a lot of nonsense like this if you dig into it. You could: Make a new passive ability that applies a custom status effect that triggers with "EventType":"OnUnconscious" (search for "ApplyStatusEffectOnEvent" to find some effects that do similar things). This effect would apply (via "StatusEffectsValueIDs") a second custom effect. This second effect would have a "ChanceToApply" value of your choice and effect type "AddInjury", applying several more injury effects to the character (also using "StatusEffectsValueIDs"), probably killing them. You may need to apply more injuries than you expect because they will not stack with existing injuries of the same type; you could instead create and use a new injury that can stack by setting its "MaxStackQuantity". Injuries are identified by giving them one of the "Injury" keywords (these are in the gui bundle). You can make all party members have the new passive ability by adding it to the "PT_Racial" progression table (search for "047aa1b8-0f46-460c-ab27-6196c5ba25d5" to see how that's done).

It's probably worth mentioning that you can probably use any of the tags listed on this page with the game's text. I'm not sure why it didn't occur to me to share this until now, hah.

Since Energetic is from a DLC, its vanilla data appears in a bundle in a different folder (PillarsOfEternityII_Data/laxb_exported in this case).

I took care of this for the next patch (1.1.1, I believe).

You can just set them to 0 and the game will automatically calculate them on startup.

This has been fixed for the 1.1 release.

Thanks for the report! It doesn't look like this is a new bug to 1.1, but I've added it to the database for the next patch.

I only took the blocks of code(or whatever its called) that I edited within, I didn't need to copy the whole file to make it work. (I took the code related to recovery and reload that I wanted to edit; in the end mod file ended up 3411 lines(for 29 edits in it) but the original attacks.gamedatabundle file has 240252 lines). What didn't work was combining code from another original file with it, I had to make 2 separate mod files from 2 separate origins for 2 separate purposes That's right, you can override particular objects from a gamedatabundle without overriding the whole bundle, you just can't override particular values on an object without overriding the whole object. You should be able to put any number of gamedata objects in one .gamedatabundle, regardless of the source. You can't mix objects from different types of bundles, of course (for example, a gamedata object and a global script). I don't think there have been any large systematic changes. Some specific data is now in gamedata that wasn't, particularly the tables that define how many spellcasts spellcasting classes get. Player voice sets also exist on their own individual gamedata objects instead of as a list on a single object, which made it difficult to have multiple voice set mods.

The process should be relatively similar on Mac. The 'override' folder should go inside the app at "PillarsOfEternityII.app\Contents\override". Nothing should need to be different about the files themselves. If you run into any issues with that, let me know and I'll dig deeper. That's right. I'll make a note of that and see if we can do something about it in a future version.

Abilities that have special code have their own gamedata types. There are about 32 of these types available, though I don't know how many are actually used currently. SpecialGenericAbilityGameData is the most common. The most correct way to identify ability gamedata would be to see if it has a "Game.GameData.GenericAbilityComponent" component on it.

Yes, there is a list of valid sprites. Currently: Those aren't actually tokens, they're just text in chatters signifying sounds that aren't words.

This will only work for string tables that are in the StringTableType enum. In general, this is any of the "game" stringtables (items, abilities, gui, cyclopedia), but not conversations or quests.

There is some game data you have to set up. Each voice needs a SpeakerGameData and needs to be added to PlayerVoiceSetGameData. This will be changing in v1.1 so that mods that add voice sets don't all need to override the same PlayerVoiceSetGameData object.

See https://forums.obsidian.net/topic/96968-can-we-mod-potd-difficulty/?p=1998989. This will be available in v1.1.

Yes, I removed the item component from each weapon entry that had it. I figured this would be a safer alternative to messing with the actual item component itself. I was wondering about whether or not updates to gamedatabundles would update the instanced items in a save file. So I am guessing that it does not. I need to further test and look through to make sure I have nothing out of place in the actual file's json syntax though. Is there anyway currently to force update from database changes for existing items already owned by the player? It depends on what you change. Almost all data is looked up straight from the gamedata, so mods will work fine in existing saves. This is one of the rare places where that isn't the case, because the "ItemMods" property on the EquippableGameData actually just dictates the starting item mods. Once an item is created, removing mods from the gamedata doesn't remove them from existing items. You can't easily fix this for existing items, but if you get new items (e.g. via a console command), they'll be up-to-date.

It looks like the mod is just removing the item mod from the game data for each gun, so if you're testing items that already existed in your save before you added the mod, they will probably still have it. Is that the case?

That's the name of an entry in a C# enum that the code uses to identify subclasses that need slightly special behavior. If you're adding a new subclass, it won't have a corresponding entry in the enum, which is in code. It should be safe to set those to "Invalid" in that case. EDIT: This property has been removed in v1.2.0.

I took a look and it looks like override conversations do need to have a particular path. It isn't the same as the stringtables, though. You can find the path in the "Filename" property in the conversation file you're overriding. This path is relative to the override folder. So re_si_ship_combat needs to appear at override/Conversations/RE_Scripted_Interactions/re_si_ship_combat.conversation. I'll add a note in the pinned thread. This is a bit weird because you can't put these files in a mod-specific subfolder. We might be able to change this later.

You can make any key a hotkey in vanilla as long as it isn't bound to a control in the Options menu (including Ctrl/Alt combos). This behavior is in code, so it's not easy to mod.

Do you mean v1.0.2? Or is the 1.0.3 the upcoming patch which is not yet on Steam? v1.0.3 is the next large patch that isn't out yet.

There is a range, but it's been removed for v1.0.3.

It depends on the data that's being modified. In this case, you probably need the trader to regenerate their inventory, which should happen if you wait about 24 hours.