SRL Archive - Development

So I used SCAR scripts downloaded from here a few years back and just recently checked back and I notice that Simba has replaced SCAR as the primary program. What are the advantages of Simba over SCAR and vice versa?

From: chamilton333
So I used SCAR scripts downloaded from here a few years back and just recently checked back and I notice that Simba has replaced SCAR as the primary program. What are the advantages of Simba over SCAR and vice versa?

• Simba is open source and is built/maintained by the community(in theory). Wizzup? is the largest contributor but others have helped in the development. Basically if you don't like something about Simba you're not allowed to complain and feel helpless, you can actually add/fix/edit whatever you want and if it's worthy it will be added to Simba.
• Scar(4.0 pre-release) is made solely by Freddy1990 and is only about 50x faster then simba ever will be. However SCAR support will be dropped/is being dropped from SRL
• Scar 3.25 is faster then SIMBA and is my preference. But don't listen to me because i'm butt hurt. ;)

tl;dr Scar is faster but simba is what is used around here now.

Currently Scar Titan is far better than simba. Faster and has more features. but hopefully when Lape comes around, Simba will be once again better.

but overall, srl is slowely stopping their support for scar, so use simba.

[QUOTE='x[Warrior]
but overall, srl is slowely stopping their support for scar, so use simba.[/QUOTE]

Here, let me fix that for ya…

[QUOTE='x[Warrior]
but overall, srl is slowely stopping…

im fairly sure scar titan is not really at a completely useable point right now; though i could be wrong. It would be fairer mayhaps to compare 3.25 and simba. In that case, they are very similar feature-wise scar seems more complete and prettier (though they can both basically do the same thing in almost every case in terms of scripting). Simba is touted to be faster than 3.25 and is also definitely compatible with SRL whereas SCAR afaik may or may not be.

From: Flight
Here, let me fix that for ya…

lol?

From: Dan Cardin
im fairly sure scar titan is not really at a completely useable point right now; though i could be wrong. It would be fairer mayhaps to compare 3.25 and simba. In that case, they are very similar feature-wise scar seems more complete and prettier (though they can both basically do the same thing in almost every case in terms of scripting). Simba is touted to be faster than 3.25 and is also definitely compatible with SRL whereas SCAR afaik may or may not be.

erm, idk if you did benchmarks or not. but scar(3.25) is def faster.

From: footballjds
Scar(4.0 pre-release) is made solely by Freddy1990 and is only about 50x faster then simba ever will be.

That's simply untrue. SCAR Titan uses paxCompiler, and Simba uses Pascal Script. Once Lape is done, SCAR Titan really won't be much faster. Your bitterness towards Simba is upsetting and I feel like you're basing your opinion off of what Freddy has said SCAR Titan will have. I admit, the plans look impressive, but no one can say exactly when Titan will be ready to be used the way we would want, or how long before some of the features will be finished.

Also, you can't really say SCAR is better if you haven't used them for the same thing. There is no support for here for SCAR Titan (like Dan said, no sure if it's even in a usable state), so unless you've written a Titan script that works with Runescape, it's a tough comparison. Lastly, if SCAR is really that much better, why isn't is used here anymore? Yeah, you could said Wizzup? pushed it on people, but the bottom line is, if SCAR worked that much better, people would use it rather than Simba, regardless of what Wizzup? says.

SRL4 still has SCAR 3.25 support in case anyone was wondering.

i did not, but whenever i would talk to simba people (generally wizzup) they would tell me that simba was faster than (before titan) SCAR. thats why i said "touted to be" since i never checked.

Tbh they're both almost exactly the same thing except like i said, scar is prettier and has a form editor. If you compare to titan you will have significantly less speed, but then you will also have to compare the change in syntax may or may not be good for SRL itself were it to conform to titan. But in terms of non titan, the speed difference, i would doubt to be more than negligible in terms of usefulness in botting for RS.

EDIT: @ coh3n. From what i remember of the benchmarks that people were doing, lape was still quite slower. I cant check atm, but it would actually surprise me a bit if lape was faster/as fast. Also in terms of why the switch happened. People are bandwagon hop-onners. Simba was new at the time and promised less crashes and faster scripts among other things so then everyone jumped on and acted like they also cared that it was open source and there you go. Now, SCAR 4 is doing the same with fastness and crashes and new features. Now people are jumping on because it looks like the cool new thing. Only time will actually tell which is actually best. Tbh, i dont think simba was a large enough positive jump to switch, but it worked out well enough and i have doubts as to whether or not SCAR will be picked up again simply because constant switching (scar to simba to complaints about pascal script and switching to lape/others to scar again) gets old and silly.

simba has a bigger community, more people working on it and with it.. along with open source + suggestions also get put into effect..

if you're concerned about 1000ths of a second in speed increase you're playing the wrong game, using the wrong languages and probably using the wrong operating system

Let's keep the comparisons to the products in their current state :)
Lape nor Titan is actually finished and there's no meaning in arguing over something (perhaps uncertain?) in the future.

From: Coh3n
That's simply untrue. SCAR Titan uses paxCompiler, and Simba uses Pascal Script. Once Lape is done, SCAR Titan really won't be much faster. Your bitterness towards Simba is upsetting and I feel like you're basing your opinion off of what Freddy has said SCAR Titan will have. I admit, the plans look impressive, but no one can say exactly when Titan will be ready to be used the way we would want, or how long before some of the features will be finished.

Also, you can't really say SCAR is better if you haven't used them for the same thing. There is no support for here for SCAR Titan (like Dan said, no sure if it's even in a usable state), so unless you've written a Titan script that works with Runescape, it's a tough comparison. Lastly, if SCAR is really that much better, why isn't is used here anymore? Yeah, you could said Wizzup? pushed it on people, but the bottom line is, if SCAR worked that much better, people would use it rather than Simba, regardless of what Wizzup? says.

SRL4 still has SCAR 3.25 support in case anyone was wondering.

I do not comment on which is better because that's someones opinion. All i did was tell the OP the facts.
I'm sorry you think i am bitter towards simba. I use it, not because i find it faster/better but because that's what is used around here. Sure i still hold allegiance towards SCAR. But that's only because i started using it back in kaitnieks days around 10 yrs ago…

From: Dan Cardin
i did not, but whenever i would talk to simba people (generally wizzup) they would tell me that simba was faster than (before titan) SCAR. thats why i said "touted to be" since i never checked.

Tbh they're both almost exactly the same thing except like i said, scar is prettier and has a form editor. If you compare to titan you will have significantly less speed, but then you will also have to compare the change in syntax may or may not be good for SRL itself were it to conform to titan. But in terms of non titan, the speed difference, i would doubt to be more than negligible in terms of usefulness in botting for RS.

3.25 is still faster then Simba is. ofc wizzup? would say it's faster ;)

From: Dan Cardin
Tbh they're both almost exactly the same thing except like i said, scar is prettier and has a form editor. If you compare to titan you will have significantly less speed, but then you will also have to compare the change in syntax may or may not be good for SRL itself were it to conform to titan. But in terms of non titan, the speed difference, i would doubt to be more than negligible in terms of usefulness in botting for RS.

Exactly. :)

From: Dan Cardin

EDIT: @ coh3n. From what i remember of the benchmarks that people were doing, lape was still quite slower. I cant check atm, but it would actually surprise me a bit if lape was faster/as fast. Also in terms of why the switch happened. People are bandwagon hop-onners. Simba was new at the time and promised less crashes and faster scripts among other things so then everyone jumped on and acted like they also cared that it was open source and there you go. Now, SCAR 4 is doing the same with fastness and crashes and new features. Now people are jumping on because it looks like the cool new thing. Only time will actually tell which is actually best. Tbh, i dont think simba was a large enough positive jump to switch, but it worked out well enough and i have doubts as to whether or not SCAR will be picked up again simply because constant switching (scar to simba to complaints about pascal script and switching to lape/others to scar again) gets old and silly.

I'm sure lape won't be as fast, paxCompiler compiles native code or something like that, so it's like using a plugin all the time (I think?). I more meant that for what we're doing, I don't think it'll make THAT much of a difference.

From: footballjds
I do not comment on which is better because that's someones opinion. All i did was tell the OP the facts.
I'm sorry you think i am bitter towards simba. I use it, not because i find it faster/better but because that's what is used around here. Sure i still hold allegiance towards SCAR. But that's only because i started using it back in kaitnieks days around 10 yrs ago…

Your "facts" weren't right though. You said SCAR is 50x faster than Simba ever will be. You can't say now how fast Simba will ever get. :p

From: Dan Cardin

3.25 is still faster then Simba is. ofc wizzup? would say it's faster ;)

Like Dan said, it doesn't really matter which is faster because the difference is insignificant for RS botting.

IMO: Scar has better user interface ( freddy really worked hard on this). I hope when the scar 4 comes out (or even the alpha/beta right), more people will make 2 version (which isn't much change btw).

From: Coh3n
That's simply untrue. SCAR Titan uses paxCompiler, and Simba uses Pascal Script. Once Lape is done, SCAR Titan really won't be much faster. Your bitterness towards Simba is upsetting and I feel like you're basing your opinion off of what Freddy has said SCAR Titan will have. I admit, the plans look impressive, but no one can say exactly when Titan will be ready to be used the way we would want, or how long before some of the features will be finished.

Not to mention that his comparison is completely flawed, as he is comparing the wrong parts. Most (say >99%) of all the CPU time is spent inside Runescape/SMART or Simba functions, and only 1% or less is PascalScript/paxCompiler running your script. The interpreter really doesn't matter all that much, unless you want to write your own findColor functions in which case paxCompiler is still too slow. Lape's main advantages (if it will come) are that it is FOSS, written by a knowledgeable friend and it is actively maintained (which means lots of features, bugfixes, etc). Lape won't offer speeds similar to FPC just like paxCompiler doesn't.

From: Coh3n
Also, you can't really say SCAR is better if you haven't used them for the same thing. There is no support for here for SCAR Titan (like Dan said, no sure if it's even in a usable state), so unless you've written a Titan script that works with Runescape, it's a tough comparison. Lastly, if SCAR is really that much better, why isn't is used here anymore? Yeah, you could said Wizzup? pushed it on people, but the bottom line is, if SCAR worked that much better, people would use it rather than Simba, regardless of what Wizzup? says.

Thank you. May I just state that this SCAR 4.0 has been in the works for over three or four years (perhaps even 5), so to be honest I'm not really impressed at the rate of development. Plus, I don't really think it does offer a lot more than the engine bought with the money that Janilabo generously donated to Freddy.

tl;dr: footballjds needs to get his arguments straight and sit on something that doesn't hurt his butt.

From: Coh3n
Your "facts" weren't right though. You said SCAR is 50x faster than Simba ever will be. You can't say now how fast Simba will ever get. :p

then i'll just use what you said: "I'm sure lape won't be as fast, paxCompiler compiles native code or something like that, so it's like using a plugin all the time (I think?)."
wait for the wink… wait for it… ;)

From: Coh3n
Like Dan said, it doesn't really matter which is faster because the difference is insignificant for RS botting.

Faster is NEVER worse when is comes to to scar/simba.

EDIT:

From: Wizzup?
tl;dr: footballjds needs to get his arguments straight and sit on something that doesn't hurt his butt.

<3 you too wizzup?

From: footballjds
then i'll just use what you said: "I'm sure lape won't be as fast, paxCompiler compiles native code or something like that, so it's like using a plugin all the time (I think?)."
wait for the wink… wait for it… ;)

Lol, what? Right now, SCAR Titan is much faster, but it won't be THAT much faster when Lape is done. Let's just stop this argument, it's pointless.

From: footballjds

Faster is NEVER worse when is comes to to scar/simba.

Course it's not worse, but it won't make a difference if you can't notice the difference in speed.

chamilton333:

Simba is Open Source.

That is the biggest difference that you might care about.


And for rest of the people.

Come on..

Like you'v been waiting for this thread all day and now you can start a arguing war :P

Scar Titan and Simba is made for different things.
Simba is mainly for RS.
Titan is more for everything (I think)

If you are in SRL stick with Simba.
Download Titan (When it's ready) for other usage.

~Home

i suppose i could be wrong but from what i've gathered whilst speaking to freddy, actual development on 4 hasn't been happening that long. maybe planning and whatnot, but afaik up until probably when simba came out it wasn't really in development and even then he had been mostly if not solely working on 3.25 for much of the time. I dont think that that really has any baring in the actual comparisons though tbh. if it did though, simba was supposed to be cross platform, and seeing as its still not usable really, on other platforms…the speed of development of simba isnt very impressive…

and while ill agree slower is never better, much of the actual speed is wasted on the fact that you're not running only your code to bot rs; you have to wait for rs, so within the scope of srl, speed isn't necessarily first priority.

From: Dan Cardin
i suppose i could be wrong but from what i've gathered whilst speaking to freddy, actual development on 4 hasn't been happening that long. maybe planning and whatnot, but afaik up until probably when simba came out it wasn't really in development and even then he had been mostly if not solely working on 3.25 for much of the time. I dont think that that really has any baring in the actual comparisons though tbh. if it did though, simba was supposed to be cross platform, and seeing as its still not usable really, on other platforms…the speed of development of simba isnt very impressive…

and while ill agree slower is never better, much of the actual speed is wasted on the fact that you're not running only your code to bot rs; you have to wait for rs, so within the scope of srl, speed isn't necessarily first priority.

I think the cross platform stuff is due to pascal script. Not 100% sure about that, though.

From: Coh3n
I think the cross platform stuff is due to pascal script. Not 100% sure about that, though.

yea that's what I was told.. it's all because of pascal / the pascal interpreter (I think is the right reason for it)

From: Home
chamilton333:

Simba is Open Source.

That is the biggest difference that you might care about.~Home

Yep. :)

From: Dan Cardin
i suppose i could be wrong but from what i've gathered whilst speaking to freddy, actual development on 4 hasn't been happening that long. maybe planning and whatnot, but afaik up until probably when simba came out it wasn't really in development and even then he had been mostly if not solely working on 3.25 for much of the time.

Well, he talked to me about it over four years ago. Plans count as well. At least I've been hearing about it for a long time…

From: Dan Cardin
I dont think that that really has any baring in the actual comparisons though tbh. if it did though, simba was supposed to be cross platform, and seeing as its still not usable really, on other platforms…the speed of development of simba isnt very impressive…

Even if the speed of development isn't impressive, it is at least stable because there's more than one person working on it.

Then again, Simba has been running on my Linux desktop for years. It works fine; the interpreter just doesn't. For example, with RUTIS it worked quite well, and the lape-branch seems to work well, too. Aside from a few minor issues such as IsKeyDown() not yet implemented I don't think we're very far from cross platform stable builds. (In fact, mopar has been building x86 and x86_64 builds for Windows and Linux for some time now, with Mac to follow later) Simba has been built with cross platformness in mind and we abstracted out most of the OS dependent API's. (Which makes the MML pretty appealing IMO, you could even plug it into SCAR as a plugin on other platforms. Too bad it's GPL. ;) )

I don't see SCAR coming to any other platform in years, as Freddy is simply waiting for the Windows API to be ``ported'' to other platforms. Something which will never happen, so until he realises this and stops using it as an excuse, I don't expect cross platform builds.

The possibilities with Simba are huge, because it is a SRL community project. libMML is just one example. It's really not too hard to ``hardcode'' your script into Simba or make your own small Simba clone (the feature people wanted, .exe's with scripts), people just don't do it yet for some reason. All in all I don't see SCAR ever coming back, at least not in this community. Luckily SCAR has it's own community forum, and I wish Freddy lots of luck with his future projects. Perhaps at some point he will realise Open Source is the way to go if you want a stable community. :)

Correct me if I'm wrong Wizzup? but i believe the thing you feel most strongly about is the fact that Simba isn't developed by a single person?

Many thanks to everyone for explaining it. Open source is definitly superior. I think it might take some time for Simba to catch up to SCAR but it should outpace it if there are multiple dedicated contributors.

Maybe Freddy will decide to join in :)

Umm..

Disadvantages of both.. U can't type bytes :c something like:

c: Byte;

if(c = 0x79) <— will give an error..

as for simba over scar? I say they're equal and only thing simba has on scar is the open source stuff.. thats about it.. Scar has a form editor, its far more stabled and doesn't freeze up all the time without giving a reason..
Simba's next advantage is that u can press ctrl+space and see what functions there are.. and that it has intellisense.. thats about it.

From: ggzz
Umm..

Disadvantages of both.. U can't type bytes :c something like:

c: Byte;

if(c = 0x79) <— will give an error..

as for simba over scar? I say they're equal and only thing simba has on scar is the open source stuff.. thats about it.. Scar has a form editor, its far more stabled and doesn't freeze up all the time without giving a reason..
Simba's next advantage is that u can press ctrl+space and see what functions there are.. and that it has intellisense.. thats about it.

var
  B: Byte;
begin
  B := $79;
end;

I was a SCAR "holdout" for quite a while. I finally switched over to Simba for the integrated update extensions for SRL/Scar, Reflection, and MSI. There were a handful of things I liked better about SCAR at the time, but to be honest I can't remember any of them now because I've adapted to Simba and it's great.

Just my thoughts on the speed and OSS. For models and web walking the speed of Titan does make a difference as well as the more complex searches you can do without sacrificing time. I can say that because I've been writing a reflection include for Titan just to get things out and have a bit of fun. As far as OSS…. I honestly dont think the end user cares one single bit as I don't, I just want a fast, working application to bot with.

It's just a open vs closed-source discussion. As SRL is a learning community, open-source fits in better.. Nothing more to say really.

SCAR Titan will never work on anything other than Windows.
SCAR Titan will never have its source released because so many components have been bought and Freddy wont replace them with his own code because he spent so much money on them.
SCAR Titan has been built with many bought components, meaning if there is an issue with something that freddy hasnt made, it will not be updated quickly unless the company that made it fixes it.

From: footballjds
Correct me if I'm wrong Wizzup? but i believe the thing you feel most strongly about is the fact that Simba isn't developed by a single person?

The open-source factor as well.

From: ggzz
Umm..

Disadvantages of both.. U can't type bytes :c something like:

c: Byte;

if(c = 0x79) <— will give an error..

as for simba over scar? I say they're equal and only thing simba has on scar is the open source stuff.. thats about it.. Scar has a form editor, its far more stabled and doesn't freeze up all the time without giving a reason..
Simba's next advantage is that u can press ctrl+space and see what functions there are.. and that it has intellisense.. thats about it.

The crashing is due to Java not being freed properly when killing SMART. IIRC, it's neither SMART's nor Simba's error, just the way RS handles things. But I'm no expert. :p

I've never heard any examples of Simba crashing when SMART wasn't being used (unless the user was using a wrongly coded form).

From: Coh3n
I've never heard any examples of Simba crashing when SMART wasn't being used (unless the user was using a wrongly coded Script).

Fixed, I've crashed Simba a lot of times =) not forms, just me doing things PS doesn't like.

From: Dgby714
Fixed, I've crashed Simba a lot of times =) not forms, just me doing things PS doesn't like.

Ah okay fair enough. I could say that's it's not Simba's problem, but Simba uses PS, so it ends up being and problem for Simba. :p

I like how SCAR Titan is moving away from Pascal and towards C++ (or at least according to Freddy). Sure Pascal is easier to learn, but it's faded from the programming scene and I will probably never be able to use it in a career of software development.

But since SCAR is a one man project I don't think that Titan will be finished anytime soon. Simba has some issues as well, but it is the most stable application for macroing at this current time.

From: Echo_
I like how SCAR Titan is moving away from Pascal and towards C++ (or at least according to Freddy).

What? He's delusional if he thinks adding one thing from C++ to Pascal is moving >..>

The only thing C++ (afaik) in Titan is C++ Operators.

From: tarajunky
I was a SCAR "holdout" for quite a while. I finally switched over to Simba for the integrated update extensions for SRL/Scar, Reflection, and MSI. There were a handful of things I liked better about SCAR at the time, but to be honest I can't remember any of them now because I've adapted to Simba and it's great.

I know right!

Any ways, Simba is currently used most commonly by everyone on the forum so I would recommend you go with it. :)

something i <3 about simba.
cntrl + clicking something :)
love u wizzup? even though you hate me and want me to sit on something soft so my but isn't hurt :p

