SRL Archive - Todo

I was wondering what you guys would expect from the Script Manager?
There are some obvious feature, and probably some less obvious features too.

• Script versioning.
• Upload scripts.
• Install scripts.
• Update scripts.
• Have different sections for scripts
• Show script stats? (Integrate stats?)
• Others? You name them.

However, these have certain complications:

Versioning:

• We need a good backend. I was personally thinking about using git as backend for storing all the files…

Uploading:

• Every update must be strictly checked, so scripters can never upload harmful scripts.
• Uploading should be relatively simple. Do scripters simply send their new script to a ``Script Maintainers'' team? Do they ask someone to pull from their git repos? (Annoying to beginners or people who don't want to / can't use git)

Install scripts:

• To where do we install scripts? A special directory? Or just in scripts?
• How does someone manage his players? (Perhaps a XML file per script? Simba can then offer an easy way to read players)

Update scripts:

• What if the user made changes to the script? (Again, players!!!)

The rest shouldn't bring in too much complications.

Comments, thoughts, ideas? (How would you prefer to upload your script, how would you prefer that Simba installed scripts, etc. Technical comments welcome too)

For players a special file in SRL, where we can define all the players we use.

Maybe some variable like Players[].Script := 'ID/NAME/?';

And function to SRL that loads only those players that script is supposed to use, the ID/NAME/?.

For the uploading, maybe some string check? Like "password" "pass" or something like that to prevent harmfull scripts, if there is found some of those strings then it would be flagged and cant be installed until a moderator/admin/someone has confirmed that the script is legit.

Some kind of blacklist of strings to be checked :)

I had this cool idea for script developers, having a list of functions in website (you can add/modify/delete functions/procedures) and then everyone included in the project (the developers of the script) can edit them, mark them as "Worked on" so no-one does the same functions. Thought i dont know if this is supposed to be put in this :)

Scripters could be able to create and package a player/bot manager with their uploaded scripts that contains needed information, such as player info (usernames/passwords and script-specific information like axe type or location), as well as setup variables (members or free world, time between breaks, etc.). This would allow users to easily input needed data while at the same time solving the problem of how to handle updating when the user changes the players/setup vars section.
I suppose what I'm suggesting is sort of a cleaner, more efficient, and more customizable form of SRL's player manager.

