-
Notifications
You must be signed in to change notification settings - Fork 2
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 initialisation from the application #34
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some fuctions was previously in `rutilstimflutre` package but it would be more convinient to have there here in order to maintain them more efficiently.
Befor this commit, the games "constants" was accessed through a global variable (and used in both UI and server parts). The problem with this design is that those values may not be updated if changed in the data-base. (this is not currently possible but it is planned to be implemented). I have refactor so that those values are always read from the DB. When those constants are used in "calculations" they are requested to the DB with `getBreedingGameConstant()` When those constants are shown in the UI, a "shiny module is used" to ease the developement (cf. `./src/fun/constants_module.R`). All the "servers outputs" for those values are defined in `src/server/server_constants.R`.
The setup script add only add (or overwrite) new files/data to this folder. So if it already exists the resulting data may contain the previous content of the folder, which do not correspond to a "fresh game session".
Now when a breeders are added/deleted, the breeders lists automatically updates to show the correct list. No need to reload the page anymore. The desing used to make that can serve a a base for similar behaviour in the future.
This helps to modify the db requests behaviour accross the entire app. - `db_get_request` is for SELECT request - `db_execute_request` is for the orther requests
To avoid the error: The `name` provided ('user-o') does not correspond to a known icon
For that some refactoring had to be done, mainly about the UI loading of the menus that cannot be used if the game is not initialised.
With this feature, the admin can initialise (or re-initialise) the game from the app directly.
Ok for me. That's cool that the code keeps living so much, good job @juliendiot42 ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am sorry this is a rather big PR but a lot of refactoring had been necessary to implement that. (And I took the opportunity to make the code cleaner).
This PR implement a way to initialise the game from the application so that user do not have to manually run the
plantbreedgame_setup.Rmd
file.@timflutre, I do not expect a complete review as it is quite big, and nothing seems to broke (thanks to the tests). However, I made one small change that I would like you to be aware of:
Before in the "theory menu" some boundaries of the inputs were specified using the game constants (
mu.trait1
,sigma.p2.trait1
). Now since those values may not exist if the game is not initialised, I used fixed values instead (it was much easier to implement, and I use the same as what is inplantbreedgame_setup.Rmd
).That mean now the theory tab and the game's constant are disconnected.
Personally I think it is OK like that. I think that if this is just the "theory" there is no reason to have this linked to the actual game values. But if you would like it to be the case I can take some time to implement it, (or I can explicitly mention that the values are not related to the game).