Talk:Fishing Strategy

This talk page is for discussing Fishing Strategy.
Sign and date your posts by typing four tildes (~~~~). Put new text below old text.	Be polite. Assume good faith. Don't delete discussions.

Expanded Tables

I created a copy of the tables at User:Nazgutek/Fish to include more information about each fish, to save myself from switching back and forth with the Fish page. Nazgutek (talk) 09:48, 12 July 2018 (BST)

These tables can be even more useful with a little tweaking. They already account for time and weather. By adding the spawn chance for each fish, it can show people how relatively likely they are to catch a specific fish at a specific place or time. The additional relevant data (difficulty, price) can presumably be put into the colored bar which currently only indicates weather, and possibly more detailed skill-related info. Eg, likelihood of spawning the fish 1 tile from shore vs 4-5 tiles (only 1 fish spawns more at 5 tiles) and likelihood of spawning the fish at player fishing skill 0 (it goes up 2% for each additional skill level of the player).

Also worth mentioning is that trash is what happens only when you fail to spawn every available fish (including any listed algae/seaweed) for that time/location/weather. MissSlaughter (talk) 06:36, 28 October 2019 (UTC)

I can see that you have a lot of enthusiasm for analyzing the fish data, and that's great! Keep going with it. I just have three pieces of advice for you:

1) The tables are actually complex templates, and any changes made will have to be made in 11 other languages, so there's no such thing as a small tweak. It can be done, but it's going to be a lot more work than just changing the templates in English.

2) Take a breath, slow down, and make sure you have the information correct before proposing changes. This is advice I've given myself, and it's good advice.

3) Version 1.4 is in the works, and we have no idea if it's going to change nothing or everything about fish data. There's a chance all your work will have to be changed when it releases. Just keep that in mind.

Once you think you have the facts right, feel free to create sandbox pages in your user space to preview and tweak formatting. And do let me know if you would like any assistance during the process! margotbean (talk) 12:36, 28 October 2019 (UTC)

A Nit

I've noticed that the table for the mountain in summer lists availability of Green Algae is limited to times before 7 PM. I think that's a bug. Butterbur (talk) 18:50, 29 January 2020 (UTC)

Fixed, in all 12 languages. margotbean (talk) 01:30, 30 January 2020 (UTC)

Depth

How can you tell how far your fishing line has to go to reach a "depth" of 5? I get golds lots of times, but the distance of the line is not equal to 5 land tiles. There's nothing more than visual cues to go on. So, the game must determine distance on its own terms. But it might be nice for a player to be able to judge distance at any given spot well enough to tell if there is a chance of gold fish from there or not. Any pointers? Butterbur (talk) 04:30, 30 January 2020 (UTC)

Depth is calculated by FishingRod::DistanceToLand

    public static int distanceToLand(int tileX, int tileY, GameLocation location)
   {
     Rectangle r = new Rectangle(tileX - 1, tileY - 1, 3, 3);
     bool flag = false;
     int num = 1;
     while (!flag && r.Width <= 11)
     {
       foreach (Vector2 position in Utility.getBorderOfThisRectangle(r))
       {
         if (location.isTileOnMap(position) && location.doesTileHaveProperty((int) position.X, (int) position.Y, "Water", "Back") == null)
         {
           flag = true;
           num = r.Width / 2;
           break;
         }
       }
       r.Inflate(1, 1);
     }
     if (r.Width > 11)
       num = 6;
     return num - 1;
   }

Basically, it draws a square around the tile that the bobber is on. This square increases until it intersects a tile on the map that doesn't have the "water" property. So the location of the bobber plays a huge part in calculating the distance/depth BlaDe (talk) 08:04, 30 January 2020 (UTC)

I do not think there is a way to judge in-game what the exact distance is without a mod installed. I've fished many times with the developer grid showing, tried to hit a tile in the Night Market submarine that would give an Iridium fish with a perfect catch, and couldn't do it. But others have done so. Same with the desert pond. So, the "unknown" is built into the game (as far as exact distance goes), and I don't see a way for the wiki to specify any better than it does, unfortunately. What I do see are a few pages that need to be re-written to change the language from "tile" to "distance", and then provide an explanation of what that is. Yay. margotbean (talk) 15:46, 30 January 2020 (UTC)

Thanks to you both. So it really is a "tile" of sorts: amazing, since land tiles are clearly discernable visually if one looks hard enough, and water tiles seem to vary somewhat, visually. Perhaps I'm looking at them wrong, expecting something different that was suggested by current writing. I'll look again there.

I'll look at some of the article language again too. If we're not meant to perceive water distance by looking, I can't see why article descriptions of this tile count are of any use. In fact, they contribute only confusion to the player. Understanding the nature of the skill increases and resulting fishing strategy are what seem important to describe. Butterbur (talk) 16:11, 30 January 2020 (UTC)

There is some RNG around the quality of a fish, but I have yet to work through exactly how depth affects it BlaDe (talk) 18:42, 30 January 2020 (UTC)

In addition, I'm still having trouble getting wordings right. "Depth" is a derivative. And the code above does not "set" it. It only provides an initial value, which changes according to other conditions. However, since ultimate "depth" factors in all (or most) factors, I'm moving its definition and terminological use to this article, and out of Fishing. I talk about casting distance there as "distance" (but even that is not quite true). The code above provides the initial distance calculation in actual tiles, but the casting distance is a modification of that, and depth is a modification of casting difference, and quality is a function of depth (but perhaps more, right?). It's a morass of engineering details we need to try to hide for the ordinary player. That level of detail only confuses. A little of the right kind of hand-waving should produce enough to get a good idea across. That's my current goal. I may yet lie a little in the article just to simplify the details. As long as we're directing the players to the correct outcome, that's legitimate. Engineers can cope. Butterbur (talk) 19:52, 30 January 2020 (UTC)

BTW, I'm assuming that "depth" is not a term that the game exposes (or not much) in its UI. Correct? I'm trying to hide the word mostly. It's a can of worms. But if I remember right (a significant "if"), it mostly or entirely occurs in code, not outside. Modding info mostly goes elsewhere than where I'm writing. Please respond if I'm wrong. Butterbur (talk) 20:00, 30 January 2020 (UTC)

From FishingRod:

StardewValley.Object @object = location.getFish(this.fishingNibbleAccumulator, this.attachments[0] != null ? this.attachments[0].ParentSheetIndex : -1, this.clearWaterDistance + (flag ? 1 : 0), this.lastUser, num + (flag ? 0.4 : 0.0), bobberTile, (string) null);

And the code that it calls in GameLocation:

public virtual Object getFish(
     float millisecondsAfterNibble,
     int bait,
     int waterDepth,
     Farmer who,
     double baitPotency,
     Vector2 bobberTile,
     string locationName = null)

