Summary
It’d be great to have a basic API for Junimatic that lets other mods enable/disable/unlock features directly. Nothing crazy, just a way to flip things on/off without relying on config or game progress.
Proposal
Setup simple IJunimaticAPI.cs with functions like:
bool minerQuestEnable(bool? value = null); // enable/disable/query quest
bool minerQuestUnlock(bool? value = null); // enable/disable/query unlock
Pass in true/false to set, or leave null to query.
Modify Unlock Checks:
In the Unlock<Feature>.cs files, append code such as
public bool IsUnlocked => ModEntry.Config.EnableWithoutQuests || Game1.MasterPlayer.eventsSeen.Contains(MiningJunimoDreamEvent)
|| ModEntry.API.minerQuestUnlock() // addedFor each corresponding quest gate, simply add a check to ensure the quest is still enabled in the API.
private void Player_Warped(object? sender, WarpedEventArgs e)
{
if (e.NewLocation is MineShaft mine
&& e.Player.IsMainPlayer
&& !ModEntry.Config.EnableWithoutQuests
&& this.mod.UnlockPortalQuest.IsUnlocked
&& !this.IsJunimoChyrysalisFound(e.Player)
&& ModEntry.API.minerQuestEnable()) // added
{
var bigSlime = mine.characters.OfType<BigSlime>().FirstOrDefault();
if (bigSlime is not null)
{
var o = ItemRegistry.Create<StardewValley.Object>(JunimoChrysalisQiid);
o.questItem.Value = true;
bigSlime.heldItem.Value = o;
}
}
}Portal Quest
Bit of a special case. I would recommend allowing the API to simply disable this quest, then either allowing the API implementers to add the recipes themselves, or for a more friendly API include a function to add the recipes to the player, api.addPortalRecipes()
With that, I don't think there is a need for any additional API. Machines can already declare their respective type by setting a CustomField.
Summary
It’d be great to have a basic API for Junimatic that lets other mods enable/disable/unlock features directly. Nothing crazy, just a way to flip things on/off without relying on config or game progress.
Proposal
Setup simple IJunimaticAPI.cs with functions like:
Pass in true/false to set, or leave null to query.
Modify Unlock Checks:
In the
Unlock<Feature>.csfiles, append code such asFor each corresponding quest gate, simply add a check to ensure the quest is still enabled in the API.
Portal Quest
Bit of a special case. I would recommend allowing the API to simply disable this quest, then either allowing the API implementers to add the recipes themselves, or for a more friendly API include a function to add the recipes to the player,
api.addPortalRecipes()With that, I don't think there is a need for any additional API. Machines can already declare their respective type by setting a CustomField.