Tinderbox Forum

Cant crack this nut - descendedFrom (parent(agent)) works for me in all cases except one!

First, - I am a new user, bursting with admiration. The freedom of the hypertext and the ability to bring things to the top with agents is absolutely wonderful, and like nothing I have come across before. It solves so many problems.
I am gradually learning how to do things in this environment, but one particular case is proving difficult…
To put the problem as simply as I can: my agent query is designed to return “meetings” (a prototype) in a particular sub-path, but, unfortunately, it supplements the result with meetings from another completely unrelated path. This is what the query looks like

descendedFrom(parent(agent)) & $Prototype==“Meeting”

I have the same problem even if I ‘hard code’ the path
descendedFrom ("/LCC/MA/") & $Prototype==“Meeting”

If I use any other prototype the returned list is correct. The query also seems to work perfectly when placed in other paths, and will return meetings for all descendants of the parent in which the agent is placed.

Ps The additional 'Meetings" come from a path ("/Music Projects/Scored out/Bournmouth planning")
Im a bit mystified, and feel I must have missed something basic.

It made me wonder if I should start using separate files for different projects, which might be a good idea anyway, but that is a different problem.

Im very grateful for any help or pointers,

PS It seems if I delete the agent and then recreate it, the query works correctly. (Whilst if I simply change the query text within the agent the problem persists) . I will see how long this remains true.
Sorry to be obsessive

Welcome to Tinderbox!

It often helps others sort out what the issue is if you could post a sample file (personal info removed) to this forum. You can upload .tbx files here.

Apart from that, I wonder if there are two “Meeting” prototypes in the file? Or a rule or other feature of the prototype that is causing the failure.

Dear Paul,
Many thanks for your reply.
I wondered the same thing, and have checked for any oddities, either in prototypes or other agents, searching in diverse way using the attributes browser, but all seemed clear,.
The thing is- it is now working. - . Deleting the agent and then creating a new one with the same query code seemed to fix it.
I was not intending to delve into such a potentially complex area so soon (ie recursive parenthood, virtual self referencing etc) but very happy that it is doing exactly what I hoped.
Very best wishes

1 Like

This is a tricky case!

The aliases inside your agent are descended from the agent. Of course, they’re also descended from the agent of its parent. As a result, any meeting that’s listed by the agent continues to be found by the agent, wherever its original resides. (Things that aren’t meetings don’t satisfy the second clause.) As a result, deleting the agent and making a new one finds different notes.

Many thanks, Im honoured to have a reply from the creator himself.
I can see how the problem happened then, (perhaps). The initial agent query was slightly wrong (a backspace missing in the path or something like that) and it captured objects from all over the place. Then, when I corrected the agent query (rather than deleting the agent) it quite reasonably included the descendants of its parent, including parts of its own earlier (incorrect) list.
Im happy that this initially mysterious behaviour makes sense (even if this interpretation isnt quite right)
Many thanks for your help. I am staggeringly impressed with the software and the thought processes around it. What a liberation it is.
Best wishes

1 Like