Concerning the direction of SRL/Simba/forums.

So, to start things off, the things I'm proposing would make some very radical changes, but obviously I don't have any more say in anything than anyone else, so thoughts/changes/hate/love/whatever is always useful.

(tl;dr at bottom)

I've been a part of SRL since before 2007 (joined 02/17/2007). I've seen things develop and SRL thrive and Simba be created and everything in between. I haven't seen everything, and I've made my fair share of mistakes and more. But one thing I do know is that SRL has always been and continues to be the best community I've ever been a part of.

That being said, things are dying down.

There are a only a few simple reasons that explain why the steady downfall is happening, but first I shall quickly explain what the downfall I speak of is.

There is currently one active developer for SRL, IceFire. Cohen does stuff for MSI, and Wizzup? and Raymond do stuff for Simba. That's about it. That's not enough for each project to thrive. And some people are quite arrogant and won't allow others any chance to contribute, which is just childish. Activity is down, as is learning (which is what this community is and always has been about).

Learning is ultimately my main point to change what's happening with SRL/Simba(/forums). The size of SRL and Simba are getting out of control. It is terrible for the learning process, and it must be dealt with if SRL is going to survive and bring in new, useful members. Some criticism of C and C++ that I've read (and agree with, somewhat) is that due to the size and vast amount of useful/valid includes and the amount of changes that are made to the languages/libraries, it's virtually impossible to be fluent in the language. I don't care much for one being entirely fluent in any language (at least not any today, as they are all poorly done in my opinion (library sizes)), but it is important to note that adding more and more just makes things more and more complicated. It pushes people away from learning and contributing, and has a very simple and fantastic solution.

Not only is the size too much, but also the learning curve is quite random, for lack of a better term. By this I mean that to get the basics, it's quite simple. Mouse, MMouse, FindColor, GetColor, IsUpText, and a few more simple things are really all you need to make a working script. And you can read a tut and pump out a script in a matter of days-weeks, depending on time and previous coding background. Those don't take any knowledge of anything really, as long as you can plug in parameters and know that you can't do some things between data types, you're golden. But then after that, what's next? TPAs, DDTMs, and an expectation of advanced custom functions. Seeing the dilemma in that should be quite obvious.

