I want to make the most accurate archer/sharpshooter. In messing around with multiclassing a fighter and a ranger on D&D Beyond I noticed I could grab the "Archery" fighting style from both classes, giving me a combined +4 to long ranged attacks. Is this some kind of bug on the site or fair game to use?
It’s a known system limitation. Those features each pull from their own list of fighting styles instead of from a centralized pool of them the way skill proficiencies are handled. We just have to follow the rules for ourselves.
It’s a known system limitation. Those features each pull from their own list of fighting styles instead of from a centralized pool of them the way skill proficiencies are handled. We just have to follow the rules for ourselves.
It does not have to be a limitation.
One table Fightingstyles
One table Classes
One table in the middle for "Class_Fightingstyles".
The basic resolution of a N:M relationship. Database design 101.
I would just unsure if I want to keep the Conditions (needed books) on the Fightingstyles table, or move it to Class_Fightingstyles. Right now option 1 should work, but Option 2 would be more suitable if a later book expands who can get which fighting style.
You don’t understand, they aren’t set up to pul from tables like that they were coded as individual class features each with their own list of Options. If you make a subclass using the Champion as a template you can see what I mean as the problem exists for Champs by default too. They know the system has this flaw and are working on a solution, but it isn’t simple because of how they designed the system. They apparently cannot just make the features draw from a centralized table like that without it crashing character sheets, so they are working on it but it’s tricky. Or so they say at any rate.
You don’t understand, they aren’t set up to pul from tables like that they were coded as individual class features each with their own list of Options.
Oh no, I fully understand. Because it is a tale as old as relational Databases*:
1. Programmer encounters a N:M Relationship
2. Programmer adds duplicate columns, duplicate tables or some other duplicate to solve it.
3. Programmer made a very common mistake of handling N:M Relationships, that cause stuff like this down the line.
N:M is a common issue. This mistake in reaction to it is a very common mistake. It happens. 99% of all DB developers did it at least once. You learn how to do it right. You will not repeat it. Eventually you even get around to fixing it in everything you already wrote, if it is still in use. The end.
*That would 1970 btw. Which makes it 1.5 decades older then me.
So you know about RDBMS? Cool. Take this in: DDB, when it was building its system originally, was required by WotC to support just the official sources and nothing further. Yeah... that's part of why there's a lot of inflexibility. And why things got cruftier as additional books were released and DDB had to sort of staple new features in.
They have been working towards rebuilding the database to be more flexible, but have had to do that incrementally, since they still need to support the everything and everyone using DDB all the time, and character sheet crashes are a serious issue they want to minimize.
I guarantee there are people on the dev team who know exactly what you mean, but they still have to get there from here, and it's tricky.
Rollback Post to RevisionRollBack
Helpful rewriter of Japanese->English translation and delver into software codebases (she/e/they)
So you know about RDBMS? Cool. Take this in: DDB, when it was building its system originally, was required by WotC to support just the official sources and nothing further. Yeah... that's part of why there's a lot of inflexibility. And why things got cruftier as additional books were released and DDB had to sort of staple new features in.
They have been working towards rebuilding the database to be more flexible, but have had to do that incrementally, since they still need to support the everything and everyone using DDB all the time, and character sheet crashes are a serious issue they want to minimize.
I guarantee there are people on the dev team who know exactly what you mean, but they still have to get there from here, and it's tricky.
Oh, I know it will probably take time. The curse of programming: No shortage of things you can do and should do. But never enough time to do half of them.
I just could not take the "it is impossible to fix" argument. Main thing is that is is on "the list" of things to do.
You don’t understand, they aren’t set up to pul from tables like that they were coded as individual class features each with their own list of Options. If you make a subclass using the Champion as a template you can see what I mean as the problem exists for Champs by default too. They know the system has this flaw and are working on a solution, but it isn’t simple because of how they designed the system.They apparently cannot just make the features draw from a centralized table like that without it crashing character sheets, so they are working on it but it’s tricky. Or so they say at any rate.
This was just posted on reddit:
https://www.reddit.com/r/DnD/comments/v4q6r2/archery_exploit_or_bad_programing/
Clearly a bug, as the rule for Fighter, Paladin and Ranger clearly says:
If I pick the right style (Defense, for example), I can even get it 3 times.
It’s a known system limitation. Those features each pull from their own list of fighting styles instead of from a centralized pool of them the way skill proficiencies are handled. We just have to follow the rules for ourselves.
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting
It does not have to be a limitation.
One table Fightingstyles
One table Classes
One table in the middle for "Class_Fightingstyles".
The basic resolution of a N:M relationship. Database design 101.
I would just unsure if I want to keep the Conditions (needed books) on the Fightingstyles table, or move it to Class_Fightingstyles. Right now option 1 should work, but Option 2 would be more suitable if a later book expands who can get which fighting style.
You don’t understand, they aren’t set up to pul from tables like that they were coded as individual class features each with their own list of Options. If you make a subclass using the Champion as a template you can see what I mean as the problem exists for Champs by default too. They know the system has this flaw and are working on a solution, but it isn’t simple because of how they designed the system. They apparently cannot just make the features draw from a centralized table like that without it crashing character sheets, so they are working on it but it’s tricky. Or so they say at any rate.
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting
Oh no, I fully understand. Because it is a tale as old as relational Databases*:
1. Programmer encounters a N:M Relationship
2. Programmer adds duplicate columns, duplicate tables or some other duplicate to solve it.
3. Programmer made a very common mistake of handling N:M Relationships, that cause stuff like this down the line.
N:M is a common issue. This mistake in reaction to it is a very common mistake. It happens. 99% of all DB developers did it at least once. You learn how to do it right. You will not repeat it. Eventually you even get around to fixing it in everything you already wrote, if it is still in use. The end.
*That would 1970 btw. Which makes it 1.5 decades older then me.
So you know about RDBMS? Cool. Take this in: DDB, when it was building its system originally, was required by WotC to support just the official sources and nothing further. Yeah... that's part of why there's a lot of inflexibility. And why things got cruftier as additional books were released and DDB had to sort of staple new features in.
They have been working towards rebuilding the database to be more flexible, but have had to do that incrementally, since they still need to support the everything and everyone using DDB all the time, and character sheet crashes are a serious issue they want to minimize.
I guarantee there are people on the dev team who know exactly what you mean, but they still have to get there from here, and it's tricky.
Helpful rewriter of Japanese->English translation and delver into software codebases (she/e/they)
Oh, I know it will probably take time. The curse of programming: No shortage of things you can do and should do. But never enough time to do half of them.
I just could not take the "it is impossible to fix" argument. Main thing is that is is on "the list" of things to do.
I never said “it is impossible to fix.” I said:
I hope that helps.
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting