Soo one of my players is a bloodhunter and got his character updated with the new version released this January. The new version switched the casting stat for the class and a lot of the features changed.
The net effect was that this change made dnd beyond not usable for them this session and that is unfortunate.
Fortunately we had a paper backup and the session went fine. However, if dndbeyond wants to be a product my table uses while we play - y'all gotta not rollout character breaking changes by default. That is disruptive to play.
I really dig the ability to version content but it would be great if DnD beyond let folks opt-in to new versions or let folks roll back to old versions of content.
Character sheets are not changed unless you change them. If the character was using the previous version of Bloodhunter, they will still be using it.
When you make a character sheet and pick something like a race or class - that choice is locked in. This means that sheet will be using that version of that choice even if it gets archived. You maintain access to everything about that choice from level 1 to 20. However, if you ever change that choice on the sheet, you can't go back to it.
Your player most likely changed the class to the new version. So let's not blame D&D Beyond for something your player did.
I can understand how it is jarring since it is a big change and we cannot homebrew the original version. However, I also understand how confusing it would be to have two different Bloodhunter class versions and this site isn't designed to support "version choices". They therefore chose to keep only the newest version available for new character creations. While I am unhappy with them doing so, I understand why and respect it.
Agreeing to your request in a way that would be simple and not confusing would require a restructure of the code and at this time it would be impractical given the other projects. They are working on a future homebrew overhaul that could lead to the creation of homebrew classes, which would solve future issues like this (since you can just homebrew the version of the class you want for private use). That, however, is a fair ways off - I'd estimate late 2020 to early 2021 at best.
Click ✨ HERE ✨ For My Youtube Videos featuring Guides, Tips & Tricks for using D&D Beyond. Need help with Homebrew? Check out ✨ thisFAQ/Guide thread ✨ by IamSposta.
Basically the things Cyb3rM1nd said. The changes aren't forced, you have to manually switch the character from the old version to the new version. But you can't switch back because that is archived with the creator's consent.
Can you point to some release notes or something that illustrates this in action? I had assumed that this would be how it should work but that doesn't line up with my player's experience.
If it does work this way - there may just be a messaging problem within the UI where users need to be better informed: "if you change this - there is a new version of the class/race/item".
Can you point to some release notes or something that illustrates this in action? I had assumed that this would be how it should work but that doesn't line up with my player's experience.
If it does work this way - there may just be a messaging problem within the UI where users need to be better informed: "if you change this - there is a new version of the class/race/item".
Ahhh! The anoucement video indicates that if you level up your old bloodhunter character, after the update ,the new version will take effect. So you could keep it as long as you didn't level up after the new version was released. That does align with what happened to my player.
I'm glad they at least communicated it in the release, would be nice to communicate that in the UI more effectively if this becomes more common.
Ahhh! The anoucement video indicates that if you level up your old bloodhunter character, after the update ,the new version will take effect. So you could keep it as long as you didn't level up after the new version was released. That does align with what happened to my player.
I'm glad they at least communicated it in the release, would be nice to communicate that in the UI more effectively if this becomes more common.
I have a level 1 archived blood hunter that I level up to 3 and is still archived. But the archived can't choose a subclass if it didn't already have one.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Soo one of my players is a bloodhunter and got his character updated with the new version released this January. The new version switched the casting stat for the class and a lot of the features changed.
The net effect was that this change made dnd beyond not usable for them this session and that is unfortunate.
Fortunately we had a paper backup and the session went fine. However, if dndbeyond wants to be a product my table uses while we play - y'all gotta not rollout character breaking changes by default. That is disruptive to play.
I really dig the ability to version content but it would be great if DnD beyond let folks opt-in to new versions or let folks roll back to old versions of content.
Character sheets are not changed unless you change them. If the character was using the previous version of Bloodhunter, they will still be using it.
When you make a character sheet and pick something like a race or class - that choice is locked in. This means that sheet will be using that version of that choice even if it gets archived. You maintain access to everything about that choice from level 1 to 20. However, if you ever change that choice on the sheet, you can't go back to it.
Your player most likely changed the class to the new version. So let's not blame D&D Beyond for something your player did.
I can understand how it is jarring since it is a big change and we cannot homebrew the original version. However, I also understand how confusing it would be to have two different Bloodhunter class versions and this site isn't designed to support "version choices". They therefore chose to keep only the newest version available for new character creations. While I am unhappy with them doing so, I understand why and respect it.
Agreeing to your request in a way that would be simple and not confusing would require a restructure of the code and at this time it would be impractical given the other projects. They are working on a future homebrew overhaul that could lead to the creation of homebrew classes, which would solve future issues like this (since you can just homebrew the version of the class you want for private use). That, however, is a fair ways off - I'd estimate late 2020 to early 2021 at best.
Click ✨ HERE ✨ For My Youtube Videos featuring Guides, Tips & Tricks for using D&D Beyond.
Need help with Homebrew? Check out ✨ this FAQ/Guide thread ✨ by IamSposta.
Basically the things Cyb3rM1nd said. The changes aren't forced, you have to manually switch the character from the old version to the new version. But you can't switch back because that is archived with the creator's consent.
Can you point to some release notes or something that illustrates this in action? I had assumed that this would be how it should work but that doesn't line up with my player's experience.
If it does work this way - there may just be a messaging problem within the UI where users need to be better informed: "if you change this - there is a new version of the class/race/item".
You mean like on the announcements forum?
https://www.dndbeyond.com/forums/d-d-beyond-general/news-announcements/56965-blood-hunter-updates
Ahhh! The anoucement video indicates that if you level up your old bloodhunter character, after the update ,the new version will take effect. So you could keep it as long as you didn't level up after the new version was released. That does align with what happened to my player.
I'm glad they at least communicated it in the release, would be nice to communicate that in the UI more effectively if this becomes more common.
I have a level 1 archived blood hunter that I level up to 3 and is still archived. But the archived can't choose a subclass if it didn't already have one.