SRL Archive - Development

Hello,

I've working on the script manager since yesterday.

As of now, it can download a script database, and show a list of scripts that aren't installed currently, or have newer versions available. (Its been decided to leave these in the same list, but I've made them in such a way as New Scripts and Updated Scripts can be kept separate).

Installing scripts works grand, but updating scripts is the problem. Now it just overwrites any files from previous versions. This includes installing the fresh new version without any of the users settings (such as Account details).

I've thought of two ways to get around this, and Dgby714 has contributed a third.

-Global Account Storage-
This would involve having the username and password combination somewhere where every script can access it.

Pros:

• Can be encrypted, so fairly secure. (rather than leaving plaintext passwords in the script)
• Easy for the scripter to use.

Cons:

• Could be security issues (Could be avoided my making some encryption mandatory)
• Can only be used for certain global info, like account/army details.

-Persistent Tagging-
Since both versions of the script can be accessed while updating, if predefined area can be copied from one area to the next. So say wrap the player details in the first script with {!–DATA(ACCOUNT) BEGIN–!} and {!–DATA(ACCOUNT) END–!} tags, and the part between then would be basically copied and pasted to the same tags in the new script.

Pros:

• Easy to implement within the scriptmanager.
• Can be used for any type of data (each "tag" can have a unique identifier)
• Very easy for the end user, as require so further action.

Cons: - I couldn't think of any really.

-Smart Merging-
"basicly get a diff of old->new and apply it to edit and if it fails just use new (fresh script)" says it all really.

Pros:

• Easy to maintain, as its just a diff of the two files.

Cons:

• Could be messy, and some scripts could break it.

Anyway, feedback is needed to see which method would be the best, currently I think the Tagging method has the most potential, but I'll leave it down to you far-sighted individuals to see which is more appropriate.

~mc_teo

P.S. maybe a poll should be added.

-Global Account Storage-

I don't see much of a future in this one. Would limit the script writers.

I don't see how the other 2 works when using forms, as that information is usually stored in a .ini and not in the script itself. Why won't we just all use .ini's?

I like the idea of persistent tagging, as I think it'd be mostly pointless to only have variables used in every script saved as there would still be updating to be done by the user for script-specific variables, and I just don't imagine smart merging working that well.

How would multiplayer be implemented? Would a form be required for every script?

From: mc_teo

Could be security issues (Could be avoided my making some encryption mandatory)
Can only be used for certain global info, like account/army details.

I just don't like the idea of saving names/passwords/pins outside of the script itself. All java bots work this way, and look how many accounts are stolen every day. I personally think keeping information within the script is one of our features that makes us so secure.

But I'm for the rest of your project, a nice script manager would be cool. :) I imagine the simplicity would attract more people.

From: Flight
I just don't like the idea of saving names/passwords/pins outside of the script itself. All java bots work this way, and look how many accounts are stolen every day. I personally think keeping information within the script is one of our features that makes us so secure.

But I'm for the rest of your project, a nice script manager would be cool. :) I imagine the simplicity would attract more people.

I second this…

The tagging approach is quite a hack, but it seems fine to me. Perhaps it's better to make it an included file? And what will you do if scripters change some of their player variables?

Wait it's against the law for a Non-Member in SRL to use a SRL-Member script, or Non-Member as in Jr's and Registered Users?

From: Wizzup?
The tagging approach is quite a hack, but it seems fine to me. Perhaps it's better to make it an included file? And what will you do if scripters change some of their player variables?

Yeah, maybe another file for the variables is a better idea. Do you mean if they change the variable name? I think maybe when a script does this it should just tell that script manager somehow that Variable_X turned into Variable_Y, and the changes will obviously already be in the script, and then the script manager will change the name of it in the variables file.

From: Huthaifah
Wait it's against the law for a Non-Member in SRL to use a SRL-Member script, or Non-Member as in Jr's and Registered Users?

Um, you realize that's my signature, right? Not part of my post. Anyway, yes, it's against the rules to leak a script to someone who doesn't have access to its part of the forum. Non-member as in people not having the SRL Member rank or above, as in Jr's and registered users.

Ultimately though your giving all Simba User's access to the Free for All section. Where as they can't get to it normally at first. Meaning user's that either haven't registered or just registered.

~BraK

What if the provider of the Members Script gives you permission to use the script?

From: BraK
Ultimately though your giving all Simba User's access to the Free for All section. Where as they can't get to it normally at first. Meaning user's that either haven't registered or just registered.

~BraK

Can't anyone access the public scripts?
But for the higher level sections, have them login through the script manager which will then check what scripts they should have access to?

From: Huthaifah
What if the provider of the Members Script gives you permission to use the script?

Then I'd think it's okay as long as you don't share with other non-members.
Anyway, this is really off-topic.

From: BraK
Ultimately though your giving all Simba User's access to the Free for All section. Where as they can't get to it normally at first. Meaning user's that either haven't registered or just registered.

~BraK

I wonder if we made a login system (not RS Name/Pass) for SRL users that would determine which scripts could be downloaded/loaded from the script manager. Login via the manager using your SRL info and load scripts according to your rank. Would something like that work?

From: Wizzup?
The tagging approach is quite a hack, but it seems fine to me. Perhaps it's better to make it an included file? And what will you do if scripters change some of their player variables?

Well again, down to creativity of scripter, and I suppose how powerful we decide to make the tagging. Could have different users tagged, and then just append the new variables.

