Armakoir

Send me your files and I'll take a look. it might be just one little thing here or there that is causing the problem.

Ah, the activation prereq should be on the new ability.

Try this InstanceID: 011111e9-0000-0000-0000-000000000000 Instead of b1a8e901-0000-0000-0000-000000000000 from: https://eternity.obsidian.net/game-data-formats/instanceids

"ActivationPrerequisite" is the way to go, for now. The new ability should be visible when in Bear form, but it should be grayed out and unusable until CL 4. That should be all you need.

1. Can we add "VisibilityConditional" to the GenericAbilityComponent? Less ideally, can "HideFromUI" from the GenericAbilityComponent function completely for Active abilities and not just Passive abilities? (the former is more work on your part, the latter is more work on our part) Let's be honest, the ability bar is kind of a clusterf#$% and the more we can reduce the clutter the better (even if that means doing more work as modder). In general, I want the player to unlock abilities via the Ability Tree, but I don't want those abilities visible on the ability bar until conditions are met. For example, being in spiritshift, having certain weaponry equipped, or other status effect related possibilities. The former request is the most straightforward, but requires updating every ability entry in the game. But I can make the latter request work, and I have it working right now... except for that ability on the ability bar that should be hidden. 2. Can we please remove the Active and Passive division in the Ability Tree UI? But can we also maintain the square icon for Active and the circle icon for Passive? I don't think this division is doing you, us, or the players any real favors. And as modders, if this division is removed, we can easily create mini-trees of Active abilities that require Passives and vice versa. Technically we can do this now, but to make it appealing on the UI we have to create an empty ability, autogrant the passive, yada yada. It's not just more work; it also requires the player to figure out whats happening.

Ok, I think I figured it out! And it's much easier than I originally thought. First, modding the progression table is not necessary! Second, you only have to modify a single line of code. In your new_abilities.gamedatabundle copy the Spiritshift_Bear_Shifter_SE_ChangeForm entry (67b5a416-ae58-4308-8222-2e1fe3b658c6). Then delete everything from that entry except "TempAbilitiesIDs". It should look like this: https://i.imgur.com/3iWxt3m.png Now add your new ability into those brackets and test!

We'll get it working. Once you learn the basics of modding Deadfire it gets much easier and quicker. For new IDs I use this: https://www.guidgen.com/ Right now for progression table changes, you must copy the entire PT_Druid entry. This may be the issue, I'm not entirely sure. I've attached a copy from 2.1beta with an empty ability reference at the top. Start with this and go back through, and we'll narrow down the problem. pt_druid.zip

Now, technically, you're done. You have added a new ability that requires a certain spiritshift. But there's really two more steps. First, you don't really need your new ability to be visible on the Druid ability tree because it is autogranted. (There are reasons to keep it visible, but it depends on what else your doing.) Plus, by making it invisible you learn something very useful about progression trees. Within the "VisibilityConditionals" you're going to create an impossible condition. The simplest way is to tell the game: if this is a Druid show the ability and if this is NOT a Druid show the ability. As for the code, I challenge you to figure it out. Now test just like you did before. The only difference is, you should never see the new ability in the Ability Tree. And with this, you're done with the progression tree. But you probably also want to condition the activation of your ability (for example, the ability can only be activated when the character is actually IN spiritshift). This requires putting a conditional into "ActivationPrerequisites" of the new ability entry in new_abilities.gamedatabundle. The advice here is: you'll be using a conditional associated with StatusEffect from this list: https://eternity.obsidian.net/game-data-formats/conditionals If you set everything up right (and if this is your intention), you should have the following example: If you select Wolf Spiritshift, you should see the harp_ability_wolfspiritshift ability on your ability bar but not on the ability tree. You should not be able to activate this ability unless that character is currently in wolf spiritshift. If your character chooses any other spiritshift during creation, the new ability should not be on the ability bar. Edit: After you've thoroughly tested the ability and everything seems good, go back to the progression table and adjust MinimumPowerLevel to whatever you intended it to be. Ask questions if you have them!

Now we'll start to attach the new ability to a spiritshift ability. What you have probably done is put the spiritshift ID into "RequiresAbilityID" and you've also used "AutoGrant", and when you load the mod you're automatically granted the ability despite the fact that you don't have the spiritshift, is that correct? The thing to know here is, as far as I can tell, "RequiresAbilityID" is mostly associated with the Ability Tree UI and it is not sufficient for conditioning abilities. To be honest, in your situation (which I think should include making the new ability invisible in the ability tree) you can probably leave the "RequiresAbilityID" zeroed. Instead, what you're going to do is create a "Conditional". Search for "HasAbility" in the PT and copy the conditional into your new ability reference. It should look like this: https://i.imgur.com/NSHMDZa.png Now find the appropriate spiritshift ability and place that ID into "Parameters". Also, put the "UnlockStyle" to "AutoGrant" (the G must be capitalized). So, now you can test again if you want. What should happen is this: if you create a new Druid and select the appropriate spiritshift, you should be automatically granted the new ability at PL 1. Now test a negative case and select a different spiritshift; you should NOT have been autogranted the ability.

