SRL Archive - Research & Development Lounge

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.

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.

From: 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.

From: 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?

From: 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.

From: 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

From: 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.

From: 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.

From: 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:

From: 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.

From: 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

From: Emaziz
c++ <3

that or Java.
both useful languages :D

From: 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

From: 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. :)

From: 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?

From: 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

From: 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

From: 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.

From: 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…

From: 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.).

From: 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

From: 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.

From: i luffs yeww
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.

In your point of view, where you really want to create programs, it is indeed better to just start of with a real language. But for RS scripts, Pascal Script will do. A decent Pascal implementation also has support for pointers and better support for exceptions. In Simba, I know RUTIS and cpascal support pointers.

@RM: Throwing away decent code is never good, but I don't think we're talking about that here? Just like you said, a restructure would be nice.

EDIT: I write up a small post and we're already 3 posts further. Talking about a dieing community :p

From: nielsie95
In your point of view, where you really want to create programs, it is indeed better to just start of with a real language. But for RS scripts, Pascal Script will do. A decent Pascal implementation also has support for pointers and better support for exceptions. In Simba, I know RUTIS and cpascal support pointers.

@RM: Throwing away decent code is never good, but I don't think we're talking about that here? Just like you said, a restructure would be nice.

I don't think Pascal/PS is the best language for this community, but I definitely don't think it's the worst. I'm fine with keeping it, as it is fast, it is known, and it does what we need. I just think that development has a higher chance of being more ground-breaking/whatever if we used C/C++ and changed our library ideology, since optimization relies in the scripter, not in the library.

I feel we're a bit trapped with our library and Simba. They are made to make scripts. I think scripts should utilize the library to the best they can, as that leads to advancements like what Linux has seen over the years. We're somewhat, for the most part, just "allowed" to use what is in SRL. There's not a lot to be optimized. The optimization happens in the include nowadays, not in the scripts. I see that as a bit backward and only leads to problems (memory leaks, bugs, fatal flaws, etc.).

EDIT:

@niels's edit, ;D I know what you mean lol. I don't think the community will die any time soon, and will probably last after RS is gone.

From: Smartzkid
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)

This. Give me java or even python and I will program up a storm :P

From: Iamadam
This. Give me java or even python and I will program up a storm :P

Both Python and Java are much slower than Pascal, and Pascal is slower than C. Not much, but still. I'm opposed to Java because of how it runs. I'm opposed to Python due to it's speed.

From: i luffs yeww
Both Python and Java are much slower than Pascal, and Pascal is slower than C. Not much, but still. I'm opposed to Java because of how it runs. I'm opposed to Python due to it's speed.

And what do you intend to do with this increased speed?

Reduce a few ms in color finding or solve mordaut faster?

agreed about /core

~RM

Well, there are some things I've been (slowly and forgetfully) working on that will take a decent amount of times (in terms of computing). They could be done in Pascal, possibly, but I feel C is a more powerful language than Pascal (in some/most cases, depending on how one uses it).

The difference in speed I'm talking about with Python is an extreme difference. Python is ~100x slower than C. Pascal is about the same speed as C, but a bit slower (up to about 5x is the slowest I found, and we wouldn't notice those differences with what we have now). Java's fine for non-color speeds, but with color finding, Python would be noticeably slower. Wizzup? has said that we would have to do finder.pas in C rather than Python because Python would be too slow.

And the speed (now) doesn't make a HUGE difference (between C/C++/Pascal), but color methods aren't as advanced as they could be. Later in the include's life it may be very useful to have things done five times as fast. ;) No reason not to have that extra speed in my opinion. (Albeit there's no real reason to switch to C/C++ instead of Pascal right this minute, in terms of the include's speed, but I don't see why we shouldn't be proactive about it.)

speaking of multiple language use, I'm not sure why reflection is maintained when so many developers dislike it . It would be more effective to commit to either reflection or colour than to waver inbetween.

I've always questioned why we do things in Pascal considering it comes of no use in today's software industry. Other than being a teaching language, Pascal is extremely old and has been replaced by Python in terms of readability. I would love to see a C based language for our community because I also plan on aiming towards a software-oriented job in the future, and Pascal isn't giving me the feeling of creativity that C++ or Java gives when writing programs. Of course with a C based language, the newer people find it harder to learn how to do simple things and resort to leeching and posting repetitive question topics. As a previous member of the private server community, I have witnessed first hand the idiocy of these people and it is quite embarrassing to be grouped with them.

Anyways, I agree with your beliefs overall i luffs yeww, but it will be harder on the less-educated who want to learn how to script.

So what do you propose, Echo? Python? As I've said, it's too slow for our purposes.

From: i luffs yeww
So what do you propose, Echo? Python? As I've said, it's too slow for our purposes.

I would have to say C/C++, but Java and C# are also viable options.

I dislike the Java choice because there are plenty of Java bots already. And I don't like how Java runs. I'm not a fan of C# either. And that wouldn't be cross-platform, I don't believe.

From: i luffs yeww
I dislike the Java choice because there are plenty of Java bots already. And I don't like how Java runs. I'm not a fan of C# either. And that wouldn't be cross-platform, I don't believe.

Then python?

From: TomTuff
Then python?

Um.

http://villavu.com/forum/showpost.php?p=794124&postcount=44
http://villavu.com/forum/showpost.php?p=794124&postcount=46
http://villavu.com/forum/showpost.php?p=794145&postcount=49

u srs, lol?

Lol he just said "tldr" about it. Ohhhh well.

So then it sounds like C/C++.

I don't think there will be a language change, Echo. I will continue to develop my bot and library, but it will most likely just stay on my hdd.

But, I think this is a good time to note the poll votes (I must say this progressed much faster than I expected).

21 at least somewhat support this (I assume that means they support at least one part of one aspect, and will count this toward a "yes"), while nine do not support this at all. I have not voted, as my vote is very obvious. ;)

Unless there's much else to discuss, I think we could move on to the actual work. I, however don't know what everyone wants, so I don't know if I should do the work without some discussing on what actions to take, as opposed to whether or not to take action.

If you want to code in c++, code in a plugin. If you want more speed, code in a plugin.

I plan on making some stuff as plugins, but I dunno if I'll do that. :p

Regardless, Simba/SRL are too beeg.

You don't like how java runs?
You must just be used to a bunch of poorly programmed things (as the rs cheating community provides so many of). It's an incredibly stable, reasonably fast - and very powerful language.
But lets not turn this into a language war. I know Java + SRL will never happen.

From: lordsaturn
If you want to code in c++, code in a plugin. If you want more speed, code in a plugin.

But will it blend?

From: Iamadam
You don't like how java runs?
You must just be used to a bunch of poorly programmed things (as the rs cheating community provides so many of). It's an incredibly stable, reasonably fast - and very powerful language.
But lets not turn this into a language war. I know Java + SRL will never happen.

I don't like how many resources I must give up for Java to continue to run. It's ridiculous. I understand the idea of the JVM and all, but I think it's done quite poorly.

Actually, C# is cross platform with the Mono project.

From: i luffs yeww
Both Python and Java are much slower than Pascal, and Pascal is slower than C. Not much, but still. I'm opposed to Java because of how it runs. I'm opposed to Python due to it's speed.

Jitted java shouldn't be terribly slower than C.

Java isn't as slow as Python, that's for sure. Just not as fast as C/C++. ;)

