Nonexistent

once it asked me to click all the squares with road signs from the entire image, except it was just a image of a tree with no road signs anywhere.

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.

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.

Agreed. Just look at Brexit - a ton of people either didn't vote or didn't take their vote seriously and regretted it after the results came out.

i think "regret" wouldn't even come close to describing the election votes, more like "hopeless", as regardless who is voted in both suck

I'm not sure what to think of Trump. I was amazed by the way he ran rings around everyone for the Republican primaries - whether it was the Republican establishment, Republican voters, Fox News, other media, or like, the American public itself.

I have absolutely no idea how he would be running things however. It's one thing to run businesses (and he has had his fair share of bankrupt businesses, though that's arguably par for the course for the range of businesses he's doing). But another to like, run the country. And it's obviously very different from the media manipulation/grandstanding/playing to crowds thing he did to get to this stage.

thats the thing too, clinton will run the country for power, trump will run the country for money, but whos gonna run the country for ethics and the people

america is such a mess

Let's build a wall.

and make violent_j pay for it

depends on if you have a black light or not

I recently started to play Neoquest II for the second time in my life due to nostalgia, the first being over a decade ago.

Some where along the way in Neopet's lifetime, it's server speed and quality has really taken a beating and Neoquest feels pretty awful to play. With each page sending out multiple small requests, the time really adds up.

This client seeks to address this issue with just plain old one HTTP GET/POST per action, no javascript, no behind the scenes multiple bs requests. Map tile images are cached in memory when they are first encountered, this is the only time there will be multiple requests per action.

This will be a progressive program, meaning I'll add things along the way as I play along, and should be completed as I finish the game.
However, I won't hold on to it until the very end because I assume that most of the functionality will be integrated part way through.

As this is not a cheating program, I am not expecting much attention, but for the people who might suddenly feel like using it in the future, you have the peace of mind knowing that this is available when you need it.  You asked for it, the bot is for cheating, and the client is for legit.
 
Client:

Spoiler

Check Version History for items currently supported in the client.
 nq2client-v1.3.0.zip   321.39KB   156 downloads
 
Screenshot:

Spoiler

INSTRUCTIONS:

Spoiler

• Open the "init.txt" file in the current folder, the format in the file is
  • identifier:=value
• Replace the default username and password values with your own information
• This step is optional:
  • Find the user agent of your favorite browser ( http://user-agent.me/ )
  • Replace the default user agent value with your own information

Version History:

Spoiler

1.0.0 - June 19, 2016

• Implemented most of basic functionality, movement, 1v1 combat etc
• Resting at inns work
• Dialogue not parsed, shops not displayed

1.1.1 - June 21, 2016

• Solo character skill upgrades
• Fixed map size changes

1.2.1 - June 25, 2016

• Codebase refactored
• Implemented multi combat

1.2.2 - June 30, 2016

• Dialogues
• Status bar
• Restructured some parsing

1.2.3 - July 3, 2016

• Added Shops
• Added Inventory

1.3.0 - July 9, 2016

• Decoupled graphical interface from logic
• Abstracted out functionality
• Due to above, performance may suffer relative to before when using graphical interface

-------Syntax-------

The script must have script.xml as its file name.
The script must open and close with the script tag.
<script>.......</script>
Attribute of tags must open and close with double quotes.

-------Constructs-------
Every construct must have both a opening and closing tag.

If: executes enclosing content if condition attribute returns
	true.
	True is any integer other than zero.
	Condition attribute can evaluate any(supported) legal
	mathematical and logical expression.
	
<if condition="evaluateState(COMBAT)">.......</if>

Else: Can only be placed directly after closing if tag.
	  Not mandatory if not needed.
	  Content will be executed if preceding if tag does not
	  return true.
	  
<if condition="cos(pi)>0">.......</if>
<else>.......</else>

Loop: loops the content if the condition returns true.

<loop condition="1">
<print message="infinite" />
</loop>


-------Invokers-------
Invokers are self closing, no separate closing tag needed.
Invokes an action to do something.

Print: prints a string or integer, spaces are deleted.
<print message="halloWelt" />
<print message="getGold(1)" />

Post Static Link: Post links that are static and 
		  never change.
<postStatic link="NW" />
			- N
			- W
			- E
			- S
			- NW
			- NE
			- SW
			- SE
			- beginBattle
			- endBattle
			- returnToMap

Post Dynamic Link: Post links that change from page to page.
		   Attribute is part of the name of the link.
<postDynamic link="attack" />

Set Target: MUST USE THIS BEFORE POSTING ANY COMBAT LINKS.
			For now, it just sets the target as the next
			enemy whose hp is not zero.
<setTarget set="next" />


-------Data Getters-------
Arguments must not have spaces.
Data can only be obtained when a relevant page is visted,
for example, if the script were to start of a combat page but
getGold(1) were called, it would result in an error.
	
getState(1)
	Returns: current state as string
	States :
		BEGIN_COMBAT
		COMBAT
		END_COMBAT
		DEFEAT
		INVENTORY
		SHOP
		SKILLS
		TRAVEL
		
evaluateState(stateName)
	Argument: compares the current state to the provided state.
	Returns : true if both states match, false otherwise.
	Example : evaluateState(END_COMBAT)
	
getMessage(1)
	Returns: message of page as string.
		 Message is cleared after every page load.
	
getGold(1)
	Returns: amount of last updated gold as string
	
getLastRest(1)
	Returns: location of last resting location
	
dynamicLinksContains(nameSegment)
	Argument: part of an link's name
	Returns : true if any of the dynamic links in current state
			  contains the name segment
	Example : dynamicLinkContains(Destroy)

hp(allyName)
	Argument: the name of an ally
	Returns : the health of ally object
	Example : hp(rohane)
	
level(allyName)
	Returns : the level of ally object

in this thread Dont vs the world

hb

Strategist, always has been, always will be.