You know what I think would be pretty cool? You run a script that has a nice Simba form popup. In this form, you can choose which script to use (from a pull down menu of scripts you've downloaded). Then all the script setup information pops up depending on the script you chose. There would also be an option to download new scripts, where it would open a new window of a list of the available scripts.

This is probably way to much, but it would make it very user friendly and avoid people making threads/posting about how to setup a script. Plus with a GUI, we can add pretty much any help tools that are needed (not that it can't be done otherwise).

Just a thought. :)

Stats (All time/31 days/7 days/24 hours)

From: Coh3n
You know what I think would be pretty cool? You run a script that has a nice Simba form popup. In this form, you can choose which script to use (from a pull down menu of scripts you've downloaded). Then all the script setup information pops up depending on the script you chose. There would also be an option to download new scripts, where it would open a new window of a list of the available scripts.

This is probably way to much, but it would make it very user friendly and avoid people making threads/posting about how to setup a script. Plus with a GUI, we can add pretty much any help tools that are needed (not that it can't be done otherwise).

Just a thought. :)

So, pretty much like RSBot lmao :D.

This isn't stats. This is a separate entity, just saying.

This *should* link to stats though :rolleyes:

I think a simple set of checks to see if the obvious phishing attempts perhaps merely using a grep would be suffice. Then making a set of trusted people able to push to the git repos, then have it setup to auto-pull from the trusted sources different times a day.

Two or three times perhaps?

From: Sex
So, pretty much like RSBot lmao :D.

Oh lol. I've never used RSBot, so I don't know what it's like. :p

From: Nava2
This *should* link to stats though :rolleyes:

Aye, just a couple recent statistics. This would allow users to tell if the script is working, etc.

From: Nava2
This isn't stats. This is a separate entity, just saying.

Is it? I was thinking of combining them.

This *should* link to stats though :rolleyes:

From: Nava2

I think a simple set of checks to see if the obvious phishing attempts perhaps merely using a grep would be suffice. Then making a set of trusted people able to push to the git repos, then have it setup to auto-pull from the trusted sources different times a day.

Two or three times perhaps?

I don't see how a few simple checks should suffice. No, I think it should be done manually, the checking.

From: Wizzup?
Is it? I was thinking of combining them.

This *should* link to stats though :rolleyes:


I don't see how a few simple checks should suffice. No, I think it should be done manually, the checking.

Oh, sorry, I thought that it should have the greps anyways. Thus it would catch things off the screen etc.

This is what I'd do. First, when the author wants to submit an update, I'd allow them to upload freely. However, if a potentially harmful line is detected in the script(s) (e.g: GetPage, etc) then it would be marked for review.

[QUOTE=Dan's The Man;704574]This is what I'd do. First, when the author wants to submit an update, I'd allow them to upload freely. However, if a potentially harmful line is detected in the script(s) (e.g: GetPage, etc) then it would be marked for review.

There are so many ways to do malicious stuff in your script, I don't want to check it only with some grep checks. I don't think uploading freely is a good idea. My idea was to have several people with push access to the git repos, and one of them can then check the script and upload it.
BTW: There were other problems too. :p

[QUOTE=Dan's The Man;704574]This is what I'd do. First, when the author wants to submit an update, I'd allow them to upload freely. However, if a potentially harmful line is detected in the script(s) (e.g: GetPage, etc) then it would be marked for review.

This is what I was thinking as well. If a script has any web access, and maybe even file access, it should be checked manually, but otherwise it should be ok to push instantly (maybe include a "time running since last update" in the ministats?)

Also, maybe we could have it so that if a script uses the SRL playerform the script manager could parse it out and load a player array directly into itself to launch the script from there. :)

Then we start to get into SRL security issues. IE if the stats urls aren't hardcoded, one could mimic the system and pass information through stats values. Etc, etc.

From: Smartzkid
Then we start to get into SRL security issues. IE if the stats urls aren't hardcoded, one could mimic the system and pass information through stats values. Etc, etc.

Well how could they if any scripts containing URLs be checked? :S The script would have to change in order for it to happen and it'd be pretty obvious :p

What about….

We have a big big script database in Simba(was the plan right?)
You can upload a script(init) but you have to establish a connection with the Villavu-database(MYSQL as in SRL Username and correct pass) then it gets added to the scripts database and it will be flagged with not approved yet.
Using the villavu database connection you can see what kind of Forum rank uploaded it.
You can download the script flagged with not approved, but you will be warned.

High level Villavu members can approve this script.
The villavu database is a lot of hassle, but works.

I didn't understand the full idea, but yeah…

I could help coding, but what language and is it for simba or a stand-alone utility?

Greetings,
Hermen

Edit:
You could also make in Simba a offline thing, so you can always script, but to auto and to upload scripts you need to connect to the SRL database…
This costs a lot more bandwidth, though.

But I like the free being of SCAR and SIMBA so maybe its not a very good idea…

Someone said something about storing players shizzle in SIMBA, we have the SRL player form like Widget said.

Hmmm how about someone make a firewall extension then we dont have to check scripts?

I propose the following, and it's already been covered in parts above, but consider this a condensed version.

Create a repository for the scripts that a group of "Script Managers" have full permissions for, or possibly a subset of permissions.
Scripters apply to get their script added. This has to be approved by the repository management group, but once they're approved, they have full administrative privilidges over scripts/theirscriptname/. They can push, pull from other people, anything like that, but it only affects their script directory. This would mean that they can update whenever they need to. (Not sure if this is possible in Git actually, if it's not, SVN is always an option, because IIRC, it is with SVN).
By default, people have read only access of course. However, this could be changed - it could be linked to a MySQL auth module so that is uses users off here too (which also allows for users to add "developers" to scripts, so you can easily develop joint scripts).
Of course, this ignores the issues of malicious scripts. Basically, it comes down to "do you trust the script". Because there are people administering the repo, it's almost the same as when someone moderates the scripts forum. People can look at new scripts, submit reports etc, anything like that. Of course, the firewall and filewall is a big plus, but it's not a necessity as far as I'm concerned.
You could add stats, ratings and other things into this repo.
You can download scripts from the repo to your local dir, and update them (with a git pull /scripts/scriptyouwanttopull), and it would merge them.

As for people editing their own scripts, there's the posibility for merging (and let's face it, if they're activly editing scripts (not just players) then they'ren ot too stupid to do this).
I think player manement could be added as an extension to Simba too, and just intergrate that with scripts in the repo (of course, this could be optional). Although, people coped with adding their players every time they updated before now.

Anything I've missed?

From: Dgby714
Hmmm how about someone make a firewall extension then we dont have to check scripts?

The entire point is that IF a script is in there, it MUST be trustworthy. See it like a Package Repository. You should be able to trust it 100%.

From: ss23
I propose the following, and it's already been covered in parts above, but consider this a condensed version.

Create a repository for the scripts that a group of "Script Managers" have full permissions for, or possibly a subset of permissions.

Yes.

From: ss23

Scripters apply to get their script added. This has to be approved by the repository management group, but once they're approved, they have full administrative privilidges over scripts/theirscriptname/.

No! This way they can at first upload a good script, and then with an update, steal all passwords!

From: ss23

They can push, pull from other people, anything like that, but it only affects their script directory. This would mean that they can update whenever they need to. (Not sure if this is possible in Git actually, if it's not, SVN is always an option, because IIRC, it is with SVN).

See previous point.

From: ss23
By default, people have read only access of course. However, this could be changed - it could be linked to a MySQL auth module so that is uses users off here too (which also allows for users to add "developers" to scripts, so you can easily develop joint scripts).
Of course, this ignores the issues of malicious scripts. Basically, it comes down to "do you trust the script".

That is not the idea. The idea is that every script in there simply is to be trusted.

From: ss23
Because there are people administering the repo, it's almost the same as when someone moderates the scripts forum. People can look at new scripts, submit reports etc, anything like that. Of course, the firewall and filewall is a big plus, but it's not a necessity as far as I'm concerned.
You could add stats, ratings and other things into this repo.
You can download scripts from the repo to your local dir, and update them (with a git pull /scripts/scriptyouwanttopull), and it would merge them.

Previous point. :)

From: ss23
As for people editing their own scripts, there's the posibility for merging (and let's face it, if they're activly editing scripts (not just players) then they'ren ot too stupid to do this).
I think player manement could be added as an extension to Simba too, and just intergrate that with scripts in the repo (of course, this could be optional). Although, people coped with adding their players every time they updated before now.

Anything I've missed?

Yes, there will be some player management in Simba, but not compiled. Probably a .simba file using the XML functions we have provided to scripts.

From: Wizzup?
The entire point is that IF a script is in there, it MUST be trustworthy. See it like a Package Repository. You should be able to trust it 100%.

Well, we check it the first time, if it is clean, we let the scripter update it (or group of scripters if its a group script). Then some checks randomly on updates? I dont think it needs anything more then that.

If I'm not mistaken, don't we not check scripts when they're posted on here? As in, we can read scripts, but they don't have to be approved before they're allowed to be viewed etc (this might have changed, I haven't done scripting in a LONG time).

Also, as I said in my post, the idea was that each person who WANTS to have a script in the repo has to be approved before they can. The idea behind this isn't "give anyone access and let them do what they want", it's a "Is this person trust worthy? Would I run a script made by them before checking it?". There's nothing stopping people going through and checking scripts when they've been updated, I just think that for most of the people on SRL, it will be an effort that's wasted. (As in, I wouldn't bother checking one of your scripts for a password stealer Wizzup ;)).
All of the issues regarding "trust of the script" seem to be said with the mindset of "EVERYONE CAN WRITE WHEN AND WHATEVER THEY LIKE", but just as a package manager in your OS doesn't work like that, I would hope that this wouldn't either. It would be approved people that have shown they're trust worthy.

If this doesn't sound alright, why not have a dual system? For Senior SRL (and other specific users if it's deemed okay), they can update whenever they like. For anyone lower, they have to be screened manually.
Of course, you could do a screen of both of them automatically if someone wants to write something to do this.

As far as I'm concerned, if you don't trust the Senior SRL, why do they have that status at all?

Regarding the player management, I'll make another thread for the discussion of it (as I would very much like to see it happen, and this isn't the place for it to be discussed)

From: Frement
Well, we check it the first time, if it is clean, we let the scripter update it (or group of scripters if its a group script). Then some checks randomly on updates? I dont think it needs anything more then that.

