SRL Archive - Discussions & Debates

What would everyone think of a version of Simba made in the .NET language - thus allowing 'scripts' to be made in .NET as well?

Advantages:

• A variety of more popular and capable languages to work in.
• Fewer language oriented bugs.
• Capable and relatively easy use of alternative IDEs.
• Faster compile times (usually not that bad today anyway).
• Compatible with Mac, Linux, and Windows (.NET was made open-source a couple weeks ago http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
• Possible to easily pre-compile scripts (This may be a negative depending on community thoughts. Can also be built in such a way as to make this difficult - community opinions on the matter?)
• Scripts could be written in just about any language desired. If you wanted to keep scripting in PS or LAPE, then that could be made to work. If you wanted to 'script' in C# instead however, and begin taking advantages of the languages/frameworks there, that's also incredibly easy.
• Significantly faster run-time computations. Have a complex object-finder? .NET is much more forgiving.
• Built in multi-threading capabilities. Want to setup multi-threading for more advanced scripts? 1 line and done.
• Want bots to work together on a task, each doing portions of the work (multi-teaming bosses or team games)? Significantly easier. (This is perfectly possible in Simba scripts today, it's just fairly difficult in comparison).

Disadvantages:

• Requires a decent re-write. However, plugins shouldn't be that awful so long as they were written truly as plugins. And SMART ports just fine. Thanks to open-sourcing, could be a small group effort.
• Probably needs some high-level approval from admins to even take advantage of the Simba name, otherwise would just be a different color bot that happens to use SMART… and our plugins… with similar code-bases.
• Pointless if noone would use it.
• Probably more… Will edit as people point them out.

Go for it!

I love the idea, but I think few people will help you because of a lack of time, knowledge and/or motivation. .NET simba would be so cool though.

i support it

I always wondered why Simba was written in Delphi, it seems .NET(C++/C#) or Java are a lot more popular

Ooh ooh, I know a name! How about Nala?

From: Frement
Ooh ooh, I know a name! How about Nala?

where did i hear that before… oh wait ;)

sounds like a good way of future-proofing simba

Seems like a neat idea but I guess the main barrier is still that the amount of people who can help or script with it is a lot smaller.

From: Kevin
What would everyone think of a version of Simba made in the .NET language - thus allowing 'scripts' to be made in .NET as well?

Advantages:

• A variety of more popular and capable languages to work in.
• Fewer language oriented bugs.
• Capable and relatively easy use of alternative IDEs.
• Faster compile times (usually not that bad today anyway).
• Compatible with Mac, Linux, and Windows (.NET was made open-source a couple weeks ago http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
• Possible to easily pre-compile scripts (This may be a negative depending on community thoughts. Can also be built in such a way as to make this difficult - community opinions on the matter?)
• Scripts could be written in just about any language desired. If you wanted to keep scripting in PS or LAPE, then that could be made to work. If you wanted to 'script' in C# instead however, and begin taking advantages of the languages/frameworks there, that's also incredibly easy.
• Significantly faster run-time computations. Have a complex object-finder? .NET is much more forgiving.
• Built in multi-threading capabilities. Want to setup multi-threading for more advanced scripts? 1 line and done.
• Want bots to work together on a task, each doing portions of the work (multi-teaming bosses or team games)? Significantly easier. (This is perfectly possible in Simba scripts today, it's just fairly difficult in comparison).

Not to discourage you, just wanna pick on a couple of statements:

• Simba can use compilers for most languages, wrap the compiler/interpreter in a DLL, load it, integrate it (..). There is no major issues at that front.
| That should cover most of the "advantages" mentioned, as most was just about language-implementations.
| There has for example been a project which aimed to integrate python in Simba, and a project to use a pascal interpreter written in C.

• There are plugins written for Simba (Lape) that gives you that simple multi-threading functionality.

• "Significantly faster run-time computations", you say.. but any Lape script can as always be extended with native libs (plugins). Such plugins are easy to write for most users as they can be written in pascal as well, there are only minor differences in the pascal-versions which you need to learn.
| Also as mentioned Simba can use just about any interpreter, as long as it can be wrapped in to a dll.
| And the most useful finder methods (and related methods) is added dir. to Simba, so their execution-time is pretty optimal..

This sounds great, but also seems like a lot of work. Do you have a team that will be able to make it happen?

do I get bonus points for learning C#?

So.. Not sure if this is just a hypothetical or are people actually working on it?

Probably just an idea.

From: akarigar
So.. Not sure if this is just a hypothetical or are people actually working on it?

From: masterBB
Probably just an idea.

It was an up-front idea to see how the opinions went and I was debating doing it… I have since received notification that something of this is actually almost completed already from another developer at our forums. It's just up to porting over SRL itself from the sounds of it.

From: Kevin
It was an up-front idea to see how the opinions went and I was debating doing it… I have since received notification that something of this is actually almost completed already from another developer at our forums. It's just up to porting over SRL itself from the sounds of it.

There have been several attempts to completely rewrite MML (Simba's core - recreating the actual UI is a non-issue, obviously) in C, C++, and other languages, I'm sure. I think the biggest advantage would be that Pascal definitely has it's share of oddities, but nothing that's a complete showstopper. Keep in mind that Simba itself was a complete rewrite and it took quite a few people quite a lot of time to get it where it is now. To just throw all that away seems like a mistake, imo. There's nothing that awful about MML, and it supports most everything people need it to (multithreading is really the only thing that people request, but I don't think it's necessary personally), and there's nothing about MML that makes it impossible to add any features if people spend some time with it.

Anyway, I'm curious about how you worded this post I'm replying to. Do you mean someone here is actively working on a complete rewrite of MML with some .NET language? If so, I'm curious. I suppose now would be a good time for something like that with Microsoft releasing so much .NET stuff for free with plans on Linux and Mac OS X support (and just having Mono improved). However, I still think it's an extreme amount of work for not much gain.

So my point is that you should look into libMML! It doesn't "fix" all the problems you mentioned, but it would allow people to write scripts in whatever language you want (all .NET languages would work fine, including F#, and I've wanted to see a functional language being used for scripting for awhile)! I just recently pushed some more updates to libMML and pyMML the other day, which you can read about here. I've been busy with the holidays and everything since then, but I do plan on finishing more, adding tests and documentation, etc. soon. If you want to help, I'd be more than happy to help you get involved!

From: i luffs yeww
There have been several attempts to completely rewrite MML (Simba's core - recreating the actual UI is a non-issue, obviously) in C, C++, and other languages, I'm sure. I think the biggest advantage would be that Pascal definitely has it's share of oddities, but nothing that's a complete showstopper. Keep in mind that Simba itself was a complete rewrite and it took quite a few people quite a lot of time to get it where it is now. To just throw all that away seems like a mistake, imo. There's nothing that awful about MML, and it supports most everything people need it to (multithreading is really the only thing that people request, but I don't think it's necessary personally), and there's nothing about MML that makes it impossible to add any features if people spend some time with it.

Anyway, I'm curious about how you worded this post I'm replying to. Do you mean someone here is actively working on a complete rewrite of MML with some .NET language? If so, I'm curious. I suppose now would be a good time for something like that with Microsoft releasing so much .NET stuff for free with plans on Linux and Mac OS X support (and just having Mono improved). However, I still think it's an extreme amount of work for not much gain.

So my point is that you should look into libMML! It doesn't "fix" all the problems you mentioned, but it would allow people to write scripts in whatever language you want (all .NET languages would work fine, including F#, and I've wanted to see a functional language being used for scripting for awhile)! I just recently pushed some more updates to libMML and pyMML the other day, which you can read about here. I've been busy with the holidays and everything since then, but I do plan on finishing more, adding tests and documentation, etc. soon. If you want to help, I'd be more than happy to help you get involved!

Yes, that is exactly what was meant. And I personally view the IDE options as a great improvement for what I've seen. But, to be fair, it's hard to complete with Visual Studio considering it's long paid history from such a large company.

As for the movement of .NET to Linux and Mac OS, it sounds like they'll be ported over quite soon - and .NET 2.0 already was to be fair, so it's mostly the upgrades to 4.5 (and the upcoming 5).

.Net is crap. Native code is much faster then it.

From: CynicRus
.Net is crap. Native code is much faster then it.

While technically true, it's only slightly faster in some situations. The optimizations in .net are amazing.

But then again, obvious troll is obvious :). It's been a while since I've seen you in the Skype chat, how've you been?

From: CynicRus
.Net is crap. Native code is much faster then it.

Same can be said for Java.. and python. Neither of which is native.. DotNet has the advantage of having better scripting capabilities than Lape, by a long shot. I'm sure Roslyn will outperform Lape in every situation.

Personally, I don't see why SRL keeps caring for Linux or Mac when Simba doesn't even work properly on it (and almost not at all for Mac).. For a long time, it was even neglected from the BuiltBot and probably still is..

From: Brandon
Same can be said for Java.. and python. Neither of which is native.. DotNet has the advantage of having better scripting capabilities than Lape, by a long shot. I'm sure Roslyn will outperform Lape in every situation.

Personally, I don't see why SRL keeps caring for Linux or Mac when Simba doesn't even work properly on it (and almost not at all for Mac).. For a long time, it was even neglected from the BuiltBot and probably still is..

I certainly agree that anything .NET puts out will be faster than Lape, but I really don't think speed is much of an issue anymore. Lape is fast enough for what it's used for.

As far as Linux and Mac support go, I certainly would enjoy seeing some work done in those areas. I personally have no need for either (I don't use Simba anyway), but I think it would help people approach Simba. I know Windows users far outweigh Linux or Mac users, but it obviously wouldn't hurt.

From: Kevin
Yes, that is exactly what was meant.

Well if you'd like, I could help you get into working on libMML or help you learn how to get it working in some .NET language! It's really not as hard as it may seem. Since I mentioned libMML in this thread I pushed both DTMs and OCR functions in libMML to my personal repo. Most of it is actually in the main Simba repo on GitHub! I'm close to having everything in libMML, I just need to clean everything up, add tests, and a few other small pieces. But for the most part, as long as you do things exactly correctly, almost everything works!

From: i luffs yeww
I know Windows users far outweigh Linux or Mac users, but it obviously wouldn't hurt.

Well if you'd like, I could help you get into working on libMML or help you learn how to get it working in some .NET language! It's really not as hard as it may seem.

It would hurt because you've got to write code for "both" platforms since the languages themselves (with the exception of a few) aren't entirely platform agnostic.

I know the difficulty level.. but I'm not interested in porting anymore (unless Dgby wants to continue). Dgby was my coding partner, but someone mentioned there's no point porting it since libMML can be compiled to a dll and loaded from whatever language (C being the base). Something like that.. Something to that effect iirc. I'm sure Simba ships with a libmml.dll

Myself and Dgby at one point (still good code):
https://github.com/Brandon-T/CMML

Myself at one point (crappy code now [with the exception of a few files]):
https://github.com/Brandon-T/PurelyCPP

From: Brandon
It would hurt because you've got to write code for "both" platforms since the languages themselves (with the exception of a few) aren't entirely platform agnostic.

I know the difficulty level.. but I'm not interested in porting anymore (unless Dgby wants to continue). Dgby was my coding partner, but someone mentioned there's no point porting it since libMML can be compiled to a dll and loaded from whatever language (C being the base). Something like that.. Something to that effect iirc. I'm sure Simba ships with a libmml.dll

Myself and Dgby at one point (still good code):
https://github.com/Brandon-T/CMML

Myself at one point (crappy code now [with the exception of a few files]):
https://github.com/Brandon-T/PurelyCPP

I was just talking about CMML to Dgby. As of late, I'm the only person actively working on libMML as far as I know. I like the idea of porting MML to C (or C++, either would be nice). Especially now that I've been looking at Lua and really enjoying it - I think Lua would be a great language to script in for this communities purposes. But I think libMML will suffice for now. It's much less work and the end result is almost identical.

https://code.google.com/p/python4delphi/ I just leave it here:)

From: i luffs yeww
Well if you'd like, I could help you get into working on libMML or help you learn how to get it working in some .NET language! It's really not as hard as it may seem. Since I mentioned libMML in this thread I pushed both DTMs and OCR functions in libMML to my personal repo. Most of it is actually in the main Simba repo on GitHub! I'm close to having everything in libMML, I just need to clean everything up, add tests, and a few other small pieces. But for the most part, as long as you do things exactly correctly, almost everything works!

In the end, as I've discovered exactly what I was considering is already almost complete, I probably won't pursue the libMML path, and instead may help port SRL to dll form :P

From: CynicRus
https://code.google.com/p/python4delphi/ I just leave it here:)

I'd love to see us be able to use python with the Simba IDE, I have always wanted to learn another scripting language besides lape/pascalscript. Except python is actually used in the real world

From: Kevin
In the end, as I've discovered exactly what I was considering is already almost complete, I probably won't pursue the libMML path, and instead may help port SRL to dll form :P

Oh, I was a bit confused when you said "yes" to my post which had multiple questions/speculations.

I'm curious about what/who you're talking about that is porting MML to some .NET language. The only few people I know who have put in the effort for something like that either gave up because it's a bit too much work for not much gain or are inactive now. I'd love to know more about it, though!