Putting all game objects into an array of gameobjets.

[Cypher]

The mutex is used because one thread in his program will be accessing the list while another will be writing to it. Bad things happen if both happen at the same time.


And, again, because I'm apparently really, really bad at explaining things today, I meant from a code-writing standpoint, not from memory-write/access. It's easier and faster to add features to a class and access members of a class, in my opinion, than a structure. I know that classes are not faster than structures--though to what degree that is true in C#, I'm not actually sure--but the speed difference is measured in nanoseconds, these days, so the 'quicker' I'm talking about is time spent typing lines of code.

I know WHY he wanted the mutex but my whole point is that it is pointless because multiple threads is more of a 'gimmock' than they are useful in a fishbot scenario. Multi-threaded bots are more of a mess than they're worth unless you know what you're doing. Especially with injected bots where you need to worry about TLS and hooking WoW everywhere it accesses TLS if you want to achieve concurrency. The fact that you have to lock pretty much all accesss to the linked list pretty much negate any performace increase you'd get anway.

I use a single thread in my fishbot to loop through the linked list until I find the object I need then act upon it. Multi-threading isn't worth it unless you have a good reason AND you know what you're doing. A fish-bot isn't what I'd call that.

Yes, the speed difference is negiligible for data types (class v struct) but not for creating repeated copies of the linked list. At which point you may be subject to cache misses, page faults, etc, along with the fact copying said memory is pointless to begin with.

EDIT: I should clarify my stance on threading. One thread for the 'bot' and one for the 'gui' is fine, but multiple threads for the 'bot' component seems silly for something so simple. It's not like you're using complex logic and navigation systems etc, its a simple fishbot.

[Xarg0]

Cypher is right, a thread that continally reads data out of WoW is a waste of resource since you don't need the hole Linked List at any time, you'll just need parts of it and reading them from the memory on demand is way better than having a full copy of the WoWObjects.
For example your fishingbot casts Fishing, now we need the Posisiton of the Fishing Bobber, we loop through the ObjectList until we find the Bobber and Calculate it's Screen Coordinates, this would take just as much time as walking through a copy of the WoWObject List, so there's no point in having a second thread to read data out of WoW, yet it's a good Idea to have Class to handle access of the WoWObjectList to make your code look cleaner.

You'll only need multi threading for your gui, so It doesn't lock up when you press a button, even a WoW Farming Bot wont need more than one bot thread, for example it'd make no difference if you use a thread for the bots current action and another thread to check the bots current state (in fight, out of fight, looting) cause a state check wont take much time you can do it in the fighting thread. An easy way to create a bot that reacts to the stuff that happens around it is to decide after every aktion what to do next, like Openbot it calls a pulse function that does an aktion, after the function returns Openbot decides what to next or what Pulse Function to call next (some functions are called in a static amount of time).

You could also create a gui that works good without threading, but you'd need to check for user input every now an then within every function of your process, threading is just a method to make your code look cleaner and for better priorty management, it'd be hard to check every 50ms for user input without threading since you'd need to know how long your code needs to execute, so use threading only when you need to be shure that certain code gets executed no mather what you'r programm is currently doing.

[Nesox]

Actually i rewrote my bot to just use one thread with ReadProcessMemory in it work's good altho i still use a list to find the fishing node i just loop through all objects to find the bobber evry time i cast i update it again so it doesnt get outdated

my bot isnt as complex atm it just fishes but ill add up with all other tradeskills soon. then i might consider not using list's it takes about 30-100 ms to copy the entire linked list so right now i dont care but i think its nice for finding herb's mining nodes w/e :drool:

[Cypher]

30-100 ms???

Are you copying the entire objects or just pointers to them?

Either way I don't see the point, but meh.

[KOS0937]

hmmm you might want to recheck your code (unless you are using a crappy interpreter language like java) because my code - copying every object into an own array - needs about 5-20ms max to do exactly that..... and it's pretty crappy code so far ^^

[Nesox]

30-100 ms???

Are you copying the entire objects or just pointers to them?

Either way I don't see the point, but meh.

i just copy the guid base adress and type

Edit: It takes about 16-23ms to copy the list

[Cypher]

Argh I still don't get why you even bother with the stupid copying but whatever. I give up.

[Xarg0]

omg just walk the wowobject list with readprocessmemory, you don't gain any performance by having a local copy of the wowobject list since you need to update it with read process memory >.<

And if you got real bad luck your pointers arn't valid at the time you want to read some data from wow, ofcourse you could update your list of pointers/guids before you walk it but where is the performence gain compared to just walk the list inside wow with read Process memory until you found what you need? I only see a small performence loss because of not needed ReadProcessMemory calls, normaly you don't need to walk the hole wowobject list to find what you're looking for, but to safe all BaseAdresses Types and GUIDS in your own list you'll need to walk the hole list inside of wow. And in addition to this you'll waste some ram, well that's no probleme if you've got alot of it, but when it comes to multibotting you need to save as much of it as you can.

[Nesox]

omg just walk the wowobject list with readprocessmemory, you don't gain any performance by having a local copy of the wowobject list since you need to update it with read process memory >.<

And if you got real bad luck your pointers arn't valid at the time you want to read some data from wow, ofcourse you could update your list of pointers/guids before you walk it but where is the performence gain compared to just walk the list inside wow with read Process memory until you found what you need? I only see a small performence loss because of not needed ReadProcessMemory calls, normaly you don't need to walk the hole wowobject list to find what you're looking for, but to safe all BaseAdresses Types and GUIDS in your own list you'll need to walk the hole list inside of wow. And in addition to this you'll waste some ram, well that's no probleme if you've got alot of it, but when it comes to multibotting you need to save as much of it as you can.

ok i'll rewrite try rewrite it stole 50% of the cpu i added a Thread.Sleep to the end of the loop to slow it down so now its below 10 altho memory could get a problem so ill try rewrite it