Talk:Honey

Rarities incorrect

I am just about absolutely certain that the article has the rarities of the rows reversed. I have just personally done some extensive testing on honey trees from about 250 slatherings on Pokémon Platinum, and Combee and Burmy are by far the most common Pokémon encountered, while Heracross is under 5%. The probabilities listed in the table imply the results ought to be just the opposite; are you honestly sure the rows don't go by descending order of probability? I have also found Combee to be significantly more common than Burmy, which really ought not to be the case if column 0 is truly 20% and column 1 70% as the article says (though this could be attributed to chance if we assume that an abnormal number of my trees started out in column 0 and remained there thanks to the 90% chance of picking from the same column). Dragonfree 16:33, 15 April 2009 (UTC)

The rarities as displayed now are clearly wrong. I haven't been playing Platinum long enough to get a feeling for the Honey Tree rarity there, but I slathered hundreds of trees in Pearl, and saw only about five heracrosses (and no munchlaxes). It was nowhere near 14%, and the claim that heracrosses are almost three times as common as combees is ridiculous.

If the percentages for the rows and the columns are both reversed, these are the D/P rarities, which match my experience much more closely:

Wurmple	29
Combee	22
Silcoon/Cascoon	14
Burmy	11
Cherubi	7.5
Aipom	5.5
Heracross	1

Extrapolating to the Platinum chart, these would be the rarities:

Combee	32
Burmy	22
Wurmple	14
Cherubi	11
Aipom	10
Heracross	1

Do these figures match everyone else's subjective experience? --NoBuddy 06:19, 6 May 2009 (UTC)

The Platinum chart is an almost perfect match for my results, at least. This also rhymes with the fact that at least when it comes to route and water encounter data, the game arranges the slots in descending order by probability; it would make sense for it to do the same for both the columns and rows here. Dragonfree 15:07, 6 May 2009 (UTC)

So, should someone at least put a disclaimer on the page, until a hacker can confirm that the rarities are backwards? There are a lot of people who use Bulbapedia without looking at the Talk pages. NoBuddy 18:10, 28 May 2009 (UTC)

I've fixed the encounter table and edited all the calculated rarities accordingly. --a_magical_me 09:03, 6 September 2009 (UTC)

I took the information DIRECTLY from the GAME CODE itself. Why are you altering it? The percentages were calculated EXACTLY the way the game determines a Pokemon. Yes I did not take into consideration the lack of "sufficient randomness", but that only accounts for less than +-0.01% of the actual amount and has nothing to do with your "subjective experience". Your "subjective" experience has nothing to do with what the game actually does. In fact, I take great insult knowing that I spent quite a bit of time putting together the technical explination and final tables for you guys to change it to what the game DOESN'T do. I will not fix it, have fun with your subjectivity. Sabresite 07:59, 17 September 2009 (UTC)

As a note, the rarities were NOT backwards, but thanks for making them backwards. I can confirm this, as I have read the code numerous times. The game's if statements are exclusive by doing a check for one column, the last column, then leaving the third with an else statement, hence why it may "seem" backwards. Sabresite 08:04, 17 September 2009 (UTC)

Sabre, just leave them. Sure, its like they WANT to have articles with incorrect info. But there is nothing we can do about it. Except make the correct info available elsewhere. Of course we can't tell anyone where it is from here because our links just get erased. The one article that was perfect is now ruined. Good job A magical me. SCV 14:18, 17 September 2009 (UTC)

SCV, Sabre, you two seem to be the only people here who understand the coding. I trust you've got it right. Go and fix it. I assure you Bulbapedia does not want to have incorrect information. If the information up now is incorrect that is because the editors who saw the change didn't understand if it was right or wrong. —darklordtrom 21:57, 17 September 2009 (UTC)

I appreciate that, and the fact is, I put the table exactly how its listed in the game's data files, and SCV and I worked hard translating the assembly code (link below in another section) into readable instructions, and then creating a program to calculate the percentages accurately. When people dispute it, its very insulting, and this is not the first time. I personally have no need to update/fix/undo the garbage that was done, sorry. Sabresite 05:45, 18 September 2009 (UTC)

