Code ownership etiquette?

I've recently come across a situation where I think some API scripts would be helpful. There's a script I use in-game, ModifyTokenImage (by Zachare Sylvestre), that allows you to define a set of images for a token, each possible image is defined in a separate handout, and cycle through them. Useful for shapeshifting characters. However, it seems to have one limitation: the token doesn't get resized if the shape is larger or smaller. I wasn't able to find a script that would do something similar, aside from The Aarons TokenMod.  I've modified a copy of ModifyTokenImage, allowing you to define a size or dimensions in the token image handouts gmnotes. If there are size parameters in the handout gmnotes, ModifyTokenImage will invoke TokenMod to resize the token to those dimensions. I think this is useful, but I'm a little uncertain of where to go from here. In addition to the code changes, my update creates a dependency in ModifyTokenImage for TokenMod, which wasn't there before. I've reached out to the original author of ModifyTokenImage, but haven't heard back from him.  Would it be bad form to submit a modification to another authors script, especially there's also an added dependency on another script that wasn't there previously? Should I fork this as another, 99.9999% derivative script that does one thing slightly differently? Or should I not submit this, and keep it private?

Generally, I'd try contacting the author and suggesting the changes. If the script hasn't been updated in a long time (yearish plus) or you don't get a response, then it's typically fine to submit an update to the script. The one caution I would add is about the added dependency. The Roll20 dependency handling is not the best and so you should put a check in for if the new dependency exists in the game and a chat message that is sent if it is missing so that existing users can manually add the dependency.

Scott C. said: Generally, I'd try contacting the author and suggesting the changes. If the script hasn't been updated in a long time (yearish plus) or you don't get a response, then it's typically fine to submit an update to the script. The one caution I would add is about the added dependency. The Roll20 dependency handling is not the best and so you should put a check in for if the new dependency exists in the game and a chat message that is sent if it is missing so that existing users can manually add the dependency. Re: the dependency. It's semi-soft, in that my implementation makes a chat API invocation, rather than directly interacting with the other module. As I understand it, if I do a '!token-mod' with sendChat and nothing picks up that api message, nothing happens. I'll admit I did this because I couldn't easily figure out how to invoke the TokenMod object directly to do what I wanted it to do. Speed isn't an issue, so the fact that there was a lot of async activity happening in the background didn't bother me.

Like Scott, I'd suggest trying to contacting the author, especially if that author is still active. They might add further changes to the script and will need to understand what you;ve adfded if it is to work, and they might just delete it if they aren't willing to support it. If you take code from another script to create a new script that does something different, submit that as a separtae script, and maybe add credits in the comments. In your specific case, it works sufficiently differently (invoking TokenMod where the orginal didn't) that I'd submit it as a separate script (with credit) or not submit it all - there's a third option. You can post it on the forum, or in your own github and mention it here. You can do that without submitting to the roll2-0 repo. That might be best for your script.

I'm going to deviate slightly from what they said above.  I'd say if the change is purely additive, and the original author is no longer maintaining it, i'd just make the modification and push it up, with the important caveat that I would not introduce any dependencies.   Changing token size shouldn't require TokenMod. Why don't you post the code here (or a link to it in a Gist or similar), and we can help you make the token scaling native to the script. 

Aaron made me realise I left off part of my answer - what to do if the code is not being maintained. My answer is the same as Aarons: go ahead and edit the code, and upload it. The license used by roll20 for the repositories expressly allows this, and anyone who posts a script should understand this, and they accept it whether they understand it or not. The scripts posted do not belong to anyone, and can be edited by anyone. It's just out of politeness we ask that you respect those who are still actively maintaining scripts - and also out of self-interest. Mess with their scripts too much and theyll get upset and might stop working on roll20 scripts, and script writers do a lot of good - we don't want to drive them away.

The Aaron said: I'm going to deviate slightly from what they said above. &nbsp;I'd say if the change is purely additive, and the original author is no longer maintaining it, i'd just make the modification and push it up, with the important caveat that I would not introduce any dependencies. &nbsp; Changing token size shouldn't require TokenMod. Why don't you post the code here (or a link to it in a Gist or similar), and we can help you make the token scaling native to the script.&nbsp; Gist of my additions. Rather than post the entire script, accept as a premise that the original script has the current playerId, a handle to a token object, and a handle to a handout object that are being passed in. At the end of the original scripts input handler, when it's completed chaining the token image, I call: resizeToken(msg.playerid, token, handout); <a href="https://gist.github.com/smjack70/bea27437c01e6148f5c397d52f16909e" rel="nofollow">https://gist.github.com/smjack70/bea27437c01e6148f5c397d52f16909e</a> I probably should have dug into TokenMod a little deeper to see what it was actually doing, but Javascript is not a language I work with regularly, and I got a little lost in the chaining. Hmm... looking this over more critically ... is the answer as simple as? token.set({"height": &lt;heightValue&gt;, "width": &lt;widthValue&gt;})

Oh, and to be clear: the first thing I did was send the original author a message describing what I was trying to do. It's only been a few days, so we're not out of the reasonable-time envelope.&nbsp;

That's correct. You don't need the " around the properties for an object in JavaScript, but it will still accept them. You can probably find where the imgsrc is getting set earlier in the script and set all three properties at the same time.&nbsp;

The Aaron said: That's correct. You don't need the " around the properties for an object in JavaScript, but it will still accept them. You can probably find where the imgsrc is getting set earlier in the script and set all three properties at the same time.&nbsp; About that (and apologies that this is turning from a question on code ownership into a scripting lesson)... I ran into a bit of an issue when trying to get the handout gmnotes value. If, in the body of the input handler (where the original script is doing its token.set(imgsrc, ...) call), I perform a handout.get(gmnotes,...), I get the following message: "Error: You must pass a callback function to .get() when getting the bio, notes, defaulttoken, or gmnotes of a Character or Handout." So I need to handle a callback. My solution was to have the input handler invoke an async function I wrote, pass the token and handout to the async function, which awaits on another function which returns a Promise containing the parsed, cleaned up output of handout.get. This is the first time I've ever encountered this async/Promise pattern, so I'm sure I made this overly complicated. But it seems to work.

Yes, gm notes, bio, and other text fields like them in the interface are stored in a blob that needs to be parsed by Roll20. The parsing is asynchronous, and so our handling of it has to be as well. Here's my preferred note get function: /** * Gets the blob info from roll20 objects asynchronously * @param {string} prop - the property to get * @param {Roll20 Object} obj - the Roll20 object to get the prop from * @returns {Promise&lt;string&gt;} - The contents of the blob. */ const getNotes = function (prop,obj) { return new Promise((resolve, reject) =&gt; { obj.get(prop, (p) =&gt; { resolve(p); }); }); }; And you'd use it like so: const myFunc = async (charObj) =&gt; { const charBio = await getNotes('bio',charObj); // Do something with the bio content }; You can use this function to get any of the async text values: bio and gmnotes on characters gmnotes and notes on handouts Simply pass the property you want as the first argument and the object that you want to get it from as the second argument.