So clearWaterDistance is passed in to become waterDepth for the purposes of getting a fish on the line. Flag is true if the bobber has hit bubbles, so bubbles affect what fish is hooked, but not the quality. BlaDe (talk) 20:57, 30 January 2020 (UTC)

Ok. But the articles have said all along (and still do) that bubbles affect water depth (not quality). But water depth can (possibly) affect quality, yes? If bubbles raise depth from 3 to 4, for example? I'm not really concerned about "purposes of getting a fish on the line". Sure, I would expect clearWaterDistance and depth to be the same at some points. But somewhere along the code strings, waterDepth is altered (as in when there are bubbles?). In addition, I'm thinking that DistanceToLand is not the same as clearWaterDistance, even though it may be used as a starting point in determining that value. Otherwise, why do the articles talk about casting distances of 3 or 5, and not 4 (pointing out that 4 happens only with bubbles)?

True, I haven't been reading the code. But I have read the articles closely. And all I've really been getting at is that there is something that doesn't fit the terminology. Whether that is because the code names things that aren't precisely what they say they are (a highly typical engineering practice - what does it matter what we call it if the compiler gets it right?), or code changes change those meanings, or something (gasp!) is wrong with the article wording (send it to the wordsmith). But the wordsmith here is saying that the words we use in the articles must mean what they do in English, not in code. So it's best to let the code do what it does, but bury its terminology, unless that terminology matches English. There's been too much leakage from code to Wiki text. And the code is opaque. (English word. Not applicable to engineers, of whom I used to be one, but which is not the job I'm doing here.) As a wordsmith, I'm saying that "depth" (in English), is not in any reasonable manner descriptive of "waterDepth", the code name. But just *exactly* what the difference is I still cannot tell. And these are not the relevant code pieces. Thanks for trying.

I'm going to continue to insist on erasing these technical names from the articles as much as I can get away with. The modders may need some of it, but that's for other articles. Butterbur (talk) 21:51, 30 January 2020 (UTC)

Butterbur, there are two relevant variables that we need to document. Conventionally, these two variables are called clearWaterDistance and depth. If you don't like those names, you could arbitrarily rename them to something different before presenting it to the end-user who reads the wiki. I'm not completely opposed to that (depending on what names you choose and how succulent & clear they end up being). But overall, arbitrarily renaming things to suit your liking is a little silly. If you just keep them as the names that they are, it will result in a cohesive lexicon throughout the Stardew Valley community, whether it be casual players who have spent 5 minutes to read the Fishing page, or min-max players who know everything about the game's mechanics, or modders working on the game, or reverse engineers working on the code. clearWaterDistance in particular is a mouthful of a term, but you must admit that it is more clear than calling it "distance". (The problem with just calling it "distance" is that it implies that it somehow has to do with how well you do on the bar-filling-animation-minigame-thing, which it doesn't, obfuscating the underlying mechanic.) --Zamiel (talk) 22:16, 30 January 2020 (UTC)

Well, my questions back to you are: document where? and for whom? You partly answered the second one. But all documenting needs to be targeted to an audience. So the third question always appears also. Document it why?

I'm not trying to be obstinate or working at odds. But what we have here is a case of collision between engineering "needs" or wishes, and the same for users (players). My take has been that the Wiki in its main is for players. That means it must be accessible to casual players as well as sophisticates. And it has to be about playing, not about game design, its mechanics (I hope I mean the same thing as you with that word), and most certainly not about modding. The latter list I associate with levels of engineering engagement that a player does not necessarily need to interact with. Some do, and that is what the Modding name space is for, and more power to them that do it. I prefer vanilla. And I write for vanilla. And that's my take on the article name space in the Wiki.

I can't agree that documenting variables is proper to a player-space arena. That's an engineering-level task. I would never "arbitrarily" rename anything. That's an activity that must be done thoughtfully or not at all. To rename according to my liking would be like expressing my opinion on anything and everything in articles. It's just not appropriate. Please do not suggest I'm going there.

You must realize that engineers name things what they do because it somehow suits them to write the code with those names. Engineers are intelligent at writing code. They are not always intelligent at naming things. And that doesn't matter to a compiler. It may matter to someone reading the code, trying to understand it, trying to modify it, etc. Those names do not matter to someone using the program. The player is confronted only with the text that the game puts up on the screen in some context or other. And there is the only place where the engineering wording hits the non-engineering world. Handling that interface is part of a whole specialty in engineering, UI design.