I have reverted all intervening edits. Thank you, Sabre and SCV, for the hard work you did to determine this. Remember people that data and code ripped from the game > any results from your own in-game testing. —darklordtrom 08:59, 18 September 2009 (UTC)

Oh, come on. Subjective, my foot. This is not just "Hey, I kinda feel like Burmy is a little more common than Heracross." This is careful, extensive, experimental testing. You cannot honestly tell me that you believe my results from 250 slatherings simply happen, by pure chance, to be negatively correlated with the real probabilities if anything, while matching up almost perfectly with what would be the case if a particular simple mistake had been made at some point in the data extraction process. I fully sympathize with generally trusting hackers over casual players, but if I had ripped something from the game data and someone came along and told me they had 250 tests on a real game that strongly suggested something was very off with my data, I would not simply blow it off, no matter how certain I was. I dare you to find anybody in the world who has actually slathered some honey trees and would not be skeptical of your numbers. Heck, I dare you to try it yourselves. When the numbers in the article don't seem to match anybody's "subjective experience", something is clearly wrong somewhere. This is not to be taken as an accusation against you who got the info, who have done an amazing job of fishing out the general mechanics of it. I'm just interested in finding the truth, and as much as I would ordinarily be inclined to trust the hackers, this is clearly not it. I am going to do more testing, this time eliminating the "same tree" bias. I'll do it thousands of times if that's what it takes. In the meantime I strongly suggest at least some sort of warning about the validity of the data be put in the article, but think what you like.Dragonfree 15:31, 18 September 2009 (UTC)

The actual code itself has been linked to in this talk discussion. Why don't you read the code, and I will get you the actual data file from the game itself so you can read that as well. Then when you are done, you can create a program to determine the ACTUAL percentages. If you are interested in finding out the exact percentages by looking at the game itself, contact me, otherwise I will not waste my time anymore with this. While you may think the numbers I presented are wrong, using subjective experience to backup your claim is like allowing religious beliefs to govern scientific theory. I dare you to actually look at the game's code and data files before making ridiculous changes to information on a wiki page. Sabresite 15:47, 18 September 2009 (UTC)

For the record, I'm not the one who edited the page - I just started the discussion here - but that's not really the point. The point is that if what the game "ACTUALLY DOES" is directly contrary to what happens when you actually play the game, something must be wrong somewhere along the line. You can't just sit here dismissing it by calling it "subjective experience" or decrying it as being something like religious faith - this is scientific testing I'm doing here, and by definition, my results ought to match up with the percentages deduced from the code, provided a sufficient sample. I don't know how in the world it manages not to match up, but the fact is nonetheless that it doesn't, and to think this doesn't demand any sort of explanation is ridiculous. Dragonfree 17:03, 18 September 2009 (UTC)

Whoa, chill. And remember that generally experimentation is considered science, and believing what you read is considered religion. 8) I'll have a look at the assembly dump below. Eevee 17:17, 18 September 2009 (UTC)

Umm... someone obviously doesn't understand how probability works. If you roll a six sided die, you have the same odds of getting any number on that die each time you roll it. That means you can get 1 one thousand times in a row, or you can get every single number an equal amount of times. It's not likely, but it's still possible. If you record the results of 1,000 die rolls and determine that you get 4 more then any other number, does that mean you are more likely to roll a 4 when you roll dice? NO! Case closed. [[Derian]] 17:10, 18 September 2009 (UTC)

Er alright that's not the best example because every roll on a dice has the same odds, where the different pokemon have different odds. Well my point is, results don't always reflect the chance. Just because there's a 10% chance of finding a certain Pokémon and a 20% chance of another, doesn't mean in 100 tries you'll find more of the Pokémon with the 20% chance. It's just more likely. Whoops left out my sig, sorry for the triple edit. [[Derian]] 17:14, 18 September 2009 (UTC)

If I roll a die 1000 times and it comes up 4 half the time, my first conclusion is going to be "this is a loaded die", not "well that COULD have happened I guess". What's the point of testing something if I'm prepared to assume my test results are a fluke, no matter what they are? Eevee 17:17, 18 September 2009 (UTC)

In practice I would assume that to, when the results found from the in-game tests heavily contradicted the results found from the coding, then it wouldn't be unreasonable to review the code and make sure there weren't any errors. but submitting those findings as the percentages isn't right, an isolated incident showing otherwise doesn't prove that the percentages are wrong. How you 'feel' about something doesn't have a bearing on science, science is about facts. Just because you feel like the die is loaded because you get more 4's then anything else doesn't mean it is, I for one can remember rolling five 6's in a row. Strange things happen. But odds aren't "This will happen this percentage of the time" odds are "this is more likely to happen then this". There's no way to be certain about something, and odds don't reflect results. Results reflect odds. Maybe those numbers found in the code were wrong, could have been a calculation error. But the results found through testing definitely weren't right, and there's no way to prove specifics scientifically what the odds are from that kind of testing. [[Derian]] 17:26, 18 September 2009 (UTC)

Law of large numbers. Five sixes in a row is not even in the same CLASS as getting one random result thrice as frequently as you should for a thousand rolls. Perhaps changing the article so soon was a bit rash, but experimental data from hundreds of attempts that completely contradicts what we "know" should at LEAST raise a few eyebrows. How can you claim a scientific approach otherwise? Discarding whatever doesn't match your existing knowledge is not the correct approach. Something is incorrect; drop the bias towards the status quo and help figure out what it is. (And please note that in fact most physical constants we have were determined experimentally, exactly because we can't just decompile the universe. Not much different from this sort of testing, really.) Eevee 17:33, 18 September 2009 (UTC)

Yeah I know... just making a point, strange things happen. Yeah I definitely agree it should be looked into. Human error counts into a lot, I'm not saying the calculations made from the data are wrong but it should be checked and double checked and rechecked whenever it's largely contradicted. We just shouldn't change this numbers without proof. Of course! When we've got hard data to work with though that changes things a bit. if we could do that with other aspects of reality, we would. Alright I'm not going to say anything else haha. This isn't a forum after all... I apologize for how many I've made so far! [[Derian]] 17:41, 18 September 2009 (UTC)

SCV and I took the code from the assembly and applied it to the table provided in the game. The table looks exactly like this: [1] - Please get the assembly code, read it, and apply it yourself to the game files. Sabresite 17:41, 18 September 2009 (UTC)

I have no problem going over the code again with SCV, and the data files, and recalculating the percentages, however going about it any other way when we have the code itself at our finger tips is childish and useless. It is also an insult to those like SCV and myself who worked VERY hard to find that data. Sabresite 17:46, 18 September 2009 (UTC)

I appreciate the revert that you did. If you guys look at the table, and review it in the game, you should see that it is exactly the same. The program by D-Trogh allows you to modify the table, so you should notice that its the same. Once you take the table and multiply them according to how its described, you will come to the same conclusions. Sabresite 17:55, 18 September 2009 (UTC)

Wow, i didn't expect such a huge reaction. Sabresite, i did look at the code before i edited the article, but i just checked it again, just for you. Here is my analysis of the asm snippet that SCV provided. The function which sets the row is on lines 45-80. Let me point out that the rates given in the rows of the encounter table contradict what is said in this very article. Observe:

For the row, if the number is between 0 and 5, Pokémon 6 is used. If the number is between 6 and 10, Pokémon 5 is used. If the number is between 11 and 20, Pokémon 4 is used. If the number is between 21 and 40, Pokémon 3 is used. If the number is between 41 and 60, Pokémon 2 is used. If the number is between 61 and 100, Pokémon 1 is used.

...which agrees with my analysis.

An example: the table says that the rate for Pokemon 6 is 40%, but according to this, Pokemon 6 has a 5% rate. The other rows in the table are similarly backwards.

As for the columns, the offsets that SCV mentioned correspond to lines 30-41, which i can see now is not the whole picture. It seems that for munchlax trees, the rates are 20% for column 1 and 70% for column 2; but for munchlax-less trees, the rates are 70% for column 1 and 20% for column 2. Surprise! We were both right!

I admire the work you and SCV have done in reversing the Pokemon games, which is why i can't bear to see this article ruined by such silly mistakes.

