0 of 0
File information
Created by
SpiderbuttonsUploaded by
SpiderbuttonsVirus scan
Some manually verified files
Notifications
71 comments
[10:19:25 ERROR Button's Extra Trigger Action Stuff] Error in BETAS.RelationshipChanged_Game1_newDayAfterFade_Transpiler: System.InvalidOperationException: Could not find proper entry point #1 for Game1_newDayAfterFade_Transpiler - Current state is invalid at HarmonyLib.CodeMatcher. ThrowlfInvalid(String explanation) at HarmonyLib.CodeMatcher. ThrowlfNotMatch(String explanation, CodeMatch[] matches)
at BETAS. Triggers. Relationship Changed.newDayAfter Fade_Transpiler(Enumerable 1 instructions, ILGenerator il)
2) If you are playing on PC, can you please launch the game, type "harmony_summary" into your SMAPI console, and then upload your log to smapi.io/log and send me the link to it?
I've been very interested in this mod, and I have to say that this and mushymato's MMAP are the best modding tools ever made for SDV 1.6. I’d like to offer a few suggestions—please consider them if you find them suitable within BETAS' scope, some I can replicate with the current version of BETA (just need a little workaround):
Game State Queries:
- Spiderbuttons.BETAS_PLAYER_NEAR_AREA: Similar to NPC_NEAR_AREA, but checks whether the player is near a specific area. This could be useful for changing parts of a map without interrupting player control.
- Spiderbuttons.BETAS_WEATHER_YESTERDAY: Similar to WEATHER_FOR_TOMORROW, though I doubt it would be useful most of the time. (I could replicate this in current version with WritePlayerModData function.)
- Spiderbuttons.BETAS_QUERY <QueryExpression>: Similar to CP's Query; provides a way to use operators within the GSQ context (+, -, IN, OR...), since you have had Tokenizable Strings works with BETAS' GSQ, maybe this will be useful?
Trigger Actions:
- Spiderbuttons.BETAS_MultipleAction: similar to RandomAction, but it executes all listed actions instead of selecting one at random.
- Spiderbuttons.BETAS_EditMapProperty <mapName> <property> <value>: edits a map property.
- Spiderbuttons.BETAS_EditTileProperty <mapName> <x> <y> <property> <value>: edits a tile property.
- Spiderbuttons.BETAS_ReplacePlayerModData: combines RemovePlayerModData and WritePlayerModData into a single operation.
- Spiderbuttons.BETAS_SortPlayerModData: Used to sort the list of values in a given key, combined with ValueAt below to get the smallest/largest/first/last value of that key. (I'm not entirely sure how this would work either, or how it would be useful, but it would be great if you can pull it off.)
Tokenizable Strings:Map Related:
PLAYERMODDATA related:
That's is all for now, I may propose more ideas in the future, but thanks for taking your time reading this long comment. Wishing you the best.PLAYER_NEAR_AREA: Doable enough! I can work this one in.
WEATHER_YESTERDAY: Not as easy as it might seem! The game doesn't store this information itself anywhere, so I would have to store it myself, and I'd really like to avoid doing this in BETAS when possible! Because if I have to store data myself, it means something using this GSQ would not work properly when it is freshly installed or installed mid-save, because it wouldn't have had time to store the data yet, and that could lead to things not working when someone expects them to. I'd recommend just using the mod data reading/writing actions for doing this yourself.
QUERY: Also probably doable, I'll have to look into how CP does it if it's easily recreatable.
Return: Not really possible with how triggers and actions work in game! Not going to be implemented.
Switch: Potentially doable, though similar/identical functionality should already be possible with vanilla's "If" action or with BETAS (potentially combined with other frameworks) so lower priority.
MultipleAction: Planned! Just haven't gotten to it yet.
Regarding the ones about editing map or tile properties: those will not be included as actions. Doing any edits to assets like that should always be done via the content pipeline (if you're using Content Patcher, this means for example using an EditMap patch). Doing otherwise has a high chance of breaking things and a 100% chance of being not permanent and being undone any time another mod does an actual patch to a relevant asset.
ReplacePlayerModData: You can already use WritePlayerModData to overwrite the mod data!
SortPlayerModData and PlayerModData_ValueAt: I can consider it, but until someone can come to me with a valid usecase for it and where this sort of action/tokenizable string would be the only way to do it, I'm not going to worry too much about it.
I have a question: If we can't patch a tile using Trigger Actions, is it possible to bypass that by directly calling a map Action or TouchAction? As far as I know, there are certain features that can only be triggered by interacting with or stepping on map tiles, such as OpenShop, AdventureShop, Blacksmith, Billboard, Concession, Cooking, and so on.
If that's not possible, would there be a chance for something like an OpenMenu or CloseMenu trigger action for those menu that aren't normally accessible?
Thanks again for reading my previous comment. Please don’t take this as a suggestion or request or anything—I'm just genuinely curious about how far Trigger Actions can go. It's a quite powerful tool, after all.
Most of the vanilla map actions, like Message, Dialogue, and Warp - are already well replicable, so I’ll mostly focus on just the Menu and Door actions.
- From a map-related perspective, this would allow GSQ checking and do other actions before opening a menu. Currently, only one vanilla map action actually supports GSQ checking: ConditionalDoor. However, even ConditionalDoor doesn’t support GSQ’s ANY argument (which I suspect is a bug). All other map actions rely on hardcoded conditions, which isn’t very intuitive.
When I say “do other actions”, I mean that each vanilla map action only does exactly one thing—for example, OpenShop opens a shop, and may fall back to a ClosedMessage, which is hardcoded. You can’t randomize the ClosedMessage based on conditions, and you can’t use that same tile to add a flag, open a letter, trigger an NPC reaction, etc., unless you rely on a Content Patcher MapPatch.
Well, you could argue that shop behavior doesn’t need to update on tick, and that EMP already supports GSQ as CP tokens—so I’d agree there’s no strong need for OpenShop trigger action. However, Door actions would benefit significantly from GSQ checking and tick updates. Being able to evaluate GSQ and perform multiple custom behaviors, while still having the door animation and opening the door normally could be extremely useful in various scenarios.
TL;DR: I want a tile to be able to do something like:
If x, play an event.
If y, open a shop as usual.
If z, do some other stuff.
If m, open a shop with a different ID.
And so on—same applies to Door, if it's doable of course.
- From a non-map perspective, being able to open menus using triggers (like ItemUsed or others) would make all menus effectively 'portable'. Combined with SpaceCore’s Guidebook UI, this could allow for more advanced idea, for example, I can pull off a entirely functional mobile phone with online shopping. But that’s an idea for another day.
Of course, if the trigger action could not just replicate but also invoke the map action directly, that would open up the possibility of using other modded map actions (like those from MMAP or MEEP) as trigger actions.
Again, this isn’t a formal suggestion, just an idea I thought I’d like to share. Thanks for reading all of this, and I really appreciate the quick response.
The problem with a trigger that does what you want is really just a matter of making sure it's generic enough that I don't need to hardcode functionality for every possible map action that exists but also not too generic that it's hard to even make it function correctly. Opening and closing menus with an action is technically possible, but consider OpenMenu for example: what does the modder such as yourself write as the argument for the action? How would I know what menu you want to open? You can write "OpenMenu Shop <shopId>", and I could check for the first argument being "Shop" and then know I need to look for a shop Id next, but that means I would need one giant If statement checking "Did they write Shop? No, okay, did they write Forge? No, did they write Letter? No, what about Dye? No, okay, did they write..." and so on, for every menu that exists, and then it wouldn't account for modded menus either! I could hardcode support for SpaceCore's guidebooks, but I can't hardcode support for every single custom menu out there. Otherwise the alternative is writing separate actions for each menu, which is similarly unwieldy and requiring hardcoding.
What I can do is add an action that just invokes an existing map action instead, like you suggest, and I'd just have to give some random coordinates (probably the player location) and hope it works out, and it'd be up to the mod author to make sure that's fine. That I can do! Combined with SpaceCore's TriggerAction map action should get one pretty far, I think.
My SMAPI log here in case it was really a bug: https://smapi.io/log/242205a0857543de8b8b1cb2a1d8b82a
Thank you in advance for the help.
Before that though, I'd also like to ask to make sure—you ran the action after Content Patcher's patches all updated, right? And you've made sure that when you spawn a fresh weapon, its projectiles are correct, and it's just the one you tried to reload that is wrong?
EDIT: I also tried reloading the Edibility field of a food item, and it seemed to work correctly this time. Maybe Weapon doesn’t count as Item in this context?
I want to create an item that works like a book, allowing players to open it page by page, or a secret love letter that can be kept in the inventory and reopened later. Something similar to MEEP's Closeup Interaction or Letter Type, but linked to item usage. So far, SpaceCore already has an "item used" trigger, but I haven't been able to find a trigger action like the one MEEP had.
Thank you in advance for creating this mod, it's a great mod regardless.
{
"Action": "EditData",
"Target": "Data/TriggerActions",
"Entries": {
"HFM1Use": {
"Id": "HFM1Use",
"Trigger": "Spiderbuttons.BETAS_ItemUnequipped",
"Condition": "ITEM_ID Target 458",
"Action": "Spiderbuttons.BETAS_DialogueBox Null Strings/Events:Heartforge.Mod.1"
}
}
},