One reason the learning curve is so horrid is because there's not much reading on PascalScript. There's not much on Pascal either (there is some, but you can't get multiple books and online tuts and as many communities as there are for C/C++/Java/Python/etc.). This is another problem, as nobody has any real reason to stick around. I can say quite confidently that SRL has always consisted of some of the best, most intuitive and intelligent programmers there are in the RS cheating society. I take pride in that because I've seen many of them grow and I have no doubt that they will have fine careers in life because of this community. Quite a few already have. I, even, have worked as a partner of Microsoft, and I did that before I was 17 (I'm 17 now), and that is entirely because of SRL. I bring this up as the bright contributors in the past move on to bigger and better things. They've no reason to try to maintain knowledge of Pascal, due to the lack of use in the real world.

As well, since we use PascalScript, there's no way for people to learn besides by using the tutorials on the forums. They're fine tutorials, but they're not as useful as other languages'. Not to criticize the tutorial writers, but to understand a language it takes much more than a few posts. It takes whole books and series and personal help and Googling and testing and questioning. So that's another aspect that needs to be changed, especially with the size and complexity of what SRL/Simba are today.

(tl;dr,)

So, how do we fix these problems? Well, simple. We change languages, cut out most of Simba/SRL, and start enforcing Taco Bell programming. This will deal with most of the problems (size, learning curve, reason to stick to Simba/SRL), will increase speed, and will allow much more advanced programmers to flourish in a more widely used and (in some cases) more advanced language.

Also, John (Dgby) is sweet. :3

Dying? I dont think so.

SRL only needs minor tweaks every now and then. True, Ice is doing a tremendeous job atm(!!!). SIMBA has just begun to sink in the community, stats is going great.

We have always been and probably always will be a small community. Our ways are different. Our goals are personal, our endevavours for the community....not for the money.

And........Taco Bell? What the Hell? (<- curse for a rhyme)


It is threads like these that generally sprout feelings of doubt. Please remove the doom-mesg from your sig yewws (up to you though)

In comparison to what it was a few years ago, it's doing much less than it should/could, in my opinion. I don't think it will die anytime soon, but I do think there is a pretty obvious problem with having only four main developers for our community.

I don't want this community to be about money, and I despise that others are. But I also know that there is a lot more learning to be done (that will be useful) if we moved to a different language.

Taco Bell programming is explained in the link.

Quote:

---

Taco Bell Programming is about developers knowing enough about Ops (and Unix in general) so that they don't overthink things, and arrive at simple, scalable solutions.

---

(Of course I mean it to be applied to SRL/Simba, not to the communities understanding and use of Unix. ;))

You can't just fix something with a concept ;) Changing languages takes time, too. Do you expect more people will come out of nothing, because we changed languages? If we have lots of good working scripts, more people will stay. If more people stay, you'll have more people wanting to make their own scripts.

Leechers don't script, because they're leechers. The learning curve isn't all that big, it's the step that it takes from leecher to scripter. Remember that our visitors generally aren't people who know how to program.

Quote:

---

Originally Posted by nielsie95

You can't just fix something with a concept ;) Changing languages takes time, too. Do you expect more people will come out of nothing, because we changed languages? If we have lots of good working scripts, more people will stay. If more people stay, you'll have more people wanting to make their own scripts.

Leechers don't script, because they're leechers. The learning curve isn't all that big, it's the step that it takes from leecher to scripter. Remember that our visitors generally aren't people who know how to program.

---

I've been working on a bot in C++ (may change to C, dunno yet). The only reason I bring this up is because I adore this community. I don't want to make yet another color bot and just work on that, but I'm drifting from Pascal and the whole libmml/*mml thing.

I am trying to make some POC examples to show, but life gets in the way a lot (I definitely understand that committing time to this forum/SRL/Simba is difficult).

That doesn't really answer my question? Do you expect more people will come out of nothing, because we changed languages? The way I see it, the language doesn't matter much. It's just the material that's already here. And you can create good scripts in pretty much any decent language. For the leechers point of view, not much changes. For the scripters already here something changes, because they have to learn a new language.

Oh right. No, I don't think people will come out of nowhere. I also know that there are people here who use C/C++, and have wanted to be able to script in C/C++ who don't now because we use Pascal. Even more so, I know that more of the Masterkill's, pwnaz0rs, etc. will have a higher chance of staying, since they don't have to stay in an unused language, as I said.

Quote:

---

Originally Posted by WT-Fakawi

Dying? I dont think so.

We have always been and probably always will be a small community. Our ways are different. Our goals are personal, our endevavours for the community....not for the money.

---

There's a quote if I ever saw one...

I'm all for a small community. The more people we have flooding in the more of those "Press-to-play" people who rely on other people to do all the work for them. This isn't a "Here's our bot and scripts, take them and use them" forum, those who who have the ambition to learn will stick around, those who don't won't, and I for one say 'GOOD'.

Everyone is welcome to join the community, don't get me wrong, but this just goes to show you how many out there are so reliant on everything being pre-set and ready to use. We've been here longer than anyone, yet we don't have the playerbase of, let's say, powerbot?

Quote:

---

Originally Posted by i luffs yeww

Oh right. No, I don't think people will come out of nowhere. I also know that there are people here who use C/C++, and have wanted to be able to script in C/C++ who don't now because we use Pascal. Even more so, I know that more of the Masterkill's, pwnaz0rs, etc. will have a higher chance of staying, since they don't have to stay in an unused language, as I said.

---

A higher chance of staying, but will they still contribute? Most of the time people leave when they've outgrown RS. This still remains a RS community, so when they're here for the language, there comes a time when they want (to learn) more. This is not and probably wont be a general programming community. Mainly because we're affiliated with RS.

Quote:

---

Originally Posted by Flight

cropped to save your middle finger (scrolling finger).

---

I don't enforce the whole rsbot/nexus/rid/etc. sort of methods. I do, however, think that rid's method of having a few scripts done fantastically is a good way to do things. It's like a fine restaurant. Fine restaurants have a small menu that they will rarely have substitutions. That's because they have those things that they do extremely well, and that's what they offer. Nothing else.

I don't think we need to go to the extent that RID is at (they have only five bots I think?), but I do think having a smaller amount of scripts that work very well is much better than many scripts that all work decently-well. I think MSI tackles this quite well, and I'd like to see that be the main scripting agent.

This brings me to another aspect; things have been kept here for ages for archiving purposes (unless there's some other reason I'm missing). This is entirely fine, and I love seeing how things progress and the history of things, but having scripts from years ago in the same sections that people are sent to look for scripts and show up in searches all the time are a bit silly. It would be easy to automatically archive some of those things in a separate forum, and this can be easily done in vB, I believe. Small change, but can be very useful imo.

EDIT:

@niels, pwnaz0r, iirc, contributed much more in help than scripting, at least in his later days. Contribution of any sort from people like that are very useful in my eyes.

I think that the impression you have of dying down is a lack of development.

This to it's core is a botting community, as Fawki pointed out, the stats are showing increased activity.

Yes, few developers are active, but that's because we've finally reached a state that can be seen as stable.

Simba is running well, MSI is running well and SRL is running well.

So development went down... even developers need breaks.

In the meantime, we've made a breakthrough in color coding, with the many times done before world color walker, Marpis' being stable and strong from what I've heard.

Actually, you can walk color the same way you walk reflection now... so yeh, color made a breakthrough.

I think you're worried that not much development is being made... but honestly there's already been more than enough development. What I believe is needed now is botting, so we have a reason to develop and something to develop for...


e.g. How come has no one done a dungeoneering script?

Why are most scripts still Chop & Bank, rather than aiming for something a bit more like ratz?

Our includes are fine, and quite likely the most stable out there, what we now need are the scripts that only the insanely creative minds at SRL think of.

~RM

Quote:

---

Originally Posted by i luffs yeww

I don't enforce the whole rsbot/nexus/rid/etc. sort of methods. I do, however, think that rid's method of having a few scripts done fantastically is a good way to do things. It's like a fine restaurant. Fine restaurants have a small menu that they will rarely have substitutions. That's because they have those things that they do extremely well, and that's what they offer. Nothing else.

EDIT:
@niels, pwnaz0r, iirc, contributed much more in help than scripting, at least in his later days. Contribution of any sort from people like that are very useful in my eyes.

---

You're right. That would be a good way to stimulate the community. In my eyes, that doesn't have to involve a new language (although multi platform support would be nice).

And yes, helpers are great and definitely good for the community. But I think people like that are looking for a challenge. And at some point, this community stops offering that for them. Maybe they want to start helping people with more serious problems (not just "how do I click a tree"), or maybe they'll leave any way (as this is still a RS community). I think you'll keep that with any language (may it be a bit later on).

I think there's too much development. ;) There at over 400 functions that Simba exports to PS atm, and that's not anywhere near as many functions as there are in SRL.

I'm confident that most methods in SRL haven't been used more than ten times in a script.

If that isn't an obvious sign that SRL is a bit out of control, then I don't know what is. (The include, not the forum.)

I seem to have phrased a few things wrong, which is entirely on me and they've been interpreted correctly, but not how I meant for them to be interpreted. I think the focus should turn to scripts and have a few very useful, very basic functions in Simba, and combinations of those in SRL. Nothing more. With those, no changes to SRL/Simba would ever be necessary to work after updates or anything (well obviously eventually it may, but not as much as it is now). All that would need to be changed was scripts.

The library and program shouldn't change. SMART has shown that quite well. I like how SMART has been developed. SMART does what it does and we are given the chance to use it to how we need. SMART doesn't need to be updated every time hooks are updated, every time pixels or colors change, or anything like that. It's a good example of what I'd like to see Simba/SRL as.

EDIT:

@niels, The language change is one I obviously don't see happening, as it would be quite the change. But I do know that I will work on it still. SCAR was still used after Simba was made for quite awhile. I have no problems with people using Simba, and it's a pretty swell program. I just think it could be done better. I made a thread (with two replies :p) about backwards compatibility, and I think a huge problem that the development of Simba had was backwards compatibility. I think it limited the advancements and usefulness by quite a lot.

The language change isn't as important as some of the other points (namely shortening SRL and Simba's functions to the essentials and changing the way those libraries are treated (they should be treated as a useful asset that you have to utilize the best you can in your script, as opposed to how they're treated now, which is basically just made to be a script that you pull select methods from and make into a different script)). I just think going to C/C++ would be a good idea for the previously mentioned reasons (it's used in the industry, so learning it is a very good idea, etc. etc.).

I wouldn't mind seeing a language switch/addition... As i am starting to look into other communities because i would like to learn a language i can use in a job later on in life. I think writing bots for runescape is a great motivator to learn a new language.

I personally feel the community is at a great point atm, MSI is supper, simba is running brilliantly and like people have said we have a color alternative to reflections walking.

developers have lives as well they cant be here developing 24/7, they need to earn a living.

i am only here because i like scripting for runescape, i dont play runescape at all and simply make script in my spare time.

i dont think changing a language will help, all it will mean is people have to make new tutorial and learn a new language, even f its similar to pascal they still need to learn it.

Quote:

---

Originally Posted by footballjds

I wouldn't mind seeing a language switch/addition... As i am starting to look into other communities because i would like to learn a language i can use in a job later on in life. I think writing bots for runescape is a great motivator to learn a new language.

---

THANK YOU. :) Rep++.