--a_magical_me 21:31, 19 September 2009 (UTC)

Are you absolutely sure that you checked all of the code involved, 100% and understood it all? Because just because they 'occur' in that order, doesn't mean that the game doesn't access them in the reverse order or change them in one spot. Add that on top of the fact that Assembly is extremely hard to follow and problems would be expected, to say the least. Also, Assembly (at least every dialect I've seen) doesn't have if..else statements. Myles ^{(talk - contrib)} 04:41, 23 September 2009 (UTC)

I also read through the code, and he is correct. Again, note that the technical description in the article contradicts the table in the article! "If the number is between 0 and 5, Pokémon 6 is used." Pokémon 6 should be 5%, not 40%. And yes, assembly doesn't have if/else per se; that link is to a rough C translation. The original dump is linked below. Eevee 06:48, 25 September 2009 (UTC)

Eevee you are correct, I wrote the rows upside down. Keep in mind that I redid the information three times to account for formatting, so it might have been accidently reversed. If the percentages are reversed, then it can be easily fixed. With that said, my attack was not on your analysis, it was on other peoples' guessing. Also a_magical_me, assembly is straightforward, and if you know how to read it, then there are no problems to be expected. Also assembly does not have dialects. Sabresite 06:41, 7 October 2009 (UTC)

Since we appear to be in agreement, I'll fix the article. It's still a bad idea to consider empirical results to be guessing; it's hard to measure accurate chances experimentally, yes, but you should always be suspicious if the game behaves very differently from how you think. The Pokémon community has had several misfacts float around for quite some time because everyone trusted "common knowledge" over what the games actually do. We're not infallible. Also, I think you mistargeted; Myles is confused about assembly, and a_magical_me is the one who reread it. See, fallible. 8) Eevee 20:18, 9 October 2009 (UTC)

Thanks for responding, Sabre! I'm glad we can put this behind us. You and SCV should keep up the good work. --a_magical_me 01:41, 10 October 2009 (UTC)

One little problem...

The English language version calls it honey, can this be edited?Gatogirl This has been taken care of. Sabresite 01:51, 26 Feburary 2009 (UTC)

Duration and Other Pokemon

Some information is incorrect. It does not take exactly ten hours before a Pokemon appears. I have periods of time shorter than this (approx 8 hours) and much longer (although I am not sure how much longer). It may also be of some use to record which other Pokemon can appear on the trees. i.e. Wurmple and one of those cocoon Pokemon. Dark2th 08:27, 15 July 2007 (UTC)

I have just found a Pokemon in a tree that I slathered with honey 4 hours ago. So the time is definitely not 10. I have also discovered what may or may not be a glitch. After slathering a tree with honey it is possible to slather it with honey again, but it seems to remove the first slathering of honey. For example, the text box will say - "The bark is slathered with honey, slather the bark with honey?" Check the tree again - "There is a sweet smell in the air, slather the bark with honey?" Has anyone else experienced this? Dark2th 08:27, 15 July 2007 (UTC)

Silcoon is the 'cocoon pokemon' I referred to earlier Dark2th 07:38, 16 July 2007 (UTC)

The duration is exactly 6 hours to 23 hours 59 minutes. Sabresite 01:49, 26 February 2009 (UTC)

Rarity

According to the game files, the pokemon are arranged in a table. The table for Diamond, Pearl, and Platinum have been posted. The rarity is based on a PRNG algorithm and applied to this table. I also put up the frequency of each combination. To calculate rarity for a pokemon, such as Wurmple, in Diamond/Pearl, you would do the following

( 0.05 × 0.10 ) + ( 0.40 * 0.70 ) = 0.285 or 28.5% Sabresite 01:54, 26 February 2009 (UTC)

I'm sorry, but I'm having a hard time trusting these calculations. There is absolutely no way that Munchlax's encounter rate is 20%. I've spent the past few days on Pokémon Platinum slathering Honey on the same five trees and not once have I encountered a Munchlax, and I've only encountered Heracross and Aipom once each. Danieru Lynx 07:43, 27 February 2009 (UTC)

Well, here is a link to the thumb code responsible for these probabilities. [2] If you can find an error in the calculation, please point it out. 021F4F2A- 021F4F42 determine which list the pokemon comes out of and 021F4F60-021F4F96 which pokemon out of that list. SCV 26 February 2009

It seems that under certain circumstances a new list number is not obtained, this definitely affects the probability. I will try to determine what causes that to happen. This effect happens per tree. SCV 27 Febreuary 2009 16:10:50 (UTC)

I figured out the discrepancy between observations and the previous calculation. There was another probability we were missing and it is that the list only changes 10% of the time. So for most people they only have a 2% chance of encountering muchlax. SCV 14:29, 1 March 2009 (UTC)

So if you get a tree that does not have a Munchlax, there is a 10% chance that the list will change, and of that 10% chance, a 20% chance that it will be Munchlax. How would we construct the statistical analysis so that we can get an overall percentage of occurance for each pokemon? Sabresite 18:02, 1 March 2009 (UTC)

Because of the nature of how the calculation works, 4 separate lists must be used. I have posted the encounter rates for each scenario. Sabresite 19:24, 1 March 2009 (UTC)

SCV has discovered more information regarding the probabilities. We will need to adjust the information greatly. Sabresite 20:50, 2 March 2009 (UTC)

The Bulbaglitch.

Okay, YouTube. Proof. Give it. TTEchidna 01:58, 26 February 2009 (UTC)

When I have time, I will produce the glitch and make a video. The easiest way to produce it is to save the game using an emulator. Go to locations 0x730C in the save file, (Route 209 Honey Tree), and 0x4730C and change the value to 0x20. Make sure you slathered something on the tree first. Changing the value tells the game to retrieve row 32 in the table, which is beyond the length of the table. The data in that location is 01, making the pokemon Bulbasaur. Sabresite 02:09, 26 February 2009 (UTC)

Well that's kinda. Hacking. Is there any way to force it for the actual game? TTEchidna 02:54, 26 February 2009 (UTC)

It is difficult to explain. I will remove it from the article until I have time to explain it in future detail. Sabresite 03:29, 26 February 2009 (UTC)

Multiple People Editing At Once

I apologize for reverting some formatting errors, Bulbapedia's site is very slow and choppy. Quite frequently I get a page down error and must repaste what I typed, which then overwrites what other people are changing. Sorry. Sabresite 02:09, 26 February 2009 (UTC)

It does that sometimes. TTEchidna 02:52, 26 February 2009 (UTC)

Making sense of the tables.

Could someone please explain to me how this formula works? On the main page, it's worded in an awkward way, and it's rather unclear what it means.

Firstly, from the 4 tables that are given, the first says "Slathering a tree". Does this mean that it is Slathered for the first time, or are these the base values for which the following three tables are derived? I'm asking this, because I'm really doubting that 20% chance of Munchlax the first time that the tree is Slathered, but the article isn't telling me that it's not.

Also, under the "Slathering the same tree" heading, the article mentions that the following three tables are only applicable "if the same tree is slathered more than once in a row". This would mean that if another tree is Slathered after the first is Slathered, then the game reverts back to the first table, meaning that the chances of encountering a Munchlax then becomes 20% again. However, I simply can't believe that Munchlax has a 20% encounter rate - there must be something wrong here.

I'd go through each of the calculations myself, but I really don't have the time at the moment, I have lots of School work to be doing, so could someone clarify the above please? Thanks a lot.--Ggled 18:31, 2 March 2009 (UTC)

As a matter of fact there is more to the calculation and the green value plays a different role than we had first anticipated. There also seems to be a restriction on Munchlax which we were not aware of before. I will adjust ALL of the numbers and tables once SCV has finished rewriting the THUMB/ARM game code in C++.

