Restarting from Scratch!

[MyndFyre]

Well folks, I'm restarting my bot API from scratch.  Why?  It has some limitations that I'd like to get past.  I just couldn't do it with the current setup.

I'm going for both high flexibility and high performance.  The flexibility is going to come from self-describing connection mechanisms, that can (I'm planning) be as diverse as BNCS, MSN, Y!IM, AIM, IRC, etc.  These can be provided via runtime-loadable assemblies.

I also want to get rid of my incoming and outgoing buffers and just use the types built into the .NET framework -- specifically, MemoryStream and BinaryWriter/BinaryReader.  They'll be encapsulated, perhaps in a derived class.

Another planned addition is priority queues for incoming and outgoing packets -- for instance, a /ban command might get the SystemCritical priority from the command processor, whereas the packet to retrieve the advertisement might get the Low priority.  Alternatively, incoming login events might get High priority where the PING event gets low priority.

At this point, I'm looking for architecture, not feature suggestions.  Code reuse is not a major factor, so be creative if possible

Thanks!

[Mephisto]

If this is just the bot in general and how you're going to code it:  Create a major base class which will not do anything particuarily important for the bot, but perhaps universal error exception functions, variables and structures which keep track of the bot data, etc.  Then from there branch off that class and create maybe 1 - 3 classes that divide the bot up (such as Connection, GUI, UI, etc.).  Then from there branch off as necessary into sub-classes of those classes to make it nice and organized.  Then in your main thread you can polymorphically call all of the functions and access the necessary data and what not and it'll be nice and organized.  You can of course from there, easily expand, in an OO manner, your program to be more complex and powerful and have more features.  The main idea in my suggestion is structuring your program so that each major part of the bot has its own class which derives from a major base class, and then from those classes have many sub-classes that have major parts to do with that part (for instance, the Connection class may have classes PacketBuffer and BnetHashing, etc.).  You will have to play around with the inheritence heirarchy probably, and it may or may not turn out exactly how I described above for whatever reasons.  But give it a try if you want.  It's what I did for my bot and it's great when it comes to updating it since it's so clean and organized.

Question though, what do you mean by yout Bot API?

[MyndFyre]

Question though, what do you mean by yout Bot API?

The mechanisms by which my bot connects to Battle.net, processes data, and handles plugins is what I mean by my API.  The most recently-published version is available here in MSDN-style help format.

Ideally, the connections API and the main, base code that I produce (the BNCS, BNLS, RCRS, local hashing, and BotNet connections) will be encapsulated such that someone who wants to make a bot can pretty much drop in my assembly, derive from a Settings class, hook into some events, and go.

The other stuff is there for additional features.  But yes, that's what I mean by my bot's API.

[OnlyMeat]

I'm going for both high flexibility and high performance.

If you want high performance i suggest using a language that is'nt  interpreted at runtime i.e c/c++, i do agree .net has great  flexibility because im using vb.net/c# and it's excellent but in the end if you want high performance software you are going to have to code it in asm/c/c++.

On the other hand if you like the ease of .net's CLR then maybe consider using mfc it makes coding simple for GUI based apps.

My personal preference is a backend coded in asm/c++ with a mfc front end.

[iago]

C# and Java really aren't that much slower than compiled code.  Some of Java's libraries (for instance, AWT/Swing, and probably some others) are horribly coded, and run like shit as a result.  But JIT code and interpreted code really aren't that much slower.  I would imagine that C# is much the same as Java in terms of performance.

[OnlyMeat]

C# and Java really aren't that much slower than compiled code.  Some of Java's libraries (for instance, AWT/Swing, and probably some others) are horribly coded, and run like shit as a result.  But JIT code and interpreted code really aren't that much slower.  I would imagine that C# is much the same as Java in terms of performance.

Well it's certainly a performance hit translating byte codes to machine code, no one can deny that so i repeat what i said if you want maximum performance you have to write in asm/c/c++ it's that simple.

[iago]

