The Class Project 2.0

[Armakoir]

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:

1. 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.
2. Upgradable Abilities. These abilities are more powerful and can be upgraded linearly as the character progresses in level.
3. 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.

[dam]

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.

 

OK I might be totally off here but, let's give it a shot anyway :

Why not make the vanilla abilities you wish to remove invisible ?

Just like Monastic Unarmed Training when you multiclass a monk with say a barbarian.

 

The abilities still exist, they just aren't displayed and cannot be picked.

 

 

It seems there is also a RemoveAbilityID which could do the trick, give your class a passive ability at level 1 which removes whatever you want to go away.

 

See here.

[Armakoir]

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

[dam]

Meh, that is too bad, thought I had something to help you out here

[Breckmoney]

Awesome I’m no help at all in terms of actually coding, but I’d be more than happy to help with design feedback/testing. Sounds fun! Lots of class/subclass mods are what I always wanted to come to Deadfire when the expanded modding was announced.

[SiliconMage]

Hey Armakoir,

 

I updated the Extended Spell Collection to use the new progression table objects to that the new spells are appended to the base progression table for each respective caster.  If you want to incorporate the next version of the Class Project, I'm definitely fine with that.

[Armakoir]

Thank you SiliconMage, appreciate it!

[Dominu305]

Armakoir!

 

First I just want to say thank you for all the work you have put in on this Mod. It really has done a lot as far as replay ability for me.

 

There was a post in the Steam "Ideas and Suggestions" forum from Lore Keeper about a Warlock and Necromancer class. Just curious if you have had any thoughts on this.

 

Also, I know how much effort goes into a project like this and especially a complete overhaul like 2.0.

I hope it doesn't come across as impatient to ask if you have an ETA on this release? I would like to wait at starting a new playthrough until this drops.

 

Thanks Man!

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

[Unvalid]

really liked the class project 1.x, looking forward to 2.X very much! please keep us as posted as possible on updates. 

[Majber]

can you share any news about this mod?