Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A fish percentage based off of results #79

Open
FinalDoom opened this issue Jun 26, 2013 · 1 comment
Open

A fish percentage based off of results #79

FinalDoom opened this issue Jun 26, 2013 · 1 comment

Comments

@FinalDoom
Copy link
Owner

Original report by Christopher White (Bitbucket: Christopher White, ).


I'm not sure whether or not suggestions should go in here, but as I can't see anywhere else to make a comment I am posting it here.

I would like to see the stats page be somehow coded into a way that is does this

  1. Uploads stats page to server
  2. Server calculates Fishing Skill + Fish/other wanted + Gear equipped
  3. After calculating that it uses some algorithm to give a percentage of success rate based on those factors.

Example:
I go to Port Windurst and get Bastore Breams, My set up is Lu Shang rod, Sinking Minnow, and Fishermans gear for each slot. My fishing level is 58 and I caught/release 1400 items, 1200 being ignored and 200 being caught. That is a 16% catch rate. Now we add that to everyone who uses FD in this way. Say 300,000 Ignored items came up and 21,000 breams came up, the percentage would be 0.07%, which would be shown in the program.

Issues: (That I can think of)
Now I can understand the issues in this, as not all players fish in the same area, many players have high fishing levels and don't fish in certain areas or just don't fish anything that doesn't make profit, and that gear/rod/bait/level are specific, so it would require a few adjustments to where they don't factor exact level but a broad amount, like within 5 of the current level.

@FinalDoom
Copy link
Owner Author

Original comment by FinalDoom (Bitbucket: FinalDoom, GitHub: FinalDoom).


It's as good a place as any to put suggestions. The people that may be keeping it up in the future will get these pushed to their copy as well, I believe.

Interesting idea. First thing for anyone interested in implementing it is that no processing should be done on the server, it should all be done on the client. The server can collect data and spit it back out. Anything else is too much for the EC2 instance it's on, and unnecessary anyway. To rewrite your idea:

  1. Branch FishStats (probably to a separate file, since that deals mostly with the stats page) to keep a collection of similar stats, keyed by area+rod+bait or just area+bait. The rod is more important for catch rate than anything. We can track which fish bite, whether or not we want to catch them: bite rate. If a fish is marked as wanted, we can also track catch rate (not as useful unless you factor in skill+gear, and it would only be updated for those wanted fish).

  2. Upload the key + sets of (fish name, bites, catch attempts if applicable + losses or whatever else) to the server. The server can have a procedure that takes an insert and does sum operations to make it a total, so that there is only one round of network use. Theoretically, track this info in a pendingStats.xml file, and only upload every X (somewhat large, 25, 50, etc) number of catches.

  3. Info can be downloaded at "start." Possibly displayed along side wanted list stuff (hard and annoying to UI and code and rewrite) or on a new stats tab that just lists all fish in the area+rod+bait, plus their stats.

Like I said, cool idea. More useful would be to make this a separate but interrelated project. Make a public website that displays this info--you select rod bait and area, it'll show you some stats, if it has any. Even better would be to generalize the code that the program runs, and how it interacts with the server (really a separate server if you're doing the web thing--EC2 wouldn't support it on free tier), so that other bots can just call the API with their own stats. This could address the issue following:

The issue I see is like what you suggested: sparsity of data. Many people are going to be working on the 1-110 track fish at various times, and many high level fishers are going to do the same things for money. There'd be lots of data there. But there are few fishers going for other things that are in the DB, and there'd be no data for them. Maybe eventually someone can take the data and figure out the algorithms better so we don't need the uploads. That'd be best.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant