Thought In Process: Human-like Neopet Autoplayer?

[Xanice]

Excellent. Give him more work to do. Dance puppets dance! Meh, if I were to finish my intended project by the end of the summer I honestly would be surprised LOL. Stalling does me no good Onward to refreshing on VB!

[DarkByte]

Could be done effectively with separate apps. Of course all in one app it would be neater but the code would get massive. Hopefully my framework will help on this.

[Xanice]

Could be done effectively with separate apps. Of course all in one app it would be neater but the code would get massive. Hopefully my framework will help on this.

By different apps, do you mean code the entities seperately? IE, let's say a autobuyer, auto stocker, etc etc. all coded as seperate applications, then essentially connect all the seperate applications together, or maybe even 'call' them when they're next in queue for being executed? Something along those lines? If that is what you mean, then yeah, I do agree that that would make the program a hell of alot more effective (to the point of this being necessity) for two reasons.

Different people could work on the coding of different parts at once without actually halting the entire project (open source type work) and also the code in itself will be both cleaner and quicker, as the program won't have to run through thousands of unneeded lines of code just to run the correct application at the right time. Coding like "If yyy condition is met, RUN autobuyer.exe" as an example would be easier for the program to sort through then if the entire autobuy script was in the same file as the auction sniper script. I think anyway? I could be entirely wrong.

[DarkByte]

I envision it as a whole bunch of apps in a folder that are linked (They can share cookie files). There would be a "Governor" app that watches over all the other apps and at say 10a.m would run a dailys program with a paramater like so

dailys.exe -expiretime=10pm

Then the app would find the "expiretime" parameter on form load and when this time comes close itself. Something along those lines doesn't seem so hard

[Xanice]

Ah okay. So then my idea was more or less on target, with the exception that my language was probably COMPLETELY wrong since I don't know the actual keyterms haha. Yeah I would envision it the same. Through this method, honestly, alot of the code could be recycled too, so the autobuyer, autonsniper, pricer, etc wouldn't have to be hardcoded all over again. Maybe adjusted (if someone was willing to allow the use of their code in the project of course) to ensure compatibility with the "governer" but that's about it.

With all this being said, I like where this topic is going, it's giving me more concrete ideas on how this program would be made. With that being said, I wonder who would want to devote long hours and manual labor for (as of yet, something that wouldn't be decided for some time) virtually no real money payoff? =P A think tank might be fun for something like this, if there were enough interest to make this a collaborative effort.

[Zachafer]

the code in itself will be both cleaner and quicker, as the program won't have to run through thousands of unneeded lines of code just to run the correct application at the right time. Coding like "If yyy condition is met, RUN autobuyer.exe" as an example would be easier for the program to sort through then if the entire autobuy script was in the same file as the auction sniper script. I think anyway? I could be entirely wrong.

@(you need an account to see links)'s idea would work, but that is a very old way of doing things. Wouldn't it be better to have one program that shared the same wrapper (cookies) between each arm of the program? Wouldn't it make threading really easy? Wouldn't it be nice to be able to communicate that you want the Auction Sniper to start after you've bought 10 items from user shops? Sure this can be done with separate applications, but not easily - and the solution is less effective than putting each "arm" of the program into an organized OOP-styled program.

With that being said, I wonder who would want to devote long hours and manual labor for (as of yet, something that wouldn't be decided for some time) virtually no real money payoff? =P

[Xanice]

@(you need an account to see links)'s idea would work, but that is a very old way of doing things. Wouldn't it be better to have one program that shared the same wrapper (cookies) between each arm of the program? Wouldn't it make threading really easy? Wouldn't it be nice to be able to communicate that you want the Auction Sniper to start after you've bought 10 items from user shops? Sure this can be done with separate applications, but not easily - and the solution is less effective than putting each "arm" of the program into an organized OOP-styled program.

You're a magic lamp full of answers Zach! Now i just need to figure out a way to direct everyone's attention to this thread x; although somehow I have high doubts sean or undead will participate

[DarkByte]

@(you need an account to see links)'s idea would work, but that is a very old way of doing things. Wouldn't it be better to have one program that shared the same wrapper (cookies) between each arm of the program? Wouldn't it make threading really easy? Wouldn't it be nice to be able to communicate that you want the Auction Sniper to start after you've bought 10 items from user shops? Sure this can be done with separate applications, but not easily - and the solution is less effective than putting each "arm" of the program into an organized OOP-styled program.

Yep absolutely that's the best way , not the easiest but the best. The problem I foresee with the method I posted is the windows user control system witch pops up when a program wants to run a admin . I suppose the best way would be to start coding and work out witch method works the best for you.

P.S not everyone wants to make programs for money .

[Zachafer]

I'm actually going to start on this - by latest Thursday

[DarkByte]

Any progress?

I started a project based on this idea , Heres what I have so far , excuse the gui it has not been worked on.

Account manager -

Each account runs in a seperate thread , you can have unlimited running at once


Money Tree grabber class-

This shows how the multiple accounts are managed , you select any logged in account from the right hand side and click "manage account" , then the money tree grabber settings you are using for that account currently will show in the window as-well as any logs ect. You can have multiple settings every different account. Additionally you can save settings to file , this will be usefull later when scheduling is added.

I know it looks simple atm , but its a crapton of code to get this working in a way that wont cause issues further down the line.

Note:Accounts are mules , usernames in sshots dont matter