Consumables In Suggested values of a string attribute

[fidel (Fidel Namisi)]

Suppose I have I have a list of ten fruits

Apple;Banana;Cherry;Dragonfruit;Elderberry;Fig;Grapefruit;Honeydew;Kiwi;Lemon

And they are the suggested values of a String Attribute called $FruitsAvailable.

Suppose that when I select For Note 1, $FruitsAvailable = “Fig”.

Then for all the other notes that have the same prototype, “Fig” should disappear from the suggested values of $FruitsAvailable.

In other words, [suggested values] should update to these suggested values: Apple;Banana;Cherry;Dragonfruit;Elderberry;Grapefruit;Honeydew;Kiwi;Lemon
(Fig is now gone from the list).

How would I go about doing that? I experimented with different takes on what’s outlined here, but with no luck.

Thanks for the help! And I’ve attached a sample file as well, if it’s of any use. Thanks again.
Fruits Available.tbx (105.7 KB)

[mwra (Mark Anderson)]

Busy (so can’t build out) but in theory you want to store, somewhere separate from the attribute (which we’ll call $YourAttributte), the starting list of suggestions: store as a Set-type (so A-Z sorted, no dupes allowed). Store a copy of that as the working Set. Now:

• collect the list of currently set values, values("YourAttribute") (see values()) and pass the output List data into a Set-type variable.
• subtract that current Set from the stored Set. This will removed from the main list and used values. Store the result as the working Set of suggested values (i.e. overwriting the copy above), e.g. vCurrentSuggestedSet
• use attribute(attributeNameStr)[keyStr] to set the new suggested values, e.g. attribute("YourAttribute")["suggested"] = vCurrentSuggestedSet;

So the master starting set and working set (vCurrentSuggestedSet) will need to be stored in an attribute for persistence, so consider the use of a ‘config’ note where the role of attributes is to store global persistent variables/constants. In this context, the starting Set is a Constant, and the current set a a Global Variable.

N.B. not tested.

[fidel (Fidel Namisi)]

Thanks for this. I’ll give it a bash and revert.

[mwra (Mark Anderson)]

My suggestion would be to develop/test this with stamps before rushing to using rules. Plus if you do use rules, consider putting them in a prototype making it easy to remove/disable aggressive list updating when not needed. Otherwise, you get rule/agent creep. The first few-always=on tasks have little impact but as we add more and never disable/prune old ones the extra background activity all adds up.

Also consider doing testing on a small test doc with suitable specimen content, rather than on a main doc. Even with back-ups, roll-back, etc., working in a mature doc can make it harder to diagnose initial errors. Plus, if you know the new code works in isolation but fails when ported to an actual working doc, it gives you some idea of where to look for conflicts. When moving code across docs be alert to attribute names, prototype connections (pasting-with-prototypes needs careful work!).

So, doing the initial development in stamps allows you to check the functionally with no overhead on the document at large.

[eastgate]

This is interesting!

My first thought was, you can’t do that! But, of course, you can. So thanks to @mwra for proving me wrong.

Now, a question I have is, why would you do that?. I can imagine scenarios where this would be useful, but it seems you know one where it would actually be useful. I’d love to know more.

[satikusala (Michael Becker)]

@fidel

Apple;Banana;Cherry;Dragonfruit;Elderberry;Fig;Grapefruit;Honeydew;Kiwi;Lemon

There are several ways you could approach this: 1) work down @mwra’s line of thinking + 2) create a resources folder and use various treatments of action code to create and remove items from lists. Before suggesting one approach and possible code angles from another, can you give some context to the project? How would you use this? What is the ultimate goal or outcome?

[satikusala (Michael Becker)]

@eastgate

Now, a question I have is, why would you do that?. I can imagine scenarios where this would be useful, but it seems you know one where it would actually be useful. I’d love to know more.

Funny, I had the same response before I saw yours. Yes, there are many ways to do this. Would be useful to have some context.

[fidel (Fidel Namisi)]

Thanks for the responses guys. In terms of context: I’m trying to use TBX to plot a story.
Excel has served me well in the past, but it’s got a lot of limitations, hence my continued experiments with TBX.
In Excel, usually I have a column (Column A) that contains the functions that all the plot beats carry out. This is a template based on Blake Snyder’s Save The Cat. So it would run something like (as per Blake Snyder’s Save The Cat):

1. Opening Image
2. Theme Stated
3. Set-Up
4. Catalyst
5. Debate
6. Break into Two
7. B Story
8. Fun and Games
9. Midpoint
10. Bad Guys Close In
11. All Is Lost
12. Dark Night of the Soul
13. Break into Three
14. Finale
15. Final Image

And the next column (Column B) would contain a one-liner of the plot beat.

In terms of adapting this to TBX, what I’d like to do is to have an attribute called $BeatFunction, whose suggested values would be the 15 “Beat Functions” just listed.
Once I create a note and then select it’s $BeatFunction, I sort of want to know that I’ve “checked it off” and don’t have to write it again. This way, by the time I’ve brainstormed/ listed a number of beats, I can quickly see from the dropdown of $BeatFunction, which beats are still pending, from a structural perspective.

