Wizard "School Savant" level 3 subclass feature adds spells to prepared spells and not spellbook.

Quote from wagnarokkr >>

Quote from MaedraDawnkeeper >>

Quote from wagnarokkr >>

Quote from charkomangus >>

Well it's gross that this is an issue of one of 4 subclasses. 

It's actually an issue on eight subclasses now. 

It's somewhat frustrating that they had every opportunity to do it right on the new ones from Arcana Unleashed but didn't.

 I'm still not convinced the dropdown is a problem.

One can just ignore the drop-down and add the spells via the normal interface, and everything works fine. In that sense, it's not a problem, because unlike some other lingering 5.5e implementation issues, it's entirely possible to set up a character that uses the feature correctly.

However, if you actually use the drop-down the way that the interface implies that you should, the behavior you get is incorrect according to the rules, and you end up with more prepared spells than you're supposed to have. In that sense, it is a problem, since there's no way anyone would know in advance that it does something it's not supposed to do, or that you need to use a workaround to get it to do the correct thing. It has already caused confusion for a lot of people.

I don't expect everyone to feel strongly about it. It's just a pet peeve of mine because this isn't something that needs a huge overhaul of the character builder to fix. All that needs to be done is remove the drop-down entirely and make it a "text only" feature like every other class feature that doesn't affect the numbers on the character sheet. But two years on, not only have they not done that, but they've introduced the same problem on four new subclasses, when they could just as easily have not done that.

You are 100% correct! All they need to do is remove the drop downs from the feature! It's absurd that they shipped as is when the correction would have been 10 minutes of a Developer's time! This is C# + JS, ReSharper would find this code pattern in a single search even if it is in multiple locations, either in a C# server rendered view or a JS frontend UI component.

I know exactly what this is though, I've had to lead multiple organizations out of the exact same quagmire, which this "oh, we'll fix it in the next version that we're working on." is a first order symptom of. It's due to a bad process approach and the process approach is bad for multiple reasons.

First being that it depends on releasing an upgrade to the entire system at once to cover all the bugs that got swept under that rug, which is a big bang redesign. Big bang redesign projects have a historically measured failure rate of over 80% per a decade's worth of measurement and reporting in the Standish Group's Chaos Report, with even recent rates still sitting at about 70%.

It is far better to decompose existing systems along architectural seams and upgrade those smaller domains that emerge. But then that requires supporting all the existing systems that fall in to those domains that will receive later upgrades. And that means you can't ignore those bugs.

But a big bang release is easier to conceptualize and it makes development teams feel more comfortable. It lets them say they can focus on writing the cooler, new software and not have to provide production support, which only appeals to a narrow demographic of developers. And it lets them feel like they will have an easier to support product if they can just rewrite the whole thing better this time and get it out the door. And that takes a lot of time!

Which leads to the second reason it's a bad process approach, the hit to reputation over time. By ignoring production support for a long period those bug related experiences pile up and lead to frustrated user seeking alternatives.

This also leads to the third reason it is a bad process approach, as the extended period of ignoring production support also erodes the internal organization. All organizations experience attrition over time, and as subject matter expertise is lost through that attrition, the ignorance of the current system becomes an additional cost while trying to implement the upgraded system as important lessons or decisions are no longer understood by a development body that has not cut their teeth upon the current system.

The top contributors to the high failure rate reported by the Chaos Report are outright project cancellation, at over 30%, as the upgrade becomes irrelevant to the business goals, and budget overruns, at over 50%.

The loss of both users and subject matter expertise directly impact the budget overruns, both by lowering revenue, which impacts budget calculations, and by increasing the cost of research and design, as implementations and decisions need to be revisited by a whole new group without previously acquired subject matter expertise.

The extended timeline also directly impacts both reasons, as it presents a longer period for unforeseen risks to manifest and for additional delays to occur that lead to increased costs and to potential irrelevance of the project for the business.

At the end of the day, this is why I've been brought in to many organizations to break up exactly this kind of logjam. This is why it is so important to not ignore a quick win like this! Literally minutes of developer time in Visual Studio can save so many threads on the forums, and even more frustrated users, including DMs that are the highest revenue users, including those that don't even bother to come to the forums!

Regardless, I absolutely second what you're saying wagnarokkr, and that is based on decades of deep software industry experience and a project delivery success rate that is well over 90%, which continues to deliver value to my clients, old and new.

Quote from zesban >>

Quote from wagnarokkr >>

