Sometimes, in an effort to go quickly, I’ll copy an existing agent whose query I want to modify. The result is that the new agent that has the wrong aliases until it updates.
I feel like I must be missing something:
Is there any way to clear or run an agent as soon as the query is changed?
Is there some better way to copy an agent, that avoids this complication? (I could go in to the original agent, navigate to its query, copy that, create the new agent and paste, but that seems like too many steps.)
Some other obvious solution I’ve not even imagined?
I had an agent with a typo, returning ~100x more results than expected, and then a few hundred lightweight agents querying that. Savefile size exploded from ~7Mb to around 1GB.
I reverted to backup and have a fixed and working document now, but the experience may indicate an edge case. It really felt like the agents’ execution thread just gave up.
Very possibly! There’s only one action thread, and with hundreds of agents doing 100x of the expected workload, it might be the case that work accumulated faster than it could be performed.
If you experience this a lot you could create a stamp, or even a $Prototype for your agents. The action code could look something like this.
//Delete aliases. Assume you have $Checked in the $Displayed Attributes. Name stamp 'stmDelete Aliases'
if($Checked==true){
var:list vList=collect_if(children,$IsAlias==true,$ID); //if condition ensures w'ere only deleting aliases
vList.each(x){
delete(x);
};
};
This stamp will cycle through every alias of an agent an delete them.
In an agent prototype, you may include stamp=("stpDelete Aliases");.
Another simple trick when closing is to turn the agent off, duplicate/copy-paste it, edit the Query to something you know returns nothing, turn back and the aliases are cleared out. Then leave or or off while to add your desired new query.
Agents, when turned off, work the way they do (retaining existing aliases), for a deliberate reason. In many cases, once the agent has matched data that changes little/never, there is no point in constantly running the query as the results don’t change, and if the underlying data changes one can re-enable the map.
What a different subset-of users do, which ill fits the above, is to make an agent and re-use it wirth differing queries as needed as they like having an agent set up ready (and likely in a known place in th doc). What is lacking - and perhaps a feature request for someone with the need to request is a flag to tell Tinderbox to remove all aliases when the agent is disabled. That doesn’t break the status quo, but allows for the alternate use. Ideally id would be a system attribute as inevitably deeper users will want agents with both behaviours in the same TBX.