First, the policy OKs "Third party software may read any text that is normally visible to players in the client while not playing a puzzle." What about text not normally visible, such as the output of copy and past from market data, order screens, product adjustments, etc. I have always assumed those were meant to be used by players.

Second, many of the existing market data programs interact with the client in minor ways other than the approved chat commands, such as by adjusting scroll bars, making sure you are on the right menus, etc. Is it OK for such software to continue to make such minor interactions with the game in non-puzzling situations? I know OOO ruled out an auto-floater, but I guess I count 'waiting for the set-sail button to pop up and then pushing it" to be a "puzzling situation", so I'm not asking for exceptions for that kind of thing, just what is needed to collect data.

Third, eighthmaster is a program that only interacts with the chat log and appears to have always been outside of any policy OOO could set, and yet it was banned. Is this program now allowed by this new policy? (For those who don't know and don't want to wade through the link, eightmaster was a really really bad poker odds assist program. All it told you is some rough odds of how good your hand is and probably was only helpful for people who had no clue about poker.)

Lastly, I presume this policy also applies to second parties too. About the only reason I can think of that it might not is if OOO wants all tools to be public.
----------------------------------------
Algol can not assert the truth of all statements in this post and still be consistent.

Eighthmaster does more than read chatlogs. It is also able to read the yohoho.log file (this is the first thing it asks for on first startup), which would appear to be a forbidden action.
----------------------------------------
Pirate tells you, "my, that's one BIG wad o' chewing gum ye have mounted on yer bonce! oO'"Sungod officer chats, "I wonder if anyone's sailing the harpsichord"Pirate tells you, "ZOMG CANDYFLOSS!!! *munches*"
----------------------------------------
[Edit 1 times,
last edit by Thunderbird at Feb 24, 2011 6:20:35 PM]

Eighthmaster does more than read chatlogs. It is also able to read the yohoho.log file (this is the first thing it asks for on first startup), which would appear to be a forbidden action.

So does QM2. So, are you claiming QM2 is now forbidden?

Log files are meant to be read by programs. Whether that program is QM2, eightmaster, xemacs, notepad or fsdb, it doesn't matter. OOO trying to say that reading a file on my computer is some how an "interaction" with YPP is crazy. They could also claim that having any other game on your computer violates their ToS due to "unfair competition", but no one would pay that claim any mind either.

Edit: I can no longer find a copy of eighthmaster to verify that it reads the yohoho.log files, or what it does with them. It has been a year or so since I looked at the source, but I can't recall any reason that it would need it, but then the whole program was pretty lame. Since this was a banned program, at least at one time, please don't post links to it if you know where to download it.
----------------------------------------
Algol can not assert the truth of all statements in this post and still be consistent.
----------------------------------------
[Edit 1 times,
last edit by wrs1864b at Feb 24, 2011 7:04:03 PM]

Wonders which of the already listed in the yppedia section have been moved to non legal...I see a list now.. stating

Defunct Third party Tools: All Stopped functioning.*Govermor in a box* Pirate Journals* PP Auctions*SeaBattle Damage Counter*Shanty Radio *Site-Maker

I see in Yppedia 3rd party tools .. Many tools here..Have they been checked and re approved by 000??

Could there be a Page/list of Non-Toss compliant Tools set up as there is for defunct?

Some indication where this list stands? Please?

I have no clue about what or how or even where to look to see if.. or what a tool does machanically and technically. I had to look up what xemac, fdbs were? And notepad?I know, in the past different pirates have said they write lil helper ?thingys? that they did not see what was wrong with the,, even tho they did give them an admitted advantage.

The Idea of having separate chat windows availability thru 000 making it a game feature would be a huge improvement to certain areas of gameplay.

How do speadset programs interact.. I have been attemping to figure out the Lotus on my machine to set one up. How do I know what the heck it reads.. or if it would..even..What about the other ones in the tools section?

How do I know if I should Trust the author. I have no way of knowing his past history re cheating, banning, sneaking back on with a new account..and name

On Midnight , yesterday, a greenie told me they had been approached by a yellow player to buy a bot program to make the game run better and should he do it?

What is happening to people using Tools that have been approved all along.. had forum threads etc. and don't see this announcement.