I hope this explanation makes sense.
Thanks!
PS: In terms of the above use case I think a rule would be better than a stamp, simply because of forgetting. If forget to run the stamp, things might not work out as expected.

[mwra (Mark Anderson)]

My initial guess/assumption for @fidel’s question was for a self-de-populating list where every suggested item(as at start) is allowed to exist only once, so once used it is discarded as a (suggested) option. This is disjoint from whether non-suggested values for said attribute are allowed: hopefully, my solution allows for either case. Regardless, the result is a self-emptying check list.

So, I’m writing a story and there can be only one king, queen and knave. Who gets which role its not at front of mind but as I write the suggested $Roles list is helpful if I can see ‘King’ is already assign, even if in the moment I don’t know which character it is.

Previously, you could have monitored assigned values() for the role, or use AB view to see what has need assigned. This allows you to figure out what is done, although there is nothing to tell you what is not done/unneeded.

If it works (been real busy today) then this is another nice instance of being able to use a toolbox to solve a niche problem. No pre-build dialog/process in sight.

[mwra (Mark Anderson)]

Got it all working only to see all values in the Displayed Attributes pop-up value. My technique works, except because the pop-up lists all suggested and used values, whilst using a suggested value removes it (using my demo code) from the suggested list is still shows in the menu and it is used as an actual value.

The problem^† is we can’t (feature request) set the exact contents of a Displayed Attributes table attribute value pop-up. Apart from that we have it nailed. Whilst we can show he ‘remaining’ suggested values elsewhere my hunch about @fidel’s usage need was correct (last post above). But unless I can control the complete contents pop-up list, my method is a bust.

[Possible feature suggestion/vaiation] One thought, even if all notes are listed, could the suggested items be listed in italics? That way, especially in a short list, it would be able to see ‘unused’ suggestions as only these would be in italics?

My test doc: Suggested-Test1.tbx (118.3 KB)

Config note /config holds original suggestion list in $RoleListing. The current unused items of the latter are stored in the same note’s $RoleListingCurrent. The attribute where we are setting variable suggested items is $Roles. All 3 user attributes are Set-type.attributes.

In content terms we are setting $Roles in the child notes of container `/Casting’. The $Edict in the container is running the code. As a tesrt —and tell-back given the above impasse—the $Text of ‘Casting’ is set to show the unused suggested $Roles values.

†. Embarrassingly, i chased a lot of false error before remembering the Displayed Attributes value menu is used values plus unused suggestions. Oh well, worth a try…

[eastgate]

In this case, where you have 15 beats and want exactly one note per beat, it might make sense to just create 15 notes at a go, each could have a placeholder name, and you could use an agent to update the note’s appearance once it is written by adding a badge or changing the border.

[mwra (Mark Anderson)]

With the last in mind, how might making those notes be done?

So first add the ‘beats’ as a list in the $Text of a note. then give it this Edict (or use a stamp):

$Text(/log)=;
var:list vBeatList = $Text.replace("\n",";");
vBeatList.each(anItem){
   create(anItem);
};

The result:

Now you can easily move the notes elsewhere if needed.

[satikusala (Michael Becker)]

I think I have a cool approach. See this:
TBX L - Beat List Automation.tbx (236.4 KB)

My solution.

1. Create a resources folder with two containers, BeatList Folder and BeatListUsed Folder. Run a $Rule in the container to populate the drop-down list—$BeatListAvailable.
2. Create prototype pScene with a Rule (see image below)

Application

1. On Scene select from the available list. The Rule will automatically populate the $BeatApplied.
   1a. The rule will move the selected beat to the used folder.
   1b. if $BeatApplied is already populated, the existing beat will be recycled, i.e., the beat will be moved to the BeatListUsedFolder.

NOTE: It is not necessary to show the $BeatListRecycle, but I left it visible so that you can see the operation.

NOTE:

1. Another Benefit here is that the individual Beat note $Text can be used to define the beat. This is great for a future report that you might want to generate.

[fidel (Fidel Namisi)]

Thanks to you both @mwra and @eastgate ! This is a simple and elegant solution.

[fidel (Fidel Namisi)]

Woah! This is actually a very good solution to the problem and it works like a charm! Plus there’s the added bonus of being able to see at a glance what beats are “outstanding”. I think I’ll run with this one. Thanks so much @satikusala @mwra @eastgate. I appreciate your help quite a lot!

[satikusala (Michael Becker)]

@fidel

This is a simple and elegant solution.

There is SOOOO much more that you could do with this: linking, automatic character allocation, any number of reports and timelines. It would be tons of fun to build this out.

[eastgate]

There is SOOOO much more that you could do with this: linking, automatic character allocation, any number of reports and timelines.

But this is a framework for writing stories. It may be that automation, beyond this initial setup, is beside the point. Or it could be terrific! Gild not the lily.

[fidel (Fidel Namisi)]

Gild not the lily, nor formalize prematurely.

[satikusala (Michael Becker)]

Like this. And yet, if you are thinking 10+ steps ahead (i.e., you know your workflow, your outputs, etc.), then gilding and “some” formalizing may be appropriate.