Thoughts about multi-botting

[Hybrox]

Hey there,
I'm planning a new personal project of mine and had some thoughts about it, which I would like to share and discuss with you guys.

All the thoughts are only for a gather-bot, no leveling etc.

Every bot seems to be using the same concept, one instance of the bot for one instance of Wow, but why is that ?
Nowadays every pc is able to handle big application which are using more than 1 GB Ram etc.

My thought was to make a bot that handles everything in one client, that would reduce the overall ram usage by a great amount.

Multi-threading is a pretty easy subject if you're using c# (compared to c++ etc.).

The only limitations I see are the Mesh generation / holding of the mesh files, which could by solved by using an external App (maybe on another server) which calculates the path and only sends you the waypoints.

Sure, it would be a very complex system you would have to make, but it should work in theory, right ?

I'm not very experienced with bot developing (working as a programmer for a while tho), so please tell me, if I underestimate the ram usage of an bot.

What do you guys think about this?

[Frosttall]

First of all: Do you speak about writing a clientless bot or an application which is able to attach to various WoW-Instances at the same time?

[Hybrox]

Originally Posted by Frosttall

First of all: Do you speak about writing a clientless bot or an application which is able to attach to various WoW-Instances at the same time?

A Clientless bot would be a mess to make with the new opcode randomization, so I've thought about the second

[Frosttall]

Opcode randomization wouldn't be a problem - pattern scan for the win.. But many other things would cause problems.. Whatever:

The reason everybody wants to keep one application for one instance is pretty simple: There are too many cases the program could crash and everything, really everything will have to be completely threadsafe and instanced.

Another one is pretty simple: C# gets pretty much trouble with handling many threads, objects and the GC. Just try to start 500 Threads doing almost nothing - your computer will be close to unresponsible. Having this amount of threads splitted over various applications makes it easier for the Windows-Kernel and the GC to split the CPU-Time. I'm currently running 1700 threads on my system in 'almost' idle state, but it's not slow at all. It would be with 500 threads by a single C# application.

I'm very sure having 100 processes á 5 threads wouldn't lag at all.






Another question: Why do I currently run about 60 chrome.exe? Why didn't Google put everything into a single process like Firefox did?
The answer is exactly the same: Only a part of the programm will crash instead of the whole one - even tho it's actually only a small page or plugin out of my 40 tabs.