Script Repository

Something like the lib/store that we have for art, the scripts should come over in some way that doesn't give access to the source. Under the API menu you will still be able to add code in the editor like we do now but you would have some sort of list of installed 3rd part scripts with configs for each (and some sort of access to said configs from the API). This would lead to a two way system of getting scripts in: Using a lib/store like we have for art, using this you cant see the source but the script has been pre-vetted by some members of the community (I would volunteer some of my time for this). And what we have now were you can play with the source and mess about. Maybe we could have a system to add scripts to your personal lib so they act like the ones on the lib/store (ie don't show the source) but only you can see them and they don't need to be vetted. My reasoning behind this is simple, its far easier to support a script that cant be edited by the user. The Lib system adds an easy way to sort a problem, at the moment some simple bad white-spaces getting copyed in the wrong place could create no end of errors.

I think if there is going to be a script repository that it would need to be a something that could pull the code as it currently stands with a click of a button, add it into your scripts automatically and with an option to take a snapshot of the code itself at that point, you could edit it manually from there without losing the ability to simply reset it. This would allow for things like being able to 'reset' the copied code to the snapshot of its original format, (I am assuming that the snapshot could be also be reset, overwritten with the current code once you're happy with the changes - the point being that the snapshot is basically a saved format, and the code that the API actually runs is that of the edited version). The main reason for this being that if the original poster decides to remove his code or change it drastically, you still have a copy that runs as you expect it to, without worrying about extra additions to the source code and still have a copy of what you originally subscribed to, while still allowing you to check updates and see if they are what you want to have running in your game without losing your already edited (and perhaps more suited to what you need) coding.  All you would need is a tab or page that tracks which scripts you are subscribed to and that 'dings' as your posts do when there is a newer version of a code to review and perhaps implement in your own list of scripts - which by the way, really should be stored separately to each campaign in a personal scripts collection, and simply tagged from in campaign so that it can access it (and be editable) from those pages. then its a simple matter of applying them to any campaign you are running, instead of having to copy and paste each tab. Just click and add, the same as from the proposed API hosting section, and then edit it directly as you do now. just don't go losing the ability to easily edit and write your code without having to get it 'officially' published. that would kinda suck.  I really like the idea of a global variable page, it would make editing the files for those who aren't comfortable with coding themselves an easy way of customizing their game the way they want it. granted, some codes will require very little in the way of that, but others already do require a fair amount of customization. I would request that if this is implemented that the global variable file itself is sort-able via some sort of tag system that is easy to follow and understand? perhaps an option to sort them by applicable scripts... similar to tagging, if a variable is applicable to more than one script, it simply shows up in each of the scripts lists. marked with an appropriate symbol or printed in a different color so you can mouse over it and get an info box (or something) that shows what other scripts access that variable (as stated by the various scripts internal tags). There will also need to be some reasonably strict guidelines and standards of coding to have your code 'published' this way, and it will take resources to test and check all the code for intended use. And I think one thing that needs to be monitored very carefully is that a scripts description is very clear about what exactly the script will do, so there are no nasty surprises - not that every script I've seen and played with hasn't done exactly that - they all explained and documented what needs to be done and what will happen when you run it, but it still needs to be said I think.  The only way to do that, as far as I can see, is to spend the time to do so. And to be frank, the idea of that makes me sad - You guys do a brilliant job of running this site and continually expanding the functionality of it all, and the thought of that ability to continue doing so being stifled (however slightly) because of having to spend more man-hours moderating the use of this new function is slightly depressing.  One work-around I can see to this is a very carefully selected core of volunteers from the community itself that can review the code and ok it - or send it back to the coder with notes on what needs to be improved for useability - before it is passed along to whomever you will have officially moderating the API library. MY vote is for yes, this should be done at some point; I happen to think that if this is going to happen at all, It needs to happen sooner rather than later. The earlier it is implemented the earlier the community can really start to benefit from a centralized easy to use API. And the better for the people throwing a lot of codes out there - they will have to be modified to match the correct formats for the variable globals and the more they have, the more time it will take them to do so, perhaps even discouraging some from doing so if it requires more time than they wish to spend doing so (though I hope not).

Dumb Q - but has there been any thought to licensing or paying for scripts?  Ie., if I pull tokens from the marketplace and pay for them, why shouldn't I also be doing the same to support the guys writing scripts?  I'd gladly pay a couple bucks for the added functionality that some of them offer.  Or at least, give people the chance to use them in one campaign, for free, and if they end up being useful, pay for them. Just my $.02.  I'd love to see more scripts and this would be a nice way to add some incentive to the process.

Excelsias said: Dumb Q - but has there been any thought to licensing or paying for scripts?  Ie., if I pull tokens from the marketplace and pay for them, why shouldn't I also be doing the same to support the guys writing scripts?  I'd gladly pay a couple bucks for the added functionality that some of them offer.  Or at least, give people the chance to use them in one campaign, for free, and if they end up being useful, pay for them. Just my $.02.  I'd love to see more scripts and this would be a nice way to add some incentive to the process. I think you should be able to get donations but not full on sales. Michael H. said: to long to quote Regarding your concerns about vetting of scripts, I thought I was clear and I cant speak for our Lord Riley but I feel it should be a community role like a moderator. I strongly feel if we are going to have a library or "store" that it should be vetted, what you have to remember is the API is a pay-walled function of roll20, so it would be best if the code that is distributed via "official" channels is up to a certain standard. But I would like to be clear, we should still have the forums or some other way to distribute the code as we do know in source form with a similar or same interface we have now to use it if you are that way inclined. In fact I would go as far as saying everything "officially" distributed should be required to have its source available via a link on the store/lib page. In short the way I see it this isn't about taking away anything we have now, its about adding options for those users that are intimidated by code. If its done well it could be a real selling point for the mentor subscription and that is a benefit to all of us. The guy who posted this thread is exactly the sort of person this is for, he just got mentor (again) and wants to use some scripts. Just to be clear I'm not mocking him its just a perfect example, if everything is working right he should need to post on the forums for anything other than to say thanks. Also vetting of scripts and a official repository lets us bypass possible problems, by enforcing a license, one of these two types i would think: You may use this code but anything you use it in must be open source and free. You may use the code but may not distribute it without permission. One works well for me and the other works well if they are to have some sort of paid store (I would rather we didn't). Modding and scripting can be a bit of a mine field, some people work in different ways to others and not everyone likes having there code used by others, by enforcing a licence or forcing the licence to be made clear (ie you can pick your licence but its displayed for everyone to see) makes life much more drama free.

The Steam Workshop is a really good model to follow. Individuals are able to subscribe to mods (make them available for install via config), comment on the mod, and rate the mod. I think something similar for the Script Repository would be great. If you back that up with some light-weight source control, so people can use specific released versions of scripts, I think you are left with a very stable community moderated platform.  I understand people's concerns about quality, but assuming use of the Repository becomes prolific (A worse case for load/A best case for business), the logistics behind reviewing individual scripts will be pretty painful. Peer/User reviewed and Rated with a "buyer beware" warning is best system I've seen for these kinds of business cases. What you end up with is a few brave souls who like to try out new scripts and save the rest of us the pain of bad scripts. Not sure if there is an external way to enforce it, but Name-spacing is going to become really important in an environment like this. A way to register a namespace and mark a script with used namespaces would be helpful to avoid weird and extremely difficult to debug results. A way to model Script dependency would also be extremely helpful. I.E. Script A requires inclusion of Script B and C. Assuming the sandbox would have access to the repository, this could probably handled with some kind of import API.

yes, but the problem with that is the fact that people will want to modify the code to fit their games. so keeping it updated automatically will basically ruin that. every auto update will wipe any custom coding you had to do to make it work with your game

Michael H. said: yes, but the problem with that is the fact that people will want to modify the code to fit their games. so keeping it updated automatically will basically ruin that. every auto update will wipe any custom coding you had to do to make it work with your game That's why I suggest a two part system one a auto updating, uneditable and vetted (this well help stop name spacing problems) Repository and what we have now were you can pick the source you want to work with (most likely using github/gist no point in making something for it) and edit it to your harts content.

which is exactly what I suggested above - a way to add a script with a click, have it copy said code into your personal 'bank' of scripts, and allow you to modify it there, only with a snapshot of what you've done stored in the bank along with a 'working copy' which you can modify and store when it works the way you want it, replacing the old snapshot - none of that modifies the original code you copied it from, so peoples work is safe from outside interference.  but the idea of having a place to go and browse scripts by function and/or author, as well as any other variable the roll20 team or community decide works, is a valid, and I think almost necessary, thing that needs to happen for this whole project to be exanded on in the future, and I believe each method - pulling scripts and adding them to a personal library which can be accessed from any campaign you might be included in -  should  be something that integrates as seamlessly as possible with the currently used method of working with the API.  My only concern here is that it's not just about what might work right now. I believe we have to think about what the roll20 team can do with it in the future, and a bit of work now getting it right will be worth the time and hassle of helping them make it something great - anything that puts an edge on helping those supporters and guests of the site want to further support roll20 and purchase prescriptions can only be good for the community, if it helps it to stand out even more to the average user who just wants to be able to click and go with no hassles and no fear of ruining the work they have already done. Also to note in the bigger picture is the possibility of companies (certainly independent companies and perhaps even commercial) out there wanting to provide tools for roll20 as it expands and grows larger, and a well planned, well built, and robust system for distributing API scripts would be an incentive to any such businesses who might wish to use roll20 for their products. Yes, it is all in what amounts to alpha right now. its still being expanded and quantified, but isn't that the best time lay the ground work for something that hope will become something truly user friendly and completely customizable to each individual experience?

Michael H. said: which is exactly what I suggested above - a way to add a script with a click, have it copy said code into your personal 'bank' of scripts, and allow you to modify it there, only with a snapshot of what you've done stored in the bank along with a 'working copy' which you can modify and store when it works the way you want it, replacing the old snapshot - none of that modifies the original code you copied it from, so peoples work is safe from outside interference.  but the idea of having a place to go and browse scripts by function and/or author, as well as any other variable the roll20 team or community decide works, is a valid, and I think almost necessary, thing that needs to happen for this whole project to be exanded on in the future, and I believe each method - pulling scripts and adding them to a personal library which can be accessed from any campaign you might be included in -  should  be something that integrates as seamlessly as possible with the currently used method of working with the API.  My only concern here is that it's not just about what might work right now. I believe we have to think about what the roll20 team can do with it in the future, and a bit of work now getting it right will be worth the time and hassle of helping them make it something great - anything that puts an edge on helping those supporters and guests of the site want to further support roll20 and purchase prescriptions can only be good for the community, if it helps it to stand out even more to the average user who just wants to be able to click and go with no hassles and no fear of ruining the work they have already done. Also to note in the bigger picture is the possibility of companies (certainly independent companies and perhaps even commercial) out there wanting to provide tools for roll20 as it expands and grows larger, and a well planned, well built, and robust system for distributing API scripts would be an incentive to any such businesses who might wish to use roll20 for their products. Yes, it is all in what amounts to alpha right now. its still being expanded and quantified, but isn't that the best time lay the ground work for something that hope will become something truly user friendly and completely customizable to each individual experience? It has to be something that is easy for normal (read non-technical) user to use without creating problems for developers, while at the same time I feel it need to take things like quality of code and prevent conflicts both in code and within the development community. So lets break this down: Easy for User: One click adding to campaigns. NO CODE!!!!! there is no good reason for a regular user to see any code at all, I agree you should be able to access it some way but it should be an option not a requirement to see it. Easy configs Auto Updates (disabled for those who are editing the code in some way) Not creating problems for Devs: Auto updates, it is hard to support something when everyone is using different versions. Code hidden and uneditable by default, with a resort function if it is changed. Nothing is more difficult that supporting something that has been changed. Some sort of auto bug report generator, gives any errors they are getting a list of all scripts they have installed, what versions they are running and copies of any edited scripts. Link everything in with gist, dev just submits a gist link and tell the system what commit to use, then when they want to update it they just pick what commit to update it to. Dependencies, auto downloading and updating. Quality of code/Preventing Conflicts: Have a system where scripts can be validated, ether by the community via voting or by dedicated moderators. List all scripts validated or not in the repository but put a mark showing there validation status, ie validated, pending, rejected. Have a set of standards as to what should be considered a valid script, ie uses name-spaces, isn't malicious, etc. A way to report scripts for errors, malicious intent and compatibility issues. A licence or set of licences (so you can pic the one you prefer) that ever dev must agree to, just to stop the sort of thing that goes on with the Minecraft modding community.