What about your virus scanner randomly checks files for infection?

From: Wizzup?
What about your virus scanner randomly checks files for infection?

No, but viruses dont fear for ban, do they? :)

From: Frement
No, but viruses dont fear for ban, do they? :)

I don't get this counter argument… lol

From: ss23
If I'm not mistaken, don't we not check scripts when they're posted on here? As in, we can read scripts, but they don't have to be approved before they're allowed to be viewed etc (this might have changed, I haven't done scripting in a LONG time).

Exactly. Because we can't just moderate every thread until we've checked it.

From: ss23

Also, as I said in my post, the idea was that each person who WANTS to have a script in the repo has to be approved before they can. The idea behind this isn't "give anyone access and let them do what they want", it's a "Is this person trust worthy? Would I run a script made by them before checking it?". There's nothing stopping people going through and checking scripts when they've been updated, I just think that for most of the people on SRL, it will be an effort that's wasted. (As in, I wouldn't bother checking one of your scripts for a password stealer Wizzup ;)).

So promising newcomers who have only been here for a couple of weeks can't get their script in the Repos?

From: ss23

All of the issues regarding "trust of the script" seem to be said with the mindset of "EVERYONE CAN WRITE WHEN AND WHATEVER THEY LIKE", but just as a package manager in your OS doesn't work like that, I would hope that this wouldn't either. It would be approved people that have shown they're trust worthy.

Yes, but they shouldn't be able to write whenever and whatever they like. That's the whole point of the system / why we use git.

From: ss23
If this doesn't sound alright, why not have a dual system? For Senior SRL (and other specific users if it's deemed okay), they can update whenever they like. For anyone lower, they have to be screened manually.
Of course, you could do a screen of both of them automatically if someone wants to write something to do this.

As far as I'm concerned, if you don't trust the Senior SRL, why do they have that status at all?

Senior Members can't steal passwords using their forum status. The rank serves a different purpose. There will be some people who check the scripts send in, but there's no need to have 50 of them.

From: ss23

Regarding the player management, I'll make another thread for the discussion of it (as I would very much like to see it happen, and this isn't the place for it to be discussed)

See the ``Settings'' section in the function list. ;)

How about a simple 'status' ?

'Checked' / 'Verified'
'Unverified'

That'll allow people to upload their scripts, it allows people to go through the scripts themselves, or wait until an authorized member has verified them. No needed time-loss. It will also be 'against our advice to use unverified scripts'.

~RM

And a pop-up warning if someone tries to get unverified script :)

From: Frement
And a pop-up warning if someone tries to get unverified script :)

Work Flow

Upload script
–> Unverified

Download script
–> if Unverified
– –> Pop Up
– – –> If accepted, download
(if member = Verifier)
–> Click 'verified' button
–> Click 'Deny' button
—-> Possible Consequences
–> Removal of script from Database (duh)
–> Banning user from uploading scripts
–> Informing staff (somehow)
–> if Verified
– –> Download

~RM

Newcomers can still add their scripts, they will just have theirs checked, just like normal members and unlike Senior SRL Members.

I believe that part of making a script means updating it whenever YOU want to, not updating it then waiting a few days for someone to manually check the changes and approve it, although of course, for non trustworthy members (read: non senior members and below, with exceptions if necessary), I think it would be a trade off that most people would be willing to accept for the safety of our characters.

Also Wizzup, since you have counter arguments for what I've suggest, and Simba is your pet project (in part at least), how would you propose this system works?

From: Rasta Magician
Work Flow

Upload script
–> Unverified

Download script
–> if Unverified
– –> Pop Up
– – –> If accepted, download
(if member = Verifier)
–> Click 'verified' button
–> Click 'Deny' button
—-> Possible Consequences
–> Removal of script from Database (duh)
–> Banning user from uploading scripts
–> Informing staff (somehow)
–> if Verified
– –> Download

~RM

Sounds good as long as updating a script is treated as uploading a new script.

From: Boreas
Sounds good as long as updating a script is treated as uploading a new script.

That's how I had it in mind as well ;)

~RM

I still like the idea of SSRL and above having some sort of "This member has been deemed awesome for all time" thing, and it makes sense, considering SSRL and above would be the ones doing the checking of the scripts in the first place (I would assume)

Regarding how it would work, I assume that it's not possible, or perhaps practical to have this all stored in a single git repository. I would think that some sort of external API where Simba just pulls/posts data to receive information about scripts, then pulls what it needs from Git would be appropriate. Then again, I haven't worked with Git much to see if it actually would work. Has anyone else who could spread light upon this matter?

From: Frement
And a pop-up warning if someone tries to get unverified script :)

kbot :thumbsup:

I'm still in for having only verified scripts. It boosts the trustworthiness tremendously. Perhaps we can later have an option to show (and install) unverified scripts too, with the extra warnings and such…?

From: Wizzup?
I'm still in for having only verified scripts. It boosts the trustworthiness tremendously. Perhaps we can later have an option to show (and install) unverified scripts too, with the extra warnings and such…?

Sounds perfect.

[x] Show Unverified Scripts.

~RM

From: Boreas
Sounds good as long as updating a script is treated as uploading a new script.

I like this plan as well, but it means people are going to have to be less trigger happy when it comes to updating, such as not updating at every small little thing. It just seems like it can get to become a hassle, if someone needs to make a small update (a one liner) and they have to get it verified every time.

How SRL members or something like that can get auto-verified on their scripts, and add a "Report This Script" into the database, just in case. What do you think?

From: drags111
I like this plan as well, but it means people are going to have to be less trigger happy when it comes to updating, such as not updating at every small little thing. It just seems like it can get to become a hassle, if someone needs to make a small update (a one liner) and they have to get it verified every time.

How SRL members or something like that can get auto-verified on their scripts, and add a "Report This Script" into the database, just in case. What do you think?

No. Many SRL Members have been banned for stealing accounts in the past.

What can be done is allowing two versions.
Meaning
version 1: verified;
version 2: unverified;

version 1 stays in verified scripts until version 2 is verified. If version 2 is accepted it replaces version 1, else version one remains.

~RM

I'd say SSRL should have auto-verified if anything.

From: Nava2
I'd say SSRL should have auto-verified if anything.

Even better, get SSRL to be the verifiers, so you can jut simply verify your own script ;)

~RM

Only make the verifiers look at the lines that have changed. Makes small updates very quick to get pushed through.