From: Dgby714
What? He's delusional if he thinks adding one thing from C++ to Pascal is moving >..>

The only thing C++ (afaik) in Titan is C++ Operators.

He's only added C++ operators for now, but plans to add complete C++ support.

From: Freddy1990
In the future the engine should also support c++ scripting and inline assembler.

From: Echo_
He's only added C++ operators for now, but plans to add complete C++ support.

If that happens.. I will ditch simba *Completely*.. I'd write every possible script for scar titan..

From: ggzz
If that happens.. I will ditch simba *Completely*.. I'd write every possible script for scar titan..

holla ;)

From: Echo_
He's only added C++ operators for now, but plans to add complete C++ support.

Simba plans to add python support. But for either Simba or SCAR, I highly doubt full support for another language will be available for quite some time.

It's pretty likely considering PaxCompiler already supports multiple languages ;)
I'm afraid you're all making some very loose assumptions, though.

From: nielsie95
It's pretty likely considering PaxCompiler already supports multiple languages ;)
I'm afraid you're all making some very loose assumptions, though.

I was just going by how long python support has been in the works + the amount of other things that need to be done beforehand. For SCAR, I just assumed it was a lot more work than it is, apparently.

From: ggzz
If that happens.. I will ditch simba *Completely*.. I'd write every possible script for scar titan..

Why? Do you really need that much more power? Or do you want to code in an trusted language?

From: Coh3n
Simba plans to add python support. But for either Simba or SCAR, I highly doubt full support for another language will be available for quite some time.

Python isn't really my cup of tea, plus it's slower than C++ ;)

From: Coh3n
Simba plans to add python support.

No. There is work being done to allow people to use MML in python.

From: masterBB
Why? Do you really need that much more power? Or do you want to code in an trusted language?

Lol?? What u mean why do u need that much more power.. its not like im going to make malicious scripts.. I'd obviously post the source of the script and have a user compile it themselves..

The reason u need this "power" is because u can do multi-threading.. U can grab window handles, U can make your scripts one click (separate executable), U can hook into smart to add GUI's to it or buttons, etc..

I prefer c++ because it just happens to be my strongest language and the only language that I can write.. all the other I can only read them and they're much harder for me personally. I personally prefer any C language over some language that barely has tutorials and people barely use..
Not very many people program in Lua, python, delphi, pascal.. Most are VB.net, C++, C#, Objective C, .Net stuff.. etc..

From: ggzz
Lol?? What u mean why do u need that much more power.. its not like im going to make malicious scripts.. I'd obviously post the source of the script and have a user compile it themselves..

Power like in horsepower. Being able to do more with less computer resources. At least I think that c++ would give you that. Not sure how much pax compiler will deliver though.