This is exactly what I mean. I'm moving away from Pascal/PascalScript (and have been for awhile) because I realized that I really do enjoy programming and would like to pursue a career in software development, and Pascal is a poor choice for that desire. Python is a much better option than Pascal, in the sense that it's used more often, but it's a bad choice for a RuneScape bot, as it's extremely slower than language like Pascal, C, or C++ (Pascal is quite fast, and that is one reason to not change languages, which may be more productive than changing languages and having that down time (but the down time could easily be non-existent, as Simba/SRL would still exist how they are until a C/C++ counterpart were finished)).

EDIT:

@Bob, I understand your point, but I'd also say you're slightly hypocritical in your argument.

"developers have lives as well they cant be here developing 24/7, they need to earn a living."

I agree. Just as we all do as we grow up. The change to C/C++ I'm proposing would be brilliant for the devs involved. Not only would they have a very good way to learn and continue their knowledge in a language (to be good at a language, you really do need to have a project to work on, and the project we have here has kept people knowledgeable in Pascal for half a decade, and I'd say this is the only Pascal outlet most of those people have, except for side projects they make because of this community/project). But they could have their hobby and their line of work both be in C/C++, as those are very much used languages today.

Not that all devs here do software engineering, but a good handful of people here that we all know and love do/will make a pretty penny in software, I'd say. This would just make them better at being able to stay here as well, even if contributions slim by some with daily work.