Again, I don't think this updating scripts should focus on too much.

From: Ogre
Can't anyone access the public scripts?
But for the higher level sections, have them login through the script manager which will then check what scripts they should have access to?

For the Members only scripts:

I was thinking of adding the ability to add multiple script databases, much like repositories. This means we could have a public one for everyone, and a private authenticated one for members.

This also means people can have private repositories, for buying and selling scripts, hosted themselves, as I know some prefer. (They could post a link to a repository on the release thread, rather than attaching different versions)

We could have like testing, and development repos too, and numerous other uses.

So should multiple repository support be added?

~mc_teo

I like the idea of the Members+ scripts being visible to everyone, but only accessible to Members+. More incentive for people to get involved with SRL, contribute, and work their way up to Members.

I like the idea of multiple repositories. That makes it very flexible, and then allowing for password authentication would be excellent. This way, script sales could be done for those who write aut genned repositories. :)

From: Nava2
This way, script sales could be done for those who write aut genned repositories. :)

No scripts sales, please? That's the thing I very very love about srl.
I was about to write something heart touching, but I apparently failed(so I won't write it), but I very dislike script selling in any way.

Separate repositories are good idea, but I don't think it's really a problem if the script manager only works with the public scripts. I know that the amount of member scripts is huge and they are very complex and best of all hence script manager would be good for them, but imo script manager is somewhat leechy and that's more like for the leechers.
The point I am trying to make is that most script manager uses would come from the public and if there would be a member section it would only be 0.5% of the total uses.

The day people start selling scripts is the day I stop making them. But then again, if someone were to make a premium script and try to sell it, you'll see me making the identical script and releasing it for free. I'm very much against script sells, I believe this is a unique feature of SRL.

I have to be honest. I think script sales is something SRL needs, along with working antirandoms etc. Having script sales will bring new scripts and scripters. That will bring more users. Im not one for advertising and blowing things out of the water, but what SRL does need, is more users.

Regarding the Script Manager and Script Sales. The Manager will have to download scripts to the users hdd, right? This is a security risk for people selling scripts. afaik, we dont have a method of obfuscating scripts for Simba. I know for SCAR freddy would do it. People could buy the script then distribute it if it was downloaded to the hdd. Is there a way to just load it into memory? Having a script downloaded into memory then started from memory is a lot safer imo.

Then the issue is, if we can do the above, what will make it so another extension or script cant read the variable storing scripts and get the paid for scripts?

You shouldn't need to worry about this with an updater, the script writer should have the needed variables/usernames/passwords that a user would change in another file, be it an include, or a text file formatted however they like, then you just replace the script with the new version and it continues to read from whatever it read from before.

From: moparisthebest
You shouldn't need to worry about this with an updater, the script writer should have the needed variables/usernames/passwords that a user would change in another file, be it an include, or a text file formatted however they like, then you just replace the script with the new version and it continues to read from whatever it read from before.

Yea but there is where the issue lies. The variables are usually in the scripts, we dont have an 'account manager' like other bots, unless we start using that account form that Sumillion wrote thats included in SRL.

Then theres the risk of account theft through that file.

Yeah, I wasn't big for the idea of selling scripts myself, but I do remember in the past people hosted scripted on their own servers, and allowing multiple repositories is the best way to assist this.

I think Mopar's method would work really well. The scripter makes the file if it doesn't exist, and fills it with script settings and all. This won't be over written then when the next update comes around, and the new script loads the settings. Then new settings can be added to the file by the updated script, while maintaining backwards compatibility.

So all scripts get overwritten when updated, and any file not updated will be left alone, are we agreed with this then?

The last thing we need is script sales…

From: mc_teo
I think Mopar's method would work really well. The scripter makes the file if it doesn't exist, and fills it with script settings and all. This won't be over written then when the next update comes around, and the new script loads the settings. Then new settings can be added to the file by the updated script, while maintaining backwards compatibility.

So all scripts get overwritten when updated, and any file not updated will be left alone, are we agreed with this then?

This is exactly what I said… Just use .ini's for the settings.

Yeah, I guess I like the idea of multiple repositories. How did you plan on having authentication work? I think it's a good idea for people to have to use their villavu user/pass because they'll be less likely to share that than anything else with a lower member to give them access.

And, yeah, on second thought the script itself should be able to completely manage a file with its settings, and update it when the script is updated with new settings.

Why do we need so much user all of a sudden? And why we want script selling all of a sudden? Weren't we a good rs/programming/learning community the way we were? Okay, some activity doesn't hurt, but srl won't die just because we are not a greedy(it was hard not to use vulgar expressions) script seller community.
I have to agree with Flight, this may make me active again to write scripts for free which are made for money.

@Ogre: the user name and hashed pass are passed as GET parameters to the server, and it will return the script list if member or 403 error if not. That means that the server script can be altered to return only the name, author and description of the script, but the mechanism used server side would need to be changed also, to basically obfuscate the url, so people couldn't just guess it.

From: noidea
Yea but there is where the issue lies. The variables are usually in the scripts, we dont have an 'account manager' like other bots, unless we start using that account form that Sumillion wrote thats included in SRL.

Then theres the risk of account theft through that file.

If the variables are in scripts and get over-written on a new version, that is the script writer's problem, and the users can complain to him. That isn't how it should be, they should always be someplace else.

There isn't a risk of account theft any other way? It looks the same to me regardless.