Quantcast

Jump to content


Photo

Neoquest II Client + Bot

neoquet ii neoquest 2 client no cheating bot automation

  • This topic is locked This topic is locked
38 replies to this topic

#26 neobo

neobo
  • 229 posts


Users Awards

Posted 09 July 2016 - 10:53 PM

What that means when using with gui: it will probably be slower compared to before when I just dumped everything directly into the gui.
What that means otherwise: the functionality are now open for usage, this is where I could start working on making scripting happen.

 

I have no idea what that means but its sounds so :cool:

Thanks for continuing to develop and share.



#27 GetJinxed

GetJinxed
  • Reckless Cheater

  • 1423 posts


Users Awards

Posted 10 July 2016 - 04:17 AM

I've decoupled the logic from the gui, what that means is that the functionality of the program are now standalone.
 
What that means when using with gui: it will probably be slower compared to before when I just dumped everything directly into the gui.
What that means otherwise: the functionality are now open for usage, this is where I could start working on making scripting happen.
 
A current description of what you can use when I start working on scripting -

  • States: The logic procedure is based on states, that is, one can ask "of what state is the game currently in?". These are the states currently available:
    • Begin combat
    • End combat
    • Defeat
    • Inventory
    • Shop
    • Skills
    • Travel
  • Static links: links that never change, such as the direction buttons. These are accessible from all states, so it is up to the user to access them responsibly.
  • Dynamic links: links that are generated depending on the situation, such as upgrading a skill or using a potion. These vary according to the state.
  • Allies: a list of your heroes. Each will have the following properties: name, level, hp, exp. Some other properties are not publicly accessible.
  • Foes: same as heroes, but some properties will take no values
  • Message: the message that is available for a given state, such as dialogue, warnings, battle description.
  • Gold: the amount of gold, stored from the last state such information was available.
  • Last rest: the last resting location.
  • Map: I haven't yet decided how to represent this for practical public usage. To be announced.
  • Table: the information contained on a table, such as from shops, where all the item information are placed within cells on a table.

Obviously these are subject to change when I start working on how to manage scripting, but these should be most of all the core functionality.

 

Amazing man! I just don't get the gui part :p Did you just made it multithreading or what?



#28 Nonexistent

Nonexistent
  • 681 posts


Users Awards

Posted 10 July 2016 - 06:40 AM

let us use a hero as an example. A hero has a name, hp, exp, level etc:
Rohane
69/420
14,230
18

Parsing is expensive, so any one piece of data is grabbed only once per page.

What I did before:

  • Parse page for data as a plain string
  • Dump the strings onto the gui to display

So what it would have looked like before:

Parser <-> Gui

When the strings are dumped directly it is relatively fast and efficient, but it is not flexible, parser had to send specific pieces of data to specific places on the gui.
The strings being dumped are stuck on the gui once dumped, retrieving for it to examine afterwards would be difficult.
The strings themselves don't have any meaning, they only have meaning because you see it in context of other strings and can derive meaning from it, for example if I showed you three strings:
"123/324", "69/420", "132/314"
You could guess that they are hp of heroes, but without context you don't know exactly what they mean, or whose it is.

What I do now:

  • Parse page for data as plain strings
  • Create a object to represent a concept (Hero)
  • Attach that string to the object as one of its properties (hp = "69/420")
  • Centralize these representations in one location for convenient access
  • Gui can access these representations and interpret them individually

So what it would look like now:

Parser -> Data <-> Gui

But now it doesn't have to only be a gui that is attached to the data, you can plug something else into it as well to interpret the data from the middle layer:

Parser -> Data <-> Script

Or plug multiple things at once

Parser -> Data <-> Gui
                     <-> Script
                     <-> Your email
                     <-> Your phone (Mobile client??!!?!?)

As you can imagine, with the extra steps, and with having to create representations, the program is slower than before.

But as you can see also, that it is now more flexible than before.

 

 

Of course, this is what I have for now, there might be better ways to do this that I am not aware of, and I will gladly change it in to a better way when I find one.

 

And also, this is why previous versions are still available, if you find that you don't like/need additions in newer versions, you could always use an older version.


Edited by Nonexistent, 10 July 2016 - 06:42 AM.


#29 GetJinxed

GetJinxed
  • Reckless Cheater

  • 1423 posts


Users Awards

Posted 10 July 2016 - 12:48 PM