From what we can gather right now, Munchlax is only available on 4/21 trees, with an encounter rating of 1%. There is also a 10% chance of no Pokemon being on the tree, and for trees where Munchlax may be encountered, there is a 9% chance. This means there will be a total of 2 base tables (Slathering a Tree with Munchlax, and Slathering a Tree without (Munchlax), and 2 sets of Slathering the Same Tree in a row, one with Munchlax, and one without. Sabresite 06:19, 3 March 2009 (UTC)

I have updated the technical information, however not the encounter ratios. I will update those tonight sometime. Sabresite 22:20, 3 March 2009 (UTC)

Charting Nothing

I would argue that charting nothing is necessary. People will NOT count the percentages to see if it adds up to 100%, or not. And since it doesn't add to 100% without the "nothing", people will think the numbers are wrong. I suggest that the entries for "No Pokemon Encountered" be represented in some fashion in that chart. Sabresite 07:38, 4 March 2009 (UTC)

I think you mean people WILL count the percentages. Maybe a note at the bottom of each table is enough? SCV 16:41, 4 March 2009 (UTC)

Yeah, something....Sabresite 17:12, 4 March 2009 (UTC)

Munchlax Trees?

The article talks about "trees with Munchlax" and "trees without Munchlax". Is there a list anywhere that says which trees are where?--Purimpopoie 00:35, 23 March 2009 (UTC)

They are unique to each game, and dependent on the player's ID number. I think that is in the article.... — THE TROM — 00:52, 23 March 2009 (UTC)

Why was the revision with a link to the munchlax tree calculator undone

As the above section clearly shows people want to know how to find them. SCV 20:03, 11 April 2009 (UTC)

   I'd like to know where a Munchlax Tree Calculator is as well. EliasT 13:51, 18 April 2009 (CST)

Time of the day?

Is the chance of encountering a certain Pokémon affected by what time it is? Only, this morning (on Diamond) about 12-15 of the Pokémon I saw were Combee, and that's supposed to be only 5.5%. Later on in the day, at around 2:00, 11 of them were Silcoon, and that's only supposed to be 1% chance. Is there something we're missing here?--Ggled 13:02, 14 April 2009 (UTC)

Were you soft-resetting your game every time you checked the same tree? Luna Tiger * the Arc Toraph 13:12, 14 April 2009 (UTC)

Soft Resetting doesn't change the Pokémon that you encounter (correct me if I'm wrong here), so I don't see how it's relevant. I didn't, by the way.--Ggled 15:28, 14 April 2009 (UTC)

Ask Sabresite. He's the one who got all the data for this. Given the preciseness of his figures, I would doubt he missed something as big as that. It hasn't been picked up on any other site either. Given how far we are after the release, I would say not. — THE TROM — 07:42, 15 April 2009 (UTC)

Fair enough. I can see your logic there. I have really weird luck anyways - it took about 70 soft resets before Mr. Backlot mentioned seeing a Porygon in Trophy Garden o_O Ggled 14:34, 15 April 2009 (UTC)

What's soft-resetting?--Totodilesentret!^{Talk to me.} 14:43, 15 April 2009 (UTC)

Start+Select+L+R to reset the game as opposed to using the power switch. Luna Tiger * the Arc Toraph 17:31, 15 April 2009 (UTC)

It's basically resetting the game without manually turning off the power, and then back on again. In DPPt, it's done by pressing L, R, Select and Start all at the same time. Ggled 17:34, 15 April 2009 (UTC)

Sources

Could the sources of information about these probabilities be added to the bottom of the page? I would like to read more in-depth information about these probabilities from their original calculations. Yenreb 03:04, 22 April 2009 (UTC)

Well, that is explained in the Technical Mechanics section. Is there anything that you think is missing? SCV 16:38, 23 April 2009 (UTC)

Page split

Nothing major here, but considering that we have separate articles for the mechanics behind Hidden Power (and probably other things), I'm suggesting the calculation part of the article is moved to Honey tree calculation, and this article is left to focus on the item. — THE TROM — 22:37, 30 April 2009 (UTC)

Muchlax

I think we should say which trees have Munchlax if only 4 of them do. Random Chaos 14:02, 4 May 2009 (UTC)

They're randomly determined at the start of the game, and are different for each one. Therefore, there's no way to tell which 4 will have Munchlax in, so we can't include it in the article.

Oh come on that sucks. Muchlax is harder to get than Heatran. Random Chaos 16:15, 4 May 2009 (UTC)

You could just go on the GTS for it. Ggled 18:20, 4 May 2009 (UTC)