From: Wizzup?
I'm still in for having only verified scripts. It boosts the trustworthiness tremendously. Perhaps we can later have an option to show (and install) unverified scripts too, with the extra warnings and such…?

sounds like ubuntu where if you apt-get the package, it wont always be up-to-date, whereas with gentoo you have to compile your self –> up to date programs.
I view the unverified scripts as the packages you have to compile yourself, except maybe more risk. You could read the package you're about to compile, but how many people do?

I think as far as re-verification goes, perhaps just using a dif would work.

From: smartzkid
only make the verifiers look at the lines that have changed. Makes small updates very quick to get pushed through.

^

From: nava2
i think as far as re-verification goes, perhaps just using a dif would work.

~rm

Hmm.. If one is able to create a script good enough to be included in the Script Manager, I guess he's not after Runescape accounts and therefore can be trusted…

In my opinion, drop the verification part and just create a 'report' button in the manager, which will report the script as bad (and after X reports automatically block the script).

Well, all we really need to be concerned about really is scripts that access the interwebs, for which we can just put a huge warning "BLA! IF ANY SCRIPTS ASK TO ACCESS THE INTERWEBS READ THEIR THREAD AND MAKE SURE THEY ARE SAFE. DON'T ALLOW ANY SCRIPTS YOU DON'T TRUSS TO ACCESS THE INETEWEBS (SRL STATS WEBSITE IS SAFE)"

Also, @Mastarraymond, I think the verification is for more than just saying a script is safe, it also shows that a script is reliable too (I thank?)

From: YoHoJo
Well, all we really need to be concerned about really is scripts that access the interwebs, for which we can just put a huge warning "BLA! IF ANY SCRIPTS ASK TO ACCESS THE INTERWEBS READ THEIR THREAD AND MAKE SURE THEY ARE SAFE. DON'T ALLOW ANY SCRIPTS YOU DON'T TRUSS TO ACCESS THE INETEWEBS (SRL STATS WEBSITE IS SAFE)"

Also, @Mastarraymond, I think the verification is for more than just saying a script is safe, it also shows that a script is reliable too (I thank?)

Verification won't tell you much about reliability, no.

~RM

I was under the impression anyone could add scripts to the manager, and thus, the verification was required.
Is this the case or is it a "You have an awesome script, now it can be added".
I figured the rating system would weed out the unreliable scripts

if you go to stats you can fill a form out that will submit your script. i havnt done it yet so im not positive it doesnt block your script or wait for admins or nelsie to give it the ok first. it looks like it will allow anyone to post a script up though.

From: g0tp0t
if you go to stats you can fill a form out that will submit your script. i havnt done it yet so im not positive it doesnt block your script or wait for admins or nelsie to give it the ok first. it looks like it will allow anyone to post a script up though.

Different systems ;)

~RM

From: g0tp0t
if you go to stats you can fill a form out that will submit your script. i havnt done it yet so im not positive it doesnt block your script or wait for admins or nelsie to give it the ok first. it looks like it will allow anyone to post a script up though.

You need to read full threads before you post. This manager will use the new stats created by Wizzup, not to mention this is a separate entity.

ooh. i am sorry. used i spy and didnt think he could possibly mean anything else :P

From: Nava2
You need to read full threads before you post. This manager will use the new stats created by Wizzup, not to mention this is a separate entity.

Hopefully they won't always be seperated. ;)

So, can anyone help with the original question?

From: ss23
So, can anyone help with the original question?

And that was?

~RM

From: Rasta Magician
And that was?

~RM

I think maybe this one(s):

From: Wizzup?
I was wondering what you guys would expect from the Script Manager?

and

From: Wizzup?
How would you prefer to upload your script, how would you prefer that Simba installed scripts, etc.

Which, indirectly, most of this has been about..

How about a line that says "This script has an unverified update available. If there has been a recent update that breaks compatibility with this script, you may update to the latest unverified version, but be aware that there is always a risk of having your account stolen." or something along the lines of that for when there's updates?

From: Widget
How about a line that says "This script has an unverified update available. If there has been a recent update that breaks compatibility with this script, you may update to the latest unverified version, but be aware that there is always a risk of having your account stolen." or something along the lines of that for when there's updates?

I would think of that as 'On top of' rather than 'instead of' the rest of what has been discussed. (Cool feature to add tho :p)

~RM

The verification process should be as quick as this:
CTRL + F words like SendEmail, SendCrap etc. and manually check them, takes a minute per script

From: marpis
The verification process should be as quick as this:
CTRL + F words like SendEmail, SendCrap etc. and manually check them, takes a minute per script

I would recommend auto-check at first, to find Player[CurrentPlayer].Pass etc. Because i can make the send function like "SFJJSF8242();".

From: ss23
I was under the impression anyone could add scripts to the manager, and thus, the verification was required.
Is this the case or is it a "You have an awesome script, now it can be added".
I figured the rating system would weed out the unreliable scripts

That was the question.

I think automatic verification system is out of the question as it wont be hard to make a script to find text on a certain line in the script (not using Player[].Pass) or disguise the pass into the proggie or something that doesn't involve sending the pass to a server using internet… It's also possible to do "Str123 := Players[0].Pass" in DeclarePlayers and then send Str123 to a server that the automatic verification system might not catch

From: Frement
I would recommend auto-check at first, to find Player[CurrentPlayer].Pass etc. Because i can make the send function like "SFJJSF8242();".

I do not agree with this, your script would have to call somewhere GetPage or any of the send functions before you can use "SFJJSF8242();" as send function, so the script would contain it, unless someone added something to srl or simba and commited it xDxD?

From: marpis
The verification process should be as quick as this:
CTRL + F words like SendEmail, SendCrap etc. and manually check them, takes a minute per script

Ctrl + F is the search function isn't it?(not 100% sure)

From: Zyt3x
I think automatic verification system is out of the question as it wont be hard to make a script to find text on a certain line in the script (not using Player[].Pass) or disguise the pass into the proggie or something that doesn't involve sending the pass to a server using internet… It's also possible to do "Str123 := Players[0].Pass" in DeclarePlayers and then send Str123 to a server that the automatic verification system might not catch

It would still contain a GET Players[0].Pass, it would be detected.
afaik you can't avoid a warning verification system, as you will need to use the send functions somewhere and if it contains one of these it should be required to be verificated by a higher member.

