Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

game.dnd5e.dice namespace vs. import usage #581

Closed
aaclayton opened this issue Jul 12, 2020 · 2 comments
Closed

game.dnd5e.dice namespace vs. import usage #581

aaclayton opened this issue Jul 12, 2020 · 2 comments
Labels
api won't change This will not be worked on

Comments

@aaclayton
Copy link
Contributor

Originally in GitLab by @LimpingNinja

In dnd5e.js during init you populate the namespace game.dnd5e.dice with the imported modules/dice.js

Though every other place you use it (mainly module/item/entity.js and module/actor/entity.js) you import it directly instead. You also don't appear to be using this namespace for anything specifically. From an outside extensibility view (though you may not want that) it seems like you could just modify the entity.js items to use game.dnd5e.dice.d20Roll and game.dnd5e.dice.damageRoll instead.

From a selfish personal perspective I want to use 1d8+1d12 for a few sessions because the players want to test it out. If these couple locations were changed to use the namespaced function it makes it available to substitute (at owners discretion) with a custom roll functionality.

Obviously non-standard dice is not part of core, and this may not be a functionality you wish to expose but just wanted to bring it up out of curiosity.

@aaclayton
Copy link
Contributor Author

Sorry I missed this one in 0.94 - I should have made this change but I'll get it for the next one.

@aaclayton
Copy link
Contributor Author

Took a look at this and decided that it's not something I plan to change for now. The purpose of providing the global reference to game.dnd5e.dice is so modules can use the d20Roll and damageRoll functions - but providing support to override those functions is a further step that would have other consequences that I don't want to take on at this time. Sorry!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api won't change This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant