SRL Archive - Discussions and Debates

ok so now that i've put the poll there i'll write this out :p

lemme just point out how stupid and distracted i was, i put multiplayer twice on that list >.> if there is a way to take out the second Multiplayer please tell me, otherwise i'd love it if someone with the power to do it would.

Well i made this because there are many talks about turning up the standards of an acceptable app, and i think that we would need an example agreed upon by most of what are a few apps that would get in at the new standard. and this pool is just to have a look at what we still think are necessities. i think that those would be necessities and that some other things suchs as Types and Records or TPAs could sort of be a bonus.

And i'd definitely like to see some apps with a better usage of srl.

~RM

i hope you meant which should be in the requirements.

I think we should, in the unlikely event that it happens, give exceptions, like we've already done with a few people whether or not to let them in if its not an RS script. Im not saying that making a bot for a flash game or whatever should get you in. But with Here, i think, was let in because she made that non-rs script. I really dislike the complete focus upon RS :(.

Anyways, thats what i think should be in there. I actually regret not putting in TPA's because its the kind of more advanced thing that the new people should learn how to use.

i regret not having space for more options, because i'd be happy if someone jsut used FindObjTPA rather than doing a whole TPA thing. But those i'd say are to vote for the absolute requirements. i for example didn't vote for walking or multiplayer, because there are some really good power scripts or really good one player scripts.

(i know for a fact that i have close to no experience in walking :P )

~RM

ALL, if you don't have all now days you can't make a few hours running script.

From: Hermpie
ALL, if you don't have all now days you can't make a few hours running script.

I disagree. I can make a kick ass power chopper without using walking.

well, i'm not going to vote for that. if i were, i would say all, i mean, they aren't hard in the least bit, a little confusing at first maybe, but not hard. and i don't mean extreme knowledge in everything, just enough to make it work.

in my opinion, among knowing all that, you need to know how to use all of them in a script for best results. and by that i mean, if findcolor works and is accurate for that thing, use it. if it takes TPA's to make it work, learn those.

as for the script they apply with. it should be a challenging script, showing a little bit of knowledge to most of the requirements. also, i think that for it to make it, it needs to be able to work for 1 hour minimum, players only going false by randoms. the reason i say it needs testing, is it can be the most advanced looking script in the world, but the advanced things aren't neccesarily the best things.

They should be able to use the minimum for the situation.
They should not use FindObj (etc.) where a find color or get pixel would work best.
They should generally hold to the standards.
They should include SRL stats if possible (ex: using a 10-liner to demonstrate comprehension of a subject – no stats).
They should speak English fluently (as to document code).
The script should show a complexity in between Free For All and Junior Members.
They should use basic constructs (if..then, case, maybe try..except for loading bitmaps).
They must include more than three ways a logical decision could be made (ex: Succeed, Fail, Try again).
They must use semi-efficient coding.
They must use an array at least once in the program (player array counts, if single player, some other array).
Show the basics of a DTM or Bitmap (need not be in main script).
Script must be modular (extract a function and still have it run properly). Code must not depend on global variables.
All scripts must succeed in at least two repetitions of an action (ex: banking, if it is a fletcher/alcher/burier one repetition will be considered 4 inventories).
Applicant must not have 'attitude'.

great input, robot! i don't think this pool had much of a result, i think it needs to be more specific. once i get back home i'll make a new thread with questions so that i get answers more of the sorts of robot's, which would be much useful to help setting new standards for our apps :)

~RM

has there not been talks about this in the past?

this was when SMART was release to SRL-Members only

http://www.villavu.com/forum/showthread.php?t=21290?t=23234&highlight=strictness

i had the same thought but scroll to fakawi's first post on the thread ;)

From: fakawi

That will not happen. The system is strict enough as it is. People are sparcely getting through. In my opinion, it is the other way around. Some SRL-Members should evaluate their judging capabilities, and let not only strict indenting or "good code" be the norm, but also place themselves in the position of the poor lonely applicant struggling to get in. You have outvoted many talented I would have let in, but I abide the rules of democracy. We are a very organised bunch, with high standards and maintain a reasonable level of communication. Your status should be used to stimulate and not to impose even stricter rules. Strict rules are the result of poor judgement.

quoted for the benefits of others.

11-19-2007

that was half a year ago. things change.

they are not sparsely getting in anymore, back then we'd see many more apps that had like 19-1, 18-0, 21-0, 17-3 votes, and those walked into members.

nowadays our voting has become so flexible, so sloppy that admins end up turning down people who have more yes' than no's. back then we were being too strict. now we are being too easy. it's the balance we are looking for ;)

plus many new members are voting quite early when they get in, and few people are setting the good example on how to vote anymore. when i got into members i nearly always had n3ss3s vote to direct me, because he would always make a long post examining various details. there were other people doing the same thing, but n3ss was doing it to every app, so i had a good example to follow, and i did not follow it blindly. i considered his words, re-looked at the app and then though for myself. i really think tha if we get the requirements more set in, like not so general. we say DTMs or BMPs are required. we never say they should be freed at the end of the script, but we still complain about when the applicant doesn't free them. really, this will benefit all of us.

~RM

I don't think there is anything wrong with the current list of requirements, its how well each of the criteria is met. Lots of the recent applications have met all of the requirements but do not use them to their full potential. For example the script will have use multiplayer and people will say "Yes you meet the requirements" but I see them calling NextPlayer in the middle of a procedure or loop and not exiting. Now Would I call that using multiplayer… no. Also people say "Yes they have failsafes" but it will be something like 'if not RadialWalk(RoadColour….) then LogOut, etc.' Techically yes that is a failsafe but it would be a lot better if they tried something else like use a symbol or try finding the colour again.

Also the 'requirements' as its commonly known should just be a guideline. An applicant should be accepted even if they are missing a certain criterion if the other aspects of the script make up for it. I mean if the script doesn't use multiplayer or doesn't use RW, etc but has TPAs, DTMs and has effective failsafes then it should receive a yes. Basically what I'm trying to say is that the requirements shouldn't be a deadset thing where if you don't meet a certain point you get declined. It should just be a way of telling applicants what we are looking for and what would improve their chances of getting accepted.

I agree with that the current list is fine, and exactly that it's about how is it being used, checking just if FindDTM is mentioned and if there is a RadialRoadWalk or even a DeclarePlayers somewhere is just too easy for the applicant.

Personally, I don't think we should even have a list. It should be decided on your own personal judgment of what you think a SRL member should be.

If we just had a tickbox chart, then, in theory, everyone should vote the same way.

My input is for everyone to use their own judgment, and not just follow the crowd when voting.

yeah its ur own personal decision, the only requirement its needed is trying to get it more difficult,strict, and good attitude :)

every application should be different. focusing on different merrits.

If theres alot they need to show, you might be shunning away someone that could be a god in one area, but not know anything in another.


The way i see it, not every man and his dog should be a member. And neither should every person with the ability to apply. Perhaps the problem is simply that…applying.

Back in the day of kaitniek.com, better status was given without the person asking, and the community itself was better as a whole. Status should be earnt, not thru simply asking for it, but by showing, over and over, that you are worthy of it.

————-
My suggestion. Remove applications, and simply base membership off obvious work, obvious skills, obvious helping, etc. Things that actualy matter, not the ability to cut and paste code as im sure some applicants do.

Jeez, if i was a complete noob, all i would needa do is see the requirements, copy, paste and slightly alter some tutorial code, and bam, instant member.

The way i see it, not every man and his dog should be a member. And neither should every person with the ability to apply. Perhaps the problem is simply that…applying.

That's right, and Star, requirements prevent a bit a flood off stupid apps, with no script saying that he/she can test scripts, or bad scripts.

The understanding I've gotten is that most of SRL Members approve to that the status's name would be better describing as "Approved Scripter" or something like that, which says that SRL Members, (excluding exceptions), should be able to script. Even nowadays, with the list, some members do post questions that would belong to the Kindergarten section we used to have.

The current requirements are fine, but the judging needs to be stricter, no need for yes(es?) like "the script isn't so good but you seem like I nice guy", the script has to be good and the applicant should be somewhat a nice guy.

My view.

Jeez, if i was a complete noob, all i would needa do is see the requirements, copy, paste and slightly alter some tutorial code, and bam, instant member.

That is what we are discussing here, it's about how are they being used in the script, not are they being used.

i'm sorry if i wasn't exactly clear. i never meant for them to have to meet ALL the requirements, but to meet most of them. and what i meant with new requirements is not actually a new requirement, only a refining of the old ones.

so instead of
Requirements:
- DTMs
- Multiplayer
- Failsafes

we would have like

Requirements:
- DTMs
— Loading, Looking for, Freeing
- Multiplayer
— Switching players in mainloop or exiting after switch
- Failsafes
— Two or three possibilities to solve a problem, not just LogOut;

i think that would be helpful. Like zephyr said, it is still the same requirements, but we use them to their full potential. A list like that would help us look for those small but important details more easily and if released to the public it will also help them add those extra lil things.

what do you guys think about it?

~RM

From: Squigglyo
every application should be different. focusing on different merrits.

If theres alot they need to show, you might be shunning away someone that could be a god in one area, but not know anything in another.


The way i see it, not every man and his dog should be a member. And neither should every person with the ability to apply. Perhaps the problem is simply that…applying.

Back in the day of kaitniek.com, better status was given without the person asking, and the community itself was better as a whole. Status should be earnt, not thru simply asking for it, but by showing, over and over, that you are worthy of it.

————-
My suggestion. Remove applications, and simply base membership off obvious work, obvious skills, obvious helping, etc. Things that actualy matter, not the ability to cut and paste code as im sure some applicants do.

Jeez, if i was a complete noob, all i would needa do is see the requirements, copy, paste and slightly alter some tutorial code, and bam, instant member.

A-a-a-aa–are you the creator of squig.scar!?!?!

What some people don't get was I included things in my 'requirements' list that you can not copy and paste. Sure, you could copy things pertaining to the elements in the list into your script, but, truly, the applicant would have to learn and test which method of accomplishing those goals is best.


What we should use in our revision of applications is the merit system. Anybody who has gone through grade school should know what it is. But, instead of testing applicants on they're knowledge of SCAR – it would be totally pointless with all of the help manuals and tutorials around – but how they use what knowledge they already have to make a script.

I believe that is what Fakawi was looking for, instead of what we looked for, as he said things about how we vote on applicants. We looked at if they had the copy and pasteable knowledge of SCAR, while he looked at their programming intelligence and how they used what they knew. This post lists all of what we should be looking for (near the bottom).

Or, if you are too lazy to read it, we should simply not look for what they include, and instead how they use reasoning in the script…

From: Timer
A-a-a-aa–are you the creator of squig.scar!?!?!

sure am. been gone a long time

From: Squigglyo
sure am. been gone a long time

Yeah, and he's my mate. And for some weird/strange reason, he absolutely hates SRL and is going to release a new Squig. :p

From: IP-Drowner
Yeah, and he's my mate. And for some weird/strange reason, he absolutely hates SRL and is going to release a new Squig. :p

lol you bastard. now everyone is gunna be expecting something.

I said i may consider it, lol. Depends how soon the police force accepts me.

From: Squigglyo
lol you bastard. now everyone is gunna be expecting something.

I said i may consider it, lol. Depends how soon the police force accepts me.

Ah, your include will never win anyways. :p
jk, it's always interesting to see people from a long time ago.
are you just temporarily staying?

i plan to stay until my main gets banned. around 6 ish marks, so thats 8 bans for cheating. so prolly a long time :p

From: Squigglyo
i plan to stay until my main gets banned. around 6 ish marks, so thats 8 bans for cheating. so prolly a long time :p

they're not giving out 0.5 blackmarks anymore, one of my accounts got perm banned after just 0.5.

how about we try to be on topic now? it's been a while.

From: RM

i'm sorry if i wasn't exactly clear. i never meant for them to have to meet ALL the requirements, but to meet most of them. and what i meant with new requirements is not actually a new requirement, only a refining of the old ones.

so instead of
Requirements:
- DTMs
- Multiplayer
- Failsafes

we would have like

Requirements:
- DTMs
— Loading, Looking for, Freeing
- Multiplayer
— Switching players in mainloop or exiting after switch
- Failsafes
— Two or three possibilities to solve a problem, not just LogOut;

i think that would be helpful. Like zephyr said, it is still the same requirements, but we use them to their full potential. A list like that would help us look for those small but important details more easily and if released to the public it will also help them add those extra lil things.

what do you guys think about it?

~RM

From: Rasta Magician
they're not giving out 0.5 blackmarks anymore, one of my accounts got perm banned after just 0.5.
.

since when? i got banned twice in the last 30 days. both 10 day bans, 0.5 marks

BMPs, DTMs, DDTMs - No
RRW or PathWalk - No
Good Failsafes - No
Arrays - Yes
TPAs - No
MultiPlayers - Yes
Loops, Cases - Yes
If, Else! - Yes
Standards - No.

—-

BMPs, DTMs, DDTMs

BMPs are inefficient; there are other things that do the same job faster

DTMs are useless for anything but interface functions, and there are replacements for this, as well

DDTMs are great for walking, but they can be confusing, especially to novices without much experience

These three tools may be useful, but they aren't necessary to having a good script.

—-

RRW or PathWalk

Nice, easy walking. Can be a pain to use, but encourages learning and using failsafes.