From: Hermen
It would still contain a GET Players[0].Pass, it would be detected.
afaik you can't avoid a warning verification system, as you will need to use the send functions somewhere and if it contains one of these it should be required to be verificated by a higher member.

Not if you make the script search the script file (script.simb, using GetFileString and such), as most users save the script after entering their details

There should be a system like JaGeX have; Green zone; Nothing suspicious. Yellow: Contains sending of information. Red: Players.Pass is used outside of DeclarePlayers; Black, Both Yellow and Red.
(or something similar)

I think that if you can find player[].pass outside of declareplayers, they are probably stealing passwords

From: MylesMadness
I think that if you can find player[].pass outside of declareplayers, they are probably stealing passwords

Not if they are used in like a form or something

Players[0].Pass := Edit1.Text;

From: Zyt3x
Not if they are used in like a form or something

Players[0].Pass := Edit1.Text;

I would consider that declaring players

It's not like you are searching specific procedures, that would be not doing-able(I know its not a word :p) it would search the whole script and loop through all lines.
then if it finds some of the unwanted shizzle it gets an unverified thingy.

It's not about pass stealing, it's also about scripts that may harm your computer.. Like a virus does.

From: MylesMadness
I would consider that declaring players

DeclarePlayers; is not the same as declaring players. I often declare players outside of DeclarePlayers :p

From: Hermen
It's not like you are searching specific procedures, that would be not doing-able(I know its not a word :p) it would search the whole script and loop through all lines.
then if it finds some of the unwanted shizzle it gets an unverified thingy.

Why is that no doable? Imo it would be very easy to do..

var
  CurProc : String;
  Script : String;
  sArr : TStringArray;
  I : Integer;

begin
  Script := 'procedure Write;' #10
            'begin' #10
            '  WriteLn(''Hello World!'');' #10
            'end;' #10 #10
            'begin' #10
            '  Write;' #10
            'end.';

  sArr := Explode(#10, Script);
  for I := 0 to High(sArr) do
    if Pos('procedure', LowerCase(sArr[I])) <> 0 then
    begin
      CurProc := Between('procedure ', ';', sArr[I]);
      WriteLn(CurProc);
    end;
end.

EDIT:

From: mastaraymond
It's not about pass stealing, it's also about scripts that may harm your computer.. Like a virus does.

Afaik, scar couldn't do much harm until you manually turned API calls on?

Simba has the ability to access file structures and stuff like that… FILE WALL!!!

IMO player info (and user settings) should be saved to a file rather than in declare players anyway.

From: Boreas
IMO player info (and user settings) should be saved to a file rather than in declare players anyway.

like rsbot's, and every other java bot? :)

i wouldn't mind it

From: Awkwardsaw
like rsbot's, and every other java bot? :)

i wouldn't mind it

Like SRLPlayerForm in misc/Users.scar which is underused.

I'll work on this in ~14 days.

From: Boreas
IMO player info (and user settings) should be saved to a file rather than in declare players anyway.

That's what I think too. :)
I made my own system because SRLPlayerForm is not working and it's really confusing reading it so I gave up trying to fix anything in it…

From: Boreas
Like SRLPlayerForm in misc/Users.scar which is underused.

<3 PlayerForm, I used it all the time. Too bad its still not working in Simba :(

What if you don't use procedure DeclarePlayers;. Like me, I prefer it to be SetupPlayers or something else totally different.

From: Frement
I would recommend auto-check at first, to find Player[CurrentPlayer].Pass etc. Because i can make the send function like "SFJJSF8242();".

But you'd still have to use the basic methods, including (but not limited to): OpenWebPage, GetPage etc.

In any case I think all scripts will be looked at by the staff (or those trusted to do so). An automated system isn't needed to look at a script first. I for one can find something "odd" in a matter of minutes just browsing a script. We have plenty of people here capable in this, I think everyone will agree on this instead of an automated system.

"All scripts that have applied for the script manager will be checked by those trusted before being accepted in the system for safety reasons."

Build player management into Simba. This would make it significantly harder to steal passwords.

From: Smartzkid
Build player management into Simba. This would make it significantly harder to steal passwords.

I agree.

And add a option to encrypt the password so Players.Pass would return an encrypted string (srl procs or something). I use this and now I don't have to worry about it anymore :)

If people are that worried about it, perhaps pgp?

http://villavu.com/wiki/Script_Manager

(Perhaps someone else can create an article + thread about managing players)

From: Smartzkid
Build player management into Simba. This would make it significantly harder to steal passwords.

would that be in the form of a plugin? I'm not sure if Simba supports adding menu items or whatnot through plugins, but that would be a bit more ideal, i think.

From: Narcle
<3 PlayerForm, I used it all the time. Too bad its still not working in Simba :(

I cant get forms to work at all in simba >.>

From: Dan Cardin
would that be in the form of a plugin? I'm not sure if Simba supports adding menu items or whatnot through plugins, but that would be a bit more ideal, i think.

Extensions can create menu items =)

From: Dgby714
I cant get forms to work at all in simba >.>

That's because you use the Linux version. :) They actually work, but not when you create them inside PS, as the interpreter stinks.

From: Dan Cardin
would that be in the form of a plugin? I'm not sure if Simba supports adding menu items or whatnot through plugins, but that would be a bit more ideal, i think.

This is already possible, with extensions.

From: Wizzup?
That's because you use the Linux version. :) They actually work, but not when you create them inside PS, as the interpreter stinks.



This is already possible, with extensions.

I use the windows version in wine =P

I also just found out how to make forms =)

From: Wizzup?
This is already possible, with extensions.

basically the same thing i assume (plugin vs extension).

I personally like the idea of no approval process. The community should drive a community based tool. I personally don't see how having the tool will be better than the forums (since as i was thinking of a good way to do this, i ended up basically describing a forum) other than a possible automatic script installer, but if that what people want, there should be positive ratings such as stars, to determine how well the script works and a report button that will immediately make the script turn red or something to make it obvious that its been reported, and it will notify someone (i'd like to say that the community would also deal with reports, but i can see spamming being a problem, so i would have a small group, that will be able to confirm or not the validity of the report, and once the decision is made, it won't be able to be reported again until a new update.).

Other than reports, it should be an open system that is made better by more people participating. I think it would also make sense to have the stars on a script degrade over time after a lower threshold of downloads has been reached. This way, you wont have previously great scripts that weren't updated showing up at the top of the list when sorted by stars.

From: Dan Cardin
basically the same thing i assume (plugin vs extension).

Actually, Extensions are written in PascalScript. :)
We want to give the same features to plugins later as well.