Familiar with the c language , that was the answer to my question:D

If speed were all anyone at SRL cared about, SRL would be a plugin and not an include. Plugins have long been used for when speed does matter and can continue to be used when that is the case. Perhaps a few comparisons of ye olde WizzyPlugin functions run in Titan to see how the comparison is speed-wise? I can only see a true positive (for SRL) from the speed increase if all of SRL could be text rather than compiled. Then again, a lot of the WizzyPlugin et al functionality generally make good things that a macroing program should have built-in rather than plugged-in.

If Wizzup? and co were struck by lightning, Simba can continue; the same cannot be said for SCAR. This, of course, only matters if the program needs to be continually developed. The answer, apparently, is that it does. Several versions of SCAR have been released, some breaking backwards compatibility and others not. I'm unsure what functionality has been gained or will be gained, but I do have to wonder if any of it has been requested truly or requested whimsically. If it's simply the case of cleaning cobwebs and spraying bugs, then why switch to newer versions which are more buggy? If new functionality is being added, then it's not vital to SRL operation and so should only be considered if the functionality offers vast improvements. Vitally, though, a stable SCAR is a necessity for otherwise a missing Freddy leaves behind a buggy Scar and, by virtue of hypotheticals, a buggy SRL.

If C++ is what you want and could write every possible script, poke around the back of Simba. The nice thing about open-sauce is that, if you wanted to, you could port all the macroing functionality to C++ or compile said macroing functionality to a plugin and then use the plugin as part of an executable (furthering the speed up!) Considering a complete switch away from Pascal to C++ would render SRL useless in macroing endeavors, a plate of further porting wouldn't be much of a problem to stomach. Even if support was there for both Pascal and C++, what purpose does having a dual-language environment serve? It would effectively split the community into two (Pascal coders and C++ coders) with their only attachment being SRL and even that would probably be ported over and maintained in parallel simply because some people preferred C++ to Pascal and vice versa - think of the madness! I'm all for encouraging diversity of programming languages, but one with experience in multiple languages knows that there is little difference between them once you learn the syntax. Pascal has a nicer syntax for beginners and that's rather nifty for a community of amateur scripters.

Of course, the other thing to remember is that Simba was developed for free for SRL. I have nothing against accepting donations to buy components, but it is the case that Freddy's hobby is SCAR and not SRL - that is, his bought components make SCAR better with the occasional side-effect of offering something extra to SRL. The two have been closely linked in the past due to an asymmetric arms race: SRL depended on SCAR and SCAR did not directly depend on SRL. With Simba around, SRL may freely develop without having to jump through the occasional SCAR hoop and SCAR may develop without restraint from SRL. Simba can be publicly maintained with a much purer symbiotic relationship than it ever had with SCAR since its developers have effectively cut out the middleman. Simply, Simba and SRL share the same goals while SCAR and SRL simply have one goal in common (that of macroing.) As have I already covered speed, I wonder what other incidental benefits might be had, but I dare guess that they are insignificant. To point out that i++ is way more awesome than Inc(i) or i := i + 1 is to point out that no new functionality was added. To point out that multiple threads may be safely run in parallel and have a simple and easy to use method of communication between them, well that has a much brighter future in further functionality (persistent random finder anyone?)


In the end though, the true advantage of Simba over Scar is that Scar is the baddIE and Simba is the goody.


A few points to ggzz: I don't think Titan has multithreading; I don't think it has compiling to exe (Freddy mentioned the engine can, but that SCAR just compiled the script to bite-code); I don't think what you mentioned about hooking into SMART would be possible, but SMART is open-sauce so you could always add in yourself. Basically, I think you are confusing a C++ interpreter with a C++ compiler, but I may be wrong (either in that Titan will be able to interpret C++ rather than compile it or in that you have mixed that up.)