Quote:

---

Originally Posted by i luffs yeww

@niels, I made a thread (with two replies :p) about backwards compatibility, and I think a huge problem that the development of Simba had was backwards compatibility. I think it limited the advancements and usefulness by quite a lot.

The language change isn't as important as some of the other points (namely shortening SRL and Simba's functions to the essentials and changing the way those libraries are treated (they should be treated as a useful asset that you have to utilize the best you can in your script, as opposed to how they're treated now, which is basically just made to be a script that you pull select methods from and make into a different script))

---

A agree about the backwards compatibility thing. It's also something I pointed out during the early active development of Simba. Now that Simba is settling, those changes can slowly be made.

About the library change; I'm not exactly sure what you mean? You want to bring SRL back to the essentials? Why? To ease the work for the developers? I think a lot of beginning scripters rather have some more high level functions. The more advanced scripters usually do a lot themselves, already.

SRL would be a bit more than just the basic essentials. But, for example, there are more TPA functions than anything else, and most aren't used. I don't think those are ALL really needed. The ones who need some that we may take out could very easily make them when they need them.

The problem I have with saying that a bigger library enforces more new scripters is that they get confused. A lot of the time we point new users to a few tutorials and advise them to look through the include to get an understanding of how things work. But with thousands of functions, most of which aren't ever used (some of which shouldn't be used), it can be very confusing for a new scripter. With how I imagine it, there would be the basics of the basics in Simba (I see no reason to have over 400 functions in Simba, other than speed, and a lot of them would have a speed difference so minuscule that it wouldn't matter), and SRL would have mixtures of those basics (with a few new methods possibly). The post to Ted's blog shows a great example. I'd suggest reading that, as it's quite short and explains it very well.

With that, optimization and advanced algorithms would be done by the scripter. It seemed very counterintuitive to do that to me before (I agreed with Python's whole "there should be one correct way of doing X," as opposed to how C and C++ can vary in speed based on how it's coded), but now I like it very much. It makes the learning curve about the user and not the library. Think about it and I hope you'll see my view. ;)

EDIT:

Quote:

---

Originally Posted by beats-

I've got walking down.

Now i've walked into lumbridge castle and im sitting next to stairs.
I just can't seem to figure it out.
Findobj?
tpas?
dtms?
=\
so confused.

Push me in the right direction please.

As most tuts are in scar and its hard to find proper info.

---

Example of a post by a new comer that shows how the library sets the learning curve and not the user, which is a very excellent aspect that we could have.

I agree up to a certain point. Maybe some more high level functions could be moved to the the misc folder and keep the essentials in the core folder. Another thing we're experimenting with (for SRL, that is) is to adjust the files in the include to be included separately, so that you can choose for yourself which files you want to use.

A lot of those high level functions usually end up in the include, because most of the time things like randoms need complicated functions. Plus, a lot of the time it's better to create wrappers around the more complicated functions (isUpText), which does create more functions, but in the end should be easier to use. So it's hard to find the right balance.

Quote:

---

Originally Posted by nielsie95

I agree up to a certain point. Maybe some more high level functions could be moved to the the misc folder and keep the essentials in the core folder. Another thing we're experimenting with (for SRL, that is) is to adjust the files in the include to be included separately, so that you can choose for yourself which files you want to use.

A lot of those high level functions usually end up in the include, because most of the time things like randoms need complicated functions. Plus, a lot of the time it's better to create wrappers around the more complicated functions (isUpText), which does create more functions, but in the end should be easier to use. So it's hard to find the right balance.

---

;) It's definitely not a simple equation of methods and language and whatever else to make a perfect bot/library/community/etc.. I feel we both agree that things are good, not perfect, but some things could be done better, no? Like I said, it'd be a bit extreme to implement everything I think would help (and I'm not as intelligent as you, Wizzup?, Raymond, etc., which is why I posted this), but I do think that at a very minimum we need to take a step back and look at it all and see what we can do about it. It's not extremely urgent, as this community will most likely last until RS dies, but things could change for the better before then, I believe.

At a very minimum a change to the core/ folder should happen. I don't know if wrappers would help much. I'd like for a new comer to look through SRL and learn from it. If they want to learn more advanced stuff, Simba is open and we can point them in that direction. :) I think it's a good idea.

c++ <3

Quote:

---

Originally Posted by Emaziz

c++ <3

---

that or Java.
both useful languages :D

Quote:

---

Originally Posted by Emaziz

c++ <3

---

;) That's what my bot and library are in atm. I'm struggling along, but I'm trying to not make any silly mistakes. Slow and steady, eh?

If you wanna help you can though. :D PM if you're interested; not really the place to talk about it.

EDIT:

@football, I'm not a fan of Java. I don't like how it runs. And there are more than enough Java bots out there that you're welcome to script for. :p

Quote:

---

Originally Posted by footballjds

that or Java.
both useful languages :D

---

Probably, but I have better use of C++ as I wanna be a game developer :spot:

Would love to use C++ to make bots as it would help me improve my scripting abilities better than pascal. :)

Quote:

---

Originally Posted by i luffs yeww

THANK YOU. :) Rep++.


@Bob, I understand your point, but I'd also say you're slightly hypocritical in your argument.

---

i dont see how i was hypocritical, care to explain?

Quote:

---

Originally Posted by Bobzilla69

i dont see how i was hypocritical, care to explain?

---

:x I did. But just in case I explained it poorly, you say that developers have lives as well and can't develop for us 24/7. I agree, but keeping Pascal makes it harder for them to have a job in the software industry AND still know Pascal and develop here. I suppose it's more irony than hypocrisy.

