I noticed that Ghosts of Saltmarsh isn't in the encounter builder with the rest of the books, is this intentional, or a bug on my end?
I looked around, and asked in the Discord, but I couldn't seem to get an answer, so I was just curious. If this was answered somewhere else, I really apologize!
Otherwise, the Encounter Builder is fantastic, and the team at D&D Beyond are incredible!
Out of pure curiosity, why do those sources need to be added to the Encounter Builder? By that, I mean, aren't they all drawing from the same DB? What is different about the EB that it doesn't have unrestricted access to the regular DB? Are there multiple DB's per access method?
Rollback Post to RevisionRollBack
"Most people are other people. Their thoughts are someone else's opinions, their lives a mimicry, their passions a quotation."
Out of pure curiosity, why do those sources need to be added to the Encounter Builder? By that, I mean, aren't they all drawing from the same DB? What is different about the EB that it doesn't have unrestricted access to the regular DB? Are there multiple DB's per access method?
Items are associated to different 'sources' (read: books) so that all the data can be entered without becoming immediately available (prior to release) as it is plugged in. This also correlates to purchasing a 'source', rather than all the data free-flowing in the same database. Likely, the EB hasn't been setup yet to include the new sources as of yet.
Out of pure curiosity, why do those sources need to be added to the Encounter Builder? By that, I mean, aren't they all drawing from the same DB? What is different about the EB that it doesn't have unrestricted access to the regular DB? Are there multiple DB's per access method?
When D&D Beyond was first launched, it was a single application with a single data store. As we've been growing the team and the site, we've been slowly breaking it up into smaller more extensible and manageable chunks (it's much easier to share work between 3+ teams if they aren't all working on the exact same codebase). This lets us more rapidly develop and deploy new features, but sometimes there are growing pains while we're on our journey to our ideal future architecture. Some examples of other places we've split out functionality into separate codebases are the twitch extension, the mega menu, the login system (Google sign in), vehicles (GoS).
The encounter builder was a natural fit for a project to develop a monster API alongside, since it so heavily integrates with monster data and is our first big user-facing alpha feature. As you can imagine, replacing all monster-related functionality on DDB is a rather large undertaking so we've been doing it piecemeal and using the encounter builder as the test-bed for the new monster API. There's still a lot more functionality to add before we can swap over the entire site to use the new API so in the meantime, we need to synchronize the site data to the monster API.
As for GoS and AI monsters specifically, they just happened to be added to the production DB after our last full sync. We've been putting in place systems to make syncing data easier during alpha, since we want to make sure that you can always use all of your purchased content, even with an alpha product. Once we get the monster API to feature parity with the full site and swap everything over to use it, we won't have to worry about synchronizing monster data anymore and everything will just be using the same API and data source.
To give some insight as to why we've been releasing encounter builder versions with partial features or data: it's because our main priority with the encounter builder alpha is rapid feedback and iteration. We want to get your feedback on new features as soon as possible so we can course correct quickly if a feature isn't solving the user need like we thought it would or if feedback reveals better ways to meet the same need. When there's a tradeoff to be made between getting faster feedback and polishing a feature, we've been erring on the side of faster feedback.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I noticed that Ghosts of Saltmarsh isn't in the encounter builder with the rest of the books, is this intentional, or a bug on my end?
I looked around, and asked in the Discord, but I couldn't seem to get an answer, so I was just curious. If this was answered somewhere else, I really apologize!
Otherwise, the Encounter Builder is fantastic, and the team at D&D Beyond are incredible!
Ghosts of Saltmarsh monsters are not yet in the encounter builder, but we're adding them in soon.
Thanks for helping us test the encounter builder! :D
Thank you so much for a quick reply! I can't wait to see it all up there! ^_^
Good to know, I thought I was somehow spelling Pirate wrong! Haha. Thanks, I'm loving the encounter builder so far!
With another new book released is there any ETA on when Saltmarsh content might be available?
Don't worry - both AI & GoS are coming soon to the Encounter Builder - sit tight until then! :D
Out of pure curiosity, why do those sources need to be added to the Encounter Builder? By that, I mean, aren't they all drawing from the same DB? What is different about the EB that it doesn't have unrestricted access to the regular DB? Are there multiple DB's per access method?
"Most people are other people. Their thoughts are someone else's opinions, their lives a mimicry, their passions a quotation."
― Oscar Wilde.
Items are associated to different 'sources' (read: books) so that all the data can be entered without becoming immediately available (prior to release) as it is plugged in. This also correlates to purchasing a 'source', rather than all the data free-flowing in the same database. Likely, the EB hasn't been setup yet to include the new sources as of yet.
[ Site Rules & Guidelines ] --- [ Homebrew Rules & Guidelines ]
Send me a message with any questions or concerns
When D&D Beyond was first launched, it was a single application with a single data store. As we've been growing the team and the site, we've been slowly breaking it up into smaller more extensible and manageable chunks (it's much easier to share work between 3+ teams if they aren't all working on the exact same codebase). This lets us more rapidly develop and deploy new features, but sometimes there are growing pains while we're on our journey to our ideal future architecture. Some examples of other places we've split out functionality into separate codebases are the twitch extension, the mega menu, the login system (Google sign in), vehicles (GoS).
The encounter builder was a natural fit for a project to develop a monster API alongside, since it so heavily integrates with monster data and is our first big user-facing alpha feature. As you can imagine, replacing all monster-related functionality on DDB is a rather large undertaking so we've been doing it piecemeal and using the encounter builder as the test-bed for the new monster API. There's still a lot more functionality to add before we can swap over the entire site to use the new API so in the meantime, we need to synchronize the site data to the monster API.
As for GoS and AI monsters specifically, they just happened to be added to the production DB after our last full sync. We've been putting in place systems to make syncing data easier during alpha, since we want to make sure that you can always use all of your purchased content, even with an alpha product. Once we get the monster API to feature parity with the full site and swap everything over to use it, we won't have to worry about synchronizing monster data anymore and everything will just be using the same API and data source.
To give some insight as to why we've been releasing encounter builder versions with partial features or data: it's because our main priority with the encounter builder alpha is rapid feedback and iteration. We want to get your feedback on new features as soon as possible so we can course correct quickly if a feature isn't solving the user need like we thought it would or if feedback reveals better ways to meet the same need. When there's a tradeoff to be made between getting faster feedback and polishing a feature, we've been erring on the side of faster feedback.