As for Python, unlike my earlier comment on C++ splitting the community, Python is much more beginner-friendly. Do note that this is effectively what my third paragraph suggests and it will have the same obstacles to face, minus the reduction in beginner-friendliness.

From: Dgby714
No. There is work being done to allow people to use MML in python.

Oh? I thought the end goal was to have Simba scriptable in python. My mistake.

From: Coh3n
Oh? I thought the end goal was to have Simba scriptable in python. My mistake.

I don't understand your statement.

The point of Simba & Python is almost invalid. What the plan was: to have the MML implemented in python for usage. Simba would allow one to easier code the MML based on tools presented. That being said, all that would need to change is external calls to the python interpreter when running Simba and changing the TSynEdit to python syntax (that's done easily, not the former stuff, though).

Again, you confused me!

From: ggzz
If that happens.. I will ditch simba *Completely*.. I'd write every possible script for scar titan..

Or you could just do it yourself if you really think you're that skilled in C++. It's not that hard to write a OOP wrapper around the libMML (although incomplete atm) now is it? Except you'll still lack an entire include such as SRL for all your scripts, so you'll have to write a lot from scratch.

Personally, I find it pretty hilarious that when I first suggested providing another language I got heavily flamed by some (SCAR supporters), and now possibly adding C++ support to SCAR seems like a good thing. However, I now believe a different language right now will not solve anything. I don't think Pascal for SRL is leaving anytime soon, especially now that hopefully lape will be complete enough to be used in SRL some day. But don't worry, I still like libMML and pyMML a lot. :)