Oh yeah I never thought about the fact that for every page refresh(action such as walking,attacking) it would parse every single time. Seems quite a project you have here man :p Can Android devices even run java?  :o Inb4PlayNQ2onmobile  :lol2:



#30 Nonexistent

Nonexistent
  • 681 posts


Users Awards

Posted 15 July 2016 - 06:31 PM

Android applications are often times written in java, yes.

My 666th post.

Scripting is now up, all information is available in op and in download files.
There's not a whole lot of debugging mechanisms, so its mostly up to the scripter to make no errors.

Disclaimer: If I make a large enough change in the future, it might break old scripts. I'm not concerned with back-wards compatibility LOLLLL

Edit: the documentation is a little bit inconsistent, I'll fix that on next update.

Here's a sample script:

Spoiler

Edited by Nonexistent, 15 July 2016 - 08:02 PM.


#31 GetJinxed

GetJinxed
  • Reckless Cheater

  • 1423 posts


Users Awards

Posted 15 July 2016 - 08:50 PM

Awesome! I'll try to learn this :p From what it seems that's basically a training script which moves North and South repetitively until a fight happens stops when the gold is above 500? :p It's easy to read hope I can learn how to make those ahah



#32 Nonexistent

Nonexistent
  • 681 posts


Users Awards

Posted 15 July 2016 - 09:01 PM

yes that is exactly what it does.

 

I tried to implement it as something that could be as intuitive as possible, and since I'm guessing most people have seen the angle brackets syntax before from trying to do profile or pet user look ups, I chose to implement it around that. And plus jsoup also comes with a xml parser, so I just used that for parsing the scripts.



#33 GetJinxed

GetJinxed
  • Reckless Cheater

  • 1423 posts


Users Awards

Posted 16 July 2016 - 06:15 AM

That seems nice =D It should be easy to make some advanced scripts this way. The only thing that could maybe break them is if there's lag on their server and if the character doesn't really move at all when it was supposed to. Regardless of that the bot as it is seems to be enough to do the whole game easily with some good scripts.

 

Btw.. RIP 666 posts :p Now aim for 1k to be a private  :)



#34 Dont

Dont
  • 257 posts


Users Awards

Posted 16 July 2016 - 06:45 AM

This seems like it would be one hell of a project. Especially with how inconsistent neo's servers are, you'd have to be making it as a speed run or it would just be so annoying to make.

Which makes it riskier, which would make the testing process a bitch.

 

 

But I'm not entirely sure, this is just what I would imagine. I don't do this stuff. haha

NQII APer has treated me just fine all the way through, even on insane. :p



#35 GetJinxed

GetJinxed
  • Reckless Cheater

  • 1423 posts


Users Awards

Posted 16 July 2016 - 06:51 AM

The advantage of this is that we can make some sort of advanced scripts which virtually reduces the need of manual input if the script is made properly :p



#36 Nonexistent

Nonexistent
  • 681 posts


Users Awards

Posted 16 July 2016 - 07:05 AM

A time out exception is thrown after 20 seconds, if you'd like to manually handle the exception I could implement that too

#37 Dont

Dont
  • 257 posts


Users Awards

Posted 16 July 2016 - 07:06 AM

Oh I can definitely see the advantage, i'm just questioning the actual worth of it. Would it not be really annoying to make? haha



#38 Nonexistent

Nonexistent
  • 681 posts


Users Awards

Posted 16 July 2016 - 07:19 AM

Idk I'm just offering the tools that can be used to make something that is custom and therefore adaptable, whether anyone wants to use the tools and what they make with it is none of my concern
You can make the bot just print lewd messages and nothing else for all I care lmao

Edited by Nonexistent, 16 July 2016 - 07:22 AM.


#39 Artleyz

Artleyz
  • 294 posts


Users Awards

Posted 20 August 2016 - 08:11 AM

@Nonexistent

Hey, any chance you could add the current location to the client? For instance, let's say you haven't played in a while and you start out at Mysterious Tower level 3. With this client, there's no way to know where you are unless you have it memorized.

 

Also, you currently have to choose your target after every move in a battle. It should probably save your current target until the monster is dead, as the actual game does.


Edited by Artleyz, 20 August 2016 - 08:20 AM.




Also tagged with one or more of these keywords: neoquet ii, neoquest 2, client, no cheating, bot, automation

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users