The data solution I presented requires a small bit of modification. It occurred to me that a character with a given cleric domain should be able to select the same domain as a druid. So a cleric 5/Druid 3 with the fire domain would get 3+WIS fire bolts doing 1d6+2 damage, and 3+WIS fire bolts dong 1d6+1 damage. Animal companion levels would still need to stack.
This means that in my data solution, you would have to remove the !PREDOMAIN and !PREABILITY tags I mentioned, and have new versions of each of the domain abilities so that the variables could be tracked separately.
I know this complicates things, but the eventual code solution (6.0?) to this should allow the domains to reference a single version of the abilities, but track the variables individually -- an object oriented approach.
Sir George Anonymous
--- In firstname.lastname@example.org, "ovka" <lpacdavis@...> wrote:
> --- In email@example.com, Eddy Anthony <eddyba@> wrote:
> > You've touched on some long standing limitations with Cleric Domains, when I
> > was testing the Druid I was unable to select any Domains at all. I didn't
> > see a purely data solution so I trackered it to be dealt with post 5.16.2.
> I have a data solution, but it's kind of ugly. Rather than granting domains, I have the Druid class grant abilities that grant the same abilities that the cleric domains grant. Then I have a series of SPELLS:xxx Domain|... tags that grant the appropriate spells once per day. To avoid overlaps, each of the Druid "domains" has a !PREDOMAIN tag, and each of the corresponding cleric domains has a !PREABILITY tag.
> It works, and allows the proper selections, but it isn't the best solution. Allowing multiple classes to track their own domains is definately a post 5.16 project.
> Sir George Anonymous