@Cohen, yes, we did/do plan to have Python support in Simba at some point. Now that we might have a proper interpreter in the near future, we might have to reconsider the decision, but using Simba functions in Python should be (and already partially is) possible in the near future. You'll just have to run it from somewhere other than Simba, which shouldn't be too hard for a developer anyway. It's not too hard to add basic Python support like ``Run/Stop'' script to Simba either, but you wouldn't have code hints, auto completion, etc.

The difference with PaxCompiler is that it has cross-language support ;) So you can write SRL in Pascal, but your scripts in another language.

From: nielsie95
The difference with PaxCompiler is that it has cross-language support ;) So you can write SRL in Pascal, but your scripts in another language.

The same would theoretically go for SRL if you'd write it in something more ``standardized''.

From: Nava2
I don't understand your statement.

The point of Simba & Python is almost invalid. What the plan was: to have the MML implemented in python for usage. Simba would allow one to easier code the MML based on tools presented. That being said, all that would need to change is external calls to the python interpreter when running Simba and changing the TSynEdit to python syntax (that's done easily, not the former stuff, though).

Again, you confused me!

I'm not sure how it was confusing. Right now Simba allows scripting in PS, in the future I thought you'd be able to script in python and by what Wizzup? said below, that's what was talked about.

From: Wizzup?

@Cohen, yes, we did/do plan to have Python support in Simba at some point. Now that we might have a proper interpreter in the near future, we might have to reconsider the decision, but using Simba functions in Python should be (and already partially is) possible in the near future. You'll just have to run it from somewhere other than Simba, which shouldn't be too hard for a developer anyway. It's not too hard to add basic Python support like ``Run/Stop'' script to Simba either, but you wouldn't have code hints, auto completion, etc.

Okay, that's what I thought. :p

Wizzup: saying that simba can run on linux is all well and good, but that doesn't mean that it can actually be used on linux. The intperpretter being the problem is pretty much the same thing as Simba being the problem until either the interpretter is fixed or it is changed. Lape support is the big hopeful, but it still hasn't been finished enough to make a debut in stable Simba, so that was what i meant.

Also, yep Simba v scar is basically an argument of opensource vs closedsource and also what SRL will run on. To the end user, i have very high doubts that the prior actually matters, but the former depends on the opinion of the people to which opensource is important…sooo..

From: Dan Cardin
Wizzup: saying that simba can run on linux is all well and good, but that doesn't mean that it can actually be used on linux. The intperpretter being the problem is pretty much the same thing as Simba being the problem until either the interpretter is fixed or it is changed. Lape support is the big hopeful, but it still hasn't been finished enough to make a debut in stable Simba, so that was what i meant.

Also, yep Simba v scar is basically an argument of opensource vs closedsource and also what SRL will run on. To the end user, i have very high doubts that the prior actually matters, but the former depends on the opinion of the people to which opensource is important…sooo..

Although I can't comment much on the former, I shall the latter. It is easy to simplify it all down to open vs closed sauce, but that leaves out things of much importance. As a simple example, Simba is built by SRL for SRL so it can have things such as automagical SRL downloaders packaged with the installer. SCAR used to have one built-in, if memory serves, but Freddy removed it to start separating SCAR from SRL. There isn't really anything wrong with what he did, but it is a point where the programmer and userbase disagree; since this isn't paid software with customer guarantees or the like, the programmer "wins" and the userbase "loses". This is all a re-utterance of my longpost though, which makes me think you didn't read it properly as I raised plenty of points that weren't simply open vs closed :(

he replaced the built in-ness with a generalised include manager that includes srl. But i can see your meaning. Even so, thus far i see, correct me if im wrong, the original couple of developers, and a few that have written bugfixes and or actually helped with things. Past that not too many helpers. So basically those that want changes must either manually change something, which most wont. Or they will suggest a change and hope it gets done, which is the same risk that you run into when suggesting things to freddy. Granted you have marginally more people to do said change, but i read a post by wizzup moments ago saying the porting of Appa wasn't worth doing unless X. Not that i disagree in this instance (because i am not knowledgeable about the subject) but its just an instance of something the community could do if someone was so inclined, but Wizzup? doesn't deem it necessary so it won't get done. despite being "written by srl" its not srl that really writes Simba. You run into that problem with both sides is all im saying.

From: Dan Cardin
Granted you have marginally more people to do said change, but i read a post by wizzup moments ago saying the porting of Appa wasn't worth doing unless X. Not that i disagree in this instance (because i am not knowledgeable about the subject) but its just an instance of something the community could do if someone was so inclined, but Wizzup? doesn't deem it necessary so it won't get done. despite being "written by srl" its not srl that really writes Simba. You run into that problem with both sides is all im saying.

That's just silly. I've never used Appa for SCAR. Just because I don't need it doesn't mean it won't be written. I'm not even the author of Appa now am I? Nielsie95 wrote it ``even though I didn't need it''.

If you have a look at the recent changelog you'll see that it is in fact, SRL writing Simba. Obviously some contribute more than others, and there's always someone in charge - if you don't like the person in charge, you fork the project or flame him.

appa was more of an off the cuff example, to demonstrate the point, and less so of a real instance of something.