From: Dan Cardin
I personally like the idea of no approval process. The community should drive a community based tool.

Well, I'm not sure what you are having in mind with the approval systems, but I can assure it wasn't like a second AppStore in my mind… ;)
There would be a lot of people that can (quickly) verify your script, and add/update it. If someone has contributed enough scripts, we could give him access as well. On the other hand, if we let everyone update their own scripts, it should be fine too. It is probably more of a hassle to set up, though.

From: Dan Cardin
I personally don't see how having the tool will be better than the forums (since as i was thinking of a good way to do this, i ended up basically describing a forum) other than a possible automatic script installer

Well, it is very important to make using SRL and its script easy. I think this will be a great addition, if done properly. :)

From: Dan Cardin
but if that what people want, there should be positive ratings such as stars, to determine how well the script works and a report button that will immediately make the script turn red or something to make it obvious that its been reported, and it will notify someone (i'd like to say that the community would also deal with reports, but i can see spamming being a problem, so i would have a small group, that will be able to confirm or not the validity of the report, and once the decision is made, it won't be able to be reported again until a new update.).

Seems like a good idea. [Mark this script as potentially dangerous]

From: Dan Cardin
Other than reports, it should be an open system that is made better by more people participating. I think it would also make sense to have the stars on a script degrade over time after a lower threshold of downloads has been reached. This way, you wont have previously great scripts that weren't updated showing up at the top of the list when sorted by stars.

Not sure which open you meant, but I think it will be safe to say that it will be open in whatever way you mean. Except for the actual adding scripts. There *must* be some sort of small layer for that to prevent unauthorized access.

Finally, it will of course be open source, so everyone is invited to work on it. ;)

well how does one add a script? through SRL? if so, there is your small layer. I suppose it would have worked better before when junior members became as such after a few weeks. Then it would make things easier to just put the limit to when they can at that point. I just find it silly that someone should have to approve your script. Does that happen here now? no. People find out if it works and dont use it if it doesnt. Same goes for password stealing. It will be the exact same situation that you have by using the forums.

From: Dan Cardin
well how does one add a script? through SRL? if so, there is your small layer. I suppose it would have worked better before when junior members became as such after a few weeks. Then it would make things easier to just put the limit to when they can at that point. I just find it silly that someone should have to approve your script. Does that happen here now? no. People find out if it works and dont use it if it doesnt. Same goes for password stealing. It will be the exact same situation that you have by using the forums.

I agree to an extent. The fact that we don't do something currently isn't a reason of why not to do it if we're changing things anyway. Instead, there are two ways I wouldn't mind.
The first is that anyone can upload a script, literally anyone, and it has to be approved before hand. This isn't a problem given that if a script is shit, it won't take long to tell, and theres a pool of SSRL to verify them (I would assume part of the reason they have this status is they're trustworthy enough to do something as simple as this).
An alternative would be, for example (although I've heard about the ranks changing), Junior Members and up being allowed to upload, but the script get's added to the database right away with a "ZOMG NOT APPROVED" warning, which spams you thousands of times before you can actually install.

I think those two ideas are basically the two things being discussed through the thread, and I've asked which one it is before (The question regarding anyone can upload or just certain people), but I haven't got an answer, so…?

From: Dan Cardin
well how does one add a script? through SRL? if so, there is your small layer. I suppose it would have worked better before when junior members became as such after a few weeks. Then it would make things easier to just put the limit to when they can at that point. I just find it silly that someone should have to approve your script. Does that happen here now? no. People find out if it works and dont use it if it doesnt. Same goes for password stealing. It will be the exact same situation that you have by using the forums.

The main point is that you technically don't want:

• A repository that everyone ``can just'' commit to.
• People access each other' files. (svn has a sucky solution to this)

This is why I came up with the system of trust. A certain amount of people can commit to the entire repos. Scripters and in updates of their scripts, and those people commit it. If scripters have send in enough and are trusted, they are also allowed to commit to the entire repos.

I mean, how often do you update your scripts on SRL? Certainly not 5 times a day. :)

From: Wizzup?
The main point is that you technically don't want:

• A repository that everyone ``can just'' commit to.
• People access each other' files. (svn has a sucky solution to this)

This is why I came up with the system of trust. A certain amount of people can commit to the entire repos. Scripters and in updates of their scripts, and those people commit it. If scripters have send in enough and are trusted, they are also allowed to commit to the entire repos.

I mean, how often do you update your scripts on SRL? Certainly not 5 times a day. :)

I believe this thread would be more succesful if people knew about the guild…

~RM

From: Rasta Magician
I believe this thread would be more succesful if people knew about the guild…

~RM

The Guild
Bwahaha :biggrin:

Anyways I agree, and its more or less what Wizzup just said…

From: Wizzup?
The main point is that you technically don't want:

• A repository that everyone ``can just'' commit to.
• People access each other' files. (svn has a sucky solution to this)

This is why I came up with the system of trust. A certain amount of people can commit to the entire repos. Scripters and in updates of their scripts, and those people commit it. If scripters have send in enough and are trusted, they are also allowed to commit to the entire repos.

I mean, how often do you update your scripts on SRL? Certainly not 5 times a day. :)

I'm not sure how that makes it better. What exactly will the commiters do? If they're anything like i would expect them to be (if all you have to do is be trusted to commmit) they're not going to scour the script looking for potential problems. They'll quickly look through. If that's the case, i don't see why simply automatically looking through the script for file access and internet access and flagging them accordingly for people to see. I would want to know why any script is doing either anyways, so just having a person looking through and determining whether or not its safe isn't going to be as useful for that purpose as an automated way.

What would you plan to do about scripts that aren't just one file, or require a plugin? I can see that as potentially being a way around automation, but then their plugin would need to have the source for you to check it (easily i think) anyway. But the real thing i was wondering about was just how you would handle it.

From: Dan Cardin
I'm not sure how that makes it better. What exactly will the commiters do? If they're anything like i would expect them to be (if all you have to do is be trusted to commmit) they're not going to scour the script looking for potential problems. They'll quickly look through. If that's the case, i don't see why simply automatically looking through the script for file access and internet access and flagging them accordingly for people to see. I would want to know why any script is doing either anyways, so just having a person looking through and determining whether or not its safe isn't going to be as useful for that purpose as an automated way.