The article space must speak plain English (or whatever language it's in). And it must be compatible with the UI. But it need not be compatible with the engineering code. As I have already said, the code is using the word "depth" in a way that is incompatible with common English. That usage should not appear in the articles. If the word "distance" is to be used there, then it must mean what we commonly mean in English by it. We understand that word in real life by applying it to what we see. And I see that the distance a fishing rod travels to land in water is not what "depth", "waterDepth" or "clearWaterDistance" mean in the code. That's because their meaning is coded. We *shouldn't*, *mustn't*, *can't*, use such codenames in plain text contexts. They are technical terms for engineering purposes only. Let them be documented, but in the writing for engineering contexts. They don't belong in the articles.

The articles will have to use plain English to try to explain what is going on. There are ways the two worlds can reach towards each other, but there are limits, and engineers do not understand those limits well. Take it from a former engineer. The Wiki should not be a technical manual. It already smacks of that heavily in some ways, but if it's understandable and useful as it is, then it's not something to complain about. It will never meet all needs. If it tries, it will end up failing some while it satisfies others. In that contest, there would be no winners. Butterbur (talk) 23:21, 30 January 2020 (UTC)

I agree that the articles should use plain English; if you want to rename the two variables to something more plain-Englishy, then as I said above, I am not completely opposed to that. I also agree that the articles should be about the vanilla game. However, at the end of the day, a player who wants to be the best fisher that they can possibly be while playing the vanilla Stardew Valley with no mods (e.g. a min-maxer) needs to know about the two variables of "depth" and "clearWaterDistance" - I do not think that it is right to hide this information from them, or else you will be misleading them into making suboptimal fishing decisions and misleading them into not understanding the game properly. --Zamiel (talk) 16:12, 31 January 2020 (UTC)

Thinking about this more, one of the best ways to simply the information may be to converge on "depth" being the main terminology for describing a tile's goodness. And then, in the bubbles section, we "lie" and say that bubbles do not increase depth, but rather slightly increase the chances to find the more rare types of fish over the more basic ones. --Zamiel (talk) 16:21, 31 January 2020 (UTC)

See Fishing/Proposed for this change, which should simplify things. Also I moved out the angled shots into a separate section to try and move as much extraneous detail out of the introductory section as possible. --Zamiel (talk) 16:59, 31 January 2020 (UTC)

I also added back in the depth probability information that got deleted by either Margo or Butterbur, not sure. --Zamiel (talk) 17:18, 31 January 2020 (UTC)

ClearWaterDistance and quality

Taken from fishingRod:

     float num1 = 1f * ((float) this.clearWaterDistance / 5f);
     int num2 = 1 + this.lastUser.FishingLevel / 2;
     float num3 = num1 * ((float) Game1.random.Next(num2, Math.Max(6, num2)) / 5f);
     if (this.favBait)
       num3 *= 1.2f;
     float fishSize = Math.Max(0.0f, Math.Min(1f, num3 * (float) (1.0 + (double) Game1.random.Next(-10, 11) / 100.0)));

Taken from BobberBar (note, there is both a property and a parameter named fishSize. This is referring to the parameter passed in from FishingRod)

       this.fishQuality = (double) fishSize < 0.33 ? 0 : ((double) fishSize < 0.66 ? 1 : 2);

So interpreting it. Num1 is directly related to clearWaterDistance. Num2 is only used to determine num3, num3 is always 6/5 * num1, or 1.2 * num1. FavBait is not implemented. Therefore there is a direct correlation between clearWaterDistance and num3. A random number between 0.9 and 1.1 is calculated, and multiplied by num3 to give fishSize. If fishSize is < 0.33, regular quality. If fishSize is <0.66, silver, otherwise gold.

clearWaterDistance	fishSize
0	-	1	0.216 - 0.264 (regular)
2	0.432 - 0.528 (silver)
3	0.648 - 0.792 (mostly gold)
4 (impossible depth)	0.864 - 1.056 (gold)
5	1.08 - 1.32 (gold)

BlaDe (talk) 15:49, 30 January 2020 (UTC)

Just to clarify for people who are confused at the code snippet above, it appears that ConcernedApe intended for fishing level to (somehow) affect fish quality in some way. However, the code is bugged, and the "max" call always returns 6, so fishing level is completely irrelevant when determining fish quality. --Zamiel (talk) 21:59, 30 January 2020 (UTC)

Rats. Lost my last edit to mishandled conflict.

Thanks, BlaDe. Much closer to the issues.

BUT: "this.clearWaterDistance". Now, is that instance variable set to the original tile count of the distance from bobber to land (casting distance, as the article says)? Or has it been manipulated into the tweaked version that eliminates a distance of 4, as per the article? Also, has it taken into account bubbles, which may have increased it by one? Or are all of those questions irrelevant because the article was wrong to begin with?

Then: "this.fishQuality=". Ok, the instance variable is set. Is it reset, or tweaked, or otherwise altered to take other elements into consideration, or is this the final calculation of it? The code here does not reflect all the possible pieces. Or does that question reflect more errors in the article?

If ConcernedApe has left a bug here, I'll ignore it. What it is is what the game does until a bugfix. Let there be an announcement that it is a bug and what it should do, and then we can change the article when it's fixed. Butterbur (talk) 22:24, 30 January 2020 (UTC)

BTW, 4 is not an impossible depth, is it? Only if it is not a tile count. Only if it is not a clearWaterDistance. Only if the tile counts have been tweaked to eliminate it. And only at a stage when bubbles have not yet been considered. Or again, is the article that wrong?

Hmm. What about depth 6? You know, 5+bubbles. All gold, ok. But what are the odds now? Butterbur (talk) 22:37, 30 January 2020 (UTC)

Folks, I'm wondering if it's worth scraping out this level of detail, even for modders. It's certainly not worth writing it all into an article. I think I'll take another run at simplification there. Tomorrow. Or the next day maybe. I'm going to sleep on it a time or two. Butterbur (talk) 22:42, 30 January 2020 (UTC)

I am basing none of this on the article, just from reading the code. I am leaving it up to others to present the information.

this.clearWaterDistance = FishingRod.distanceToLand((int) ((double) this.bobber.X / 64.0), (int) ((double) this.bobber.Y / 64.0), this.lastUser.currentLocation);

The code for distanceToLand is posted above. It is good to note that there was a bug in 1.3, in that for the purposes of finding a fish to hook, the clearWaterDistance of the last hooked fish was used.

If you read through the code, you will notice that the way it is written it will never return 4. I did testing on this method in 1.3, and this particular method hasn't changed in 1.4

I inferred it above but will say it explicitly here. Bubbles do not affect fish quality. They affect the calculation around the fish that is hooked, and cut bite time in 4. Therefore for the purposes of fish quality you cannot have a distance of 4 or 6.

I also note there is one other place in BobberBar that updates fishQuality. If you are using the training rod, quality is reset to regular. Also, when pulling a fish from water, a perfect bumps silver to gold and gold to iridium. BlaDe (talk) 23:16, 30 January 2020 (UTC)

I've been reading through everything here and at Talk:Fishing trying to make sense of this whole discussion and the Fishing page editing stalemate. I've also pored through the game source code. But my interpretation of the code disagrees substantially with what it is stated here. Which in turn makes me question alot of the subsequent analysis.

I have two problems with this specific section:

• I can't find any basis for the claim that the distanceToLand function can never return a value of 4.
  • Based on the code (e.g., #Depth above), possible values of r.Width are 3, 5, 7, 9, or 11 -- which will result in values for num of 1, 2, 3, 4, or 5, respectively; plus, num is set to 6 if all rectangles fail. Given that the function return value is num-1, the possible values are 0, 1, 2, 3, 4, or 5.

• The fishing level does have an impact on fish quality, per the code at the start of this section. Game1.random.Next(num2, Math.Max(6, num2)) does not return a fixed value of 6 -- rather, it returns a random number in the range num2 to max(6,num2). (random.Next documentation)
  • For example, at fishing level 0, random.Next() should return a value anywhere from 1 to 6.
  • Furthermore, I don't think there's anything bugged about max(6,num2) -- for FishingLevel 12-13, num2 is set to 7. Without having max(6,num2), the random.Next function would fail with an ArgumentOutOfRangeException.

Ultimately, however, my biggest concern is that the fishSize numbers in the above table do not match up with my in-game experience -- and I believe in-game experience always trumps analysis of code. I clearly remember a character with fishing level 6 spending a couple days trying to get a gold-quality sturgeon as a birthday gift for Willy and getting nothing but silver-quality, even though I was doing maximum-distance casts every time. Even the non-sturgeon fish that I was catching were mostly silver. More generally, I've never found gold-quality fish to be commonplace until I max out my fishing level. Nebulous Maestress (talk) 01:25, 5 March 2020 (UTC)

Thank you for sense checking. I obviously missed the result of the Max being used as an upper limit in the Next call. Oops. This was something I never tested in game, I will revisit the above table in time.

The clearWaterDistance though I did test in game (with a custom mod that printed the current value off the fishingrod)

Let's assume that a tile immediately beside the bobber tile is land. The width of the rectangle is 3. flag gets set to true, num gets set to 1 (3/2 = 1.5 cast to int). Rectangle gets inflated to have a width of 5, but as flag is true the while loops breaks. Width is not > 11 so num stays the same, and num - 1 , or 0 is returned.

Now let's assume that a tile 2 away fro the bobber tile is land. Carrying on from the last example, the rectangle width is 5. Flag = true, num = 2, rectangle inflated to 7, still < 11 so 1 is returned.

Repeat until the rectangle width is 11 and a land tile is within range. num gets set to 5, which we would expect to be returned as 4 after num -1. However, the rectangle gets inflated before we stop looping in the while. Now width is 13, so num gets set to 6, which will return as 5 after num - 1. This will never return 4.

I also replicated this code to programatically create the distance maps. I had an image ready for distance4, but this was never used.

Please let me know if you see any holes in this logic. BlaDe (talk) 04:00, 5 March 2020 (UTC)

Aha, at last I get why 4 isn't possible. I overlooked the double-loop -- assumed break was terminating the while loop, but instead it terminates the foreach loop. Perfect case to use 'break 2', except C never bothered to implement that useful construct. The additional validation of in-game testing is extra-helpful here, but I hadn't seen any mention of that previously. Thanks!

Meanwhile, I've been testing this in-game -- focusing on hard statistics for the effect of fishing level on fish quality, instead of relying on my anecdotal evidence (and questionable memory). I thought I mostly understood what was going on in version 1.3. But version 1.4 has changed much more than I expected, and I've been scrambling to make sense of things again.

In particular, I suspect 1.4 has changed the clearWaterDistance values. Although the DistanceToLand function hasn't changed from 1.3 to 1.4, the values passed into the function have changed -- both tileX and tileY are larger by 1 in 1.4. Note the 1.3 code:

 this.clearWaterDistance = FishingRod.distanceToLand((int) ((double) this.bobber.X / (double) Game1.tileSize - 1.0), (int) ((double) this.bobber.Y / (double) Game1.tileSize - 1.0), this.lastUser.currentLocation);

Versus the 1.4 code:

 clearWaterDistance = distanceToLand((int)(bobber.X / 64f), (int)(bobber.Y / 64f), lastUser.currentLocation);

Since you mentioned that most of your testing was in 1.3, I'm wondering what version was used to generate BeachDistance.png? The results I'm getting in-game from version 1.4 will make alot more sense if the map has shifted. Nebulous Maestress (talk) 07:54, 6 March 2020 (UTC)

The beach distance was on 1.3, and I will need to reconfirm the sources of my map tiles for the generated images in my google drive.

The generated images cycled through the map, calculating what the distance is for each tile. We will need to get to the bottom of that version difference... Was the value of the bobber point set differently? I don't have access to my full dev tools right now unfortunatelyBlaDe (talk) 18:29, 6 March 2020 (UTC)

There are two code changes I've found. One is the above-mentioned change when calling distanceToLand, with v1.3 using (bobber.X/64-1,bobber.Y/64-1), and v1.4 using (bobber.X/64,bobber.Y/64).

Second, the position of the in-game bobber image has been shifted by 48 pixels. In v1.3 temporarySprites.Add was invoked at (bobber.X-80,bobber.Y-80); in v1.4 it's at (bobber.X-32,bobber.Y-32). In my tests I'd repeatedly done maximum-distance casts at the exact same location so many times that this change was very evident as soon as I upgraded to v1.4. A maximum-distance cast to the west ends up nearly one tile further away in v1.4 than it did in v1.3. But this visual change (at least in westward casts) is not the whole story.

Some specific examples that you might want to test against:

• There's a small, single rock immediately west of Willy's store (one tile south of a seaweed patch). On :File:BeachDistance.png that rock is clearly at clearWaterDistance=2. I've now done 50+ fishing casts where my bobber has landed directly on top of that rock, and the numbers all say cWD=3 not 2. More generally, the entire cWD=5 region between the piers appears to have shifted one tile south and one tile east.
• One tile north and two tiles west of that rock there's a patch of seaweed at cWD=5. In v1.3, my level-4 character would stand at the very edge of pier (the pier next to Willy's) and a maximum distance cast would land on that seaweed, just past half-way, and always be at cWD=5. In v1.4, the same maximum-distance cast now lands nearly one tile further east -- and that location in v1.4 is at cWD=4. As far as I can tell, internally a maximum distance cast goes the same distance -- e.g. bobber.X and bobber.Y are the same. The visual change in cast distance is consistent with the 48-pixel image shift. But if the visual change were the only change, cWD values would be the same. The fact that a maximum-distance cast now lands at cWD=4 instead of cWD=5 says that there's a second change somewhere -- I think it's consistent with the change in how distanceToLand() is called, but my brain is refusing to process X/Y conversions any more.

If screenshots are necessary to explain where exactly I'm talking about, let me know. I'm also finalizing a mega-post about my test results in general, which should help explain why I'm claiming that I know the cWD values of specific spots.

By the way, one suggestion if you end up remaking beachDistance.png: could you perhaps flip the color scheme, so that cWD=5 is nearly transparent, and cWD=1 is opaque? I think being able to pick out landmarks (rocks, seaweed) in cWD=5 is much more useful -- for example, to find a target if you want to fish for iridium. Nebulous Maestress (talk) 22:44, 6 March 2020 (UTC)

I don't have time to read/respond/theorise on everything right now, but I have made these: https://drive.google.com/folderview?id=1V2QyBBabV6z0YtQobJzmNfpzESHV3Zes I need to recheck my program to see if I sourced the tile information from 1.3 or 1.4. Also feel free to suggest alternate colour schemes.BlaDe (talk) 01:55, 7 March 2020 (UTC)

NebulousMaestress, what I have been saying about all this stuff has mostly to do with terminology and concept, and how the articles should be written for clarity. On Talk:Fishing, I define "casting distance" as a "true" distance, backed up by the UI. My claim is that none of these other "distances" are really distances at all, at least not in the sense that we would want to refer to them in main articles. And that is specifically *because* you cannot get a value of 4 in most cases. This in itself is enough to demonstrate that the code is busy setting derivative values, for purposes that lead somewhere else, and not for describing actual distances. For example, clearWaterDistance or distanceToLand are not real distances because the values do not represent what the UI tells you - what the player sees.

Casting distance is from the player to the bobber, and this is the root. Only once the bobber has arrived is it possible to measure distance to land, because (in natural language), that would be from the bobber back to the closest land tile. That is what the variable name clearWaterDistance leads you to think about, but that variable does not represent that concept. For one thing, it isn't set to 4, even when a cast is to a place 4 tiles from the nearest land. The variable actually means something else. It's an internal value the game wants to have in order to calculate something else. So you have to look not only at how it is set, you have to find where it is used and what effect its values have on the downstream calculation. Only then can you determine what it is for and how it affects play. The same thing goes for "depth", which is in no way a real depth of any kind.

As far as I can see, these values affect the frequency of the various quality levels of the fish you catch. My own experience at fishing level 6 matches your description pretty well, so I think I can say that matches what I have seen of the code. Interesting that you found code differences between v1.3 and v1.4. (Nice!) But was the code executed by the same object? Perhaps v1.4 calls it in the FishingRod code, while v1.3 is from somewhere else? References to names that appear the same might not be the same in that case.

At any rate, my argument with Zamiel has mostly been to say that the variables are not real distances and we should not say they are. So the discussion of the variables belongs more in modding talk than elsewhere, and care should be taken to speak of the variables as variables and not as distances. Because the code's variable names and the concept of distance do not match up. Butterbur (talk) 22:08, 7 March 2020 (UTC)

I had been slowly working my way up to the whole Talk:Fishing discussion; I felt a need to first figure out what's happening in-game before wading into a very long discussion about how to document it.

In short, I agree completely that using "distance" in plain-English for clearWaterDistance is wrong (and "casting distance" is even worse). I've been using clearWaterDistance solely because that's the variable name in code.

And yes, the code changes I've highlighted are within the same object/function. Nebulous Maestress (talk) 23:15, 7 March 2020 (UTC)

Music to my ears! Thanks! I think I think you can ignore Talk:Fishing from here on. Butterbur (talk) 00:50, 8 March 2020 (UTC)

I'm guessing this is now the best thread to continue with general 'where-to-go-from-here' feedback:

• Details on clearWaterDistance/etc. do belong on the wiki, but on Fishing Strategy, not Fishing. Per Zamiel, the target audience is a min-maxer, not an everyday player. You can successfully play the game without knowing anything about it, so it doesn't belong on Fishing.
• We shouldn't add information to the articles until we're sure it's correct. False information is worse than no information. Right now I don't trust any of the maps of clearWaterDistance -- my best guess is that only 4 of the cWD=5 tiles on File:BeachDistance.png are truly at cWD=5. We need more validation from in-game experience (especially more platforms), such as:
  • confirmation that specific fishing spots really have better quality fish
  • ideally, confirmation that better treasure is possible at specific locations
  • tests of exactly where legendary fish (specficlally those with waterDepth checks) appear. Do bubbles truly make legendary fish spawn closer to land? (Is there any other case where a player is really going to care that bubbles increase waterDepth by 1?)

In other words, think specifically about how this information is going to help players / be used by players, and then do some spot-checks.

• As for the semantics:
  • 'Casting distance' for clearWaterDistance is completely incorrect; at least half the bad information out there right now stems from misleading uses of casting distance.
  • How about something completely neutral like 'score'? "Each cast is assigned a score of 1, 2, 3, or 5". If/when waterDepth and effects of bubbles are relevant, that could be an 'adjusted score' or 'modified score'. Extra benefit: 'score' isn't used on any fish-related page right now (actually even wiki-wide I'm shocked how few pages use it). Nebulous Maestress (talk) 00:14, 9 March 2020 (UTC)