And unless you have a super good reason to use C#, I don't see why to use it. I wasn't a fan of the syntax when I used it, and there aren't any benefits from it in comparison to C/C++, and it's not as fast as C/C++.

But then again I haven't done a ton in C#. All of it was for Winpho7.

From: Smartzkid
Actually, C# is cross platform with the Mono project.

Mono is pretty poor, I think I told you this before. It's best to write in a language where the upstream officially supports your OS.

From: i luffs yeww
21 at least somewhat support this (I assume that means they support at least one part of one aspect, and will count this toward a "yes"), while nine do not support this at all. I have not voted, as my vote is very obvious. ;)

So you believe that if you'd only have had 2 options: yes / no it would be 21 yes and 9 no's? I doubt it.

No, I'm just saying what I said.. :p When I did the numbers, there were 21 who at least somewhat supported at least one part of one aspect. People can see the poll results on their own, I just did the simple math for the lazy ones. ;)

23 at least somewhat support something about what has been posted, 11 don't support anything that's been posted, as of now.

From: i luffs yeww
No, I'm just saying what I said.. :p When I did the numbers, there were 21 who at least somewhat supported at least one part of one aspect. People can see the poll results on their own, I just did the simple math for the lazy ones. ;)

23 at least somewhat support something about what has been posted, 11 don't support anything that's been posted, as of now.

Yeah. But you said they'll count as a yes, which is what I was referring to..

Make a poll. Do you want C++? :D

If that was directed at me, yes. :p

But, the problem with the poll is I dunno how I'd do it. There are aspects from each thing that people may agree/disagree with.

I think it's up to people with more power than me to approve things, but I will work on some of this stuff starting Friday.

I mean make a poll: "Do you want C++?" :P

Oh. I don't think the language change will happen. ;)

I thought I saw somebody working on a Simba derivative that works with C scripting, forgot where I saw it though :p

Just wondering why you'd go through all the trouble to re-code Simba in C/C++ if you can just use libMML. (Read: work on libMML and use it)

From: Echo_
I thought I saw somebody working on a Simba derivative that works with C scripting, forgot where I saw it though :p

Ben wrote a library in C, and made a kind of C scripting interpreter in java, if that's what you're thinking of.

From: Wizzup?
Just wondering why you'd go through all the trouble to re-code Simba in C/C++ if you can just use libMML. (Read: work on libMML and use it)

As I've said (I guess it wasn't as clear here, I said it to Nava), I'm becoming less impressed by libmml. It's a cool project, but I don't know if the loss of speed is worth it for autoing. If, however, we took a different approach to how we do SRL/Simba/MML/libMML, I'd be fine with using Pascal, working on libMML, and having {language}MMLs made. But another problem with that is it'll separate some people from the main language, which could be sorta bad. Different languages getting different development with different groups of people would make all of them (including normal PascalScript) have less users, and could be bad.

I thought about this a bit since we talked the other night, Ian, and I have a few thoughts. I don't think changing the language is a good idea. Sure, support for other languages would be cool, and I'm sure there are some existing members (including me) that would benefit from it, but it's not necessarily going to bring in new people. Personally, I like having PS as our scripting base. The interpreter may not be the greatest at times, but the language itself I think is fantastic for the people that are drawn to SRL - teenagers looking to bot in Runescape.

I've read in more than one place that Pascal is the easiest programming language to learn simply because it's the one that most resembles the English language. Sure, there's no companies out there that actually use Pascal, but it's still very beneficial. I'll use myself as an example. I took an Introduction to Programming class in my last year of high school. It revolved around Java. Sure, there were a few things that were new (OOP, syntax), but I basically walked through that class. Why? Because I already new most basic programming concepts from PS (loops, statements, types, etc.).

My point is that the knowledge people gain from PS is far from useless (I know you never said it was, I'm just saying). I honestly think one of the main reasons people get in to scripting is because PS is so easy to understand. I mean seriously, you can almost read a well written script like a book:

function openBank(): boolean;
begin
  if (findColor()) then
  begin
    mouse();
    result := true;
  end;
end;

It's very very basic, but the programming concepts are there, and they help with learning any other language. Like I said, there are people that would love to see support for another language, but I don't think that's the right direction for SRL.

About the size of the Simba/SRL library. I don't see anything wrong with it being large. Actually, I think that makes it better. It gives the scripter a lot more to choose from. No one wants to write a procedure that's already been written and they can access very easily. I do agree, though, that a library of such size needs to be much better organized and laid out, and I'm sure there are functions/procedures that aren't necessary, but I don't think having a large library is bad. I think it would be much better if it worked something like Java where you import only certain files rather than the entire library.

I think that's it. :p

Random note: Another advantage of other languages: Multithreading.

One thing about Pascal that I do like is that it's very simple to understand and read, as a start, but a lot of people (there have been threads/posts) that say they understand C-style syntax more than our syntax. Different people like different syntax. So that issue isn't a huge one in my eyes; we can't make everyone happy.

The size of the library is obviously just programming ideology, and it's sorta like debating democrat vs republican. That isn't gonna go to my side, but some people have said that the include could be cropped at least a little.

EDIT:

@Smartz, why would we need that for rs? The only thing I can think of is random detection, but even then it's not entirely necessary.

From: i luffs yeww
One thing about Pascal that I do like is that it's very simple to understand and read, as a start, but a lot of people (there have been threads/posts) that say they understand C-style syntax more than our syntax. Different people like different syntax. So that issue isn't a huge one in my eyes; we can't make everyone happy.

Which is why I said support for other languages would be cool, but completely switching isn't necessary.

It would make it easier to implement antirandoms. If we got ambitious, we could even give the scripter the option of letting the library create the antirandoms thread. People wouldn't even have to bother with antirandoms.

EDIT: Also, advanced GUI's need multiple threads.

I, for one, would love multi-threading. I could keep track of my inventory items, mm levels and search for objects on the main screen, all at once!

I don't know if multithreading is possible by adding new languages, but I may just be too sober to realize I'm wrong. For example, if we did have threads, everything still has to go back through MML (Pascal), which doesn't have thread support (I don't think?), so it wouldn't be TRUE multi threading.

Nah. The code's in memory, just because the library is only loaded once doesn't mean it will block until some other function in the library is executed. Granted, problems will arise if the library uses global variables unsafely.

So we could still thread if we use libMML? ;o

Hell yeah bro

Oh, sweet maaaaaaan. I'm sure some people will enjoy that, if libMML ever gets worked on. :p

I'd work on it but it's too big for me to care to work on. :/

(Maybe I'll just smoke some weed and do it. ;) Should be more fun.)

Pascal does have TThread, btw…

Why have I always been under the impression that we can't thread, then, John? :x

PascalScript runs in a single thread

Oh alright. kthxxxxx.

From: Smartzkid
Nah. The code's in memory, just because the library is only loaded once doesn't mean it will block until some other function in the library is executed. Granted, problems will arise if the library uses global variables unsafely.

As far as I know libMML should be threadsafe. Granted, it's not finished but I'm pretty sure it is / will be. Simba is the living proof… (Did I say living?)

From: Wizzup?
Simba is the living proof… (Did I say living?)

Let's check my eight balls.

"Without a doubt"

Looks like it.

Even if a library isn't threadsafe, one can load it multiple times. It's not fun, it's not pretty, but it usually works.

Luffs: I'd rep this at you, but I can't rep you again for the forseeable future: "You have eight balls?"

Hahaha I have to magic eight balls. I was gonna ask them both but I decided to just ask one.

So is python definitely not going happen? It's fast enough for youtube and other google stuff.

I'm sure they cache their processed information, and surely they're not doing video processing.

From: Smartzkid
I'm sure they cache their processed information, and surely they're not doing video processing.

This. I don't think it'd be fast enough, but then again Wizzup? did some tests with pyMML before (I did as well with getting color) and I think it did fine.. Can't remember. I may redo some tests to see what happens.

From: i luffs yeww
I may redo some tests to see what happens.

Doubt it…

Also, "Too big for me to care to work on", wut

libMML will be ~10k lines iirc. It's over 420 functions..

Why would you not care? It will need a lot of work, and seeing as it is the solution to most (all) of the problems you presented in this thread, why would you not want to work on it?

420 functions? :p

It is not the solution to most things I mentioned. I've posted being opposed to it as well.

There were 421 when I last asked John, but I just say 420 because that's way better. :p

No, You asked how many functions are in Simba…..

I added a WriteLn to see how many functions are added to PS, There are prob less functions in MML.

Well everything in MMLCore needs to be in libmml, afaik. Regardless it's a lot.

Actually I think it's everything exported, because it's everything that's in Simba's function list when you open it and don't include anything, I think.

Nah MML has overloaded functions (I think) and some classes.

CBAS [C++ Based Autoing System AFAIK]

From: Smartzkid
CBAS [C++ Based Autoing System AFAIK]

;o That's cool. Looking through the libraries it seems like it's just like SRL's, which still isn't the main point of what I want to change. :/ Definitely will probably help though. :D

I admit, while cheating is still possible, for some reason popularity of it is waning. It's sad to see it go - it has a history almost as big as RuneScape itself.
I would be happy to see a move to .NET-based languages. Yeah, I know it isn't all too compatible (Mono isn't exactly the perfect solution, but it works a bit) but, hey, if it supports 4+ languages now that makes the learning curve about as steep as a horizontal line. The languages are fairly easy to learn, and spread over C#-VB-C++, there's a crapload of potential programmers already. It's not too tightly integrated with cheating, the IDEs are (in my opinion) balanced just right, and it has excellent support for team development, things like git and svn, and especially libraries. It would also allow people to develop singular programs using just the library itself, like one program solely dedicated to running one particular script. Yes, there is the issue with access to the source being a tad more complicated than things like SCAR and Simba, but someone could develop a flowchart-based .NET IDE or something? I dunno. I'd just welcome .NET with open arms, and get back into scripting.

From: Zyt3x
I, for one, would love multi-threading. I could keep track of my inventory items, mm levels and search for objects on the main screen, all at once!

I can do that in a loop, bitch.

oooops. Do those ms really make a difference? naaaaaaaah.

~RM

*deleted*

From: Bad Processor
I admit, while cheating is still possible, for some reason popularity of it is waning. It's sad to see it go - it has a history almost as big as RuneScape itself.
I would be happy to see a move to .NET-based languages. Yeah, I know it isn't all too compatible (Mono isn't exactly the perfect solution, but it works a bit) but, hey, if it supports 4+ languages now that makes the learning curve about as steep as a horizontal line. The languages are fairly easy to learn, and spread over C#-VB-C++, there's a crapload of potential programmers already. It's not too tightly integrated with cheating, the IDEs are (in my opinion) balanced just right, and it has excellent support for team development, things like git and svn, and especially libraries. It would also allow people to develop singular programs using just the library itself, like one program solely dedicated to running one particular script. Yes, there is the issue with access to the source being a tad more complicated than things like SCAR and Simba, but someone could develop a flowchart-based .NET IDE or something? I dunno. I'd just welcome .NET with open arms, and get back into scripting.

Your comment on VB gave me a horrid thought, Drag'n'Drop Simba! :eek:
I do agree with you on C# though, I have got into programming with it recently since GUI programming with C# is a lot easier than with Java. Would there be a way to add the .NET csc to Simba in order to support cross platform C# compilation?

http://www.mono-project.com/CSharp_Compiler

We could redistribute that. If we used microsoft's compiler, people would be required to download C# Express. I've had no trouble with the mono compiler or runtime on windows, but I primarily use microsoft's versions.

@Echo: Tried WPF yet? It's pretty amazing :)

From: Smartzkid
@Echo: Tried WPF yet? It's pretty amazing :)

No, I was using forms before. I just searched it and it looks outstanding :D Thanks for the tip

From: Smartzkid
http://www.mono-project.com/CSharp_Compiler

We could redistribute that. If we used microsoft's compiler, people would be required to download C# Express. I've had no trouble with the mono compiler or runtime on windows, but I primarily use microsoft's versions.

@Echo: Tried WPF yet? It's pretty amazing :)

That would be excellent! As long as, like, .NET and Mono are fully compatible, that could really work.

From: i luffs yeww
This. I don't think it'd be fast enough, but then again Wizzup? did some tests with pyMML before (I did as well with getting color) and I think it did fine.. Can't remember. I may redo some tests to see what happens.

It has a speed parity (approx) with Pascalscript. If pascalscript is fast enough, so is Python.

From: i luffs yeww
libMML will be ~10k lines iirc. It's over 420 functions..

Don't think it will be that long. I don't think all those functions will be exported either. I'd say about 50 functions.

From: Boreas
So is python definitely not going happen? It's fast enough for youtube and other google stuff.

I'm still very fond of Python, it's just not important enough to focus on, at the moment. I'm pretty sure it will still happen though.

From: Smartzkid
http://www.mono-project.com/CSharp_Compiler

We could redistribute that. If we used microsoft's compiler, people would be required to download C# Express. I've had no trouble with the mono compiler or runtime on windows, but I primarily use microsoft's versions.

@Echo: Tried WPF yet? It's pretty amazing :)

C Sharp is as bad (if not worse) than Java, so I don't see us going there any time soon. As stated before, Mono is not mature; and C# is too micro$oft and fiddled with weird patents.

50 functions? I thought all the TPA functions etc. had to be done?

Hey Guys,

Interesting view on the situation, but I don't agree, why ditch our pascalscript/delphi?
It's a perfect language for the piece coding we do, we are a community learning to script for some game and trying to leech the leechers to start scripting/coding, while gaining a lot of programming knowledge.
Pascalscript does not limit us for coding for rs. Maybe it's ugly, or not as good as C++.
Why buy a not affordable 35" inch screen if a 24" suits it purpose more than 100%?
Okay, we have some more speed, I agree, but it's not worth it.
Pascal script is perfectly simple to start learning programming languages and I like it because it's pretty organized in my eyes, I really enjoyed coding in SCAR/SIMBA. It never limited me.
This is not an I want to code for RS because with the coding for RS I can get a Job later, then I think you should just code your own (closed source) bot, or something. There are loads of other bots out there, which support other languages, the languages you prefer.

Conclusion, Look Simba, SRL and MSI need innovation by the years(Devs did a great job and succeeded), but pascalscript does it job perfectly, I don't see any flaws. No need to start doing C++, you can't deny that C++ is somewhat harder to code, but that isn't needed. =)

But on the other hand, I can really really understand that you just want to code something that you could use later, or more challenging(if you think this, you haven't done everything in simba yet xD), I'm not interested in RS anymore for a long time, that's why I left too. I stayed for a long time for the coding, coding is just awesome and this community is awesome =D.
Maybe I made some false arguments or I typed some bullshit, but I haven't been in the scene for a long time and I was just hopping by for a sec.

Anyways I'm gone,
I probably won't read your reaction, but I will try to not forget to check this thread once.

From: Hermen
cropped to save scroll wheels.

:) Well I have been thinking about this more and more, regardless of the amount of work people can see (none), and I may keep the languages and do some work on libmml and add python support, but I will also do some (read: a shit ton) editing (read: deleting) of MML/SRL. Those were the main things I cared about, as Pascal is a pretty good place to start, when you have a project like this on your plate to mess with, and I'm accepting that now.

Pascal is fast enough for what we need it to do, and PascalScript is easy to get started and go (I still think C++ is pretty easy to get into as well, but there are more things one has to be aware of, which makes it possibly not the best choice, unless you learn the language proper). I'll see how everything turns out and show some people to see what they think. :)

Thanks to all the views on this, and I'll get started right after getting an arizona. :D

Pascal does its job fine. Pascalscript does not.

Well then maybe I'll talk to Dgby/niels about lape? I hear that's cross-platform and doing well?

From: i luffs yeww
Well then maybe I'll talk to Dgby/niels about lape? I hear that's cross-platform and doing well?

I'm unsure what you want to do. But I suppose you could talk to them if you have questions.

Well you say PascalScript is the problem, and I hear lape is a better alternative? :p I dunno, I may be wrong.

hurr durr, double post + bump.

(tl;dr at bottom, as usual)

So, here I am, listening to a brilliant man named Bjarne Stroustrup talk about some sweet stuff (C++0x <3), and he mentions memory. It made me think about memory management in general, and reminded me of a pretty big reason that I seem to have completely didn't even bring up in this thread, and it's a very important one indeed.

Jagex has done a shitty job with RuneScape, in my opinion. Countless bugs, awful memory management (albeit I blame Java and the shitty JVM for this more than Jagex, but still, I can't imagine Java would be so used and THAT shitty all the time, but hey, I may just be too kind to Java ;)), and just an awful line of "improvements." But most importantly, the memory that RS takes is outstanding. I remember when I was just a wee lad I could play RS on my old mac from '86 if I had private chat off (I think public was fine), and I got about 5 fps. Now, I literally couldn't, because it takes up more memory than that computer even had. With hardware advancing and becoming cheaper and more used in common PCs, memory is usually fine. Video editing, intense photo editing, and super cool new games are all some examples of why people would need more memory/faster processor(s), etc.

Oh, and there's RuneScape(/Java).

I remember seeing the proggy for tarajunkies chickenkiller of 122 hours or some hysterically long time by uhh.. well his name slips my mind (started with a b, I think), but the point is, that was doable, and there were quite a few proggies that were all in the 50-100 hour range. That was a fantastic time where scripts could be ran indefinitely, and all that would stop it was someone's parents wanting to use the mouse that SCAR took from them. I'm sad to see proggies more in the 5-50 hour range, where 50 is quite long, in today's world of SRL.

And it can't all be Java's fault, as people are getting quite long reports with RSBot (~100 hours every once in awhile, I've seen), and RSBot uses Java, so it wouldn't make sense that moar Java would allow for longer proggies. So, it comes back to SRL(/Simba/scripts/reflection/MSI/PascalScript/Pascal/MML/whatever it may be). We have known that there are quite a few memory leaks all around different scripts/includes/libraries. And usually they're fixed. But it seems quite silly to me that we even have them. With a well structured library and proper use of the library, memory leaks should be able to be found quite easily, and shouldn't continue to pop up.

I know most people don't agree with me about the language changes/library downsize/etc., and that's fine, but I would like to at least see a proper restructure to MML/SRL/reflection/etc. so that memory leaks will not happen, unless something goes terribly wrong in a script and somehow leaks. (Memory leaks which happen in scripts should be able to be controlled in most cases with proper checks at runtime.)

I don't really know if this is just a stupid post that doesn't mean anything because obviously people aren't causing memory leaks on purpose (hopefully), but I do know that it happens in the changes are generally a bit more like band-aids, and aren't good for a community. I haven't had the time to look through SRL5 much (I did notice my name in there, and I wish I would've known earlier when I still had my code to give to the developers, but oh well), but from what I've heard/seen (sorta) is that it's more of just a restructure for appearance and losing SCAR functionality, but doesn't really address a whole lot else (which is completely understandable and I see nothing wrong with that, I just that a functional upgrade is also necessary at some point soon). And in my eyes, SRL and RS have evolved together, which is fantastic, except for what we're evolving with is sad and flawed and ugly. SRL shouldn't follow their standards.

(tl;dr,)

So, to sum this ramble up, at the very least, a restructure to deal with memory leaks is needed sometime soon. We really can't be messing around with that when RS is so bloated and stupid. I hope that can be agreed on, and if I have done nothing but cause over 100 posts by people, I hope I at least bring some more people to the attention of the include, and thus increase the standard for a fine, well working include.

:) Thanks.

From: i luffs yeww

Jagex has done a shitty job with RuneScape, in my opinion. Countless bugs, awful memory management (albeit I blame Java and the shitty JVM for this more than Jagex, but still, I can't imagine Java would be so used and THAT shitty all the time, but hey, I may just be too kind to Java ;)), and just an awful line of "improvements." But most importantly, the memory that RS takes is outstanding. I remember when I was just a wee lad I could play RS on my old mac from '86 if I had private chat off (I think public was fine), and I got about 5 fps. Now, I literally couldn't, because it takes up more memory than that computer even had. With hardware advancing and becoming cheaper and more used in common PCs, memory is usually fine. Video editing, intense photo editing, and super cool new games are all some examples of why people would need more memory/faster processor(s), etc.

It's pretty hard to do awful memory management in Java as Java itself handles pretty much everything. Just like you said, it could be the JVM, but you can't really blame Jagex for it. Also, Jagex just "goes with the flow". If they still had the graphics you could play on your '86 Max, they would have a lot less players. You need to evolve to keep your market share. Besides, computers nowadays can handle such graphics, so why not make use of that?

EDIT: I just thought of OpenGL. Jagex could probably leak some memory there..

From: i luffs yeww

I know most people don't agree with me about the language changes/library downsize/etc., and that's fine, but I would like to at least see a proper restructure to MML/SRL/reflection/etc. so that memory leaks will not happen, unless something goes terribly wrong in a script and somehow leaks. (Memory leaks which happen in scripts should be able to be controlled in most cases with proper checks at runtime.)

*cut*

So, to sum this ramble up, at the very least, a restructure to deal with memory leaks is needed sometime soon. We really can't be messing around with that when RS is so bloated and stupid. I hope that can be agreed on, and if I have done nothing but cause over 100 posts by people, I hope I at least bring some more people to the attention of the include, and thus increase the standard for a fine, well working include.

Pascal itself also does not need you to do much management. Arrays, records, strings and variants are all handled by the compiler. You only need to manage the memory you allocate by getMem (which isn't in PS as there are no pointers) and classes. SRL doesn't really use a lot of classes. Bitmaps and dtm's are managed by Simba, so that pretty much leaves forms (which aren't used that often either).

Now, reflection is a bit of an exception here, as it lets SMART allocate memory. Here, a nice wrapper system would indeed simplify things. Inside Simba/MML it is easier to leak memory (getMem). I don't think MML allocates that much memory, though. Probably in the color finding functions, but they get called very much and crashes would probably rise sooner if they were leaking memory.

Memory leaks are annoying, easily made and sometimes hard to find. They are not solved by a mere restructure, though. Plus, you might introduce new memory leaks by restructuring.

Well of course just because you restructure something doesn't mean you solve the problem. But I still completely believe that the way SRL and Simba and RuneScape (and many other things) have been handled is pretty bad, as features just get thrown in and thrown in. I know this isn't a major language like C++ or C or anything where there are quite strict "regulations" to get things changed, but I don't see the harm in being a bit more strict with it.

I autoed for a brief hiccup in the past couple weeks for all of about 24 hours, and since then it was months if not years. But I had seen quite a few threads/posts about people having troubles with crashes and a lot of the problems were because of scripts, and not the includes, iirc. I see no reason to not have a bit more checks at runtime, since we know in general what will be done in the script. It's not like we're using this for large projects where new types are made and blah blah blah, so checking some basic stuff seems logical to me.

I need sleep. I can tell I'm not making a whole lot of sense.

i really don't see what's wrong with downsizing the library. Or the very least putting a multitude of the functions where they wont be automatically included. I dont fee like reading through 4 pages to see if that's generally agreed upon, but that makes sense to me. I forget if it was just because of including msi, but when i was working on the msi form it loaded srl and msi before loading the form and it took like 8 seconds or something. That is simply crazy.

I still and probably will continue to support switching or allowing for python. Python and pascal are fairly similar in terms of syntax. I feel like a lexer/parser(if i have the terminology correct) would have a fairly easy time of converting pascal syntax to python if you still wanted to support pascal (which i feel like you would want to). And mopar seemed to express interest in making this happen. I feel like it is definitely fast enough for our needs, or if not afaik, pypy or Cpython are faster.

From: nielsie95
It's pretty hard to do awful memory management in Java as Java itself handles pretty much everything. Just like you said, it could be the JVM, but you can't really blame Jagex for it. Also, Jagex just "goes with the flow". If they still had the graphics you could play on your '86 Max, they would have a lot less players. You need to evolve to keep your market share. Besides, computers nowadays can handle such graphics, so why not make use of that?



Pascal itself also does not need you to do much management. Arrays, records, strings and variants are all handled by the compiler. You only need to manage the memory you allocate by getMem (which isn't in PS as there are no pointers) and classes. SRL doesn't really use a lot of classes. Bitmaps and dtm's are managed by Simba, so that pretty much leaves forms (which aren't used that often either).

Now, reflection is a bit of an exception here, as it lets SMART allocate memory. Here, a nice wrapper system would indeed simplify things. Inside Simba/MML it is easier to leak memory (getMem). I don't think MML allocates that much memory, though. Probably in the color finding functions, but they get called very much and crashes would probably rise sooner if they were leaking memory.

Memory leaks are annoying, easily made and sometimes hard to find. They are not solved by a mere restructure, though. Plus, you might introduce new memory leaks by restructuring.

The wrapper has already been written by me some time ago, it just needs to be used. :)

From: Dan Cardin
i really don't see what's wrong with downsizing the library. Or the very least putting a multitude of the functions where they wont be automatically included. I dont fee like reading through 4 pages to see if that's generally agreed upon, but that makes sense to me. I forget if it was just because of including msi, but when i was working on the msi form it loaded srl and msi before loading the form and it took like 8 seconds or something. That is simply crazy.

I completely agree with you, but quite a few people don't. A lot of the powers that be here like the whole "it's there if you need it but you don't have to use it" ideology, which is fine, but I don't want a bunch of nonsense in /core.

From: Dan Cardin
I still and probably will continue to support switching or allowing for python. Python and pascal are fairly similar in terms of syntax. I feel like a lexer/parser(if i have the terminology correct) would have a fairly easy time of converting pascal syntax to python if you still wanted to support pascal (which i feel like you would want to). And mopar seemed to express interest in making this happen. I feel like it is definitely fast enough for our needs, or if not afaik, pypy or Cpython are faster.

My biggest problem with adding Python support (which I'd still be happy to do, if changes are made), is that there's too much to be done. Not like "oh, this is a lot of work, so I won't do it," but more like "this is a lot of work that will never be used and will only make things slower, so there's no point in doing it unless things change." MML is quite large. SRL is even bigger. I don't want to do all of that work because it's simply too much right now.

I'm going back and forth on actually implementing the changes I think would be useful or not, and it's hard for me to decide. I think there are a lot of silly things about continuing the use of PascalScript/Pascal, but also a lot of good reasons to use it. I've been trying to get a little more educated about how/why changes are made to other languages (read: C++), and what would be best for MML/SRL. I won't voice my opinions currently, but I am also trying to remember that C++ is a general purpose, object oriented, high level language, which is far from PascalScript, and our specific use for it. But I still think things can be learned from looking at C++/Python/etc.

And @ Wizzup, I'm confus. What are you saying is done but not used? :x

IIRC memory leak detection?

I doubt that adding the interpretter itself would be difficult in itself. There's not much incentive to work towards something that isnt guarunteed to even be added. Adding it is the first step. But who am i to criticize. I doubt i would have the knowledge to do anything towards making python work to the needs nor the time atm.

From: Dan Cardin
IIRC memory leak detection?

I doubt that adding the interpretter itself would be difficult in itself. There's not much incentive to work towards something that isnt guarunteed to even be added. Adding it is the first step. But who am i to criticize. I doubt i would have the knowledge to do anything towards making python work to the needs nor the time atm.

;) You definitely could. It's really not that difficult. It's just a lot of work.

It's nothing that most (active) members here couldn't do, really. Takes a slight knowledge of Pascal beyond PascalScript to finish libmml, and then some basic knowledge in a different language for what you're adding (Python, for example).

But it's also not something you wanna just do willy nilly, because then errors will come up, and it'd be best to keep those to a minimum.

Also, Wizzup/Dgby know more about this than me.

From: i luffs yeww
;) You definitely could. It's really not that difficult. It's just a lot of work.

It's nothing that most (active) members here couldn't do, really. Takes a slight knowledge of Pascal beyond PascalScript to finish libmml, and then some basic knowledge in a different language for what you're adding (Python, for example).

But it's also not something you wanna just do willy nilly, because then errors will come up, and it'd be best to keep those to a minimum.

Also, Wizzup/Dgby know more about this than me.

And then it takes some more knowledge / experience to do it properly. ;)

From: Wizzup?
And then it takes some more knowledge / experience to do it properly. ;)

Well obviously nobody wants arrogantly ignorant programmers to do the work (lolme), but it also doesn't take K&R or Stroustrup. ;)

i was talking moreso of mopar's idea of pascalscript being converted to python so that the python interpreter can be used rather than a pascal one. afaik then pymml would take over if i understand it right. and IIRC you guys said that pymml could be automatically generated. Ofc it would have to be rewritten eventually, but if it can be done automatically, i dont see why it shouldnt be for finishing it quickly's sake.

From: Wizzup?
And then it takes some more knowledge / experience to do it properly. ;)

No need to discourage people.. If you want to start working on this but are running into some problems, I'm sure there are enough people willing to help :)

Well I've been confused on why more of this can't be gen'd. I dunno.

One thing with pyMML is that some of the things in MML can be done without calling them from the .dll, and can just be done in the language itself a better/faster/more convenient way. But, as you said, it can be do manually later.

