Unfortunately, it is not what that means... It means only that some moderators who do not have any authority outside of the forum saw it and moved it to the correct place and tagged it. That does not mean that any devs saw it or that it is considered for implementation :-/
The same happened with my request for truly private characters where not even the people in the same campaign can see what you do not want them to (like race and class)
Come on. I need some real imagination to come up with a reason this might not be possible to get done in less than an hour plus maybe two or three testing. Please.
Ball Bearings (bag of 1,000) demonstrate that everything needed is there, weight per piece 2/1000 and quantity (quantity invalidates the workaround of making homebrew items)
Come on D&D beyond! It's been two years since people started asking for this, what's so hard about letting people make items with a value less then 1gp?!
Seriously this isn't the only thread about small problems (which I assume) are easly fixed and that have been requested 2 years ago.
These things were impossible to fix until fairly recently. In order to fix a lot of this stuff they needed to do several major and overlapping system upgrades to both their hardware and software. Those upgrades included adding additional servers, taking everything that was all on one Monolith originally and dividing it all onto their own dedicated servers. (That was an ongoing thing for, about half a year.) But before they could do any of that, they first had to reprogram the character sheet framework from the ground up so that it would be capable of querying data from outside the monolith. (That took almost a year.) and then they had to troubleshoot that new framework. (That took the rest of that year.) That 18ish month process took you don’t even wanna know how much “not simple” work to pull off. But before they could do any of that, they first had to figure out what needed to be done and how best to do it without crashing the system. (That took about 6 months.)
So all told, just to do a single one of these “simple fixes” took 2 years and probably somewhere in the neighborhood of a couple million dollars. In the meantime, the list of stuff needs fixin’ has gotten pretty long. And they are starting with the major fixes first since the minor, simple ones are genuinely of lower priority. In due time they’ll get to these simple ones.
Keep in mind that throughout that whole process they also still had to keep up with WotC’s ever increasing release schedule. And the newer material has become more challenging to implement with each new title. For example, the Optional Class Features in Tasha’s took them a year to code, and there are still a few things giving them trouble. Another example is the Artificer also in Tasha’s has some fairly significant changes from the version that came out in Eberron Rising. DDB was still working on fully implementing the Eberron version and all of a sudden they had to scrap a bunch of what they had been working on and start over with the new versions.
The stuff currently in playtest for the upcoming November 16th release of Strichaven is currently completely impossible for DDB to implement in any functional way at all, and they only have 4 months before deadline. Also worth mentioning is that if WotC changes stuff before the final print, DDB won’t see the changes before the week of Halloween. That will leave them little time to program. And they still have some wrinkles to iron out before Beyond the Witchlight is released late September.
As you can see they have a pretty full plate on their table. (And WotC has recently announced they plan to further increase their release schedule next year.)
Well, being a software architect this sounds somewhat alarming. Hope they pulled themselves up from the mud by that project. A system like this following the rules set by someone else needs to have the ability to implement every rule that can be written (different than any one might imagine) without getting into the layer that does what the latest posting implied being the 18 months project (scalability). Done that once. Becomes more of a (domain) language design project than what most people understand coding to be, but has been done at least a few thousand times before. Hope that is what they did. If not they need to start asap...
You are right. They basically need a DSL-type approach, but one that can build rules from smaller units. That is what their "Generic Feature System" (or now termed "Universal Feature System" in their dev updates) is supposed to be for. It has been in work for a while and is supposed to be done sometime later this year (probably fall?). With this, then can then implement any rule. Their existing system obviously has dedicated code for all rules. This system essential creates a DSL for any rules, as you put it. Then they can do new rules, epic boons, and other outstanding rules much, much quicker.
They are also working on major changes for the inventory system. Hopefully one of those updates has this small change in it. I, too, am frustrated that this change hasn't been implemented yet, though I understand why it is low priority for them.
A system like this following the rules set by someone else needs to have the ability to implement every rule that can be written (different than any one might imagine)
That was their plan from the inception, but when they were negotiating with WotC about it all, WotC’s response was a hard. “No. Your system cannot be designed to make anything that anyone could ever imagine. Your system is only allowed to implement official WotC rules.” So that’s what DDB built. About a year later when Ravnica came out some of the new rules were already outside the bounds of the system that WotC had insisted on limiting.
That’s when DDB started planning the whole overhaul. Basically, the have to scrap the entire system that WotC insisted on and convert over to a system more like what they had originally intended, but far less ideal than the original would have likely been. After all, instead of building it up from new with that purpose they are now forced to build from the system they already have and make it work. Considering the fact that the vast majority of users have been blissfully unaware of any of this for the past two years speaks volumes to the skill with which it is being accomplished.
People tend to forget about all the stuff that has been fixed because nobody talks about them anymore. Why? Because they work now. Who notices the 87 bagillion of things that work great? Nobody, they’re too distracted by the, what, half a bagillion things that work “less than great.” Things that used to be glaring system malfunctions are now running smoothly. So smooth in fact that even people who remember when they weren’t smooth forget they weren’t smooth before.
For example, people complain because their homebrew takes a few minutes to update. Nobody remembers that only 24 months ago, those same homebrews would have been crashing character sheets left and right because they were set up incorrectly or incompatible with each other. Why does it take some time to update now? In part because they have to progress through several server caches when before there was almost no caching required at all. But also because the system is compensating to make sure sheets don’t crash from poorly implemented ‘brews. Now, for bad homebrew to crash a sheet it has to be really bad, and their needs to be a lot of it.
Homebrew’s my jam, I am almost constantly working on several projects at a time. in addition, for a couple years now one of my favorite pastimes has been throwing everything I can at this system just to se what it can handle, and how I can break it. It helps me better design new stuff, but also keeps me ‘brewing when I hit a block so I can work through that creative block. Before I could snap it like a twig without effort. Just a couple magic items with a goofy* modifier on each would jam each other up something fierce. Now, there are a couple few things that I know will crash a character sheet, but those are specifically the things DDB says “don’t ever do this or it will crash character sheets.” Other than those, it’s now really, really unlikely for almost any combination of things to accidentally crash sheets anymore.
Trust me, they have been making vast improvements for almost a year now, but most people don’t notice. Usually because they happened to not have encountered that flaw before. Or they did and forgot about it or didn’t realize it wasn’t working correctly last time, or whatever. Nobody talks about how Favored Enemy or Disciple of Life didn’t used to work because they work fine now. So the real measure is not how many things people are still complaining about, it’s in how many things people stopped complaining about. But again, nobody notices those. 🤷♂️
The other reason some of this stuff takes a while is because they are hyper cautious to ensure nothing they fix will break anything else. Take this decimal value bug for example. They might have identified a fix they could have in place by close of business. But they might also have discovered that if they do it that way it might cause issues to 5% of the character sheets that have custom equipment. If they have also identified an alternative solution that will have absolutely no adverse affects whatsoever, but will take 12-24 weeks to implement because it means tweaking something else first, then that’s the one they’re gonna go with. And if they could get a better short-term juice:squeeze by spending that same 12-24 weeks fixing or implementing a different project, then it gets bumped.
If you ask me, they might be a little overly cautious at times. Sometimes the bandaid approach really is the less painful method. For example, the fix to Favored Enemy required “breaking” every Ranger character sheet on the sight.^1,2 They felt like dirty, dirty sinners for it. But it really wasn’t all that bad. After all, it took a legitimately game experience affecting bug and turned it into a nuisance that only persists for old PCs. AFAIK, every Ranger made new since then is experiencing no issues whatsoever. Yes, I think there were some other unintended consequences as well.^3 But again, the issue that got fixed was way more of a problem for folks than the new glitch that only pops up if you dupe a PC. Lots of people play Rangers every minute of every day. A handful of folks copy a character once in a while, and while the display in the builder is affected, the actual character sheets themselves display and function correctly. I count that as a win, and not a pyrrhic victory either. The juice:squeeze appears worth it, at least from where I’m sitting.
You are right. They basically need a DSL-type approach, but one that can build rules from smaller units. That is what their "Generic Feature System" (or now termed "Universal Feature System" in their dev updates) is supposed to be for. It has been in work for a while and is supposed to be done sometime later this year (probably fall?). With this, then can then implement any rule. Their existing system obviously has dedicated code for all rules. This system essential creates a DSL for any rules, as you put it. Then they can do new rules, epic boons, and other outstanding rules much, much quicker.
They are also working on major changes for the inventory system. Hopefully one of those updates has this small change in it. I, too, am frustrated that this change hasn't been implemented yet, though I understand why it is low priority for them.
Noticed recently how stuff like the notifications go a li’l wonky from time to time and then seem to resolve themselves? That stuff happens when they are doing big updates behind the scenes. Every time that stuff happens they are mowing their line of scrimmage 10 yards closer to that end zone.
People tend to forget about all the stuff that has been fixed because nobody talks about them anymore.
No, people tend to forget about the stuff that has been fixed because the developers don't seem to communicate. There's no "frequently requested features" thread for people to fall back on and prevent these threads from happening. The roadmap is offline, the developer updates scarce, the feature request portal abandoned. People don't talk about the stuff that's been fixed because we can't tell that there are currently things that are being fixed. Far fewer people catch the fixes because they haven't been anticipating it ahead of time.
Leaving OGL 1.0(a) untouched and making SRD 5.1 CC-BY-4.0 is a great first step. The next is a promise to do the same for future editions. Here's a discussion thread on that.
I will say that I was very excited about the container support being added. As someone who likes to have/use lots of items with my artificer, that is really helpful. I know that feature originally didn't have support for custom items, and I was hopeful that when the custom items were added back, that it would include this bug fix. Alas, it did not.
Yup still an issue in September 2022. Tad disappointing to read this because I've just migrated my group to use D&D Beyond from a VTT to manage their character sheets on.
I am making some Blight Seeds that have a street value of about 3 silver pieces... NOT A GOLD COIN! I think as a work around, I'll add the value into the description but.... It's not really good is it?
Whats interesting is that a 'Candle' has a item cost base of 0.05 gold value and a 'Waterskin' has a cost base of 0.2 gold value.
This really shouldn't be that hard to fix. Just add in a "step" element to the appropriate HTML/CSS tag (I found out that items already in the system have this "step" element, whereas custom items do not). "Step" controls the increment, and not having a "step" makes the increment default to integers/whole numbers. It shouldn't take more than 10 minutes to find the relevant webpage file and make the modification. Then another 10 to find the relevant backend attribute to edit so that what is saved reflects what is intended, as well as to ensure errors aren't thrown. Allow an hour or two for dedicated testing, then push to live.
Having said that, IamSposta's point about them being cautious of fixes breaking other things is very appropriate, since it happens literally every day in IT. Same for his point about feature priorities; this one is just too small to be higher on the list. Do I wish it was higher? Yes, but I can also understand why it isn't.
I think the biggest potential roadblock for this would be if they have been keeping Custom Items in a different database table from the other items in the inventory.
If this were the case, the it is possible that the Custom Item tables has weigh and cost as integers instead of floats. Changing that data type would require a data migration which is never fun.
Presumably for inventory, they are using a ForeignKey to a table with official and homebrew items in it, and then having other fields for quantity and all the customization options. Instead of supporting the whole CustomItem table, they could make a CustomItem item and use the existing customization infrastructure. The only difference would be adding support for custom descriptions. This would be a more performant and maintainable final solution.
I wouldn't be surprised if the goal is to get rid of a CustomItem table, and therefore there is a desire to avoid "throw away" work on features for it. The work to remove the CustomItem table would be non-trivial however, so it gets delayed in favor of other features. It's technical debt that has a low interest rate.
All of this is of course just conjecture since I haven't seen their source code or database schema. I'm just making educated guesses based on my experience in maintaining software tools and the observations I've made about the particular way things operate and break.
All of this is of course just conjecture since I haven't seen their source code or database schema. I'm just making educated guesses based on my experience in maintaining software tools and the observations I've made about the particular way things operate and break.
You got that right. The rest, ... as a software architect I feel I should just not comment on.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Hopefully they can get around to it.
All me Hombews:
https://docs.google.com/document/d/1WUnYn1tRvbkKOPpAkWOVlpe2S3JVLpV_LDOVzKG2DgQ/edit?usp=drivesdk
I, as well, want this.
Unfortunately, it is not what that means... It means only that some moderators who do not have any authority outside of the forum saw it and moved it to the correct place and tagged it. That does not mean that any devs saw it or that it is considered for implementation :-/
The same happened with my request for truly private characters where not even the people in the same campaign can see what you do not want them to (like race and class)
I'll add my voice and support
Come on. I need some real imagination to come up with a reason this might not be possible to get done in less than an hour plus maybe two or three testing. Please.
Ball Bearings (bag of 1,000) demonstrate that everything needed is there, weight per piece 2/1000 and quantity (quantity invalidates the workaround of making homebrew items)
Come on D&D beyond! It's been two years since people started asking for this, what's so hard about letting people make items with a value less then 1gp?!
Seriously this isn't the only thread about small problems (which I assume) are easly fixed and that have been requested 2 years ago.
These things were impossible to fix until fairly recently. In order to fix a lot of this stuff they needed to do several major and overlapping system upgrades to both their hardware and software. Those upgrades included adding additional servers, taking everything that was all on one Monolith originally and dividing it all onto their own dedicated servers. (That was an ongoing thing for, about half a year.) But before they could do any of that, they first had to reprogram the character sheet framework from the ground up so that it would be capable of querying data from outside the monolith. (That took almost a year.) and then they had to troubleshoot that new framework. (That took the rest of that year.) That 18ish month process took you don’t even wanna know how much “not simple” work to pull off. But before they could do any of that, they first had to figure out what needed to be done and how best to do it without crashing the system. (That took about 6 months.)
So all told, just to do a single one of these “simple fixes” took 2 years and probably somewhere in the neighborhood of a couple million dollars. In the meantime, the list of stuff needs fixin’ has gotten pretty long. And they are starting with the major fixes first since the minor, simple ones are genuinely of lower priority. In due time they’ll get to these simple ones.
Keep in mind that throughout that whole process they also still had to keep up with WotC’s ever increasing release schedule. And the newer material has become more challenging to implement with each new title. For example, the Optional Class Features in Tasha’s took them a year to code, and there are still a few things giving them trouble. Another example is the Artificer also in Tasha’s has some fairly significant changes from the version that came out in Eberron Rising. DDB was still working on fully implementing the Eberron version and all of a sudden they had to scrap a bunch of what they had been working on and start over with the new versions.
The stuff currently in playtest for the upcoming November 16th release of Strichaven is currently completely impossible for DDB to implement in any functional way at all, and they only have 4 months before deadline. Also worth mentioning is that if WotC changes stuff before the final print, DDB won’t see the changes before the week of Halloween. That will leave them little time to program. And they still have some wrinkles to iron out before Beyond the Witchlight is released late September.
As you can see they have a pretty full plate on their table. (And WotC has recently announced they plan to further increase their release schedule next year.)
I hope that helps.
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting
Well, being a software architect this sounds somewhat alarming. Hope they pulled themselves up from the mud by that project. A system like this following the rules set by someone else needs to have the ability to implement every rule that can be written (different than any one might imagine) without getting into the layer that does what the latest posting implied being the 18 months project (scalability). Done that once. Becomes more of a (domain) language design project than what most people understand coding to be, but has been done at least a few thousand times before. Hope that is what they did. If not they need to start asap...
You are right. They basically need a DSL-type approach, but one that can build rules from smaller units. That is what their "Generic Feature System" (or now termed "Universal Feature System" in their dev updates) is supposed to be for. It has been in work for a while and is supposed to be done sometime later this year (probably fall?). With this, then can then implement any rule. Their existing system obviously has dedicated code for all rules. This system essential creates a DSL for any rules, as you put it. Then they can do new rules, epic boons, and other outstanding rules much, much quicker.
They are also working on major changes for the inventory system. Hopefully one of those updates has this small change in it. I, too, am frustrated that this change hasn't been implemented yet, though I understand why it is low priority for them.
That was their plan from the inception, but when they were negotiating with WotC about it all, WotC’s response was a hard. “No. Your system cannot be designed to make anything that anyone could ever imagine. Your system is only allowed to implement official WotC rules.” So that’s what DDB built. About a year later when Ravnica came out some of the new rules were already outside the bounds of the system that WotC had insisted on limiting.
That’s when DDB started planning the whole overhaul. Basically, the have to scrap the entire system that WotC insisted on and convert over to a system more like what they had originally intended, but far less ideal than the original would have likely been. After all, instead of building it up from new with that purpose they are now forced to build from the system they already have and make it work. Considering the fact that the vast majority of users have been blissfully unaware of any of this for the past two years speaks volumes to the skill with which it is being accomplished.
People tend to forget about all the stuff that has been fixed because nobody talks about them anymore. Why? Because they work now. Who notices the 87 bagillion of things that work great? Nobody, they’re too distracted by the, what, half a bagillion things that work “less than great.” Things that used to be glaring system malfunctions are now running smoothly. So smooth in fact that even people who remember when they weren’t smooth forget they weren’t smooth before.
For example, people complain because their homebrew takes a few minutes to update. Nobody remembers that only 24 months ago, those same homebrews would have been crashing character sheets left and right because they were set up incorrectly or incompatible with each other. Why does it take some time to update now? In part because they have to progress through several server caches when before there was almost no caching required at all. But also because the system is compensating to make sure sheets don’t crash from poorly implemented ‘brews. Now, for bad homebrew to crash a sheet it has to be really bad, and their needs to be a lot of it.
Homebrew’s my jam, I am almost constantly working on several projects at a time. in addition, for a couple years now one of my favorite pastimes has been throwing everything I can at this system just to se what it can handle, and how I can break it. It helps me better design new stuff, but also keeps me ‘brewing when I hit a block so I can work through that creative block. Before I could snap it like a twig without effort. Just a couple magic items with a goofy* modifier on each would jam each other up something fierce. Now, there are a couple few things that I know will crash a character sheet, but those are specifically the things DDB says “don’t ever do this or it will crash character sheets.” Other than those, it’s now really, really unlikely for almost any combination of things to accidentally crash sheets anymore.
Trust me, they have been making vast improvements for almost a year now, but most people don’t notice. Usually because they happened to not have encountered that flaw before. Or they did and forgot about it or didn’t realize it wasn’t working correctly last time, or whatever. Nobody talks about how Favored Enemy or Disciple of Life didn’t used to work because they work fine now. So the real measure is not how many things people are still complaining about, it’s in how many things people stopped complaining about. But again, nobody notices those. 🤷♂️
The other reason some of this stuff takes a while is because they are hyper cautious to ensure nothing they fix will break anything else. Take this decimal value bug for example. They might have identified a fix they could have in place by close of business. But they might also have discovered that if they do it that way it might cause issues to 5% of the character sheets that have custom equipment. If they have also identified an alternative solution that will have absolutely no adverse affects whatsoever, but will take 12-24 weeks to implement because it means tweaking something else first, then that’s the one they’re gonna go with. And if they could get a better short-term juice:squeeze by spending that same 12-24 weeks fixing or implementing a different project, then it gets bumped.
If you ask me, they might be a little overly cautious at times. Sometimes the bandaid approach really is the less painful method. For example, the fix to Favored Enemy required “breaking” every Ranger character sheet on the sight.^1,2 They felt like dirty, dirty sinners for it. But it really wasn’t all that bad. After all, it took a legitimately game experience affecting bug and turned it into a nuisance that only persists for old PCs. AFAIK, every Ranger made new since then is experiencing no issues whatsoever. Yes, I think there were some other unintended consequences as well.^3 But again, the issue that got fixed was way more of a problem for folks than the new glitch that only pops up if you dupe a PC. Lots of people play Rangers every minute of every day. A handful of folks copy a character once in a while, and while the display in the builder is affected, the actual character sheets themselves display and function correctly. I count that as a win, and not a pyrrhic victory either. The juice:squeeze appears worth it, at least from where I’m sitting.
Footnote and references:
*(By “goofy Modifiers” I mean some that were designed and implemented for one type of thing being used on something completely different. Like something designed for a class used in a feat or vice versa. Or some that appear to do one thing as long as it’s viewed in a vacuum, but actually does something else. Only, that “something else” was unnoticeable until a second magic weapon gets added to the same character sheet. Stuff like that.)
^1(https://www.dndbeyond.com/forums/d-d-beyond-general/news-announcements/90361-updates-to-ranger-characters)
^2(https://www.dndbeyond.com/forums/d-d-beyond-general/bugs-support/90737-issue-with-ranger-favored-enemy-update)
^3(https://www.dndbeyond.com/forums/d-d-beyond-general/bugs-support/90399-copy-character)
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting
Noticed recently how stuff like the notifications go a li’l wonky from time to time and then seem to resolve themselves? That stuff happens when they are doing big updates behind the scenes. Every time that stuff happens they are mowing their line of scrimmage 10 yards closer to that end zone.
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting
still no decimals
I am also here.
Am snek.
No, people tend to forget about the stuff that has been fixed because the developers don't seem to communicate. There's no "frequently requested features" thread for people to fall back on and prevent these threads from happening. The roadmap is offline, the developer updates scarce, the feature request portal abandoned. People don't talk about the stuff that's been fixed because we can't tell that there are currently things that are being fixed. Far fewer people catch the fixes because they haven't been anticipating it ahead of time.
Leaving OGL 1.0(a) untouched and making SRD 5.1 CC-BY-4.0 is a great first step. The next is a promise to do the same for future editions. Here's a discussion thread on that.
#OpenDnD
DDB is great, but it could be better. Here are some things I think could improve DDB
I will say that I was very excited about the container support being added. As someone who likes to have/use lots of items with my artificer, that is really helpful. I know that feature originally didn't have support for custom items, and I was hopeful that when the custom items were added back, that it would include this bug fix. Alas, it did not.
still an issue in sept 2022
Yup still an issue in September 2022. Tad disappointing to read this because I've just migrated my group to use D&D Beyond from a VTT to manage their character sheets on.
I am making some Blight Seeds that have a street value of about 3 silver pieces... NOT A GOLD COIN! I think as a work around, I'll add the value into the description but.... It's not really good is it?
Whats interesting is that a 'Candle' has a item cost base of 0.05 gold value and a 'Waterskin' has a cost base of 0.2 gold value.
This really shouldn't be that hard to fix. Just add in a "step" element to the appropriate HTML/CSS tag (I found out that items already in the system have this "step" element, whereas custom items do not). "Step" controls the increment, and not having a "step" makes the increment default to integers/whole numbers. It shouldn't take more than 10 minutes to find the relevant webpage file and make the modification. Then another 10 to find the relevant backend attribute to edit so that what is saved reflects what is intended, as well as to ensure errors aren't thrown. Allow an hour or two for dedicated testing, then push to live.
Having said that, IamSposta's point about them being cautious of fixes breaking other things is very appropriate, since it happens literally every day in IT. Same for his point about feature priorities; this one is just too small to be higher on the list. Do I wish it was higher? Yes, but I can also understand why it isn't.
I think the biggest potential roadblock for this would be if they have been keeping Custom Items in a different database table from the other items in the inventory.
If this were the case, the it is possible that the Custom Item tables has weigh and cost as integers instead of floats. Changing that data type would require a data migration which is never fun.
Presumably for inventory, they are using a ForeignKey to a table with official and homebrew items in it, and then having other fields for quantity and all the customization options. Instead of supporting the whole CustomItem table, they could make a CustomItem item and use the existing customization infrastructure. The only difference would be adding support for custom descriptions. This would be a more performant and maintainable final solution.
I wouldn't be surprised if the goal is to get rid of a CustomItem table, and therefore there is a desire to avoid "throw away" work on features for it. The work to remove the CustomItem table would be non-trivial however, so it gets delayed in favor of other features. It's technical debt that has a low interest rate.
All of this is of course just conjecture since I haven't seen their source code or database schema. I'm just making educated guesses based on my experience in maintaining software tools and the observations I've made about the particular way things operate and break.
You got that right. The rest, ... as a software architect I feel I should just not comment on.