I won't have time for a couple of weeks to have any in depth input (so much involved in moving house...), but there are a few things I can say off the top of my head. I trust my diagrams for fishing "score" for all locations based on the tile. What I no longer trust, and was taking for granted, is how the tile that the bobber is on is selected, and how it relates to what is seen visually.

I am confident to say that bubbles do increase "score" in regards to legendary fish, however I agree tests will be beneficial.

Something to note, a streamer was using my distance map for the mountains, and was able to hook a legend in the 5 spot near the mine entrance.

Do we know of a mod that outputs the current location of the bobber/the values of the location used in distanceFromLand()? If it is still a question when I am setup again I could alter one of my mods. BlaDe (talk) 04:46, 9 March 2020 (UTC)

My take on "Details on clearWaterDistance/etc. do belong on the wiki, but on Fishing Strategy, not Fishing. Per Zamiel, the target audience is a min-maxer, not an everyday player." Do I take it aright that this is a suggestion that "Fishing Strategy" is to become an article exclusively for min-maxers? Sorry, but I think that would be a mistake. There's a good deal of strategy that would be useful to the ordinary player, and I'm not sure that can all be crammed onto "Fishing", if that's the plan. Also, the article name "Fishing Strategy" does not itself suggest min-maxing, but something general. And if you're wanting an entire article for what is of interest only to min-maxers, that's fine, but such article(s) should imply that directly, and not mislead. How about a new article? Call it "Min-maxed Fishing"?

As to cWD and "depths" of various kinds, "score" and variants seem to me a great approach for article terminology. If a modder wants to tweak code and needs to know, modding docs could give a translation from article term to variable name. Butterbur (talk) 05:51, 10 March 2020 (UTC)

One more: as for benefits from specific fishing spots, I have always had the impression that certain ones had the benefit of more-frequent strikes. I picked that idea up from some article language half-forgotten from 2 or 3 years ago. Is it now known to be false? If not, perhaps that's another thing that needs verification. More bites are a good thing, yes? Butterbur (talk) 06:04, 10 March 2020 (UTC)

Old wives tale I'm afraid

     float val2 = (float) Game1.random.Next(FishingRod.minFishingBiteTime, FishingRod.maxFishingBiteTime - 250 * who.FishingLevel - (this.attachments[1] == null || this.attachments[1].ParentSheetIndex != 686 ? (this.attachments[1] == null || this.attachments[1].ParentSheetIndex != 687 ? 0 : 10000) : 5000));
     if (isFirstCast)
       val2 *= 0.75f;
     if (this.attachments[0] != null)
     {
       val2 *= 0.5f;
       if ((int) ((NetFieldBase<int, NetInt>) this.attachments[0].parentSheetIndex) == 774)
         val2 *= 0.75f;
     }
     return Math.Max(500f, val2);

The result of this goes onto timeUntilFishingBite. Tile location does not come into it ( I excluded the code around fish ponds) BlaDe (talk) 10:06, 10 March 2020 (UTC)

Not surprised. Meets my experience. Thanks for the verification! Butterbur (talk) 15:00, 10 March 2020 (UTC)

Btw, fwiw, about "old wives". Many are not superstitious. Never really were, more than anyone else. Which implies that that very old saying was a commonly-accepted slur directed towards old women. I think this one is often overlooked as such and just wanted to direct attention to it. I figure you'd be with me on that, 'cause the older the habit, the harder it dies. Didn't even occur to me until hours later. Butterbur (talk) 16:54, 10 March 2020 (UTC)

