Armakoir

Thank you for your kind words. I do have thoughts about a warlock/necro/alchemist = animancer type class, but I intend to redo the existing classes first. As for an ETA, a rough estimate would be a couple months for a tested release with all the classes. I'd rather not release classes piecemeal. The work actually isn't that time consuming (perhaps I've just honed my Ctrl-F skills), it's just a lot of changes.

Thank you SiliconMage, appreciate it!

This is a very cool idea, but I don't think we have access to autoattack as a modifiable ability. That said, since each attack is fairly deliberate in turn based mode, perhaps an active ability could be created that costs nothing to use or train, would be selectable (ie situationally optional) during combat, and could get pretty close to the functionality that you're describing. The hardest part would be the finisher/off-hand animation. That may not be something that can be singled out like I think the mainhand attack can be. But this idea is worth researching and testing to find a solution.

I'll explain with an example. Example 1 The barbarian ability tree has Frenzy as a basic ability for all barbarians. The Berserker subclass adds an Uber Frenzy and does exactly what you're saying: it makes the basic Frenzy invisible for only the Berserker. But, the code to make Frenzy invisible is contained within the basic Frenzy entry itself and not within the added Uber Frenzy entry. So, once Frenzy is implemented into a progression table it cannot be individually modified by an outside mod and the only way to add this invisibility is to override the entire existing barbarian progression table. So, let's say a modder wanted to add a Frothing-Mouth subclass or something that (like the Berserker) added a Frothing Frenzy ability and made the basic Frenzy invisible. This modder cannot specifically change the Frenzy entry to make it invisible based upon a player selecting the FM subclass; instead, they would have to override the entire progression table to make this change, and that just gets messy for a single change to one ability. Of course within my own mod and my own changes, I can add the necessary conditionals and this isn't really a problem. But if I'm already rebuilding so much, why not try to establish a plan, expectation, or standard for other modders who want to supplement my changes with their own. I think it's just much better in the long run to say, "I'm going purely additive and if you like my changes and want to add to them, consider your designs from a purely additive perspective as well". The RemoveAbilityID is helpful, but for a different reason. From the player's perspective, when you upgrade any ability it looks like you're attaching some new function to an existing ability. But from a modding perspective, you're actually acquiring a new ability and removing the old ability wherein the new ability just contains the old abilitiy's functionality plus new stuff. RemoveAbilityID functions as a way of actually removing the old ability so there isn't a duplicate of the lesser/older ability on the ability bar. When it comes to the Combined Abilities that I mentioned, I'm seeing subclasses being a great source of unique options for these abilities. So, an example. Example 2 A modder wants to add a new subclass and combined abilities (or any of the three ability types I mentioned) that are exclusive and only visible to that subclass. In this situation, none of the existing progression table needs to be modified or replaced, and the same functionality of using basic abilities as prereqs for combined abilities still works. So, a Thief subclass is added with a combined ability called Flash Attack that uses Blinding Strike as a prereq. The purely additive code contains the visibility conditions for Flash Attack (ie, only visible to Thiefs) and it also contains the RemoveAbilityID of Blinding Strike. When Flash Attack is trained, Blinding Strike is removed (from the ability bar but not from the ability tree) and can no longer be used as a prereq for other combined abilities. This functionality also works across class lines, so if Flash Attack required both Blinding Strike and a Wizard spell to be trained, those conditionals could be completely contained in the additive code. (Note: we're only allowed 1 RemoveAbilityID per entry, but there are ways around this).

I have time and energy now and I want to work on an update for the Class Project mod. And by "update" I mean I want to completely rebuild the mod from the ground up. I am creating this thread as a place to share my plan and progress and to receive input from those who have it (both in general about the mod and more specifically about skills or abilities). I'm also hoping that either experienced modders or those simply wanting to learn and help would be interested in sharing some of the work load or allowing me to incorporate their ideas into the Class Project. The Gist With 4.1, we gained some modding flexibility when working with progression tables (see here). We cannot modify existing entries in a progression table, but we can add entries to a progression table. So why not tabula rasa the progression tables and make things more additively modular? This is the gist of the rebuild. TCP will become multiple mods. But, when it comes down to determining where the modularity cleaver should land things are not so simple. For now I'm going to skip why that is, but the solution is this: additive becomes the key design principle. This results in more gameplay options for the player, but more modding work for myself or others. I'll explain. I don't like the vanilla passives or how they are organized, and I've tried to tweak them in TCP but I haven't really been successful. As a modder, I want to continue working on the passives for my own gameplay, but also give options for players to play the POE2 that they want to play. So... the modular cleaver will separate the current TCP into "TCP Core" and "TCP Passives" (and other less essential or problematic mods). There's two options for TCP Core. First, an actual tabula rasa progression table file for each class with a separate file that additively rebuilds the active abilities into that blank PT. Or second, a normal override of progression tables that consists of just active abilities with the expectation that passives and other additional abilities will be added for each class. The second option seems better, because it would allow other modders to do their own override of a specific class progression table while maintaining the ability to add entries to a progression table later in the mod load order. One of my probems is that numerous subclasses modify the available abilities/spells within their class in a way that is subtractive. A good example is spell availability to wizards via their school/subclass. These schools do not add spells, but rather limit access to basic wizard spells. From a modding perspective, this is problematic because of where this substraction code needs to be and the fact that one mod cannot simply modify the progression table of vanilla or other mods. So, my solution is that the basic ability tree for a class will be slightly more simplified than it is right now with the expectation that subclasses are redesigned to only add abilities (this redesign of subclasses as additive results in more work). Subclasses might become their own module because they would potentially contain both active and passive abilities, but I haven't quite decided on this yet. TCP Passives would actually be two different additive mods: one for the vanilla passives and one for the changes I want to make. My existing changes to Weapon Proficiencies/Modalities would also become a separate mod. The goal is essentially this: players would choose the modules that work for them. Maybe that is my TCP Core and someone else's Passives. Or my TCP Passives and someone else's Core. Plus an additive mod for weapon proficiencies, or an additive package(s) of Subclasses, or a PT override for a specific class while still allowing compatibility with other broad or specific additive mods. Classes and their Ability Tree Content Most of the martial classes will undergo quite a change. The forked ability upgrades just don't work because the biggest limitation I keep running into is the ability tree UI and the availability of space. So, this is what I'm thinking: Basic Abilities. These abilities (hopefully numbering 5 or 6) should be reliable but not powerful regardless of level and available at level 1. These abilities are essentially the bread and butter abilities that define the behavior of each class. Upgradable Abilities. These abilities are more powerful and can be upgraded linearly as the character progresses in level. Combined Abilities. These more specialized non-upgradable abilities fill in the ability tree with options. These abilities would combine the effects of two abilities (potentially across class lines) but come at a cost of giving up those more basic abilities. By giving up the more basic abilities, you would also lock access to other combo ability options that use that same basic ability as a requirement. So, an example of combined abilities. A rogue at level 1 has access to Blinding Strike. This attack simply blinds the target; no damage boost, no accuracy boost, just blinding, just reliability without any real oomph. At some higher levels the character can select from 3 or 4 abilities that include Blinding Strike as a prereq. Options here may include adding a damage boost to Blinding Strike, adding Smoke Cloud to BS, combining BS with a Fighter's defensive boost, or some splash damage from a Barbarian ability, or whatever. Regardless, the player trains one ability and Blinding Strike itself is removed along with the potential to use BS as an unlock for other combined abilities. This approach to active abilities is partly why I want to deal with passives separately. Passives (for some classes) take up so much room in the UI or get pushed off the screen because of the active ability tree. But with some good planning, many of those same passive effects can be automatically combined into active ability choices freeing up more UI space for interesting active ability decisions instead of blanket passive upgrades. This approach also works with mod compatibility and the additive principle. So that's basically the plan. Now begins the work. And hopefully in the next few days I'll have a rogue tree example that I can share.

For 1, can you just refund the minimum requirement as part of the ability? Or is part of the problem that you want the calculation to be based upon 40 (ie, the pre-ability focus value)? For 2, there is a work around for making a spell a weapon attack. IIRC, the vanilla fighter ability Clear Out is an example. Basically, Clear Out is an AOE "spell" that inflicts weapon damage. This might do what you're trying to accomplish: maintaining primary weapon damage but not increase the SE damage via Sneak Attack, etc.

I have the same, but I haven't figured it out yet.

So, it looks like this new capability does not allow us to modify existing entries on a class progression table (ClassProgressionTableGameData). I have not researched the "modify" potential of the CharacterProgressionTableGameData but I'm assuming it is the same. I guess I just misread and assumed that that was the new capability. So, if we want to remove, rearrange, or reconnect existing abilities we have to still override the entire progression table. Can anyone else confirm?

With v4.0 Real Time, there are no issues. With Turn Based, I'm working on an update.

It looks to me like removing an ability from a progression table is actually just making it invisible via the VisibilityConditional. I've started using the conditional "Boolean AlwaysFalse()" as a means for making something invisible. When you upgrade an ability you're actually training a new ability and removing the old, hence the RemoveAbilityID. This would not function to remove an ability from the PT completely though. Interestingly (in previous version; untested in 4.1), I could RemoveAbilityID while having a "0000-" in the AddAbilityID without causing problems. RequiresAbilityID is mostly, but not entirely, the aesthetic for connecting two abilities with a line. I say not entirely because it does have some functionality beyond the connecting line but I've never tried to track down exactly what that functionality is.

Yes, might take some time though. Major changes for me.

Looking at the code (but not having actually used the Blood Mage), I think this might be pretty complex to achieve. I do not know of conditionals that would work (but perhaps they've been added recently?). That said, there may be a way to change the self-attack into a series of self-attacks that allow for the functionality you desire. I like the idea you're suggesting; it makes a lot of sense. I'll try to look into it more.

It's part of my Class Project mod. As of this post, I've uploaded a possible fix to Steam. Please let me know in the coming days if the bug persists. If the debuff does not disappear on it's own, try a retraining of the effected character.

"AttackTargetOnEventWithChance" is not a valid StatusEffectType. For Rooting_Pain_SE_EventOnWound ( "b467966d-0ad5-424e-aa0a-b2d9d0ecf327" ) change the StatusEffectType to "ApplyStatusEffectOnEvent" (BaseValue is not used with this StatusEffectType).

Because the menu for backgrounds does not scroll, therefore you're limited to 17 possible backgrounds per culture. There are no mods that allow you manually assign skill points independently of other choices. Maybe it's possible with scripting, but I don't think anyone is really getting that in depth with the code.

Remove an SE by applying a 0 time immunity! That makes so much sense. Great progress. Here's a thought regarding the aggregation of Fracture. If 10 stacks are the max, then each shred ability could apply 10 SEs. Each SE has a unique keyword and requires the previous keyword on a target to apply (the first stack wouldnt require a keyword). Annhilation would then filter it's damage according to the appropriate keyword on the target. It's a bit clunky, but I think it could work. You could probably do the Accuracy bonus at the same time via the attack filter and the keywords on the target. Your Excel visuals are awesome. Going to steal that idea for my guide if you don't mind

I *think* this might be possible without dll work, but it is still a fair amount of work. Status effects can stack, so the first step is replacing all the shred powers for the Soulblade. You can also do AoE attacks that ignore the target. The only real tricky part is triggering/removing the stacked SEs. This idea peaks my curiosity, but no guarantees. RL is kicking my ass right now.

Makes sense, Spherikal. The infinite SE is applied when the ability is trained and only at this time. It will never reapply the SE.

I have some experience with items/enchanents. If you want it to be a system available to all magical items, then yeah it would be extensive. But it is possible. You can basically use any item as an ingredient even if that item isn't technically an ingredient. So, you can create recipes that transform a magical items into another item (an enchanted hilt, for example) and then use that new item as an ingredient in another recipe. The problem with "crafting" in the code is that it's not written to be flexible. The recipes need to include specific items to create specific items. In other words, you can't have variables for the ingredients. The system wouldn't be very flexible. Another limitation would be the recipe output: you can only create a single item from a recipe (excepting duplicates of that specific items). So, a sword with multiple enchantments could only be broken down into a single enchanted item. Does this sound right to those with more extensive knowledge?

Heya Spherikal. I'm on mobile, so I'm limited. SE #4 should be applied as soon as the passive is trained. Is this the case?

I've been wanting to put together a guide to modding subclasses. With you and others asking, I should finally get on that. In the meantime, the important thing to remember about modding sub/classes is that in the progression table file you MUST include the entire entry for the class you are working with; in other words, you cannot partially modify progression tables like you can abilities or other tables. So, for the wizard, you must include the entire "PT_Wizard" entry from the progression table file.

Did you use the correct folder structure for your stringtable? Unlike gamedatabundles, the localization files need to be in a specific file path.

https://forums.obsidian.net/topic/94795-obsidian-will-you-provide-xml-documentation-or-other-editing-tools-on-release/?p=1977260

We just don't have enough active modders to support requests, at least in any sort of timely manner. A few have my interest though and hopefully I can incorporate them at some point.

Apathy?