yes what i mean by having lives is that they have job, not necessarily coding, i am a network manager i do no coding in my job, but i do coding in my spare time.

fair enough you think that coding a bot is going to relate into coding for a job but you wouldn't, you are using it as a stepping stone to experience what coding is like then move onto different languages once you get into university or collage where they teach you more about them.

but thats just what i think

Quote:

---

Originally Posted by Bobzilla69

yes what i mean by having lives is that they have job, not necessarily coding, i am a network manager i do no coding in my job, but i do coding in my spare time.

fair enough you think that coding a bot is going to relate into coding for a job but you wouldn't, you are using it as a stepping stone to experience what coding is like then move onto different languages once you get into university or collage where they teach you more about them.

but thats just what i think

---

;) I know that the language used here won't always be what people do as a job. I used C# and VB.NET more than anything when I was working as a partner of Microsoft. But one thing is that there is definitely a higher chance if we used C/C++ that the hobby here will be used in a job/career for the programmer.

Also, I'd say that learning C/C++ can be more beneficial than learning Pascal, somewhat. Many more languages have been influenced by C than Pascal, so learning Python, Java, etc. would be easier to learn if you started with C/C++ rather than Pascal.

Also important to note that most people here don't know Pascal. Most of us know PascalScript scripting, but not Pascal, and there's a pretty noticeable difference.

A lot of languages are alike. It's the concepts that you should learn. When you know loops/ifs/methods in Pascal Script, you know them in other languages too. The syntax is just different. In that point of view, an important thing Pascal Script lacks is OOP. But when you know your basics, it's easy to adopt a new language. For example, I've never written anything in C, but when I look at this, I see a lot of familiar things.

Also, I'd say the difference isn't that big between Pascal and Pascal script?

not sure if support

Quote:

---

Originally Posted by nielsie95

A lot of languages are alike. It's the concepts that you should learn. When you know loops/ifs/methods in Pascal Script, you know them in other languages too. The syntax is just different. In that point of view, an important thing Pascal Script lacks is OOP. But when you know your basics, it's easy to adopt a new language. For example, I've never written anything in C, but when I look at this, I see a lot of familiar things.

Also, I'd say the difference isn't that big between Pascal and Pascal script?

---

There are a few differences. Pointers, for one (syntax). It's nothing big, but some things still confuse me. Error exception is different as well. Nothing HUGE, and I don't think it's that big of a difference, but I stand by me saying that someone learning C/C++ is better than PascalScript. You can learn the syntax of a language in a few days-weeks, especially if you understand another language, but then there'd be the whole phenomena of people who know a bit of the syntax and not much else who don't understand the language or the concept and it leads to problems for the rest of us ("the reflection phenomena" ;)). Except for here you don't get fired for stuff like that.

