Set default token bar links on a compendium drop

Hello Community, Really sorry to start a third link on a very close subject, but as I follow my head banging journey to compendium integration, the right question to ask the community seems to change. Link to the 2 other threads if you want to follow my journey <a href="https://app.roll20.net/forum/post/11120503/sheetworkers-getting-the-attribute-id-in-the-sheetworker/?pageforid=11121989#post-11121989" rel="nofollow">https://app.roll20.net/forum/post/11120503/sheetworkers-getting-the-attribute-id-in-the-sheetworker/?pageforid=11121989#post-11121989</a> <a href="https://app.roll20.net/forum/post/11113833/slug%7D" rel="nofollow">https://app.roll20.net/forum/post/11113833/slug%7D</a> OK, my objective is pretty simple : I am working on a compendium and its integration with a custom sheet. The custom sheet has a companion API, so if necessary I can reach my objective through an API function. When dropping a character from the compendium, the system already assigns it a default token, and what i would like is for either a sheetworker or an API function to set the barX_link of the default token to 3 attributes (Karma,Wounds,Damage)... No customization from the user, always these 3 attributes. Few points following my journey: 1- I have seen several people in several threads stating that setDefaultToken was initially an API function, so when I had difficulties with the sheetworker, I tried putting the routine in the API... But setDefaultToken is not recognized when I load my API... Do I do something wrong ? 2- I have had the discussions with another user (Ooosh), that while he was giving an example from DnD 5e that worked to set the links via setDefaultToken in the sheetworker, when I was trying the same it was not creating any link ( inspecting the Objects showed me that it was writing the attribute name in the Token Object, while it was expecting a Token Id) 3- I ended up figuring out that DnD routine was triggered by&nbsp; on("sheet:compendium-drop", () =&gt; { while mine was triggered by on("change:drop-name" so I figured it was the cause, and wrote a new routine, very similar to the DnD routine: on("sheet:compendium-drop", () =&gt; { const tokenOutput = {"bar1_link":"Karma", "bar2_link":"Wounds", "bar3_link":"Damage"}; setDefaultToken(tokenOutput); }); This looks like a step forward because I finally have the default token showing the links but this is still not the end of it. Note that there is no value, nor max despite the link ( I also tried to add value and max in the same setdefault token but it didn't solve the second problem), and when a character is dropped, its token normally appears on the VTT, but here it doesn't. Also if I try to drop the token from the journal, nothing happens. Looking at the JS console, I have the following Finally, if I go back in the default token property, and change any of the links, all the linked value suddenly appear, and the default token seems "repaired" (i.e. I can drop it from the journal)... Help from fellow API / Sheet /Compendium people would be very appreciated, because I don't know where to move from here ? Seems the sheetworker is a better way to go (will support people that don't have a Pro Account), but what am I doing wrong that ends up in a broken default token ?

I think the token drop function uses the token's width &amp; height to work out where to snap the token to (that's why you're getting a crash for the "left" value of the token). You can fix that by supplying width &amp; height to the setDefaultToken(). Here's a minimal working example. It probably doesn't need the getAttrs in there, but I had been logging the value. &lt;div class="outer"&gt; &lt;input type="text" name="attr_test" value="5"/&gt; &lt;/div&gt; &lt;script type="text/sheetworker"&gt; on("sheet:opened", () =&gt; { setAttrs({ test: 13 }); }); on("sheet:compendium-drop", () =&gt; { getAttrs(['test'], (attrs) =&gt; { setDefaultToken({ bar1_link: 'test', width: 70, height: 70 }); }); }); &lt;/script&gt;

You're a genius ! The size not being set was the issue !!! Thanks so much for the time you took !

While not your issue, I'd also point out that the name you assign for the linkage is case sensitive based on what it is set as in your sheet's attributes/abilities tab. Note that this can be different than what is specified in your html if you used a sheetworker to set it and used a different case in the sheetworker and in the html. This is, in my opinion, yet one more strong reason to NOT use capitalization in attribute names. snake_case or kebab-case are much more dependable with character sheet implementations. Also, unrelated, but Jiboux, these three threads could have easily been a single thread. They aren't separate issues, but simply evolutions of the discussion of the original issue. Simply updating the original thread instead of fragmenting this into several threads would have made following the evolution of the problem much easier.

Thanks Scott, 1- Capitalization : I have jumped in an existing sheet that is now 20.000 lines of HTML + 12000 lines of JS... If I was starting one from scratch I would definitely stop capitalizing, but with the legacy we didn't want to go through it 2-Fragmenting : sorry about that... I felt (maybe wrongly) that due to starting the subject with too much of an unclear question, I wouldn't get answers... Hence why I tried to restart new threads that would start over from a cleaner perspective... Maybe a bad idea Again thanks for your support ! I really appreciate the help that we get on this forum

With what you are working on, it may be worth going back and paying the tech debt. I've worked on all sorts of sheets, and you pay the tech debt one way or the other. Even if you decide not to pay it by actually updating code, you pay it through the increased time it takes to develop, maintain, and add features to the sheet with tech debt.

Scott C. said: With what you are working on, it may be worth going back and paying the tech debt. I've worked on all sorts of sheets, and you pay the tech debt one way or the other. Even if you decide not to pay it by actually updating code, you pay it through the increased time it takes to develop, maintain, and add features to the sheet with tech debt. CF:&nbsp;D&amp;D 5th Edition by Roll20 Sheet, the OG of tech debt.

keithcurtis said: CF:&nbsp;D&amp;D 5th Edition by Roll20 Sheet, the OG of tech debt. A certain metamancer (who I shan't name) asked an AI artbot to portray the spaghettified chimera qualities of a certain 5e sheet (which I also shan't name). The result was appropriate, it looks like a creature that does intermittent psychic damage to players each session.

Scott C. said: With what you are working on, it may be worth going back and paying the tech debt. I've worked on all sorts of sheets, and you pay the tech debt one way or the other. Even if you decide not to pay it by actually updating code, you pay it through the increased time it takes to develop, maintain, and add features to the sheet with tech debt. Thanks for pointing it out... Will have to consider it if I find the courage...