Same job can be accomplished other ways, forcing people to use RRW and similar tools would be foolish

—-

Walking of some sort

It's important to know how to navigate.

Scripts should exhibit some sort of walking, anything better than coord-clicking should be adequate.

—-

Good Failsafes

Failsafes take a lot of experience and creativity to make. You can't expect anyone but an advanced scripter to correctly implement good failsafes

—-

Arrays

Used everywhere, from multiplayer to objectfinding. Logical requirement.

Arrays are easy to learn, and not too hard to master; it pays to know arrays

—-

TPAs

Great for objectfinding, but there are plenty of ways to find an object without using TPAs

Another advanced concept that comes with experience and often isn't needed until one needs to find an especially tricky object.

—-

MultiPlayers

Absolutely necessary to know, the spirit of SRL. Even though one and two player scripts are becoming more and more popular these days, there is still a place for large army based scripts.

—-

Loops, Cases

Used everywhere. Without loops, there is no script.

Cases should not be required, but long if-else strings should be noted, and the author directed to a tutorial about cases.

—-

If, Else!

If anyone doesn't know how to use these, they shouldn't even think about applying.

—-

Standards

Vary from person to person, everyone has their opinions of what does and doesn't look good in a script.

Standards should not be enforced strictly. Good use of standards should be encouraged, but not to the extent of denying someone over a couple missed indents.

—-

Much of scripting comes with experience. Make standards too high, and nobody will get in. Too low, and everyone will get in. Whatever you do, set a standard, and stick to it. As it is, complete idiots manage to get in, while very skilled people somehow get denied.

What some people don't get was I included things in my 'requirements' list that you can not copy and paste. Sure, you could copy things pertaining to the elements in the list into your script, but, truly, the applicant would have to learn and test which method of accomplishing those goals is best.


What we should use in our revision of applications is the merit system. Anybody who has gone through grade school should know what it is. But, instead of testing applicants on they're knowledge of SCAR – it would be totally pointless with all of the help manuals and tutorials around – but how they use what knowledge they already have to make a script.

I believe that is what Fakawi was looking for, instead of what we looked for, as he said things about how we vote on applicants. We looked at if they had the copy and pasteable knowledge of SCAR, while he looked at their programming intelligence and how they used what they knew. This post lists all of what we should be looking for (near the bottom).

Or, if you are too lazy to read it, we should simply not look for what they include, and instead how they use reasoning in the script…

….

Or, if you are too lazy to read it, we should simply not look for what they include, and instead how they use reasoning in the script…

That hits the nail.
And thats why I say we should not have a checklist. Otherwise everyone will be forced to script with these methods, and you don't develop your own style

There has to be a chance to look if it is atleast good enough, otherwise people will apply with stupid FindColor scripts saying that it gets the job done.

We could have a good example script a bit above par, and it is expected that people will copy some things of it, but we could simply deny the application if it looks like that something is copied of it and changed just a tiny bit.

i agree, i think that the logic they use is more important that the functions/procedures they've learnt so far. but how many of us can judge logic correctly? and when they ask what do i need for members are we gonna answer "good logic" ?

and by requiring that they learn certain things will oblige them to use a certain logic. How do they walk? Do they use cases? would an if have been better?

i do think that the logic is most important, but i think that by giving a list of requirements they have an aim of what to learn and can more or less tell when they're ready for members.

i would love to see a Requirements thread just saying "Good Logic".

but i do think that one thing that could be wonderful to also help develop personal style is that they submit one script and then they can submit a second script/ various functions which shows they have the knowledge of other things. Many people have been putting DDTMs in their apps with nothing dynamic just to show they know it. it would be a better script without it, and they could post their DDTM knowledge on the second script / various functions

edit: i like n3ss3s idea of an example script.

~RM

I like the idea of n3ss3s too.
BMPs, DTMs, DDTMs needed
RRW or PathWalk needed
Good Failsafes NEEDED!
Arrays not needed, but will help
TPAs not needed, but will help
MultiPlayers NEEDED!
Loops, Cases needed
If, Else! NEEDED!
Standards needed

I think they should find the best way to use things.. but not use too simple ways;)

I have an auto alcher I use. 20 lines. Yes, I watch it and talk to friends while it runs, but thats not the point. The point is I would choose it over a 500 line alcher that accomplishes the same functions. If I was looking for a 'watch-me' alcher, why would I choose the 'less-smart' version where the person apparently has not thought about the control flow of the program?

To me, I would give props to the 'less-is-more'. There are too many things overdone now.