Now, take the copied individual ability reference and "reset" it. It should look something like this: https://i.imgur.com/qeBtUEa.png ProTip: the game does not crash or reject a "zeroed" AddAbilityID Now take these steps: 1. Make sure the Druid ID is in "ClassID" 2. Copy the new ability ID from new_abilities.gamedatabundle and place it in "AddAbilityID" 3. Set "MinimumPowerLevel" to something low and easily testable (probably 1) 4. Change the "Note" to something you'd prefer 5. In your situation, maintain "IsMutuallyExclusiveUpgrade" as false There's more to do, but now is a good time for a quick test. Load the game with your mod and check the Druid Ability Tree. You should see the whole vanilla Druid tree as well as your new ability (but you should not have the ability). Edit: you could also now test the functionality of the ability despite the fact that it's not attach to spiritshifting.

Of course I'll help! First, I'm assuming you have a new ability built in another file (let's call it "new_abilities.gamedatabundle" for reference) with new unique GUID. Second, we'll call the copy of the entire Druid progression table "pt_druid.gamedatabundle". This copy of the very large PT_Druid entry should contain a lot of individual ability references. Third, copy ANY of the individual ability references within the progression table and place that copy at the very top of the of the AbilityUnlocks section.

Ok, let me try to understand more. You're trying to add abilities to the Druid that are only available during spiritshift. Correct? The first step is telling the game (via the PT_Druid) that these abilities belong to the Druid, and when they are unlocked. As before, make a copy of the PT_Druid entry. Then add an ability entry for one of your new abilities. This entry should have the same ID as the ability you've created. Then you need to modify this new ability in the progression table. If I'm understanding you correctly, I suggest the following: It should be AutoGrant. A condition should be having the appropriate spiritshift ability. The ability should be invisible in the ability tree. I'm on mobile ATM, but I can explain more later. And perhaps it's time for a progression tree tutorial.

Yep, that's progression table work which you cannot presently modify line by line. It's not really a matter of rebuilding the progression tree, just the PT_Druid entry of the progressiontables.gamedatabundle. Copy that entry into a new file and make your adjustments within the entry. It's not as much work as it seems, and the only real downside is the lack of compatibility with other mods that also change the PT_Druid entry.

Hiya BMac I am experiencing a weird graphical bug with the progression tables and ability trees, and I'm curious about your thoughts (ie, cause? fixable?). Here is a pic: https://i.imgur.com/RbQ2piD.png Whenever I increase the "required abilities" to 3 or more on a single ability, the vertical divider appears. It doesn't seem to effect any gameplay, but it's aesthetically displeasing. I'll continue to play around and see if i goes away under other conditions, and I know the ability tree has a mind of it's own in terms of positioning, but.... any thoughts? Edit: So this problem seems to resolve itself when the PT begins to fill in with abilities. Please disregard (and see post below)

The v34 update to the beta branch has fixed my issues with Subclasses and Recipe categories. Thank you so much BMac and OBS! You're doing amazing work.

If you have 2.1 beta installed and you're adding a new priest subclass, then the new subclass won't be recognized.

The ranger one is mine. All mods which add new subclasses are broken with 2.1b. New subclass entries are not being recognized. This seems to be the issue. I've posted in the beta notes thread. Edit: I would suggest reverting back to 2.01 in order to continue your gameplay progress.

I'm not sure that the approach you're taking with long duration times will work. But I am intrigued by the goal you're talking about (forcing players out of their optimal group setup). If duration doesn't work, what are some other approaches you're considering?

RecipeCategory entries are also not being recognized.

BMac... mods that add new subclasses have been broken with this beta update. I have tested this with my two mods and those of NocturnalTrance. It seems like new CharacterSubClassGameData entries are no longer being recognized. All of the other tweaks that I've made are working (including progressiontable changes, new abilities, tweaks to existing abilities, and tweaks to existing subclasses). I have adjusted the formatting of these entries and moved them to new bundles hoping to cause other issues within a given bundle, but I'm not creating problems. The entries themselves are good; they simply are not recognized in both saved games and new game startups. Please fix this before release.

BMac is aware of this proficiency icon issue and says it will be fixed.

Have you tried the WeaponTypeComponent from WeaponTypeGameData? Nevermind. I tried creating a new WeaponType but it broke the item.

Spells and abilities like this are assigned to a character via the class progression tables. Look in exported for progressiontables.gamedatabundle, and within this file search for "PT_Priest". You'll need to duplicate the entire PT_Priest entry and then make your modifications because of how the progression tables work. If you need an example for the priest, I suggest looking at NocturnalTrance's priest mods.

The request form really does help us keep track of things. Please use it!

Have you tried the WeaponTypeComponent from WeaponTypeGameData?