Huh, I thought the old was referring to the tale, not the wife. I suppose it could be taken either way BlaDe (talk) 18:52, 10 March 2020 (UTC)

Well, if it was the tale that was old, it was the wife who was telling it. It is still her story. Have men not also spread superstitious stories? Yes, but not all men. And not all women. Why is the wife singled out? Because then it is the more suspect. Hence, the slur. Just in case there's any question, I am male. And if it was the wife who was old, you could also make a case that it's also a slur against the elderly.

You see? We scarcely give it a thought, but when we do think about it, it comes up wrong whatever way you look at it. If it walks like a duck and quacks like a duck... as another saying goes.

Hmm. Makes me think of slime. It slicks, it sticks, and it makes filthy. Well, we can take out our Galaxy Swords and soon take care of that. :) Butterbur (talk) 23:08, 10 March 2020 (UTC)

Lots of points; my brief feedback:

• As a wife-who-some-would-call-old, thanks for defending my reputation Butterbur ;)
• One extra adjustment that's made to bite time: timeUntilFishingBite /= 4f if you land on bubbles (aka fishSplashPoint).
• Re: article for all of this (see also). My main point was just not on Fishing, because Fishing should be general audience, and this isn't general audience. Min-maxers are one example of a specialized audience that cares about strategy details (said as someone who also probably qualifies as a min-maxer).
• BlaDe, thanks for the map-related comments, and I agree fully; apologies if my comments have made it sound otherwise. My primary intent has been to emphasize that shifting the maps by just one tile changes the cWD values at nearly all reachable locations.

Nebulous Maestress (talk) 16:02, 11 March 2020 (UTC)

Quality and ClearWaterDistance

This started off as followup to the previous section -- I wanted to test in-game whether fish quality was affected by fishing level, and more generally confirm whether the equations for fFishSize worked. But I ended up flipping everything backwards: now I'm using in-game fish size/quality data to test clearWaterDistance maps such as File:BeachDistance.png. And I'm finding discrepancies.

Last minute note: to the best of my knowledge, my final tests were all using iOS version 1.4.5.143. I don't know how/where to confirm version in-game, but I did an app update on Mar.5 and redid all my tests after that point (and my iPad doesn't say there are any new updates). Why does that matter? Because per the app store, 1.4.5.145 was released on Mar. 3 for iOS and Fixes a problem with fishing. I'm not seeing any documentation details, plus I don't have the 1.4.5.145 code.

Definitions

• cWD: clearWaterDistance. Sometimes described as 'tiles from nearest land', although I don't even think that's accurate.
• S/G: gold-quality fish if cast is perfect; silver-quality fish otherwise
• G/I: iridium-quality fish if cast is perfect; gold-quality fish otherwise
• fFishSize: the value (range 0 to 1) predicted the equations in #ClearWaterDistance and quality. I'm opting to name this variable fFishSize instead of fishSize because the latter name is also used in code to describe the fish size in inches. fFishSize directly determines the fish quality, but is only one factor in the final fish size.
• perfect: A fish caught by a perfect casting mini-game. My testing relied nearly exclusively on perfect fish -- I ignored fish unles "Perfect" appeared at the end of the mini-game. So (unless explicitly stated otherwise), a gold-quality fish means S/G, a.k.a. an "upgraded" silver-quality fish, a.k.a., fFishSize was less than 0.66.

Fish Quality Conclusions

• Fish quality is primarily controlled by clearWaterDistance. This is old news, but thought it worth repeating before starting to obsess about secondary factors.
• Fish quality is affected by fishing level. This is pretty easy to prove conclusively. If fishing level were irrelevant, every fish caught at cWD=5 would be G/I in quality -- silver fish would be impossible at the location, for any player. But when I tested at fishing=4, 5 of the 20 fish were gold (S/G) quality. (At fishing=10 from the exact same spot, all 10 fish were iridium and maximum size, proving that the location was indeed cWD=5).
• Buffing fishing level, including buffs past level 10, improves fish quality, i.e., I confirmed the v1.4 change-log entry 'The effect of fishing level on fish size no longer caps at 10.' In v1.3, the fFishSize equation was slightly different, and imposed a maximum fishing level of 10. I tested specfically at cWD=3, comparing level=10 to level=13. At level=13 all 20 fish were G/I, but at level=10 1 of 20 fish was S/G. Statistically, my sample size is a bit small to be conclusive, but the range of fish sizes provide very clear additional evidence.
• Training Rod fish are always base quality. Not a surprise, but I did confirm via tests, even for perfect catches. I did find a minor bug with the Training Rod: the fish are not mimimum-size fish (details below).
• Level 0 players can land gold (even iridium) quality fish. Unlike in v1.3, a level-0 maximum-distance cast to the west can reach cWD=5 -- at which point the chance of G/I fish jumps from 1% to 41%. In tests my level 0 character caught a 17" gold herring and a 14" gold anchovy (both non-perfect casts), plus three silver fish, before leveling up. I then reloaded and went to the mountains, so I'd have a chance at a level-0 perfect catch: I caught a 51" iridium carp on my 6th try. Those sizes and qualities are only possible if the casts reached cWD=5.

Note that even though I'm concluding that numerically fishing level matters for fish quality, arguably the effect was only relevant in v1.3. In v1.3, it was nearly impossible to catch G/I fish at low levels (1% chance only for maximum-distance casts at specific locations). But in v1.4, gold quality fish are almost easy to catch at levels 0/1, between perfect-fish quality upgrades, and the ability to reach cWD=5 at level 0. Good players should even be able to rope in iridium fish right from the start of the game.

Full Equation Predictions

I generated a huge table of predicted fish size/quality to verify my test data; I'm dumping it all here. I added Herring and Sardine columns because those were most of my test data. The real fish sizes make it clear that the values found at each depth are distinctly different.

The most extensive tests of this data have been done for cWD=3 and 5, and fishing levels 4, 10, 13 -- and the collected data agrees completely with predictions. I've also done random spot checks elsewhere (e.g., some fishing at level=0, but I don't have the patience to do tons of perfect catches at level 0).

cWD	Fishing Level	fFishSize		Fish Quality (% chance)			Perfect Fish Size (inches)
		min	max	Base	S/G	G/I	Sardine	Herring