If it is a good script, you can read the logic from the main loop. The way they have broken script into modules, the way they vary from global to local variables and their names, the way they use the simple code and so much more. To set a list will only encourage people to let in all members who vaguely reach the list and deny all else, which could end up letting in more unskilled members or a lot more, but more likely not really change anything except what applications come with…

I rest my case, because i've been out argued, and i do agree logic is the important part. i just don't believe we can all judge logic the same way and that we can set a minimum level of logic requirement as it is different for each of us.

~RM

Still, there can be no checklist. If there was a checklist, you're either in or out.

how about a guide list then :) NOT a checklist, but a guide list, to let them know what might help them get in :p

otherwise if they have no list to guide them they'll be applying with any scripts. we'll see autotalkers apps flowing in…

~RM

A guide is still to much like a checklist. But I guess we could say: "Apply as long as you are proud of the script."

According to the poll, seems like everything should be required! :p except TPA's, they're all alone =[. Poor TPA's…

I think good style and creativity should be in that list too..

i'd definitely add creativity to that list. i don't really see what you mean by good style, hugo?

~RM

From: Rasta Magician
i'd definitely add creativity to that list. i don't really see what you mean by good style, hugo?

~RM

erm like..


the way you build up the script as you go should be sensible like not have only one procedure to do everything but make a sort of mini library of procedures in your script or something :D

IMHO all of them with the exception of DDTM's.

I think standards is already like an unspoken requirement because, let's be honest, who is going to try and read a script with all the lines randomly spaced and everything going crazy everywhere.

I think Bitmaps or DTMs should be a requirement (you must use one or the other), unless for some reason your script does not require one. But most scripts do so I do not think it will be that big of a deal.

DDTMs and TPAs I think should just remain a bonus.

I think RadialWalking should be required because it is one of the best walking methods and very few scripts that are complex enough to be used as a good application script do not have walking. And I hate seeing pure symbol finding as a walking procedure.

Now that I think about it, maybe we should have a list of maybe 5 to 10 of the more complex things and make them use like 4/5 or 7/10 or something. That way if a few of them are not their strong suit, they can still be part of the member community.

I also think that as a hint on the requirements, you should suggest that people use good spelling and proper grammar. I know that this does not necessarily mean how good you are at scripting, especially since people who are not fluent in English can script just as well. But it really makes me not want to vote for someone who cannot spell any words correctly and uses awful grammar. I can understand mistakes here and there and the abbreviation or shortening of words (I do that a lot just so that I can type faster). But when I see: I wana b in slr mebmers cuz I think its cool. I am real good at scripting. Honestly it is just as bad as having bad standards - I just don't wanna read that crap. :D -> anyways just my thoughts -> feel free to tear my ideas apart and hate me :p.

Edit: I now agree with Starblaster about having no checklist really. Almost every member, and pretty much everyone in this discussion, no what is a good script and what is not. Therefore we can all get a pretty good idea of what is a good script and what is not. We can create an objective look at each script individually. Really, you almost do not need any requirements, except that the script must accomplish a semi-complex task (that way people aren't applying with autotalkers). Other than that, I think we are all smart enough to figure out what scripts are good enough to make an application.

@ Smartzkid: I agree with many/most of your points except that of failsafes. Yes it takes lots of practice to get truly wonderful failsafes, but the most basic failsafes. If this yay, else try something else, else logout can be used by even though most basic scripters. Just the fact that they have an alternate means to complete the same task in case the first way fails is enough to show that they at least understand the importance of failsafes and are on the road to become a high enough level to use them masterfully.

[QUOTE=Dan's The Man;398734]Yeah, and he's my mate. And for some weird/strange reason, he absolutely hates SRL and is going to release a new Squig. :p

And when Squig posts below it and quotes it says by IP-Drowner for some reason lol. Hehe, just thought I would point that out to everyone.

TPAs are the true judge of math skills in this forum. If you are smart, you can do tpas in your sleep, otherwise you suck.

This has been discussed a million times, it's not about what we require, but about the enforcement! I hate to see people going there thinking that they have to vote either yes or no and then they do "umm alright I guess it's okay yes from me".

B, TPAs aren't hard, if someone has there TPA: TPointArray, you ain't supposed to go "shit you're new and already have TPAs, yes" , because it's just an array!


End rant.

B, TPAs aren't hard, if someone has there TPA: TPointArray, you ain't supposed to go "shit you're new and already have TPAs, yes" , because it's just an array!

I didnt know arrays until after I got my masters cup :p

Wow i know arrays but i can t create TPA's properly the on I use for all my scripts took me about 4 hours =[