On top of that, pySRL has to be made, and that really shouldn't be done automatically, since that wouldn't utilize OOP, which is a pretty big reason to be using Python in the first place.

The interpreter itself may be a bit more work, afaik.

EDIT:

@niels, I dunno.. Most people here aren't familiar with MML/libMML/Pascal.

From: nielsie95
No need to discourage people.. If you want to start working on this but are running into some problems, I'm sure there are enough people willing to help :)

Discouraging people is the last thing I want to do. I've been saying it's pretty easy to work on Simba and related stuff for ages. It's just that if you want to write a proper libMML and Python bindings you need more knowledge than just ``how pointers work''. You also need knowledge of both FPCs and Pythons GC, how to use python's native interface, etc. :)

From: i luffs yeww
On top of that, pySRL has to be made, and that really shouldn't be done automatically, since that wouldn't utilize OOP, which is a pretty big reason to be using Python in the first place.

Seeing as srl is written in simba, it wouldnt have to be done. The only doing would be to allow python to do the colorfinding stuff and whatnot that simba can do. Once you have simba in python(lib/pymml), srl would be able to stay the same. or afaik that was the idea.

From: Dan Cardin
Seeing as srl is written in simba, it wouldnt have to be done. The only doing would be to allow python to do the colorfinding stuff and whatnot that simba can do. Once you have simba in python(lib/pymml), srl would be able to stay the same. or afaik that was the idea.

Were not putting Simba in Python =/ Were adding MML to Python (Using libMML)

From: Dan Cardin
Seeing as srl is written in simba, it wouldnt have to be done. The only doing would be to allow python to do the colorfinding stuff and whatnot that simba can do. Once you have simba in python(lib/pymml), srl would be able to stay the same. or afaik that was the idea.

SRL is written in Simba? :x wat. Simba isn't a language.

The idea is to package up MML into a .so/.dll called libMML, but it's a little different from MML. Then you make pyMML which will just "import" functions from libMML, so that pySRL can use them, as SRL uses MML functions. Then we need to implement a CPython interpreter as well. (Well we don't NEED to, but it would be easier to script/test, sorta.)

We can already load SMART, find colors, click, move the mouse (with Python), and I had keyboard functions working too but they're not in the repo, iirc. Bitmaps, DTMs, TPAs and I dunno what else still need to be done (I guess like.. crypto, sockets, etc., but I still don't see why those are in MML, tbh).

There's something to be said for using rather simple languages like Pascal for runescape scripting.

I've written some scripts for RSBot, and personally it feels like the complexity needed to accomplish relatively small things is way out of proportion. I was coding scripts here in pascal when i was only 13 years old, there's no way i could have done that in Java.

What i see is simply a lack of in-demand scripts being made. In the end that's what gets people to come here, scripts. Once scripts are being made actively, demand for increased functionality from SRL and SIMBA will grow.

From: matviy
words have been said, and have echoed beyond the great wilderness in all directions – until now.

Well, one thing is that SRL isn't really aimed at just simplicity and making a bunch of scripts and ease of use like RSBot, but it's more of a learning community than a botting community.

A cookie for anyone who ports SRL to Malbolge.
– BP

Porting is bad idea, in just about every case.

But, on topic, http://pastebin.com/kbvK8Zj5 <– why I absolutely despise dynamic typing.

I really do not want to be a part of pySRL. :/ I fear it will be horribly messy and confusing, because of the practice Python promotes.

I still think C/C++ would be a good choice, but whatever. :p

Malbolge is a bad idea in every case. ;)

I'm actually learning python right now - why not give it a chance? (Plus, this way I won't be entirely hypocritical when I'm arguing against it ;))

From: Smartzkid
Malbolge is a bad idea in every case. ;)

I'm actually learning python right now - why not give it a chance? (Plus, this way I won't be entirely hypocritical when I'm arguing against it ;))

I think it's fine to open up a terminal, "python," and then do some small calculations or testing functions or mess with some stuff, and it's quite a good language to do that with, as you can just throw variables around like it's nobody's business. But it better stay nobody's business, because you'll damn well get yourself into some errors if you try to collaborate.

A language which promotes bad practice is a bad language, in my opinion.

From: i luffs yeww
Well, one thing is that SRL isn't really aimed at just simplicity and making a bunch of scripts and ease of use like RSBot, but it's more of a learning community than a botting community.

I could not agree more.

I believe this is part of the general foundation of what sets SRL apart from all other botting communities, because in the end this is a true community, the others are more like… bot gateways, designed just to give you the bot/script and away you go.

From: Flight
I could not agree more.

I believe this is part of the general foundation of what sets SRL apart from all other botting communities, because in the end this is a true community, the others are more like… bot gateways, designed just to give you the bot/script and away you go.

i tried to "Like" this but then i realized i wasn't on Facebook :p

From: i luffs yeww
I think it's fine to open up a terminal, "python," and then do some small calculations or testing functions or mess with some stuff, and it's quite a good language to do that with, as you can just throw variables around like it's nobody's business. But it better stay nobody's business, because you'll damn well get yourself into some errors if you try to collaborate.

A language which promotes bad practice is a bad language, in my opinion.

what do you mean about throwing variables around. From my experience, i don't remember anything being particularly different between python and pascal in terms of variables. In fact, in python you have to say when something is a global variable, so it makes it harder to screw things up inadvertently. The main reason something like C++ or languages like that IMO, is that they are a lot more complicated in terms of code. Python has some fairly elegant ways to deal with many things that might normally be annoying. As well as making python scripts is a really easy and quick thing to do. You go in, do your stuff, then you're done. I find development to be very fast and flexible, which is the kind of development you want to have for making rs scripts.

http://pastie.org/pastes/1840808/text?key=gvvraz6rq7dxkirwuvw0a

^ what I mean about "throwing variables around." There's no declared types at all in that. (It's from someone on 420chan.org/prog/.)

And, like I said, I think Python is fine for a one man job that doesn't do much. But a whole include with a bunch of different people contributing would be a dreadful process.

So, just because you don't understand Python and don't document your code you think it's a bad choice?

I've used Python in several projects on my university, with groups up to six people. Didn't have problems with ``throwing variables around'' and not understanding their code.

You aren't the type of person I'm talking about, Wizzup?. I know you're fine with Python, and I can read that and know what it was MEANT to do, but I also know that I could put in quite a few things that would be the wrong input and I wouldn't get an error.

But there aren't many people who are as fluent with Python as you, and so not only will there be a lot of stuff in pySRL that won't be good code.

And that wasn't my code by the way. And I know that it was a very extreme example, but still.

From: i luffs yeww
But there aren't many people who are as fluent with Python as you, and so not only will there be a lot of stuff in pySRL that won't be good code.

People can learn though, right?
I'm presuming that there's only a few people from the whole forum that knew the actual syntax for PS before joining the forum. I learned as I joined, just as many others did. Besides, the forum is about learning anyway :D

From: HarryJames
People can learn though, right?
I'm presuming that there's only a few people from the whole forum that knew the actual syntax for PS before joining the forum. I learned as I joined, just as many others did. Besides, the forum is about learning anyway :D

This is true. I think very few people knew Pascal when they stumbled across Scar in the beginning. But it's always the ambition that drives us to learn the language. Atleast this way we'll have the basic coding knowledge when jumping into Python so it won't be as tough as when one first begins scripting. Whatever ways Scar/Simba change, we'll always adapt to it because of that ambition.

Well of course people will learn. ;) There are very bright people here, but Python and PascalScript are quite different.

And of course you can declare variables as a certain type, but then that sorta defeats the purpose of dynamic typing.

But I'm sure we'll see what I mean if libMML ever gets done.

I've read barely any of this thread, but I will do when I get round to it (tomorrow perhaps?).

Is somebody porting it, is it just an idea or what?
Anyway, g'night :)

It should not be ported. As I just said, PascalScript and Python work very differently. It would be a stupid idea to just change the syntax.

From: i luffs yeww
You aren't the type of person I'm talking about, Wizzup?. I know you're fine with Python, and I can read that and know what it was MEANT to do, but I also know that I could put in quite a few things that would be the wrong input and I wouldn't get an error.

But there aren't many people who are as fluent with Python as you, and so not only will there be a lot of stuff in pySRL that won't be good code.

And that wasn't my code by the way. And I know that it was a very extreme example, but still.

Because, essentially with all the argument you're using against Python, you're very much pleading for Java. Java is that enterprise language with all that OOP and Java so you don't really need to understand each others code… That's why it's so huge in enterprises. And it's a hell to work on/in/with it, trust me. :p

I definitely don't want Java. :p

And I don't think that Python is a bad choice for those who are good with it, like you, but you have to realize that it's not really a language that would be beneficial for this community with the current amount of Python knowledge, that's all.

Also, I see no reason to make things more confusing and slower instead of using a statically typed language.

From: i luffs yeww
http://pastie.org/pastes/1840808/text?key=gvvraz6rq7dxkirwuvw0a

^ what I mean about "throwing variables around." There's no declared types at all in that. (It's from someone on 420chan.org/prog/.)

And, like I said, I think Python is fine for a one man job that doesn't do much. But a whole include with a bunch of different people contributing would be a dreadful process.

First of all using python will shorten the includes greatly and it will also teach proper formatting(right word?) of code. Also just because there's a bunch of people contributing doesn't mean there are going to be problems. Im pretty sure it would've happened already if that was the case(though PS sorta prevents it).

slightly offtopic: If python leads to dreadful problems then I wonder how many problems the guys at google must have :P

How well do you know Java and Python, luffs?

From: KingKong
y u mad tho? the quote is above.

PascalScript doesn't have dynamic typing support. It is also a much different language from Python, in a number of ways. It's sorta unfair to even compare the two, imo.

From: Zyt3x
How well do you know Java and Python, luffs?

I know the syntax of both to an extent. And I can figure out bugs and errors in both without TOO much trouble. Definitely not very efficient with either, but I have worked with both. I could help with either language, after it was implemented (I've done some, but it was pretty poor; I also have learned a lot more about computing in general, so if I relearned the languages I could help to implement them, but I'm not a fan of either and don't think it'd be worth my time to work with them at this time).

I'm nowhere near as good with Python as Wizzup?, and nowhere near as good with Java as quite a few people here, if that helps. :p

python is, in my opinion, certainly less confusing than pascalscript. Development in python is very fast (writing code in python can take less lines than pascalscript and very many less lines than C, which you were advocating). The interpreter is very stable and complete especially compared to pascalscript and pascal alternatives. And if you are thinking that python is slow compared to pascalscript, then there are a number of alternative implementations that have very much so increased speed. ( i also think that you would have the easiest time coming up with script backwards compatibility in python)

I doubt that the lack of statically typed variables will be a problem. And good practices in python come with learning python. Which is the same in any language. I'm sure you'd end up with far more problems moving to C style languages. Even if i could think of a reason for not using python, (unless it was something huge) then it seems to me like its the lesser of two(or however many) evils.

I disagree about good practices coming with learning Python. That's sorta what I'm trying to say in the end; Python supports and promotes bad practice, in my opinion, which is why I dislike it.

But, in comparison to the other alternatives, it may be the best option. For now, at least.

(Also, I'd say Pascal is more stable and complete than Python, really. Python functions via Cygwin or MinGW or something on Windows (think it's Cygwin); Pascal functions just fine natively on Linux, Windows, and OS X, afaik.)

I may start browsing through docs.python.org and maybe listen to some Google talks, but I dunno if I want to try to get back into lib/pyMML/pySRL stuff.

For group projects can't you just name variables like str_temp, MyInt?

Or we could just use Hungarian notation.

I know that it's not impossible to use good practice with dynamic typing, but still, it worries me.

How good are the python IDE's out there? Do they have good autocomplete? MSVS2010 has wonderful autocomplete ("intellisense"), this is my benchmark.

There's IDLE. :p Dunno, I don't use IDEs.

http://en.wikipedia.org/wiki/List_of_integrated_development_environments#Python

I read something on this yesterday. Given that with python you can create new things at runtime or something like that i forget the reason but, there isn't perfect autocomplete because it wouldn't necessarily be accurate. but I use SPE and i have used PyScripter. and they both have autocomplete, and at least in SPE it just shows all the possibilities, and narrows down as you type. Like I said, not perfect, but functional. I've never had a problem with it, and autocomplete is almost never as useful to me as tooltips showing me the required input to things is.

From: i luffs yeww
Or we could just use Hungarian notation.

I know that it's not impossible to use good practice with dynamic typing, but still, it worries me.

It's also not impossible for bad practice with static typing. Doesn't the laziness level of the programmer on a particular day count more? A stricter compiler can't say, "Err: Insufficient commenting- Line 567 '//counting and stuff' does not properly describe what you are doing". I guess I'm not saying don't worry, but rather, worry all the time :f:

I agree with that, Boreas. I just don't see why that extra level of possible confusion is worth it, since there's no big reason to actually use dynamic typing, imo.

I'd agree. Even though I have the option to use dynamic typing in C#, I don't. Why choose not to have the extra layer of security that strict types offer?

I've posted this a few times already, but .NET is a semi-smart choice, partly down to the eleventy-one languages it offers in one. So something written in C++ would work in IronPython, VB and C# too.

I would not use .NET. For one, we don't need it. And two, I don't want to support Microsoft.

Lots of IDE's, open standards, multiple VM's, JIT, static/dynamic typing, generics, multiple languages, easy interoperability, the option of type safety, I can go on and on.

Show me another option that can match it.

> Microsoft.

I won't use it for that reason alone.

Still thinking about Python.

BS dude. Just because MS is a large company doesn't mean they're implicitly evil…

Well of course not. But they are awful, in my opinion.