1	0-1	0.04	0.22	100	0	0	2 - 4	9 - 11
1	2-3	0.07	0.22	100	0	0	2 - 4	9 - 11
1	4-5	0.11	0.22	100	0	0	3 - 4	10 - 11
1	6-7	0.14	0.22	100	0	0	3 - 4	10 - 11
1	8-9	0.18	0.22	100	0	0	3 - 4	11
1	10-11	0.22	0.26	100	0	0	4	11 - 12
1	12-13	0.25	0.31	100	0	0	4 - 5	12
1	14	0.29	0.35	67	33	0	5	12 - 13
2	0-1	0.07	0.44	73	27	0	2 - 6	9 - 14
2	2-3	0.14	0.44	67	33	0	3 - 6	10 - 14
2	4-5	0.22	0.44	56	44	0	4 - 6	11 - 14
2	6-7	0.29	0.44	33	67	0	5 - 6	12 - 14
2	8-9	0.36	0.44	0	100	0	5 - 6	13 - 14
2	10-11	0.43	0.53	0	100	0	6 - 7	14 - 15
2	12-13	0.50	0.62	0	100	0	7 - 8	15 - 16
2	14	0.58	0.70	0	67	33	8 - 9	15 - 17
3	0-1	0.11	0.66	42	57	1	3 - 9	10 - 16
3	2-3	0.22	0.66	27	71	1	4 - 9	11 - 16
3	4-5	0.32	0.66	3	95	2	5 - 9	12 - 16
3	6-7	0.43	0.66	0	98	2	6 - 9	14 - 16
3	8-9	0.54	0.66	0	95	5	7 - 9	15 - 16
3	10-11	0.65	0.79	0	10	90	9 - 10	16 - 18
3	12-13	0.76	0.92	0	0	100	10 - 12	18 - 20
3	14	0.86	1.00	0	0	100	11 - 13	19 - 21
5	0-1	0.18	1.00	20	39	41	3 - 13	11 - 21
5	2-3	0.36	1.00	0	49	51	5 - 13	13 - 21
5	4-5	0.54	1.00	0	32	68	7 - 13	15 - 21
5	6-7	0.72	1.00	0	0	100	9 - 13	17 - 21
5	8-9	0.90	1.00	0	0	100	11 - 13	19 - 21
5	10-11	1.00	1.00	0	0	100	13	21
5	12-13	1.00	1.00	0	0	100	13	21
5	14	1.00	1.00	0	0	100	13	21

Notes:

• Fishing level includes any buffs
  • (In version 1.3, buffs past level 10 were ignored by this calculation).
• The size ranges shown are only valid for perfect casts. Sizes will generally be smaller on non-perfect casts.
• cWD=4 has been excluded because it does not happen
• Note that the random.Next() function behaves (in my mind) bizarrely. Namely, random.Next(n,6) will only return a value of 6 if n=6: random.Next(4,6)=[4,5]; random.Next(5,6)=[5]; random.Next(6,6)=[6]. It's what's documented, and the results come out right, but it just seems wrong to me.

Fish Sizes

Fish sizes are basically irrelevant -- they have no impact on game play, and I may be the first player to ever pay this much attention to fish sizes. However, I was driven to collect fish size data by my scientific obsession with robust, statistically-valid tests: it's nearly impossible to prove an equation works using percent chances, but easy to prove by testing fish sizes. Except there are a few extra complications hiding in fish sizes.

The short version is: fFishSize only determines the final fish size in inches for perfect catches. In that case, the code is:

  fishSize = 1 + (int)((float)minFishSize + (float)(maxFishSize - minFishSize) * fFishSize);

For non-perfect catches, the fish size is decreased (but the fish quality is not).

In case anyone else is tempted to start watching fish sizes, here's the full scoop:

