With all this me being active for around 5 posts.. I'm going to devote some time this weekend to programming some shiz and maybe releasing what I do. I guarantee it will never be finished however.
Printable View
With all this me being active for around 5 posts.. I'm going to devote some time this weekend to programming some shiz and maybe releasing what I do. I guarantee it will never be finished however.
Feel free to peer in on me. My current join.me link is below.
My Current Join Me:
The Github Repo:Code:https://secure.join.me/609-284-641
Code:https://github.com/ScriptProdigy/nF
Btw, its a zOMG client
I'll be keeping an eye out for you.
Not sure how I want to organize the packet handling class.. This is really difficult to decide upon, considering there are like 30 packets send/received before you ever show up on the map. In my old class I had the startup hard coded. Which worked 75% of the time but broke sometimes and you had to restart it. Bit of a pain, don't like it hard coded either.Quote:
Originally Posted by The Unintelligible
EDIT::
Also, I don't want to send any packets directly from the main class, it's nasty. I want the main class to be super easy to do things so I can change that fairly quickly and have a very different zOMG bot. Yah know?
My head feels weird today, so I may sound a bit off but here's my take.
I'd go with a simple black box abstraction model where all the internal work is hidden in classes or some form of abstraction and only the main logic/program flow is exposed. It's actually a pretty common style, especially in OO languages.
But for the packets specifically set up a packet stack to where different packets are handled individually (i.e. if [packet 6] do stuff, elif [packet 9] do stuff, etc). That's the cleanest way to manage/organize packets that I can think of any way.
Your setup has to be pretty cohesive to write something like this immaculately.
Yea, my current hierarchy is:
main -> GZL (GaiaZomgLib)
GZL -> GSI
GZL -> PacketHandler
where, packethandler will handle the packets, gsi handles gsi, and gzl is the middle man between main and the rest of everything.
Should open source it. Speaking of which, I'm following you and the Logicalgamers account on Github.
https://github.com/Protozoid/
I'll make the git repo tomorrow and push it.Quote:
Originally Posted by The Unintelligible
Well, that response was certainly fast. But yeah, will look out for it.
I'll bet my house nothing eventuates from this.
Quote:
Originally Posted by Artificial
It never fails. It never fails..Quote:
Originally Posted by MattSmith
To be fair, I read the title, had a quick peruse of the thread to understand its context, and came to my conclusion.
Quote:
Originally Posted by Artificial
This. Haha, I guaranteed it will never be finished. But I need something clean to impress people so who knows. Maybe I will finish this. Lol, what the fuck am I saying..Quote:
Originally Posted by MattSmith
Sounds cool, can't wait for the source, so I can actually understand some of this shit :P
EDIT: Your joinme is down
Yea I know, I was setting up the git repo and pushing the initial commit to github. Check now :PQuote:
Originally Posted by Flareboy323
This is sort of what I want, how easy it should be.
Code:####
## This is what I want to be able to do. This friggin' easy.
####
self.GZL.startup()
while(True):
Pos = self.GZL.get_position()
Sel_Mob = self.GZL.get_nearest_monster(Pos)
self.GZL.attack(Sel_Mob)
Another quick update:
I think I'm going to write a sniffer that will decode the zOMG packets automatically so I don't have to decrypt them manually anymore.. I'll do it in C# because intercepting packets should be easy in this, decoding may be difficult but we shall find out!
Overkill. Try building a testing unit instead. Preferably in Python as a class or something. A sniffer would be pointlessly unnecessary in this case.Quote:
Originally Posted by MattSmith
Something like so:
I may write it up and give you a push request. This is given I have the time though.Code:## Recover packets from established socket with allocated buffer
sock = testing.connect(server, ip)
testing.sniff(sock, 1024)
Edit: There might be a few advantages to using an external sniffer. It just seems redundant to me. Whatever you decide to go with I guess.
I have it mostly written already, just have to implement decoding the data.Quote:
Originally Posted by The Unintelligible
Eh, can't find a lib for amf so I'm going to just save the packets to a file then write the decrypting in python.
Should be pretty easy henceforth then. Comparatively that's the simple part (setting up the interceptor and such is usually considered the "hard" part).Quote:
Originally Posted by MattSmith
Wonder how you're going to top WPE/Wireshark's intuitiveness, though.
Good idea. Faster than writing an entire dedicated sniffer for sure.Quote:
Originally Posted by MattSmith
Taking a break, got to get some school work done. Wireshark is pissin' me off so I'll deal with stuff laters.
Man, it would be awesome if you could give me a runthrough of all this stuff or something, I've always wanted to make flash bots, but have never been able to :P
They aren't flash bots lol. They're clients for games. Flash things usually just involve variable editing or some means of manipulating Flash.Quote:
Originally Posted by Flareboy323
Making clients take a bit of knowledge of client & server/TCP/networking/sockets/etc. No one can just instill the ability to make bots/clients into you. It's something that takes time and practice.
Well I know that, but when I say "Flash bot" I mean everything from bot, to trainer, to client. And I know, but if I just see some source and get into it, learning and experimenting with the rest becomes easy, and only takes time instead of 100% concentration on it.Quote:
Originally Posted by The Unintelligible
Back at it again, not sure how long I'll be on but I'll be on at least for a few.
@Flare - It's not really a trainer or anything. You can consider it a client that has been made from reverse engineering the original one. Just figuring out how they handle their packet structure and you are golden.
Alrighty so, I think I've figured out how I'm going to handle incoming packets and such. EVENTS! Yes, I know python doesn't natively support events but because python is so fucking incredible, 26 lines of code will implement the same exact event structure of C#.
Anyways, events should allow me to make it nice and clean! Especially the startup packets!Code:http://www.valuedlessons.com/2008/04/events-in-python.html
I have no idea how to find out how they handle packets o-o but anyways, what will said client do?Quote:
Originally Posted by MattSmith
Events? That's usually for GUIs or widgets (i.e. ON_CLOSE). I mean, they could probably be applied elsewhere but as far as practicality and usefulness goes, I'm not sure how far you'll go.
I guess we'll just have to find out.
If you take a look at gaia's zOMG client, it's all handled with events as well. And the more I thought about it, its a good idea.Quote:
Originally Posted by The Unintelligible