I'll just say this:

Holy shit no, don't take good useful procedures out of SRL just because people don't know how to use them and do not know how useful they are. I have no wish whatsoever of going back to PRE-SRL times where everyone has their own include cus no one was smart enough to realize tat 10 people writting the same function differently is inefficient. If anything dig up the threads on how SRL 4 was structured (cus its lost its structure) and restart from there.

Most functions are actually used and most functions are actually useful. If you haven't written enough scripts to actually have a use for those functions, my friend, that is not the dev's fault that is your own.

Furthermore, some functions could be condensed to become just one, which is why there are many wrappers for user friendliness. This has been said and discussed a million times. What is missing is organization, not cutting down on code.

Structure it into many levels if you wish to, but don't go throwing away years of work. That'd just be bluntly stupid.

the TPA functions that aren't used? Maybe they are, except they're used in private scripts?

~RM

A more streamlined approach would be preferable.
Currently it is very difficult to judge the community's progression as a whole due to development being spread out over so many projects.

Quote:

---

Originally Posted by Sir R. M8gic1an

I'll just say this:

Holy shit no, don't take good useful procedures out of SRL just because people don't know how to use them and do not know how useful they are. I have no wish whatsoever of going back to PRE-SRL times where everyone has their own include cus no one was smart enough to realize tat 10 people writting the same function differently is inefficient. If anything dig up the threads on how SRL 4 was structured (cus its lost its structure) and restart from there.

Most functions are actually used and most functions are actually useful. If you haven't written enough scripts to actually have a use for those functions, my friend, that is not the dev's fault that is your own.

Furthermore, some functions could be condensed to become just one, which is why there are many wrappers for user friendliness. This has been said and discussed a million times. What is missing is organization, not cutting down on code.

Structure it into many levels if you wish to, but don't go throwing away years of work. That'd just be bluntly stupid.

the TPA functions that aren't used? Maybe they are, except they're used in private scripts?

~RM

---

I can list tons of functions right now that are loaded every time you include SRL that most people don't use and haven't ever been used.

When is the last time someone used "TradeScreen?" If you don't see that there are a lot of unused functions in SRL/Simba, I'm confus.

I don't care if they get put somewhere else (I wouldn't want them to just be gone forever, as I think archiving is useful), and I think it'd be good. If private scripts use TradeScreen, let those few private scripts load it from misc/whatever instead of having SRL continue to be flooded with things that generally aren't used.

I'm not saying we should just take out useful functions because people think they're too difficult, either. Sorry if I gave off that sort of idea. I just think the way they're used should be changed. Like I said, the learning curve can very easily be adapted to suit the scripter's speed, rather than expecting people to live up to the developers' expectations of what people should know. It would also allow more variations and optimizations that could be quite fantastic for development of scripts/include/Simba.

I'm pushing extremes. I understand that. I didn't post this to expect anyone to just say "alright yeah let's completely change everything we've been doing for over half a decade and do what this 17 year old kid says." I'm just saying going toward some of the things I'm proposing would be beneficial. I'm not expecting the language change to happen. I just think it could help the community, scripts, and activity/longevity of intelligent people.

:)

EDIT:

@tofu, I agree to an extent. I don't know if I posted this or if I brought it up in #srl or msn or what, but I think having a main set of scripts that work extremely well and do what they're expected to do (MSI) is a fantastic approach. It's what RID does, and their bots have fantastic feedback. But one thing I dislike about them is that their closed, so they have no way to tell if any new valid scripters come along and could help with their bots/development. We wouldn't have this, as we could still have normal scripters making their own scripts and everything, and we can pick those up for MSI.

And before someone says something along the lines of "well if we just have MSI why would anyone write scripts, and why would anyone use them?" Well, we already have MSI and people already use other scripts. I'd be willing to try out scripts of non-MSI users if this happened, although others would as well, I'm sure.