What would you plan to do about scripts that aren't just one file, or require a plugin? I can see that as potentially being a way around automation, but then their plugin would need to have the source for you to check it (easily i think) anyway. But the real thing i was wondering about was just how you would handle it.

The system can handle more than one file. Plugins are not supported. Why would a script need a plugin? Anyway, it can always be added later if it turns out to be a requirement. It's not at all hard to load DLL's dynamically.

I don't know of any specific instances where scripts have been used, but from the things I've heard its not completely uncommon. I think Icefire needed one for one of his scripts, or maybe one of mixster's pathfindy things? But since you have the capability to allow them, what would be the checking them plan?

I still don't understand why don't you just do a quick scan for all the possible dangerous methods (OpenWebPage, DeleteFile, RewriteFile, GetPage)?

If it's turned out to be clean, then it will get added to the database. If it isn't, it'll get flagged and pending for moderator (or the Trust group, you say) review (of course, the line number will be included in the "flag report" so the moderator could quickly find where the potential threat is located)…

^ People could always use their own methods of doing it, rename procedures/functions, etc. That wouldn't help much by just blocking those things. Especially with Simba/MML being open, so you can just get the very basic ways of doing it, and copying that with names like "MineRock," etc.

I dunno if this has been mentioned.. but what about plugins? =X

Checking them would involve source code and then compiling it, I guess.
The reason to ``just'' check it automatically is that there will still need to be a way to regulate who can throw stuff in the repository, and who can't. You simply don't want everyone to have access to it as it will become messy in so many ways I don't think I can imagine all right now. That's why it needs to be checked / regulated. This doesn't mean it will be a second apple store… ;)

^ Wait was that at me?

From: i luffs yeww
^ Wait was that at me?

From: Wizzup?
Checking them would involve source code and then compiling it, I guess.

Pretty sure he was talking about plugins here :)

Maybe .scar file association?
Would be pretty awesome…
Maybe it already can..

I'm not sure if you're talking about the Script Manager or Simba itself. For Simba, see this extension. To add SCAR extension you must adjust the constant at the top. :)

Well yeah, to get a script into the repository it should be checked to make sure that it both follows standards and actually works, but each update shouldn't have to be verified (unless it trips the internet flags).

Also, about people claiming people can just rename things, if you have to use GetPage, you'll still end up calling that when you rename stuff ("MaskFunction := @GetPage;") so it won't make a difference.

I meant you could just take the GetPage function and rename it.

From: i luffs yeww
I meant you could just take the GetPage function and rename it.

But you really can't.

Why not? D:

You'd have to reference it in the script, which would trigger the warning system (and then when someone looked at it it'd be really suspicious). The other way would be to use a custom version of SIMBA, but you'd have to get everyone else to use it first which would defeat the point.

From: i luffs yeww
Why not? D:

function MineRock(S : String): Boolean;
begin
  Result := GetPage(S) <> 'error';
end;

You still have to use GetPage even though you're renaming it ;)

I don't think anyone is getting what I mean.

Let's say I've a function GetMessage(s: String): String;, and it's flagged by the system. Since SRL/Simba is open, I can just take..

function GetMessage(s: String): String;
//from here
begin
  Writeln('lolwut');
  Result := s;
end;
//to here

And put that in my script as this..

function lolwut(s: String): String;
begin
  Writeln('lolwut');
  Result := s;
end;

see? I never called GetMessage. I just used the exact same method of it. And I could do that for Writeln, etc. etc. if they were blocked as well.

From: i luffs yeww
I don't think anyone is getting what I mean.

Let's say I've a function GetMessage(s: String): String;, and it's flagged by the system. Since SRL/Simba is open, I can just take..

function GetMessage(s: String): String;
//from here
begin
  Writeln('lolwut');
  Result := s;
end;
//to here

And put that in my script as this..

function lolwut(s: String): String;
begin
  Writeln('lolwut');
  Result := s;
end;

see? I never called GetMessage. I just used the exact same method of it. And I could do that for Writeln, etc. etc. if they were blocked as well.

Not from PS, the methods aren't exported…

^ You can edit it, can't you? Simply change the name of GetPage (or whatever it may be) and call it lolwut in your script.

GetPage is a 'native' function, if you will. Built into Simba. You can't duplicate it without calls to other known 'unsafe' functions, a plugin, or API calls.

So Simba isn't completely open? Or am I missing something? Even if it is built into it, you can edit it and rebuild it, can't you? 'o.O?

From: i luffs yeww
So Simba isn't completely open? Or am I missing something? Even if it is built into it, you can edit it and rebuild it, can't you? 'o.O?

You'd have to distribute your version of Simba tho.

~RM

Ah. Fair enough. But then how would stats be used? Are they planned on being integrated with Simba? (As now GetPage/etc. are necessary.)

From: nielsie95
I'm not sure if you're talking about the Script Manager or Simba itself. For Simba, see this extension. To add SCAR extension you must adjust the constant at the top. :)

I guess as in the scar button (under tools I think) that's quite simply: Associate .scar files d:

I've used quite a few scripts that have been SCAR intended, but work well with Simba as well… So, a cool little button, that way I don't have to look at a gay WINDOWS icon and rather a freakin lion? :D

Stats will be part of SRL, thus theres no issue since we know SRL is safe. ;)

The idea is that you shouldn't have to call "GetPage" from your script. SRL's stats will, but they're hardcoded so that they can only call the SRL Stats server, and you can't change that from within the script. With script updating built into the the Script Manager, nearly all scripts shouldn't have a reason to connect to the internet from in the script itself.

(Slight offtopic, but does Simba have an Open/CloseConnection function in it like SCAR's?)

Ahh. Alright. :) Thanks.

From: Widget
The idea is that you shouldn't have to call "GetPage" from your script. SRL's stats will, but they're hardcoded so that they can only call the SRL Stats server, and you can't change that from within the script. With script updating built into the the Script Manager, nearly all scripts shouldn't have a reason to connect to the internet from in the script itself.