Quote from MaedraDawnkeeper >>

Quote from wagnarokkr >>

Quote from charkomangus >>

Well it's gross that this is an issue of one of 4 subclasses. 

It's actually an issue on eight subclasses now. 

It's somewhat frustrating that they had every opportunity to do it right on the new ones from Arcana Unleashed but didn't.

 I'm still not convinced the dropdown is a problem.

One can just ignore the drop-down and add the spells via the normal interface, and everything works fine. In that sense, it's not a problem, because unlike some other lingering 5.5e implementation issues, it's entirely possible to set up a character that uses the feature correctly.

However, if you actually use the drop-down the way that the interface implies that you should, the behavior you get is incorrect according to the rules, and you end up with more prepared spells than you're supposed to have. In that sense, it is a problem, since there's no way anyone would know in advance that it does something it's not supposed to do, or that you need to use a workaround to get it to do the correct thing. It has already caused confusion for a lot of people.

I don't expect everyone to feel strongly about it. It's just a pet peeve of mine because this isn't something that needs a huge overhaul of the character builder to fix. All that needs to be done is remove the drop-down entirely and make it a "text only" feature like every other class feature that doesn't affect the numbers on the character sheet. But two years on, not only have they not done that, but they've introduced the same problem on four new subclasses, when they could just as easily have not done that.

You are 100% correct! All they need to do is remove the drop downs from the feature! It's absurd that they shipped as is when the correction would have been 10 minutes of a Developer's time! This is C# + JS, ReSharper would find this code pattern in a single search even if it is in multiple locations, either in a C# server rendered view or a JS frontend UI component.

I know exactly what this is though, I've had to lead multiple organizations out of the exact same quagmire, which this "oh, we'll fix it in the next version that we're working on." is a first order symptom of. It's due to a bad process approach and the process approach is bad for multiple reasons.

First being that it depends on releasing an upgrade to the entire system at once to cover all the bugs that got swept under that rug, which is a big bang redesign. Big bang redesign projects have a historically measured failure rate of over 80% per a decade's worth of measurement and reporting in the Standish Group's Chaos Report, with even recent rates still sitting at about 70%.

It is far better to decompose existing systems along architectural seams and upgrade those smaller domains that emerge. But then that requires supporting all the existing systems that fall in to those domains that will receive later upgrades. And that means you can't ignore those bugs.

But a big bang release is easier to conceptualize and it makes development teams feel more comfortable. It lets them say they can focus on writing the cooler, new software and not have to provide production support, which only appeals to a narrow demographic of developers. And it lets them feel like they will have an easier to support product if they can just rewrite the whole thing better this time and get it out the door. And that takes a lot of time!

Which leads to the second reason it's a bad process approach, the hit to reputation over time. By ignoring production support for a long period those bug related experiences pile up and lead to frustrated user seeking alternatives.

This also leads to the third reason it is a bad process approach, as the extended period of ignoring production support also erodes the internal organization. All organizations experience attrition over time, and as subject matter expertise is lost through that attrition, the ignorance of the current system becomes an additional cost while trying to implement the upgraded system as important lessons or decisions are no longer understood by a development body that has not cut their teeth upon the current system.

The top contributors to the high failure rate reported by the Chaos Report are outright project cancellation, at over 30%, as the upgrade becomes irrelevant to the business goals, and budget overruns, at over 50%.

The loss of both users and subject matter expertise directly impact the budget overruns, both by lowering revenue, which impacts budget calculations, and by increasing the cost of research and design, as implementations and decisions need to be revisited by a whole new group without previously acquired subject matter expertise.

The extended timeline also directly impacts both reasons, as it presents a longer period for unforeseen risks to manifest and for additional delays to occur that lead to increased costs and to potential irrelevance of the project for the business.

At the end of the day, this is why I've been brought in to many organizations to break up exactly this kind of logjam. This is why it is so important to not ignore a quick win like this! Literally minutes of developer time in Visual Studio can save so many threads on the forums, and even more frustrated users, including DMs that are the highest revenue users, including those that don't even bother to come to the forums!

Regardless, I absolutely second what you're saying wagnarokkr, and that is based on decades of deep software industry experience and a project delivery success rate that is well over 90%, which continues to deliver value to my clients, old and new.

 Are you trying to get hired? Are you proposing a coding-based solution or a management one? & do you know how the site is coded, or are you assuming?

This wall of text needs a TL:DR, because it's all over the map spouting jargon & not citing sources.