• During the fishing mini-game, BobberBar decreases the fish size by one inch for every 0.8 seconds that is spent off-fish (and off-treasure if you're using a Treasure Hunter lure). So the longer it takes to reel in the fish, the smaller the size. Fish quality is not changed.
  • Trivia: this is the only way to catch a true minimum-size fish (for example, a 1" sardine) -- but your 1" fish might be silver or gold in quality.
• The training rod is supposed to force all fish to be minimum size, via this code in BobberBar:

  if (beginnersRod)
  {
     fishQuality = 0;
     fishSize = minFishSize;
  }

Except it's bugged because fishSize is an ambiguous variable name, and the code modifies the wrong variable. It would have to be this.FishSize = minFishSize to have the desired effect. I've confirmed this bug in-game (e.g., caught a 21" herring using the training rod).

• A super-obscure fish size bug in v1.3 has been fixed in v1.4. The code presumably intended to prevent maximum-size fish from being caught on non-perfect catches, but didn't work. For example, instead of preventing 21" herrings from being caught, it prevented 20" herrings from being caught unless you made a perfect catch.
  • Correction: I goofed when looking in the new code, because this bug is completely unchanged in v1.4. And the bug has (has always had) one visible effect: all legendary fish are 1" smaller than their supposedly "fixed" size -- in fact the "fixed" size is completely impossible (e.g., crimsonfish data says minFishSize=maxFishSize=20. But unless you miraculously are able to do a perfect catch, you'll always catch a 19" crimsonfish. If you manage a perfect or very-near-perfect catch you'll get 21", never 20").

clearWaterDistance, round 386

I started out by taking the File:BeachDistance.png, picking some locations with cWD=3 and cWD=5, and catching fish from those locations. But even early on (in v1.3) I noticed oddities -- fish caught in one half of the tile matched expectations exactly, but fish from the other half didn't match at all. Then when I moved to v1.4, values across the entire tile changed -- none of the values looked like cWD=5, but instead they all matched cWD=3 exactly. (Another 1.4 change is that I noticed that my maximum-distance casts were landing in different locations)

At this point, I trust the fFishSize equation, but not the available cWD maps. Instead, I'm using fFishSize to map out the "real" in-game values of cWD. How? With fishing=10, I aim my bobber to land in a specific location, make a perfect catch, then check the fish size. A maximum size fish (e.g., a 21" herring) means the spot must be cWD=5. I've done enough tests now to trust that I could catch 100 perfect fish from that exact spot, and every one would be maximum size. I've also done enough tests to trust that as I start moving my bobber around, the fish size will immediately change to a smaller value (e.g., 16"-18" for a herring) if my bobber lands outside of cWD=5. Every fish size is uniquely associated with a single value of cWD -- as long as it's a perfect catch. It's just a tediously slow process.

I want to emphasize here that I'm treating the displayed in-game location of the bobber (the little white-and-red circle) as the "true" bobber location. From a code perspective this may be backwards, but I think it's the only valid approach when considering how you play the game. Anyone who's interested in cWD is going to identify some type of landmark in the water (rocks, kelp patch) and try to make their bobber land on top that feature.

An example to demonstrate my point (and also perhaps explain why I think any of this matters). Somebody desperately wants iridium ore, and finds out that it's possible to fish for it at cWD=5. So that player pulls up the map at File:BeachDistance.png and says, "Aha, there's a patch of kelp below the east end of the pier that's in cWD=5. I'm going to aim my bobber to land in the middle of that kelp and keep fishing until I catch some iridium." But thousands of fish and hundreds of treasure chests later, there's no iridium -- because the tile (in v1.4) is actually cWD=3.

Worse yet, in v1.3 players could hope to get iridium from that spot -- but only if the bobber landed in the far (southern half) of the tile. I'm guessing this is behind some of the conflicting stories about iridium catches.

Translating the in-game bobber image into clearWaterDistance involves a few conversions -- and the code for those conversions has changed in v1.4:

• The bobber image is offset from the internal Bobber NetPosition variable. I believe this is the v1.4 line of code that creates the bobber image (in FishingRod::DoFunction):

   location.temporarySprites.Add(new TemporaryAnimatedSprite(28, 100f, 2, 1, new Vector2(bobber.X - 32f, bobber.Y - 32f), flicker: false, flipped: false));

Specifically (bobber.X - 32f, bobber.Y - 32f), i.e., a 32 pixel offset (but in v1.3, this same line of code had an 80 pixel offset). Is that the offset to the corner of the animation PNG? How big is the PNG? Where within the PNG is the visible bobber circle? I'd guess the circle is maybe 16 pixels across, so unless the PNG has a ton of empty space to make it 64 pixels across, I'd guess that the center of the visible circle is displaced from the internal code position. Any modders who can shed some light?

• clearWaterDistance is not calculated directly from the internal Bobber variable. It's calculated by the function distanceToLand -- which takes as arguments tileX and tileY that are derived from Bobber. The v1.4 code:

   clearWaterDistance = distanceToLand((int)(bobber.X / 64f), (int)(bobber.Y / 64f), lastUser.currentLocation);

But in v1.3, the passed-in values were both 1 unit smaller:

   clearWaterDistance = distanceToLand((int) ((double) bobber.X / (double) Game1.tileSize - 1.0), (int) ((double) bobber.Y / (double) Game1.tileSize - 1.0), lastUser.currentLocation);

So mapping clearWaterDistance values isn't easy. Which means it's even more important to have some way of spot-checking/validating maps against what happens in-game. And when I do that, I get discrepancies.

As far as I can tell, in v1.4 the map at File:BeachDistance.png needs to be shifted roughly one tile east and one tile south. Specific details that I've tested:

• South of Willy's shop, cWD=5 starts 5 tiles south of the pier, whereas the map says it starts 4 tiles south. For example, a bobber needs to land in the tile containing a big rock.
• Immediately west of Willy's shop, cWD=5 starts 3 tiles out, not 4. The tile with a three-rock formation is at cWD=5. The tile with a single small rock is at cWD=3.
• In between the piers, the transition from cWD=5 back to cWD=3 happens 5 tiles from the western pier, not 4 tiles.
• I tested some casts north from the island in Cindersap Forest. cWD=5 starts 3 tiles north of the island, i.e., one tile before the change in water color. The five-rock tile (north of the lilypad) is at cWD=5, not cWD=3.
• The transition between cWD values happens when the middle of the bobber is roughly on the tile boundary, but in-game it's hard to precisely know where the tile boundary is located.

For historical purposes (and/or to help people understand why/how gameplay has changed from v1.3 to v1.4), I think in v1.3 the map was only one-half tile off -- but I didn't fully realize what was happening, so I only effectively tested cWD values across a single tile. Specifically:

• Southwest of Willy's shop there's a tile with three rocks that File:BeachDistance.png places at cWD=3. But actually the dividing line runs across the middle of the title. A bobber that lands dead in the middle of the three rocks is in cWD=3. But if the bobber starts to overlap the northern two rocks, it's at cWD=2.

Final Thoughts

Apologies for the super-long post, but I felt I was upending a few apple carts and wanted to provide enough details in case others want to check for themselves.

My main takeaway is that we really don't understand clearWaterDistance yet. Values have changed from 1.3 to 1.4 (and possibly not intentionally -- it's not documented in the change logs), so any 1.3-based analyses/inferences need to be rechecked. Until that's done, adding any information about clearWaterDistance to wiki articles seems reckless -- especially hard data, such as what level you need to be reach cWD=5, or maps of where to find cWD. Even our plain-English definitions of clearWaterDistance have become invalid -- it's not really 'tiles from nearest land' any more; if the nearest land is to the east or north, it's 'tiles to the strip of water next to the land'.

But the continuation of that argument belongs somewhere else, e.g. Talk:Fishing. Once I catch my breath.... Nebulous Maestress (talk) 22:52, 7 March 2020 (UTC)

The clearWaterDistance changes I've described are not specific to v1.4.5.143. My iPhone does not have the latest update, so it's probably v1.4.5.142. Level=0 tests on the iPhone duplicate those on the iPad: a max-distance cast to the west lands more than 3 tiles away from land and I caught multiple gold-quality non-perfect fish -- the tile is cWD=5.

(For some reason the one visible difference in .143 is some buggy-seeming animation of the character while fishing -- the character looks left while casting right, then flips around).Nebulous Maestress (talk) 23:24, 7 March 2020 (UTC)

A super super-long post! Thanks for going to all that effort! I have certainly not understood clearWaterDistance either, at any time. I could only see that it was obscure and not as it was being described. Great job digging out details! The "not really 'tiles from nearest land'" part is what I never was able to get across. I'm certain you're on the right track. Once we know what it really is, we'll have a shot at describing it. But until the code settles, that will be tricky. Sounds like they're doing good things in that arena. Perhaps CA can give some guidance on development timing. It looks complex enough that it could take some time, but maybe that's just looking from the outside. Butterbur (talk) 01:16, 8 March 2020 (UTC)

Prime Fishing Locations

Based on the information about depth, even though it's not fully understood, the prime locations pictures are in some cases completely wrong. Most glaringly, there's no advantage to fishing by the rock in the ocean - so can we please at least remove the ones based on hearsay and myths?

Ideally I'd like to see the maps with color coding for depth of each square. --Unsigned comment by Raist (talk) 12:25, 15 July 2020

What timing! A change for this is being mocked up on my user page. BlaDe (talk) 19:56, 15 July 2020 (UTC)

Honestly, I don't care what replaces it - I just want the strictly misleadingly incorrect info removed ASAP. If one more person tells me that the wiki says the ocean rock is better I'm gonna delete it. Your pics are an obviously more informative replacement. I'd suggest a different color grading, and maybe even highlighting a few ideal spots to fish in and what fishing is the minimum to reach the best depth from that spot, but I'm more concerned with removing the bad first. FWIW, on your town map, the bushes in the bottom left by the river are missing...?Raist (talk) 22:14, 15 July 2020 (UTC)