I'm going to begin a project called 'BasicOP' which is going to be designed almost entirely like JavaOP; entirely plugin oriented. If anyone is interested in helping with this project give me a holla!! On another interesting side note: I will be making this entirely native vb -- i.e. no third party controls/libraries will be used and everything will be done locally via visual basic 6.0
Me and a few friends have got some basic GUI stuff implemented as well as most of the plugin code that'll be used. It will essentially expose the same kind of functions and callbacks as JavaOP does, because this will save a lot of time design wise i.e. not reinventing the wheel! thx again iago :P
sure
I was thinking of the same thing, making a 'plug-in bot'. I was about to post asking the best way to go about doing plugins.
I dont know about you but i planned on having pretty much everything as a plugin. - Commands etc.
Well if you're still looking for a hand or something let me know.
BasicOp sounds much better then the name i had in mind.... "plug-in bot" ;D
PM Me
If you program the exact same API, or really close, I'd be glad to port some of the plugins over.
i wouldnt mind designing the interface, as I know what the average user would want to see and etc.
And I also wouldn't mind designing a site and some other things
AIM: SuperKenshinX
MSN:
[email protected]
Quote from: Clan CDH on July 23, 2006, 10:43 PM
i wouldnt mind designing the interface, as I know what the average user would want to see and etc.
And I also wouldn't mind designing a site and some other things
AIM: SuperKenshinX
MSN: [email protected]
What would be the point? It's an operator bot, it's not supposed to be visually appealing anyway.
Quote from: Networks on August 01, 2006, 01:26 AM
Quote from: Clan CDH on July 23, 2006, 10:43 PM
i wouldnt mind designing the interface, as I know what the average user would want to see and etc.
And I also wouldn't mind designing a site and some other things
AIM: SuperKenshinX
MSN: [email protected]
What would be the point? It's an operator bot, it's not supposed to be visually appealing anyway.
Well the bot is plugin oriented so it could either be used for chatting or moderation.
Quote from: Networks on August 01, 2006, 01:26 AM
Quote from: Clan CDH on July 23, 2006, 10:43 PM
i wouldnt mind designing the interface, as I know what the average user would want to see and etc.
And I also wouldn't mind designing a site and some other things
AIM: SuperKenshinX
MSN: [email protected]
What would be the point? It's an operator bot, it's not supposed to be visually appealing anyway.
An operator bot could always have "two parts". A graphical interface, and a command-line/terminal interface. So the GUI part of the application could be where things are configured and done in a visual manner, this is easier on the user I would assume, and the command-line/terminal part would be where I/O goes, this part should be here of course so the application does not crash. The command-line/terminal part would of course be its own application. It's an idea I've considered, if I ever decided to write a Battle.net client one of these days.
PS. I needed my 900th post :).
Quote from: Yegg on August 01, 2006, 12:58 PM
Quote from: Networks on August 01, 2006, 01:26 AM
Quote from: Clan CDH on July 23, 2006, 10:43 PM
i wouldnt mind designing the interface, as I know what the average user would want to see and etc.
And I also wouldn't mind designing a site and some other things
AIM: SuperKenshinX
MSN: [email protected]
What would be the point? It's an operator bot, it's not supposed to be visually appealing anyway.
An operator bot could always have "two parts". A graphical interface, and a command-line/terminal interface. So the GUI part of the application could be where things are configured and done in a visual manner, this is easier on the user I would assume, and the command-line/terminal part would be where I/O goes, this part should be here of course so the application does not crash. The command-line/terminal part would of course be its own application. It's an idea I've considered, if I ever decided to write a Battle.net client one of these days.
PS. I needed my 900th post :).
What in the
fuck does any of that mean? I've read it over four times and still don't get it.
Quote from: Warrior on August 01, 2006, 05:23 PM
What in the fuck does any of that mean? I've read it over four times and still don't get it.
Which part do you not understand? I'll word it differently.
Have two applications that work together. One has a GUI, the other without (it is command-line). The GUI application can be used for anything that
could make the life of the user
easier. Making it easier as in having the GUI application allow the user to modify a database of some sort for the bot, change the configuration, anything similar to this. When it is time to connect, the GUI application could run the command-line program and the command-line program would load in the current bot files (any database needed, configuration, etc.) and connect to Battle.net. This command-line program would be what interacts with Battle.net, while the GUI application is used stricly for changing the contents of the bot's files. If it is necessary, the two applications can communicate to one another using whatever means possible depending on the OS (Linux has pipes, Windows has its methods, I am unsure what those are but they must exist).
Quote from: Yegg on August 01, 2006, 07:25 PM
Quote from: Warrior on August 01, 2006, 05:23 PM
What in the fuck does any of that mean? I've read it over four times and still don't get it.
Which part do you not understand? I'll word it differently.
Have two applications that work together. One has a GUI, the other without (it is command-line). The GUI application can be used for anything that could make the life of the user easier. Making it easier as in having the GUI application allow the user to modify a database of some sort for the bot, change the configuration, anything similar to this. When it is time to connect, the GUI application could run the command-line program and the command-line program would load in the current bot files (any database needed, configuration, etc.) and connect to Battle.net. This command-line program would be what interacts with Battle.net, while the GUI application is used stricly for changing the contents of the bot's files. If it is necessary, the two applications can communicate to one another using whatever means possible depending on the OS (Linux has pipes, Windows has its methods, I am unsure what those are but they must exist).
Good, that's much better. Now I think it's a little overkill when you can just implement a plugin system instead of having to deal with message passing and all of that other bullcrap that VB shouldn't even be using.
If anything just implement proper error handlers and any exceptions which occured can be handled and the proper action taken. Seperating an application from another isn't going to solve the problem if the GUI for example hangs, it would probably starve the other App waiting to recieve notification and effectively probably hang them both.
Do what I did with Network's opbot. He made a tiny little UI for it, for loading plugins and monitoring vital stuff. I wrote a plugin for it that gave it a full-fledged chatbot UI.
Quote from: Joex86] link=topic=14864.msg156473#msg156473 date=1154637079]
Do what I did with Network's opbot. He made a tiny little UI for it, for loading plugins and monitoring vital stuff. I wrote a plugin for it that gave it a full-fledged chatbot UI.
An idea you stole from me. Bastard.
Here's An Idea:How bout you build a bot that connects to bnet via hashing or bnls and also make it totally scriptable so therefore the people of battle.net can accually put there ideas into the bot rather then yours!
I already made that (http://www.liquid-server.org/sources/EmptyChat2/).
shoulda posted this uhm when i replyed the first time... n its not to out dated since someone else posted couple days ago =)
Looks like, everyone that replyed got the subject wrong, everything will be coded in the bot, sadly, i don't think vb6 could handle such a thing or well, it would actually be one huge project, that'll be some lagg when compiling, so if you wont use any external ocx/activex blah blah blah ect, would be you elimitating API's aswell? =) , and im guessing no bncsutil.dll, bnetauth.dll hmm going to write your own checkrevision functions in vb? =\
checkrevision in vb taking 20 seconds for war3 for the loss.
Quote from: l2k-Shadow on September 08, 2006, 02:34 PM
checkrevision in vb taking 20 seconds for war3 for the loss.
Fix it then ;p
Hahaha, that's horrible! I read something about unrolling a loop in there making it go faster (the processor can just move forward instead of having to go back), so I wonder if that'd work well. Look in MBNCSUtil's code for an example.
Quote from: Joex86] link=topic=14864.msg157737#msg157737 date=1157892624]
Hahaha, that's horrible! I read something about unrolling a loop in there making it go faster (the processor can just move forward instead of having to go back), so I wonder if that'd work well. Look in MBNCSUtil's code for an example.
Unrolling a loop is to keep code caches effective (the L1 cache of a processor, for example). Repeatedly jumping backwards can cause the cache to miss. I took the idea from BNCSUtil, although if you look at the original BNCSUtil source code, shadypalm used macros to simplify the code much more than I could do in C#.
It would never cause a 20 second delay. :P