If I had Wifi Random Chaos 19:04, 4 May 2009 (UTC)

Wait, so there's only 4 paces to get them just like feebas right? so if I check all trees listed rthen one of those has to be the 90% munchlax tree? I'm really confused about the honey stuff, I still need heracross, too. (sidenote: I hate GTS)--Barakku 02:37, 7 May 2009 (UTC)

They don't change, unlike the Feebas locations. R.A. Hunter Blade 02:42, 7 May 2009 (UTC)

Ohh, good to know, thanks. From recent experience with GTS I may be able to get one there...--Barakku 16:38, 7 May 2009 (UTC)

Useless amounts of detail

Mechanics are all well and good, but they generally take the form of explaining the logic. This reads more like pseudocode (which, effectively, it is). Ex: "Let R be the pseudo-random number from 0 to 65535. E = ( R / 656 ) % 656". Is it really necessary to explain exactly what algorithm the game uses to get a random number in [0, 99]? It's also confusing to start out explaining the save format, which is meaningless before any trees at all have been slathered. Unless there are objections, I'm going to rewrite this to be a bit more high-level. Eevee 20:57, 9 October 2009 (UTC)

Generation V

Does Honey exist in B/W at all? Combee still has Honey Gather if anyone wants to check for themselves by transfering one over.... Shiramu Kuromu 01:16, 15 January 2011 (UTC)

Bump. And yes, it does exist but only as a leftover item from Generation IV within their coding. ポケモンあいこうか 14:44, 5 August 2011 (UTC)

Pokemon X and Y

As far as I can tell, honey can only be found in several hidden locations in Pokemon X and Y, but does anyone know how often they respawn? I can't find this information anywhere... Ulithium Dragon (talk) 22:12, 4 April 2014 (UTC)

How to determine which Pokemon will appear on a tree

This chart is really confusing on this page. I'm currently playing D/P/Pt (the only main Pokemon games I've never played as I couldn't afford a DS in 2008-2009) and I cannot at all get a Heracross! I get so pissed off when all I get are these dumb Wurmples! It's a giant waste of time, money (as you have to buy Honey), and patience!

Is there any way to determine how a Pokemon will show up? Is that fully pre-determined on when you slather the tree? Does slathering it more than once increase the chances of a rare Pokemon like Hearcross or Burmy showing up? Does the time of day or exact minute and hour matter at all?

I can't proceed further in the game because Heracross is the only one I can catch (in the way I am playing) who learns the HM I need to proceed further (which is Strength, by the way). Plus, I need to catch a male one to teach it Thief in order to get a Lucky Egg Chansey in the wild, but I *really* want it on a CompoundEyes Yanma, so I need to teach it to one of the only Pokemon I can later breed onto a baby Yanma with CompoundEyes later on, wherever I am able to finally catch one in the Great Marsh.

Long story short: I NEED Heracross, but all I get when I check trees the next day are f---ing Wurmples, non-stop! It's so frustrating! I can't even get a Cherubi or Aipom, not that I care too much for them, but they are needed to complete the SinnohDex. - unsigned comment from Mcheetah (talk • contribs)

From a big-picture point of view, it's not incredibly different from tall grass, except in the fact that one encounter takes 6 hours to happen. Of course, that's a huge difference, in its way, but the point is, all you can do (or the best you can do) is keep trying, on as many trees as possible. Whenever you do see one on a tree, though, you can safely reset to find whatever kind of Heracross you want; it'll stay a Heracross, but its stats and stuff will change. Tiddlywinks (talk) 04:05, 3 February 2015 (UTC)

Changing DS clock

The article currently says that changing the clock on the DS has no effect on honey trees. However, I tested this on a DSi, and the honey trees do depend on the DS clock. The article should probably say something about how it works on some systems and not on others. sumwun (talk) 23:20, 4 June 2017 (UTC)

Split

Now that items have their own substantial pages, the Honey tree section has become a large part of this page that only applies to a minority of the games in which this item appears. I think the best course of action is to split Honey trees to their own page, and keep this page about the item alone. Obviously this page would still need to link to that page. --SnorlaxMonster 08:48, 24 February 2019 (UTC)