Problem Description
A cross grimoire dependency is a mechanism by which spells can inform sorcery of what grimoires to look in for a particular spell or provider if they dont already exist in the current grimoire, or there are more providers in another grimoire.
It should be noted that this mechanism is only needed if the user does not have the necessary grimoires installed. Currently this is just games and z-rejected. Occasionally a spell will require something that only exists in another grimoire, such as JAVA. If the (new) user doesnt have z-rejected added the dependency wont be resolved and the parent cannot be cast.
Existing Setup
Currently we have depends and optional_depends, these are overloaded such that one can specify either a single spell or a provider, by convention providers are upper-case, spells are lower case, but sorcery makes no such distinction. The parameters are as follows
depends "spell depended on" "enabled options" "description" depends "provider required" "enabled options" "description" optional_depends "spell depended on" "enabled options" "disabled options" "description" optional_depends "provider requested" "enabled options" "disabled options" "description"
Sorcery actually determines the difference by seeing if the spell depended on exists, if so it must be a "spell" dependency, if not it is a provider. If the grimoire holding the spell doesnt exist then the code will unfortunatly assume this is a provider. If we had kept the depends and requires clauses seperate there wouldnt be this mess, but with the current setup, we must add the grimoires before determining if this is a spell or a provider dependency.
Implementation Outline
For cross grimoire dependencies another single optional parameter will be added. For depends this is will be the fourth parameter, for optional_depends this is the fifth parameter. If the parameter is not specified the spell/provider is assumed to exist in one of the pre-existing grimoires as is already the case. In other words this is completely backwards compatible. If no grimoires are specified none of the cross grimoire code will be looked at.
If there are multiple grimoires the parameter must be quoted properly.
Grimoires will be added with "scribe add <grimoire name>", which means they will be added from the default sourcemage codex location. There is currently no supported mechanism by which one can get grimoires from any other location. This is not an important requirement for this features functionality, but may be added at a later date.
In the case of "depends" at least one of the grimoires must exist, so the user will be queried for which ones they want, and after all is said and done, if there aren't any grimoires installed the depends must fail. If all the grimoires are installed the question is short circuited.
In the case of "optional_depends" the user will be queried for which grimoires they want out of the ones that are not already installed, if no grimoires are installed the dependency is marked as off because it is optional.
A special grimoire name of "current" may be used to denote that some providers exist in the current grimoire (which may in theory be the stable/test branches of the same main grimoire). This avoids the need to list all branches and needlessly query the user about downloading other branches of the same grimoire, and removes any requirement to change "test" to "stable" when integrating from test to stable.
The function calls are now: depends "spell depended on" "enabled options" "description" "grimoires" depends "provider required" "enabled options" "description" "grimoires" optional_depends "spell depended on" "enabled options" "disabled options" "description" "grimoires" optional_depends "provider requested" "enabled options" "disabled options" "description" "grimoires"
(not that all the fields except for the first one are still optional)
Known Problems (and some solutions or comments)
- If someone really doesnt want a grimoire installed whenever they cast a spell that depends or optionally depends on a spell in that grimoire they will be asked if they want to add it. In the case of at least of the grimoires existing (such as current) the default answer to adding the grimoire will be "no", but the user will _always_ be given the query. This is unfortunate for those who, for example, dont want the z-rejected grimoire and want to use free versions of the provider. One solution to this is to add a dummy grimoire under the name of z-rejected, and localize it so its not updated. The implementation is sufficiently dumb enough that it wont actually check if the grimoires have the providers or not, just that they are installed.
Updates are not automatic. Normally with providers one can say that a spell provides something and all the other spells that need it "automatically" know about that provider during depends resolution. Because cross-grimoire depends is an attempt to wander into the unknown, no automatic updating can occur. Therefore spells that require something from another grimoire must explicitly say what grimoires those are. If the providers in the secondary grimoire stop being providers dependent spells must too be updated. There is no simple way to avoid this problem other than including information about all the grimoires seperatly from generating it from within the grimoire. There is no plan to change the current setup, and therefore this problem will not be solved, ever. The cross-grimoire case is rare enough as it is, so the case of a cross-griomire provider changing providerness is sufficiently rare that it is not worth the effort in sorcery to solve the problem
- Some users may have a slow connection and will not want to wait for a grimoire to download during dependency resolution. The cost of downloading an extra grimoire has to be paid exactly once. The defaults are safe, the grimoire is only automatically downloaded if its needed. Also the games and z-rejected grimoires are fairly small in comparison to the main grimoires which the user should already have.