(Slight offtopic, but does Simba have an Open/CloseConnection function in it like SCAR's?)

I think t was implemented… if not it was supposed to be

From: c0rrupt f1r3
I guess as in the scar button (under tools I think) that's quite simply: Associate .scar files d:

I've used quite a few scripts that have been SCAR intended, but work well with Simba as well… So, a cool little button, that way I don't have to look at a gay WINDOWS icon and rather a freakin lion? :D

Yes, that's what the extension does ;) See the other thread for an explanation.

Very basic…


Any ideas for an alternative user interface? I don't particularly like this one, but it gets the job done I guess.
Also note that "Rate" will probably not be an action in that list, I just couldn't think of a better 2nd item for the list right now… (Obviously the icon makes no sense either yet)

Maybe categories?

Yes, but there are several ways to implement that into the UI. It will also have a small search/filter feature.

From: Wizzup?
Yes, but there are several ways to implement that into the UI. It will also have a small search/filter feature.

Something like that? I just made red boxes cause I didn't know what the list menus and edit boxes are like :/

Yes, or add an extra item list with the categories:

(Yeah, it looks FUBAR in ASCII)

|–category—|—scripts in cat.—| desc,rating,version,author
|——————|————————–|—————-|
|**Mining***|*Essence Miner**| DESCRIPTION ETC
|—Fishing—-|—Power Miner—-|
|–Smithing—|

Splitpane the right side panel. Show standard information in the upper pane and the description in the lower pane.

make each script into a button, like the forums, just the whole thing is the link rather than just the text and each has an uninstall button on it. Then that brings you to the description and whatnot. Something like firefox's new addon manager.

From: Dan Cardin
make each script into a button, like the forums, just the whole thing is the link rather than just the text and each has an uninstall button on it. Then that brings you to the description and whatnot. Something like firefox's new addon manager.

+1, that'd be great. And, you'd reinctroduce a (somewhat?) familiar interface (to most people) wrapped around a new functionality.

Alright, let's see if I can do that in Lazarus… :p

The initial version won't be exactly as discussed here, but we can add plenty of functionality/gui later. Expect it in a few days.

There's one thing… I think I'll make it save all the scripts to Simba/Scripts instead of giving it it's own directory. This does mean it may override modifed scripts, but it will warn for this. Y/N? Suggestions for a better way to store them? It will also manage extensions.

What's wrong with a separate directory?
Simba/ScriptManager sounds about fine for me – there wouldn't be any worries about overwriting, and everything would be more organized that way.

From: uncfan1119

where did you get that.. :o

From: Nava2
where did you get that.. :o

your not the only one who wants to know…..

YAY i'm third!

~shut

From: uncfan1119

You should condense the GUI a bit though

From Nava's post I'm guessing somewhere on pastebin, but I like it!

~RM

From: Widget
You should condense the GUI a bit though

This is better, but I would love to see the scripts list as a table (with Ratings, Level, Author, name etc etc.), where one could sort as well.

Then the description having wiki-markup/TeX would be nice as well.

(Or maybe sphinx markup? idk..)

AFAIK this installs directly from the forums? Why do you need a username and password? How will it update?

User/pass for rating and download. Updated every time you open it (I guess).Refresh button could be added but not really necessary imo

rating doesn't work
And login conformation will be added

From: uncfan1119
User/pass for rating and download. Updated every time you open it (I guess).Refresh button could be added but not really necessary imo

rating doesn't work
And login conformation will be added

I'm confused. Did you already write a lot of code to do this or is this something you quickly made to demonstrate how it could look/work?

hmm seems like a good idea, hopefully soon

I am waiting quite eagerly for this :) !
Any news? Considering it's finals time I doubt anything new has progressed…

If there's skill categories like the above example, will scripts like MSI be able to appear in multiple categories? I would much rather it be that way than a separate category for "Misc" scripts. When people look for a Woodcutter, they go to the Woodcutting section, not Misc.

I also suggest a warning if the script has already been downloaded. For example, if someone downloads MSI from the Woodcutting category, it shouldn't be redownloaded if they try to from the Mining section, know what I mean?

Also, if for example, I was to make MSI work off of one extension - download, run, remote and any other features that may come - would the script manager be able to download the one .sex file into MSI/Extensions?

E: Last thing, for the heading for MSI, would there be a way to display all the sub-scripts we have? Rather than just saying AIO Woodcutter. That may be too much to ask though. As an alternative we could just list all the scripts under "More Info".

Considering this is still in coding, there will be a way.

Just think of the way that would keep things most organized;)

~RM

Who currently is working on this? I would kind of like to give this a try/help whoever is developing it.

From: HyperSecret
Who currently is working on this? I would kind of like to give this a try/help whoever is developing it.

yea, if its gonna be written in simba, then i will help, if its written in some other language like C, C++ or python or something like that, then i cant help

but yea, if its written in simba, then i would be glad to help

~shut

Its being written in FPC I believe for the client side, and python for the server side.

Please, someone correct me if I'm wrong.

From: Nava2
Its being written in FPC I believe for the client side, and python for the server side.

Please, someone correct me if I'm wrong.

The server side is kinda done. The client side just needs work. Mastaraymond is supposed to work on it. Client side is written in FPC.

From: Wizzup?
Client side is written in FPC.

which is what simba uses, correct?

~shut

From: Shuttleu
which is what simba uses, correct?

~shut

Yes. It will be integrated in / a part of Simba.

is it posible to make a option to make a script open soure or not? like rsbuddy did.

From: go9090go
is it posible to make a option to make a script open soure or not? like rsbuddy did.

Not at the moment, but there is ways to hide the source code, but I don't recommend it.

Why would you like to hide it anyways?

From: Zyt3x
Not at the moment, but there is ways to hide the source code, but I don't recommend it.

Why would you like to hide it anyways?

Well as I found out people are selling simba scripts on other sites and one site is trying to make it closed source so pretty much that could be the main reason.

Then scripts would have to be looked at by an admin before releasing surely?

From: Zyt3x
Not at the moment, but there is ways to hide the source code, but I don't recommend it.

Why would you like to hide it anyways?

well i thinking about "large scripts", i made on rsbuddy a c2 dungeon fisher and just before the nuke i finished a dungeon c1 rusher. It was a large project. If i had more time it made it to a aio dungeon bot. I am not gana make those large script when i know other people can walk with it. It just aint feel fine. :S Its must be a persenal project. Btw srry for english am not that great in english :s

From: akonowns
Then scripts would have to be looked at by an admin before releasing surely?

yes or you can do it like ebay do it with seller. Giving stars, if a scripter got 200+ 5 stars you know more about the scripter. Or simba have to make a function who logs a player in and enters the pin so scripts can only login with this hiden function. So the pas and username (+pin) will never used in the script. Just ideas ;)