I am Fully Behind the Idea of this. I do hope it does eliminate a lot of the borderline additions people have done.I don't, however, think it is enough for 000 to Change the Rules and Not , at least, review and sort the current tools into legal and non-legal lists.Or approved, dissapproved or whatever name ye want.

Eighthmaster does more than read chatlogs. It is also able to read the yohoho.log file (this is the first thing it asks for on first startup), which would appear to be a forbidden action.

So does QM2. So, are you claiming QM2 is now forbidden?

Log files are meant to be read by programs. Whether that program is QM2, eightmaster, xemacs, notepad or fsdb, it doesn't matter. OOO trying to say that reading a file on my computer is some how an "interaction" with YPP is crazy. They could also claim that having any other game on your computer violates their ToS due to "unfair competition", but no one would pay that claim any mind either.

Edit: I can no longer find a copy of eighthmaster to verify that it reads the yohoho.log files, or what it does with them. It has been a year or so since I looked at the source, but I can't recall any reason that it would need it, but then the whole program was pretty lame. Since this was a banned program, at least at one time, please don't post links to it if you know where to download it.

From what I can piece together of the old EighthMaster thread, EighthMaster is a casualty of an attempt to rein in puzzling aids. The thing is, there can be individual legal actions that can be combined into a single illegal activity. Reading the chatlog, parsing puzzle information, analyzing puzzle information, and playing a puzzle are all individually legal, but reading the chatlog to parse and analyze current puzzle information to tell you how to play the current puzzle is not, at least according to precedent. While EighthMaster itself seems legal, it became associated with a particular script whose most common usage was NOT legal, and as a result EighthMaster got banned altogether. This is kind of like how file sharing itself is not illegal, but the fact that some file sharing programs were overwhelmingly used for illegal purposes led to measures taken against the file sharing programs themselves. (It seems that they may have wanted to block poker aids by saying that you can only use information that can be seen while not playing a puzzle, and poker hands only show up when you're actually playing poker. Perhaps the confusion would be removed by moving the reporting of poker events (who wins the hand, etc.) from the chat window and turning them into floating status text in the puzzle itself. But that seems like a waste of developer time to make a change like that for the sole purpose of removing a corner case ambiguity in third party software policy as opposed to just flat-out telling us "parsing the current poker hand isn't allowed, even though it shows up in the chatlog.")

See, this is why we can't have nice things: Release a useful tool, and someone will find a way to abuse it and get the whole thing banned.

Re: Quartermaster: OOO stated that they tried to frame the new policy in such a way that popular explicitly allowed existing tools would still be allowed. I would be very surprised if Quartermaster were not one of those existing tools they were aiming to keep legal.

Re: Spreadsheet programs: I'll admit I'm not familiar with many of the spreadsheet programs, but the ones I am familiar with (shopkeeping aids, LP memorization aids, fleet location aids) all seem to fall well within the limits for allowed programs: They only take in information the player can normally see (which is trivially true when the player has to enter in information manually) while NOT playing a puzzle, and they don't interface with the client in any way.

Re: How to tell what tools are still approved: As far as I can tell, the new policy focuses on what the tools do, not how they do it (with the exception of "don't modify any files in the game"). This is useful, since as a tool user you just need to check to make sure that its functionality complies with the policy without needing to know about its implementation.
----------------------------------------
Tanonev on all oceans; currently exploring Meridian.Puppetar by Tilinka

As stated in the announcement post, this change in policy does not intend to break established previously approved software or to impose harsher limits than before. This policy is simply meant to make the criteria of what's acceptable and what isn't transparent to everyone.

It was almost expected that a few details would be missing, and should it prove to be necessary, we're certainly willing to add those into the policy. We're very careful with what we do add there, though - it seems better to temporarily disallow tools with functionality that wasn't addressed than someone rulemongering a sloppily phrased part of that policy into a tool that is outside of the scope of what we consider benign.

To address a few specific points:

Reading the "copy/paste" data from trade screens - this, for example, is certainly reasonable. I'm not aware of software currently using this (in an automated way - manually copy/pasting certainly does not fall under this policy), but should there be demand, we can add that.

Using scroll bars is a bit less simple to add, but since it does make sense for software using OCR, we'll see about getting this added in a sufficiently clear way, with all necessary restrictions.

The section about reading the chatlog was mostly added to avoid questions of the "this stuff is not listed, is that okay?"-type which inevitably would come up if that bit wasn't there.

Yohoho.log does fall into a similar category; however, I'm not sure what information is needed from there? If an author of software making use of it could contact us about this via the support form and explain what information is used from there, that'd be appreciated.

With regards to specific previously approved software, I'd recommend contacting the author and asking him - ideally, publicly in our forums, as that means many eyes will see what's stated and can comment on it. Even if the author is inactive, chances are that there's other players who will have a good idea.

Modification of any files in the Puzzle Pirates directory is not permitted with one exception: Players with a vision deficiency may replace puzzle graphics for the sole purpose of bringing their puzzle tile recognition on par with normal vision.

Alright, I have a minor case of dyslexia. I cannot tell the blue/green silver melts apart without spending about 2 seconds, and even then I still get it wrong a fair amount.

That's enough of a vision deficiency that I'd like to use better graphics for "on par with normal vision".

Originally, I used tinted melts, but then we got an official decision that that was unacceptable.

I'd like to know what is acceptable for dyslexic pirates.
----------------------------------------
"We're trying to find the error bars on that number"

Modification of any files in the Puzzle Pirates directory is not permitted with one exception: Players with a vision deficiency may replace puzzle graphics for the sole purpose of bringing their puzzle tile recognition on par with normal vision.

Alright, I have a minor case of dyslexia. I cannot tell the blue/green silver melts apart without spending about 2 seconds, and even then I still get it wrong a fair amount.

That's enough of a vision deficiency that I'd like to use better graphics for "on par with normal vision".

Originally, I used tinted melts, but then we got an official decision that that was unacceptable.

I'd like to know what is acceptable for dyslexic pirates.

There have been some individuals who have gotten approval for tinted melts on a case-by-case basis. I'd recommend asking OOO about your specific case to see whether they'd allow it, and if not, what alternatives they would suggest.

Personally, I'd prefer if OOO just officially released high-contrast versions of puzzle graphics and made them available to everyone via ingame options, not just people with vision problems (how on earth has OOO been verifying this?).
----------------------------------------
Tanonev on all oceans; currently exploring Meridian.Puppetar by Tilinka

Modification of any files in the Puzzle Pirates directory is not permitted with one exception: Players with a vision deficiency may replace puzzle graphics for the sole purpose of bringing their puzzle tile recognition on par with normal vision.

Can we make just one more exception for the whistle sound file, please?

Right now, the only legal options are "no audio alerts for various important events" vs. "infernal whistling device cranked to eleven".
----------------------------------------
.

There have been some individuals who have gotten approval for tinted melts on a case-by-case basis. I'd recommend asking OOO about your specific case to see whether they'd allow it, and if not, what alternatives they would suggest.

Actually, please do not.

Part of the reason for this change in policy is to avoid "case by case" judgements. They generally just won't be fair, and it's not possible for us to provide the medical expertise to determine what exact needs a specific condition has.

Here's a rule of thumb: If you could - and this is, of course, hypothetical - get an occulist or physician otherwise appropriate to your issue to attest that you'd need a specific modification to bring yourself to a non-disadvantaged capability of playing the puzzle in question, that graphic change is okay. If, on the other hand, you could not, then it's not.

I do want to emphasize that this does not mean we require you to have a certificate on hand. While we do reserve the right to require documentation in exceptional cases, this has, to my knowledge, not happened in Puzzle Pirate's history, and I don't forsee that to change.

Can we make just one more exception for the whistle sound file, please?

Right now, the only legal options are "no audio alerts for various important events" vs. "infernal whistling device cranked to eleven".

Apparently I missed answering this before; the short version, however, is no, sorry.

This would be a customisation due to what boils down to a matter of taste. That's just not in the intended scope of this policy, and it's, frankly, a can of worms we'd rather keep shut. Of course, this specific change is perfectly innocent, but the specific purpose of the new policy is to get away from case-by-case judgement of every little bit.

And general "customisation", while certainly not an unreasonable request, is just not something we currently allow.

Do feel free to bring up issues like volume balance (as I understand, that's your gripe with the whistle?) in a separate topic.

First, sorry for the long post. I've started a reply twice and thrown them away because they are too long.

First, don't panic!

I'm not panicked, but I am nervous. I've been programming since I was in grade school and think nothing of throwing together programs/scripts/long command lines, to do whatever. I have been writing various programs/scripts/command lines to do stuff, mostly with the log files, since I started playing YPP, to find who are good skellie fighters, to track when I've last updated labor, to compare booze prices, to filter out BS from the chat log so I can deal with large ships, etc.

It would be cool if we could have crystal clear rules that everyone agreed on their interpretations. That isn't going to happen, but I'd like to make a few observations:

First, rules that can not be enforced (except through confessions) are generally bad rules. For example, saying you can't read log files is something that can't be detected or enforced. If the poker cards in the chat log can be used in objectionable ways, it is far more effective to either remove the lines from the chat log, or to delay writing them until after the hand is over. Similarly, if there are lines in the yohoho.log that can be abused, then it is much more effective to remove/change those lines.

Second, rules that are never enforced only hurt honest players. For example, an amazing number of high-end SFers apparently have medical conditions that warrant the use of changed sprinkle images. I've yet to hear of anyone getting in trouble for changing image files.

Third, despite the horrible impression given by TV/movies dating back to the 1960s, computer programs are not magical. Computer programs don't instantly give the perfect answer to any problem. Paradoxically, computer programs are also portrayed as being trivially broken, encryption systems can always be cracked in 30 seconds air-time, telling a computer to do something impossible causes it to go into an infinite loop, etc.

I really suspect the real problem with eighthmaster was that someone got on a lucky winning streak, and other players blamed it on the use of a program rather than luck/skill. Eighthmaster, from everything I can tell, was a very lame program that may well have done more harm than good to its users, but all too many poker players are not rational/logical. They blame OOO for rigging poker. They blame the use of aids. They blame anything but their own sorry playing skills.

Rules based off of how the ignorant react are generally bad rules.

People who don't consider themselves programmers are often, actually, programmers. Spreadsheets are certainly turing complete, as are many databases (SQL), and even things like MS Word's search and replace (regular expressions) may be close to turning complete.

A rule that bans a java program but allows MS Word because the latter isn't "really programming" is a a rule based on ignorance and a bad rule.

Fourth, I think there is a huge difference between using programs during puzzling contexts and non-puzzling contexts. As tanonev points out, some things that may be ok in a non-puzzling context might not be ok in a puzzling context. Ruling out all "aids" or "helpers" in puzzling contexts, however goes against history. Many of the first third party programs were aids to make it easier for bnavvers during the battle, such as calculating damage percentages. It isn't clear to me that this is signicantly different than eighthmaster's poker help.

I'm really not sure where a line should be drawn here, even a fuzzy line. Damage counters tell bnavvers whether it is good to grapple or disengage, eighthmaster tried to tell poker players whether it is good to bid or fold. Neither tell the player an absolute, you need judgment of the situation.

Endymion wrote:

Reading the "copy/paste" data from trade screens - this, for example, is certainly reasonable. I'm not aware of software currently using this (in an automated way - manually copy/pasting certainly does not fall under this policy), but should there be demand, we can add that.

See, for example Y!PP Ship Sort Tool, "where-vessels" tool, or my ships parser. I have since written a wrapper around my ships_parser to press the "dock" button, the "where vessels" button, type C-A, C-C and run the perl script, copy files to various places, does sanity checking, etc. Basically, I type "./update_ships" and I get an updated list of ships. I did this mostly because doing the list of steps manually meant I would try to cut and paste commands into the shell, clobbering the cut and past from YPP, so I had to do things in a confusing order.

edit: yeah, alan would hate me
----------------------------------------
Algol can not assert the truth of all statements in this post and still be consistent.
----------------------------------------
[Edit 1 times,
last edit by wrs1864b at Mar 1, 2011 8:33:20 PM]

After considering various feedback, we've made the following adjustments/additions:

==Reading information directly from the running client==Third party software may read any text that is normally visible to players in the client while not playing a puzzle. This includes the data generated by selecting and copying trade and similar tables.For the sole purpose of making the appropriate tables and menus visible, software may make use of scroll bars and drop down menus while not playing a puzzle. Software may also automate selection and copying of text.

==Reading yohoho.log==Software may parse the yohoho*.log file generated by the game.

==Reading \rsrc and \scenes==Software may read and parse the data in these subdirectories of the Puzzle Pirates client directory. In addition, software may make use of \code\config.jar to access the color definitions needed to parse that data.

==Linking to code==Linking to executable code in the Puzzle Pirates client is allowed with the followingrestrictions:* The software may not attempt to disassemble or reverse engineer parts ofPuzzle Pirates executable code* The software may not attempt to connect to any Puzzle Pirates servers* The software may not attempt to recreate or emulate playable content ofPuzzle Pirates* The software may not directly or indirectly interact with a runningPuzzle Pirates client

After considering various feedback, we've made the following adjustments/additions:

Oh dear, reading the updated version almost made my head explode. Not wanting to criticize, but: By trying to get away from directly approving third party software on an individual "by name" basis, you ended up with indirectly approving individual third party software on a "by it's specific requirements" basis. Legally an improvement, but practically, you are still doing what you wanted to get away from in the first place, just in a more complicated (and to the non-tech savvy user) confusing, and unstructured way. All in all, the list of rules, as it is now, only makes sense to tool developers and advanced users, who can recognize the "signature" of their tool in one of the rules. The standard player will likely be left with more questions than answers.

I don't even know what executable code is, let alone whether or not something like Quartermaster might "directly or indirectly interact with a running Puzzle Pirates client". I'm afraid Scenepainter is probably right, unless this is intended to be some kind of hands-off 'please behave' policy.
----------------------------------------
My friends, love is better than anger. Hope is better than fear. Optimism is better than despair. So let us be loving, hopeful and optimistic. And we'll change the world. ~ Jack Layton

Agreed that the list of allowed software interactions won't be very helpful to a player with someone else's program sitting in front of them. Although I suppose every author could post a list of all the ways the software conforms to the policy and rely on other tech-savvy players to spot omissions or inaccuracies.

Dylan wrote:

Algol can not assert the truth of all statements in this post and still be consistent.

I don't even know what executable code is, let alone whether or not something like Quartermaster might "directly or indirectly interact with a running Puzzle Pirates client".

Let me take my shot at what this all means. (Disclaimer: I'm not a lawyer-- follow this at your own risk).

==Linking to code==Linking to executable code in the Puzzle Pirates client is allowed with the followingrestrictions:* The software may not attempt to disassemble or reverse engineer parts of Puzzle Pirates executable code

No taking apart the program to find out how it ticks.

* The software may not attempt to connect to any Puzzle Pirates servers

No trying to mess with the computers at YPP headquarters.

* The software may not attempt to recreate or emulate playable content of Puzzle Pirates

It's OUR game. You're not allowed to try to recreate it.

* The software may not directly or indirectly interact with a running Puzzle Pirates client

Or make any bots, you lazy bilge-drinkers.
----------------------------------------
Gurndigarn on Emerald Ocean"Oh, come on. You jobbed onto a ship called the Cursed Isle Raider and you expected *refined*?"

Yes, that part (and possibly others) clearly will be confusing to average players.

However: As stated at the very top of the page, and also fairly obvious, I'd think, as an end-user of software you already need to trust the author.

And if end-users trust that the author does write software not doing them harm, why would they not trust an author's statement of "yes, my software complies to these terms"? Certainly, any software author can answer this for his own software. If not, then we're too ambiguous in some places. Should that be the case, point those out and we'll try to be clearer.

The risk is still on the user, but that's not really avoidable. And I'd think the risk of compromising your PC is always far bigger than violating that policy.

Hence the recommendation to ask if in doubt, and to not use it if you still have doubts after that. We could never take responsibility for third party software, after all, so that part has not changed.

As for "catering to specific software", that, to a degree, is true: We wanted to make sure that existing legit software stays within the rules without anyone having to worry. We did, however, make the corresponding adjustments as broad as we're comfortable with. Also don't forget that for some purposes, there really only is just one tool, because others don't want to needlessly reinvent the wheel.

The drawback of not being all that clear to end-users is something we certainly acknowledge - but there's few other viable paths to go.

The previous way of approving specific software doesn't really work. There are literally dozens of various tools out there, and most of them have several versions. In order to really "approve" a tool, those versions all would have to be reviewed, and if we were serious about it, it'd have to be a source code review. That's just logistically not possible.

We could, instead, just stop all that, point to the ToS and leave it at that, but I don't think anyone would prefer that.

It would be ideal if it was possible to phrase all that understandable for everyone as well as clear enough to keep everything we don't want to approve (and most of you don't want approved, either!) disallowed. But I'm not sure if there's a better compromise achievable than what we currently have - software is a complex thing, by nature. (Realistic) suggestions certainly are welcome.

Agreed that the list of allowed software interactions won't be very helpful to a player with someone else's program sitting in front of them. Although I suppose every author could post a list of all the ways the software conforms to the policy and rely on other tech-savvy players to spot omissions or inaccuracies.

Indeed, that's what I'd imagine how this goes in the long run. As noted on the page itself, players have a lot of reason to not trust authors who're not willing to discuss their tool on these forums for all to see.

I don't even know what executable code is, let alone whether or not something like Quartermaster might "directly or indirectly interact with a running Puzzle Pirates client".

Heck, if you read the (poorly written!) letter of the policy, instead of the spirit, OOO has prohibited anyone from running Puzzle Pirates. Ever.

Operating systems have to "directly or indirectly interact with a running Puzzle Pirates client" for the game to function. (Of course, I don't think that they're going to enforce the policy that literally.)
----------------------------------------
.

I don't even know what executable code is, let alone whether or not something like Quartermaster might "directly or indirectly interact with a running Puzzle Pirates client".

Let me take my shot at what this all means. (Disclaimer: I'm not a lawyer-- follow this at your own risk).

To shed some light on this: The rule about "Linking to code" is what I referred to as a "signature" in my previous post. More precisely, it is (along with "Reading \rsrc and \scenes) the signature for "SceneHaul" (YPP -> YoTools converter) and got added after I emailed OOO, requesting a revision/clarification of the rules in regard to my two tools.

So, the story kinda goes something like this: OOO cannot tell you SceneHaul/ScenePainter is OK to use as this would be an endorsement. They cannot endorse any third party software as they can never be completely sure what that software (or a future version of it) does. For all they know, it (or that future version) might steal passwords. However, some third party software is desirable to have around (I'm pretty sure, for example, that this "Armed and notorious" picture, you see after logging in was done with ScenePainter - either that, or someone had a lot of fun with photoshop).This conflict of interest is solved by phrasing the rules in a way that authors of YPP addons can recognize their particular software in it and tell the community, that even though there is neither endorsement nor approval, the application is safe to use in the sense that it will not get you banned.All in all, that's the most sensible way to do this. The only problem is that, as things are now, only very few, very tech savvy people are able to recognize the signatures and are therefore able to tell which software is meant by which rule. Of course, it is not very helpful, if only the author of a certain piece of software is able to tell you whether or not it is OK to use it (guess, what the answer will always be), which brings me back to shedding some light:

"# 2.5 Reading information directly from the running client" is the signature for Pirate commodity trader with bleach. It says simply that you may take screenshots from the client and extract data via OCR. You may even send synthetic keyboard/mouse commands to the client to scroll the trading interface to the desired location. You may, however, not use screenshots, OCR and synthetic keyboard/mouseinput in puzzles (that would be botting).

"# 2.6 Reading \rsrc and \scenes" and "# 2.7 Linking to code" is ScenePainter and SceneHaul. SceneHaul needs something out of yoclient-dop.jar to do it's work. The restrictions don't apply to it, but are there to stop people from considering that file to be fair game.

Of course, I should now mention, that nothing was ever endorsed/approved. You cannot rely on anything I said above and should you get manage to get yourself banned, it's still your own fault.

There are a lot of people that I trust not to be malicious who I may not necessarily trust not to be dumb. :-) But thank you Endymion, with that explanation of the background philosophy I think I can work out a way to work with the new policy.
----------------------------------------
My friends, love is better than anger. Hope is better than fear. Optimism is better than despair. So let us be loving, hopeful and optimistic. And we'll change the world. ~ Jack Layton

First of, I would like to thank OOO for putting so much thought into this. I can't see any such policy being even close to perfect, the subject area is just too messy.

OK, now for a few quick comments....

xelto wrote:

* The software may not directly or indirectly interact with a running Puzzle Pirates client

Or make any bots, you lazy bilge-drinkers.

abacadafa wrote:

Operating systems have to "directly or indirectly interact with a running Puzzle Pirates client" for the game to function. (Of course, I don't think that they're going to enforce the policy that literally.)

I believe these two are misinterpretations of the new policy. It is ok for a program to interact with the YPP client, as outlined in the policy. It is not, however, OK for a program that has linked to the YPP code to do so.

An operating system loads programs, but does not link to the program, so that example is invalid.

This policy, however, appears to rule out the use of the new PCTB/YARRG market data uploader. The new uploader overrides some dynamically linked libraries in order to use the Java Accessibility API to implement a "screen reader" (normally used by blind people) to extract the market data text, rather than using an OCR system. Actually, I think this may be a gray area, since the new uploader links with the JVM, rather than the YPP code running in the JVM.

xelto wrote:

* The software may not attempt to recreate or emulate playable content of Puzzle Pirates

It's OUR game. You're not allowed to try to recreate it.

Again, this is in the linking section. My interpretation is that things like the distilling simulator and bnav simulator are ok, but you can not link into the YPP client's SF code and then recreate/emulate the puzzle.

I'm really not certain that my interpretation is correct here, but it makes more sense to me than your interpretation.
----------------------------------------
Algol can not assert the truth of all statements in this post and still be consistent.

This policy, however, appears to rule out the use of the new PCTB/YARRG market data uploader. The new uploader overrides some dynamically linked libraries in order to use the Java Accessibility API to implement a "screen reader" (normally used by blind people) to extract the market data text, rather than using an OCR system. Actually, I think this may be a gray area, since the new uploader links with the JVM, rather than the YPP code running in the JVM.

I'm assuming the word "read" in this context referes to any and all methods of reading data from the client - The most obvious being using Screen Capture/OCR, but I don't see that it necessarily imply that reading has to be done this way?

Working through the relevent section of the new fangled rules... and speaking as somebody entirely unfamiliar with the Java Accessibility API works so stand to be proven wrong...

The software may not attempt to disassemble or reverse engineer parts of Puzzle Pirates executable codeIt does not disassemble code, nor does it reverse engineer code...

The software may not attempt to connect to any Puzzle Pirates servers It does not connect to the server.

The software may not attempt to recreate or emulate playable content of Puzzle Pirates It does not do anything that even remotely looks like playable content.

The software may not directly or indirectly interact with a running Puzzle Pirates clientThis is where it gets murky... You can you can argue whether or not the JVM is part of the client, but a "spirit of the game" kind of answer suggest that it would be. Then you come to the question of interacting... Pull your dictionaries out - To take a plain English interpretation of "interact", I figure that if something is not "driving" the game in any way (for example, by clicking buttons without any player interaction).. But I can also see a different interpretation of the language. My common sense answer says its fine... However I could easily see OOO commen sense answer being its out.

[Internet Rule Lawyer]If you can't connect to a YPP Server, technically you can't connect to the yoweb pages...[/Internet Rule Lawyer]

And before we see a mysterious deletion from the wiki... The uploader may be questionable, but I see nothing wrong with the Yarrg website itself?
----------------------------------------

Actually to clarify the obvious, I'm assuming the "Spirit of the Game" rule is alive and well - Looking at the rules, A screen reader that checks a bilge board out, and recommends an area of the board you should play (for example, by displaying a toolbar to the side of, and external to, the client) is otherwise completely fine. (I'm assuming a tool that drives the mouse pointer to where you should click in your OS of choice is captured under "indirectly interacting")
----------------------------------------

It does not, as wrs1864b said above, override any dynamically linked libraries. It merely arranges for the JVM to be invoked with two extra arguments: -Djavax.accessibility.assistive_technologies=net.chiark.yarrg.MarketUploader and -Djava.ext.dirs=(the path to wherever the JARRG code has been installed):(the path to the regular JVM extentions)

This makes the JVM start up our code as an accessibility extension, at the same time it starts up the Puzzle Pirates client. Our code is not "linked" against the executable code in the client: it does not name any of the classes that make up the client, it doesn't make any direct calls to code in the client, and it has no access to any of the client's internal state. It can quite happily be compiled and run on a machine that doesn't have the client installed (although of course it's not terribly useful then).

The Puzzle Pirates user interface is implemented using Java Swing. It's made up of a hierarchy of Swing components like text entry boxes and tables, which all implement the accessibility API. Our code uses the API to look down the hierarchy to find the market data table and read its contents. It can't read the table if it isn't on the screen! It also looks at a few other things: it looks in the window title to figure out which ocean it's on, it looks at the tooltips for the ends of the league tracker to try to find an island name, and if that fails it types "/who" and looks for the island name in the panel that pops up under the "Ahoy" tab. It also checks that the dropdown "display" button is set to "All".

These are all things that the various OCR-based screen readers do too. The only real difference is that ours is doing them through the accessibility API within the same JVM, rather than through the window system API from a different process.

The software may not directly or indirectly interact with a running Puzzle Pirates clientThis is where it gets murky... You can you can argue whether or not the JVM is part of the client, but a "spirit of the game" kind of answer suggest that it would be. Then you come to the question of interacting... Pull your dictionaries out - To take a plain English interpretation of "interact", I figure that if something is not "driving" the game in any way (for example, by clicking buttons without any player interaction).. But I can also see a different interpretation of the language. My common sense answer says its fine... However I could easily see OOO commen sense answer being its out.

That one's causing a bit of confusion to me too - it would be nice to have it clarified! The way I read it at the moment, it's saying "and by the way, if you do link to executable code in the Puzzle Pirates client, you're not allowed to do anything at all"!
----------------------------------------Anaplian, Shadow Riders, Midnight Ocean

This policy, however, appears to rule out the use of the new PCTB/YARRG market data uploader. The new uploader overrides some dynamically linked libraries in order to use the Java Accessibility API to implement a "screen reader" (normally used by blind people) to extract the market data text, rather than using an OCR system. Actually, I think this may be a gray area, since the new uploader links with the JVM, rather than the YPP code running in the JVM.

We consider that uploader covered under the "read stuff from running client" section. It's indeed phrased "a bit murky". I'll imagine that anyone familiar with how that uploader works can understand why we didn't even attempt to cover the method in detail in that policy - if we wanted to go into that sort of detail, we'd have to write a book (or a dozen), specifying functions and classes and what exactly can be done to them for what purpose in what circumstances.

Not to mention that that'd drop the understandability of that policy for average users to zero.

Again, this is in the linking section. My interpretation is that things like the distilling simulator and bnav simulator are ok, but you can not link into the YPP client's SF code and then recreate/emulate the puzzle.

While those are okay (as I believe they've been "cleared"), generally recreation of any puzzle would be more of a copyright issue than anything this policy intends to address. From the point of view of this policy alone, the statement above is definitely correct.

Actually to clarify the obvious, I'm assuming the "Spirit of the Game" rule is alive and well - Looking at the rules, A screen reader that checks a bilge board out, and recommends an area of the board you should play (for example, by displaying a toolbar to the side of, and external to, the client) is otherwise completely fine.

I'm not sure where you read from this policy that using any method to provide assistance in a puzzle would be "okay"ed by this policy? That is not intended, and I don't see how you can read that into it.

That one's causing a bit of confusion to me too - it would be nice to have it clarified! The way I read it at the moment, it's saying "and by the way, if you do link to executable code in the Puzzle Pirates client, you're not allowed to do anything at all"!

That's actually basically correct. I'm currently only aware of one previously accepted tool that the entire "linking to code" section applies to - that's SceneHaul. That tool converts scene data to XML, and it does not need the Puzzle Pirates client running, nor would it interact with the client in any way if it was running. That is the sort of stuff this part is giving the "okay" to.