Hey guys...
I've finally posted a new release of my bot. Alpha 4 -- it is PRE-beta. It takes up quite a bit of RAM (about 50mb), but it really varies. I think as it runs the memory reqs go down. That's been my experience as I've been using it on my computer.
I'd like some suggestions and comments on what isn't working. I noticed that I'm not responding to two event types (ServerBroadcast and, IIRC, ChannelRestricted). As it is, though, I believe that things are working generally well, aside from the initial run slowness (.NET compilation) and that stuff. Before I release Beta 1, I'm going to start running FxCop and Application Center Test before publishing.
If anyone has comments, and it's not too much trouble, bug reports and that could be posted on my forums (http://forum.armabot.net/).
The website for downloading and all that is http://www.armabot.net/
Thanks all!
very nice looking bot from the screen shots!
WOW Very Very Nice. One of the best bots ive ever seen. Very nice job.
I like the WAR3 profile view :D
Quote from: Falcon[anti-yL] on June 25, 2004, 10:57 PM
I like the WAR3 profile view :D
yeah that had to take alot of hard work!
You should write a BinaryChat plugin which adds the Warcraft III profile things so bots which support the BinaryChat plugin API can make use of it. Shouldn't take long to copy dialog and send/receive handling over, while using Yoni's EmptyPlugin as compile-ready template.
I gte a problem when i try to run it. "The application failed to initilize properly (0x0000135)". Any help.
Do you have the .NET framework?
Not simple enough. I like bots that are bare, and straight forward.
Quote from: warz on June 26, 2004, 10:50 AM
Not simple enough. I like bots that are bare, and straight forward.
And don't eat up twice as much RAM as the starcraft game client :P
Quote from: The-Rabid-Lord on June 26, 2004, 07:48 AM
I gte a problem when i try to run it. "The application failed to initilize properly (0x0000135)". Any help.
http://www.armabot.net/sysreq.aspx
This topic is in the wrong forum. This is Battle.net Bot Development, not releases :)
/me just had to say that :P
Quote from: UserLoser. on June 26, 2004, 05:15 PM
This topic is in the wrong forum. This is Battle.net Bot Development, not releases :)
/me just had to say that :P
I checked with Spht first, to make sure it would be allright.
The runtime error is that you need to get the .NET Framework 1.1.
Quote from: UserLoser. on June 26, 2004, 05:15 PM
This topic is in the wrong forum. This is Battle.net Bot Development, not releases :)
/me just had to say that :P
As long as the point of thread is to get input to help "develop" the bot, then it's fine.
"Here is my bot, download it" is an advertisement and is not allowed.
Excellent job so far!
I have been interested in learning C# so I think I will start messing around with your plugin system.
Holy crap. That is the best I have ever seen or will ever see...
Quote from: Hitmen on June 26, 2004, 11:01 AM
Quote from: warz on June 26, 2004, 10:50 AM
Not simple enough. I like bots that are bare, and straight forward.
And don't eat up twice as much RAM as the starcraft game client :P
Like I said, I believe that's due to the Just-in-Time compiler eating it all up at the first run. The bot's been running for about 30 hours and at the moment is only consuming 13mb of RAM (which is a lot less than the 50mb it was using yesterday when I first launched it on this computer).
Thanks for the support. Here's some more info on the plugins, since Tuber mentioned that he wanted to play with my system....
I'm very displeased with what is included in the PluginBase class. Since ArmaBot plugins should (theoretically) be only used in ArmaBot, it isn't a problem if I allow the user to add references to the configuration options, right? So, that's what I'm going to do. I'm going to document the other assemblies and also add references to the current profile's configuration profile for each assembly, in a similar manner to the way that your ASP.NET pages work.
When you create an ASP.NET page, you're also creating a class that derives from System.Web.UI.Page. Page defines certain members such as Server (an HttpServerUtility object), Session (HttpSessionState object), Application (HttpApplicationState object), and so on. Those of use who have used traditional ASP regard them as simply script objects that are provided by the runtime; however, they aren't, and it will work similarly in the Beta 1 plugin.
Expect the PluginBase class to have the same methods that it has now, but add a whole lot. Code developed for Alpha 4 should work with beta 1 provided that it is recompiled. Hopefully. ;-)
You should support BCP. Other bots stupport BCP already. Let's try and have a common plugin format? It'd be so cool.
Keep in mind that the way he does things are vastly different from a BCP Plugin and so supporting those will be sort of hard I think. Your bot looks nice Myndfyre, if I wasn't avoiding C# id try it out :p
Quote from: Myndfyre on June 27, 2004, 03:07 AM
Quote from: Hitmen on June 26, 2004, 11:01 AM
Quote from: warz on June 26, 2004, 10:50 AM
Not simple enough. I like bots that are bare, and straight forward.
And don't eat up twice as much RAM as the starcraft game client :P
Like I said, I believe that's due to the Just-in-Time compiler eating it all up at the first run. The bot's been running for about 30 hours and at the moment is only consuming 13mb of RAM (which is a lot less than the 50mb it was using yesterday when I first launched it on this computer).
Looks to me like C# isn't much better as far as speed and memory consumption compared to Java. I am not blown away by C# yet, but you have definitely put a lot of quality work into your bot.
Quote from: Arta[vL] on June 27, 2004, 10:18 AM
You should support BCP. Other bots stupport BCP already. Let's try and have a common plugin format? It'd be so cool.
I'm working on that, but it's a way off. Part of the trick is knowing what functions to call; the standard method of calling P/Invoke on a BCP would be to put the DLL file in at compile-time:
[DllImport("EmptyPlugin.bcp")]
public static extern void DoSomething(/*...*/);
In this case, it will work only for EmptyPlugin. I posted the first BCP callback functions in another post, and it's a planned feature, but I'm not sure if it will make it into version 1. Definitely in by version 2. :)
I'm going to keep my current plugin system, though. .NET will work fastest with .NET; I'd have unnecessary transfer in between .NET and unmanaged code eating clock cycles if I did only BCP.