But with direct machine code, you can't do inline optimizations based on current data.  For example, in C++, if you have a loop that does nothing a million times, it'll take a lot of time.  In Java (and probably in C#), it'll be skipped.  Better performance!

[OnlyMeat]

But with direct machine code, you can't do inline optimizations based on current data.  For example, in C++, if you have a loop that does nothing a million times, it'll take a lot of time.  In Java (and probably in C#), it'll be skipped.  Better performance!

A compiler can only be expected to do so much, if you write poor code then it's the programmers fault.

It's not the compilers responsibility to remove poor coding practises, although modern c++ compilers make significant optimizations even to poorly coded work.

Also making optimizations based on current data could you explain further i have little knowlege of this, from what it sounds like i cant see how you can optimize any further than compiling base code as program data is variable i.e it can change rapidly so running a loop one time might not do anything but calling another time might require some sort of complex operation.

[drivehappy]

Well it's certainly a performance hit translating byte codes to machine code, no one can deny that so i repeat what i said if you want maximum performance you have to write in asm/c/c++ it's that simple.

Maximum performance, yes. But if you really don't want to spend 4 times the time to code and debug, you're better off with C#. The performance for this sort of project is negligable, even managed direct3d applications run nearly the same (~5% hit).

[OnlyMeat]

Well it's certainly a performance hit translating byte codes to machine code, no one can deny that so i repeat what i said if you want maximum performance you have to write in asm/c/c++ it's that simple.

Maximum performance, yes. But if you really don't want to spend 4 times the time to code and debug, you're better off with C#. The performance for this sort of project is negligable, even managed direct3d applications run nearly the same (~5% hit).

So thats why no high end graphics games are written in interpreted languages?

[MyndFyre]

If you want high performance i suggest using a language that is'nt  interpreted at runtime i.e c/c++

Learn what you're talking about.  .NET code is compiled just-in-time, once.  The native-code assembly is then cached until it is changed; in a release build, it doesn't change frequently.

I'm sorry to come down on you so hard, but I hear that all the time, and people just don't get it.  Java bytecode is interpreted at each pass; .NET code is interpreted once.

[edit] Can a moderator please split off the posts in this thread that are unrelated to this topic -- the topic being an effective architecture? [/edit]

[UserLoser.]

What's BNLS RCRS?  Or do I have the wrong idea on what it is?

[OnlyMeat]

If you want high performance i suggest using a language that is'nt  interpreted at runtime i.e c/c++

Learn what you're talking about.  .NET code is compiled just-in-time, once.  The native-code assembly is then cached until it is changed; in a release build, it doesn't change frequently.

I'm sorry to come down on you so hard, but I hear that all the time, and people just don't get it.  Java bytecode is interpreted at each pass; .NET code is interpreted once.

[edit] Can a moderator please split off the posts in this thread that are unrelated to this topic -- the topic being an effective architecture? [/edit]

Dont worry about it you are not coming down on me hard you just agreed with my statement that it's an interpreted language, even if it's compiled JIT once it's still interpreted i.e interpreted  = non native just to keep it simple for you.

And this is also related to your original question in that it's an architectural issue selecting a language based on it's qualities and you also said you wanted fexibility and high performance and i therefore suggested a more appropriate language for high performance applications.

If you dont like the answers dont ask the questions

[Warrior]

What's BNLS RCRS? Or do I have the wrong idea on what it is?

RCRS stands for Remote Check Revision Server, its a plaintext server iago wrote for JavaOp and others to use its pretty neat.

[iago]

What's BNLS RCRS? Or do I have the wrong idea on what it is?

RCRS stands for Remote Check Revision Server, its a plaintext server iago wrote for JavaOp and others to use its pretty neat.

It's an opensource server to do the versioning for logon so you don't need hashfiles or version information locally.  It doesn't (and I refuse to) touch cdkeys and  passwords, because that's just asking for trouble.  It's also decentralized, I have two stable servers, and anybody can run their own, so no chance in them being taken down.

In any case, I don't see what that has to do with this thread.