Sure, for the average user, Windows is a fine OS. I don't think that's very debatable. But, for people who want to develop anything in the software field, Microsoft is an awful company (so are Apple, IBM, Oracle, etc.). Any company that patents such nonsense as them are evil in my eyes (I can understand patents and copyright, as long as it's used appropriately).

I don't want to support a company that is detrimental to technology. I just don't feel right.

I also dislike closed-source software (not everything they do is closed). I don't want to support a company/group/person that has closed-source software.

Bro, every company has IP, most protect it pretty heavily.

I don't want to support a company/group/person that has closed-source software.

i find it a bit silly to generalize it to everyone like that.

As for .net and other suggestions. I think that this may be getting a bit out of hand. The main reason why i suggest python is that afaik the interpretter would be fairly easy to add to simba, and the conversion to python would be fairly painless compared to other options.

I dont see that: Lots of IDE's, multiple VM's, JIT, static/dynamic typing, multiple languages, would be particularly useful. Having multiple languages would probably be bad for Simba in general, which is why I like the idea of something that might be able to be lexer'ed from the pascalscript we use into python. I don't mind the syntax/way of doing things that we do with pascal, i just dislike the certain unsolvable problems we have with pascalscript's interpreter and whatnot. Multiple languages, would probably fragment the fairly small number of scripts we have and make things more complicated. Most of the other stuff is just not useful to Simba itself.

Simpler with this sort of thing is probably better. I'd rather just stay with what we have now than switching, except that i feel that python is a rather elegant solution that could conserve backwards compatibility.

Note: MSIL (.net) assemblies can interact seamlessly even if they were compiled from different languages.

From: Smartzkid
BS dude. Just because MS is a large company doesn't mean they're implicitly evil…

You don't really know what you're talking about. Have you ever read some articles on Groklaw? (slashdot has some references to all that crap around microsoft too)

For example, a recent article: http://www.groklaw.net/article.php?story=20110427052238659
There's a reason both the US and Europe still have a antitrust case going against Microsoft. They are evil.

Wikipedia has a good page on it too.

I didnt knew the did put patents on things they didn't invent, thats just wrong.

From: tom99
I didnt knew the did put patents on things they didn't invent, thats just wrong.

Most of the patents are invalid anyway, the system really needs to be completely reworked…

From: Wizzup?
You don't really know what you're talking about. Have you ever read some articles on Groklaw? (slashdot has some references to all that crap around microsoft too)

For example, a recent article: http://www.groklaw.net/article.php?story=20110427052238659
There's a reason both the US and Europe still have a antitrust case going against Microsoft. They are evil.

Wikipedia has a good page on it too.

good read, (:

I agree- Pascal is not a practical language to learn in today's society if one is interested in pursuing a computer science career or even for light programming on the side.

If for some reason, SRL converted to C++, Objective-C, or Java, I'd start programming here again. RS botting is the perfect way to get used to a language's syntax.

Obviously, there's no way to "convert" Simba and SRL to another language without it taking an unbelievably long amount of time. Maybe someone could start it as a side project?

From: TravisV10
I agree- Pascal is not a practical language to learn in today's society if one is interested in pursuing a computer science career or even for light programming on the side.

If for some reason, SRL converted to C++, Objective-C, or Java, I'd start programming here again. RS botting is the perfect way to get used to a language's syntax.

Obviously, there's no way to "convert" Simba and SRL to another language without it taking an unbelievably long amount of time. Maybe someone could start it as a side project?

Actually its actually simple to 'convert', theoretically atleast. But its underway, search for libmml development. Work is already being done to allow people to make scripts in python.

I didn't read previous 4 pages but I'd support and it'd be nice if we can have duo support for pascal and c/c++/python so maybe the lower class can learn the pascal and then switch to higher class to make plugin or scripts once they are bored. Probably confusing as hell but It might work he

Pascal is a great beginner language but once they learn that they need to move on to another better language.

From: Main Ftw
I didn't read previous 4 pages but I'd support and it'd be nice if we can have duo support for pascal and c/c++/python so maybe the lower class can learn the pascal and then switch to higher class to make plugin or scripts once they are bored. Probably confusing as hell but It might work he

You can already make plugins in other languages.

I'm taking a C++ class right now, i'd be glad to help with SRL. I think the main problem is that it is difficult to learn to make SRL scripts. I think the wiki is heading in the right direction but it needs alot more work to be the most helpful it can be. On the wiki there are scattered tutorials on random things that are reallly really helpful, but there isn't a ditinct path to go down from script kiddie to developer. I learned chunks of SRL from the wiki tutorials and the forums but to put it all together the best thing to do is just read scripts other people wrote.

tl;dr:
We need an all-encompassing SRL programming bible.

From: blackfire553


tl;dr:
We need an all-encompassing SRL programming bible.

^^ this. The wiki seems badly outdated. I just finished my first course in C++ and it makes learning pascal a lot easier. I have mostly been learning Simba by reading others scripts, but come of the standard stuff seems to be passed by like and inside joke e.g. how to grab colors/ images from RS "oh just use RSbot" and anything with walking.

Only based on how much I have read the forums of course, but there is a lot of digging through posts involved.

And that's a pretty important factor as to why I'd like the change. I have to get done with school over the next couple weeks, but I still do some work from time to time on this. Definitely isn't a small change.

From: blackfire553
I'm taking a C++ class right now, i'd be glad to help with SRL. I think the main problem is that it is difficult to learn to make SRL scripts. I think the wiki is heading in the right direction but it needs alot more work to be the most helpful it can be. On the wiki there are scattered tutorials on random things that are reallly really helpful, but there isn't a ditinct path to go down from script kiddie to developer. I learned chunks of SRL from the wiki tutorials and the forums but to put it all together the best thing to do is just read scripts other people wrote.

tl;dr:
We need an all-encompassing SRL programming bible.

http://docs.wizzup.org/simba was supposed to get a full introduction into Simba scripting, but I haven't found the time to do it yet and everyone else seems to lack the time or will to make it either. A actual SRL guide exists in various forms, but none are too extensive. There is http://docs.wizzup.org/srl-5/ but this is for the yet-to-come SRL 5 and mainly contains information about functions. You could use it as a reference; but it may not always be correct and lack information. The idea was to add additional text (not just text about what a function does) to that documentation.

Sticky that link in tutorial section wizz! perhaps people (like me) just don't know about goodies like that exists :(

You don't like the direction of the forums? Get over it. Leave then if you don't like. Everyone else is doing fine, except you. Baw baw baw.

From: jerryt
You don't like the direction of the forums? Get over it. Leave then if you don't like. Everyone else is doing fine, except you. Baw baw baw.

lol you troll, you. Just saying to WT that everyone here are e-thugs (far too obviously trollin'), and then saying everyone is fine. As well as saying that recursion is faster than iteration and calling me stupid. While it can be, so can iteration. And for someone to have to ask which to use, clearly iteration is the better choice (at least in his case), as he doesn't know how to optimize recursive calls.

So go play somewhere else, alright? You're only entertaining yourself.

I am New Here,My name is Jesse and this is my first entry here.

thank you

From: jiadongpeng
I am New Here,My name is Jesse and this is my first entry here.

thank you

It's sad that you're so desperate for posts. :(

Just a hint, next time post a thread indicating you're new etc. in the Welcome to SRL section.

From: Smarter Child
It's sad that you're so desperate for posts. :(

Just a hint, next time post a thread indicating you're new etc. in the Welcome to SRL section.

It's a spambot, silly.

From: Harry
It's a spambot, silly.

Thread: How To Get A Good…
Reason: Spam Bot
06-27-2011 12:02 AM by pyroryan 10 / Never

Thread: Concerning the…
Reason: Spam Bot
06-27-2011 12:02 AM by (censored unless he wants to be named) 10 / Never

Proness? Note the time.

From: pyroryan
Thread: How To Get A Good…
Reason: Spam Bot
06-27-2011 12:02 AM by pyroryan 10 / Never

Thread: Concerning the…
Reason: Spam Bot
06-27-2011 12:02 AM by (censored unless he wants to be named) 10 / Never

Proness? Note the time.

lol'd and creepy!

I'd be very interest in development in C#. Or rather any .NET language. I have often thought of ways this could be achieved. My issue is lack of time.