Again, you are making the same point as me, thats the whole point of being able to click and essentially run the script as is with minimal setup. The only thing that I'm suggesting between choosing a script and then applying it is a personal depository so that scripts you subscribe to are easy ti find and do not require setuping up initially each time you create a new campaign

Michael H. said: Again, you are making the same point as me, thats the whole point of being able to click and essentially run the script as is with minimal setup. The only thing that I'm suggesting between choosing a script and then applying it is a personal depository so that scripts you subscribe to are easy ti find and do not require setuping up initially each time you create a new campaign At no point did i say i wasnt making the same point, but the clearer we are the easier time Riley will have working out what exactly we all want. I disagree that initial setups should be skipped at any point, config options should be set to default when they are added to a campaign for the first time, also it should be possible to set them to default at the push of a button as well as being able to change/reset config options as part of a script update. Config conflicts/errors are a possible area where bugs could crop up. For example: lets say I have been using the char sheet creator script with my 4e campaign I have this set in the config along with various other options to do with 4e, I now make a campaign where i will be playing Shadow Run I set it to run in Shadow Run mode but I forget to change a rarely used option I had to set to use my version of 4e, now the script doesn't do what it was meant to and will take quite some time to debug and worst case will waist time for the dev looking for something that isn't there. This isn't the best example but you get the point. I agree we should have a list of subscribed/favourite scripts. In short its not about minimal setup its about easy and non-technical setups, you may have to set a lot of config options but they should be easy to do and you shouldn't need to look at code at any point. One thing you need to take into account is i am coming at this from a devs point of view and trying to make things easyer for the ~60% of the current script devs who mainly by there own admission have no experience coding and therefore no experience in maintaining a code base for for non-technical front end users. I don't want one click install because its faster for the user, I want it because it stops the user breaking something by copy/pasting wrong, don't get me wrong its a nice side effect but not my goal. Happy Devs that don't have to sit around supporting stupid user errors will make more and better scripts, its as simple as that. Also just to change the subject, although I agree that the user should always have access to the code if they want it, I would like to add that it would be better for the community as a whole if they discuss the functionality they want with the dev and see if he would add it as a option (assuming it isn't some sort of odd home-brew that no other system will ever use) this way everyone who can use that function not just the person who edited it in. (yes they could release there edit but it would be better to give it do the dev)

ok, I think you misunderstood my meaning behind initial set up(maybe). i'm referring to the current method of finding a clean copy of the script you want and having to copy it manually to a page for a new campaign, or with a global library system having to find it to tag it again and apply it. over and over again. talk about tedious. simply clicking on a script to add it to a campaign, being able to add several scripts at once (ie going through a list of scripts and checking the ones you want before clicking an 'apply scripts to campaign' button.) once they are loaded up as a part of a campaign, you can go to the config page and edit the various config options there. perhaps when you load a campaign after applying a new script it checks for a confirm script options return, and every time you load a campaign for the first time after applying a new script it loads into the config page automatically, even if just have you confirm you want this script to be applied, and to confirm you're happy accepting the default config if you do not wish to change anything. A personal database tied to the users account solves this, allowing a person to have a clean copy of a script they already use and apply it to the new campaign. not avoiding going through and setting up said script with a new config (which should be separate and easy to understand, I agree), unless the one in their personal bank is already set to the values they want (which would be more for the advanced users than the inexperienced ones.) Each campaign should hold a separate copy of the script independent of the others so that any changes made to a script from the campaign page do not effect the others. I'm not suggesting that one script manages all the campaigns, it was never my intent to convey that as an option. speaking of which, I am almost one of those 60% you are talking about. I haven't developed anything for a long time, and when I was, it was for a much smaller fanbase than the internet. It was also in basic(though I have done work with C++ about ten years ago, it was only dabling). So i'm practically ignorant of javascripting, and seeing as it has been 20 years - since high school - since i was writing any kind of code consistantly, I happily put myself with the uneducated masses on this one. on your last point, I happen to agree with you. Devs should have a say in what goes in their code, and modifications to that code that are published should be rightly credited to the original dev. I'm sure the community will have plenty to say on the matter as more and more scripts come out that look similar. 

 If you back that up with some light-weight source control, so people can use specific released versions of scripts This line actually addresses the auto-update issue. The point of the light-weight source control is that no released version of a script is ever destroyed. You never have to worry about someone changing a script and breaking your campaign. Consequently, you could toggle auto-update and source control would allow you to rollback to older versions of a script if you run into backwards compatibility issues. Regarding, personal repositories, that's an easy one. Just allow favorites. Also another neat feature of Steam Workshop is the ability to define collections. Anyone is able to snag a bunch of content they feel is related, bundle it, and make it available for one-click download, instead of snagging all the components individually.

Brandon B. said:  If you back that up with some light-weight source control, so people can use specific released versions of scripts This line actually addresses the auto-update issue. The point of the light-weight source control is that no released version of a script is ever destroyed. You never have to worry about someone changing a script and breaking your campaign. Consequently, you could toggle auto-update and source control would allow you to rollback to older versions of a script if you run into backwards compatibility issues. Regarding, personal repositories, that's an easy one. Just allow favorites. Also another neat feature of Steam Workshop is the ability to define collections. Anyone is able to snag a bunch of content they feel is related, bundle it, and make it available for one-click download, instead of snagging all the components individually. It would be better to just use GIST, you know dont reinvent the wheel, see my post with the bullit points for details.

Alex L. said: Brandon B. said:  If you back that up with some light-weight source control, so people can use specific released versions of scripts This line actually addresses the auto-update issue. The point of the light-weight source control is that no released version of a script is ever destroyed. You never have to worry about someone changing a script and breaking your campaign. Consequently, you could toggle auto-update and source control would allow you to rollback to older versions of a script if you run into backwards compatibility issues. Regarding, personal repositories, that's an easy one. Just allow favorites. Also another neat feature of Steam Workshop is the ability to define collections. Anyone is able to snag a bunch of content they feel is related, bundle it, and make it available for one-click download, instead of snagging all the components individually. It would be better to just use GIST, you know dont reinvent the wheel, see my post with the bullit points for details. No reason you can't build on top of GIST/GIT and add functionality to cover any gaps. Think we are saying the same thing here, except I was just being generic. You could probably get by with each campaign having its own repository for its sandbox with an easy configuration UI for setting up the dependencies. Concerning editing imported code: As long as the campaign specific code is rendered/imported last, there really shouldn't be reason to have to directly edit imported scripts. You can just easily override declared global functions or functions on prototypes. So instead of 'Code hidden and uneditable by default', and I would say, 'Hidden by default, read only for non-contributors' and encourage people to write libraries which have their own customization hooks (like events). People can always cut and paste to create a new script if they have to.

In additon to everything else it would be nice to be able to have a CSS script so we don't have to in-line everything. I know direct already changes class to scriptname_class or something, this would let us use it.