And people would still try to script, because people are curious beings and want to learn and extend their knowledge. :) RSBot has a set of scripts that they enforce more than others, yet people still use free alternatives made by the community. Same idea, but more organized (and better scripts :D).

I know a script that TradeScreen is used in or at least was ...

I think a better solution would be to use the current language, but highly encourage other languages ...

I don't want to learn another language right now personally... It would be grate but for now im still perfecting what I have...

Quote:

---

Originally Posted by Yago

I know a script that TradeScreen is used in or at least was ...

I think a better solution would be to use the current language, but highly encourage other languages ...

I don't want to learn another language right now personally... It would be grate but for now im still perfecting what I have...

---

:p Of course it was used at sometime. Someone asked for it. But really, it's not about TradeScreen. It's just one that I know isn't used very much. There are plenty more. Most functions are things like FindColor, FindDTM, IsUpText, Mouse, etc.. If you scroll through some of the included files (amount.scar, for example), you'll see tons of functions that you aren't used.

The problem I have with libMML and having more interpreters and language support etc. is that it will just be more stuff in Simba/SRL that isn't used. If MML, libMML, and all language MMLs were just the bare essentials, I'd be fine with it, if the language autoing libraries were also smaller than now (as in pySRL, rbSRL, jSRL, etc.).

Quote:

---

Originally Posted by i luffs yeww

:p Of course it was used at sometime. Someone asked for it. But really, it's not about TradeScreen. It's just one that I know isn't used very much. There are plenty more. Most functions are things like FindColor, FindDTM, IsUpText, Mouse, etc.. If you scroll through some of the included files (amount.scar, for example), you'll see tons of functions that you aren't used.

The problem I have with libMML and having more interpreters and language support etc. is that it will just be more stuff in Simba/SRL that isn't used. If MML, libMML, and all language MMLs were just the bare essentials, I'd be fine with it, if the language autoing libraries were also smaller than now (as in pySRL, rbSRL, jSRL, etc.).

---

If size/space is your problem then make it optional to download them as stated above.

Ian, changing the structure as to how things are loaded is one thing. Removing is another.

Any script that incorporates trade uses TradeScreen.
This was even part of an AutoResponder (MKs if I'm not mistaken) that would deal with trades.
There also used to be an antiban that dealt with trades.
etc.

Go ahead and make a plan of what you think should be where and why, I just wanted to state that functions people think aren't useful actually are.

~RM

Quote:

---

Originally Posted by nielsie95

A higher chance of staying, but will they still contribute? Most of the time people leave when they've outgrown RS. This still remains a RS community, so when they're here for the language, there comes a time when they want (to learn) more. This is not and probably wont be a general programming community. Mainly because we're affiliated with RS.

---

I actually don't contribute code anymore because I strongly dislike pascalscript. I run scripts because I feel like it, and I'm curious how high I can get my army's levels. I would contribute code actively if we used a different language. (Lape should be a huge improvement, though)

It's not a huge problem about size/speed, and more so about learning for me. With computing and networking advancing, it doesn't take a lot of time to download, install, and run Simba as it is now. Even with libmml, pymml, and pysrl, I don't think it will be too much. But I do think that the learning aspect would quickly diminish, and it would only separate our community, like the whole SCAR/Simba thing used to.

EDIT:

@RM, I know that there are a few instances (and I remember them) of TradeScreen. But TradeScreen isn't the only one. There are tons. Like I said, there are over 420 functions exported to PS. I know for a fact that you've never used some of those functions. Not just because you aren't as active (scripting-wise) as you used to be, but because a lot of them are simply not used in ANY botting situations. People bot certain things for certain reasons. There aren't many bots that handle trades or anything. Those are nice things for a silly little concept, but really I see no reason at all to include things like that in the main SRL core/ include.

@Smartz, thanks! :) Support is nice. And knowing that I'm not just making all of this up is good for me.