Describe the bug
When multiple bee's are on the same flower they are bumped about which increases pollination time due to the closeToTarget check being done

To Reproduce
Get more than 3 bees on one flower and watch them bump back and forth

Expected behavior
They should all be able to pollinate from the same flower, Multiple flowers would work but the scan finds and returns the first found.

Additional context
Recommended either increasing the range on closeToTarget to 0.25 or, when doing the flower scan don't select the first item in the array, but randomize so they spread out (Random is not spread but is close enough and not resource intensive)

Also when the pollinating flower in question is not a small item, (AKA A block) the offset on the saved flower pos should be different to stop bee's flying around on top of the block, though not sure how much of a pain that would be to implement

Thanks!

Closing as flower selection was resolved and clipping wasn’t reproducible but does also occasionally happen with vanilla mobs

that's vanilla code

is that an issue? (I'm not a modder, just a programmer) The mod vastly increases the functionality of the bee's and having 16 bee's all after the same flower (If you are not at the apiary stage) has some issues that could be rectified by modifying the values no?

so the only thing we changed about the pollination goal is that vanillas logic takes about 500ms to execute where ours takes about 90ms. the functionality remains exactly the same just ours is more optimized. You can use a honey dipper to specify the flower the bee should use for pollination. in the next version of the mod I will be adding an experimental performance mode where bees will only go to hives/flowers that have been designated with the honey dipper so servers can improve performance at the expense of more active management by the player.

oh and we added the ability to use entities as a flower

Ok Understood, Your trying to stay Vanilla as possible, Thanks

While I appreciate your due diligence in obtaining this data I can assure you that it is in fact an issue with vanilla and not us specifically. I don’t have access to an IDE atm to be able to show you our code vs vanilla code. But basically bees want to be within 0.1 blocks of the block they are trying to pollinate. Vanilla bees obviously only pollinate flowers. Flowers are non-solid blocks. As such there’s no collision for bees to bounce off of. So with that information it is clear that more than one bee can occupy enough space that it is within 0.1 blocks of the block they are pollinating whereas if the flower is a solid block it is much more difficult for multiple bees to do the same thing.

I can change it so that bees pick a random selection from available flowers within the scanned region that match the flowers they are allowed to pollinate. However doing so would be at the expense of performance. Bees in general are already very inefficient. In fact, in testing our changes to vanilla logic have improved the efficiencies but were at the point now where any further optimizations would have negligible impact to performance without rewriting the pathfinding AI from scratch since that accounts for a MASSIVE chunk of the performance. Rewriting the pathfinding will take me a fair amount of time and testing as I need to reverse engineer vanillas pathfinding so I can identify areas of improvement.

later tonight when I have access to my pc I can post the relevant snippets of code that show why bees have difficulty in pollinating the same blocks. Also keep in mind that larger bees like the Oreo bee will have even more difficulty in sharing flowers Bc of their larger collision boxes.

Just for reference. This is where in our code you can find the .1 blocks. This line of code is exactly the same in vanilla logic.

https://github.com/Resourceful-Bees/ResourcefulBees/blob/b2696e64fc6c8e1cfa01db2ec9dee30a26355b30/src/main/java/com/resourcefulbees/resourcefulbees/entity/goals/BeePollinateGoal.java#L149

Not to rebring this up, but, this is not a vanilla issue. It is a RSBee model issue, from what I understand. Below are two screenshots of your bees vs vanilla bees. MULTIPLE vanilla bees can be in the same block space and all pollinate the same flower, and all enter and exit the hive, in the same block space, while RsBees can not do this.

If my deduction is correct, because vanilla bees hitboxes entirely float above the pollination block, they are able to pollinate and re enter the hive, however, with RsBees, this is not the case, as mentioned. Their hitboxes when multiples are in the same block space extend beyond the block they are in. And, in most cases, they will never be able to polinate if more than one are in the same block space at the same time trying to pollinate.

Image one: Vanilla bees, models are properly contained, up to 24 bees before cramming, and all can pollinate and enter hive perfectly fine, including RsBeeHives.

Image two: RsBees, models extend beyond containment, and not a single been can pollinate as they can never fully be on top of the block they are trying to pollinate. The bee in the image is the Mason bee. I have tried with two, three, and four, and in every case, with every single RsBee, they can not pollinate if they try and share the same block at the exact same time. For more than two real hours, these bees, all my RsBees, just sat there, not entering the hive, not pollinating, just buzzing. They are not working.

I definitely think that this issue is not related to vanilla, as mentioned, vanilla bees do not do this.

Ok I did the exact same setup as what you have and the bees worked perfectly so idk whats the difference between our setups but they are working the exact same as the vanilla bees and are producing at the same speed. I did notice one difference and thats in your screenshots the hitbox goes through the walls but in dev they touch the edge of the blocks.

No worries. We’re testing some adjustments to the value so that it doesn’t have a significant visual impact but functions better

What pack are you playing because again the hitboxes seem to just go through walls in your screenshots

Yeah if you could tell me the pack, pack version, and mod version

ATM6 1.5.7, forge 36.1.2, ResourcefulBees-1.16.5-0.6.5b.jar, But, I am playing on three different packs, including sky bees, and ATM6 sky. I will check those worlds and see if the same behavior exists.

Oh, and about the hitboxes going through walls, its strange I thought indeed, as the bees do not glitch through the walls when they are like this.

So, ATM6S latest release, all the same versions listed above, and the same position happens.

On Sky Bees, Final Version 2, al the same versions listed above, AND!!! they do not have their hitboxes going through walls. So, I wonder what mod is causing this interaction in ATM6? Of course, the MASON bee is not a thing in sky bees, but, I have tried a few bees, and no extended hitboxes.

Well need to start identifying which mods affect bees and look through their sources. If no luck then we’ll have to look at mods that affect entities themselves. Chances are some mod is altering the scaling of the hit boxes. Either to fix an issue or inadvertently.

I'm also not trying to be a pain in the ass here! and I understand that your code is almost the same as vanilla,

however the modded bee's do behave differently to vanilla, I don't know if forge it causing a difference but see attached. The first pic shows the vanilla bee's, they spread out and pollinate without any issues, or even when not spread they pollinate fine. they have a great run cycle.

The second picture shows a bee that has been created to mimic vanilla, that pollinates on flowers, as vanilla does. They group around a single flower and get stuck bumping around it, waiting one by one, they have a run rate that is 80% less efficient than vanilla bee's. but are doing the exact same process

I know you guys are trying to keep it efficient, but you might need some modifications rather than having the collision calculations that are happening as well as bee's being out of the hive most of the day/night

I love the mod! Just trying to beee helpful! :)

Not to rebring this up, but, this is not a vanilla issue. It is a RSBee model issue, from what I understand. Below are two screenshots of your bees vs vanilla bees. MULTIPLE vanilla bees can be in the same block space and all pollinate the same flower, and all enter and exit the hive, in the same block space, while RsBees can not do this.

If my deduction is correct, because vanilla bees hitboxes entirely float above the pollination block, they are able to pollinate and re enter the hive, however, with RsBees, this is not the case, as mentioned. Their hitboxes when multiples are in the same block space extend beyond the block they are in. And, in most cases, they will never be able to polinate if more than one are in the same block space at the same time trying to pollinate.

Image one: Vanilla bees, models are properly contained, up to 24 bees before cramming, and all can pollinate and enter hive perfectly fine, including RsBeeHives.

Image two: RsBees, models extend beyond containment, and not a single been can pollinate as they can never fully be on top of the block they are trying to pollinate. The bee in the image is the Mason bee. I have tried with two, three, and four, and in every case, with every single RsBee, they can not pollinate if they try and share the same block at the exact same time. For more than two real hours, these bees, all my RsBees, just sat there, not entering the hive, not pollinating, just buzzing. They are not working.

I definitely think that this issue is not related to vanilla, as mentioned, vanilla bees do not do this.

I have tested in a testing world (skybees mod pack), and used the exact same setup as yours. I found that the modded bees are path finding to flowers that they cannot reach instead of the one inside the 1 block space. This causes them to not hover over the flower inside the setup and instead trying to reach the flower outside and not producing any honeycombs. I tried to use all solid blocks to block all the vision but the modded bees seems to still tried to get out of the setup and reach the flowers outside. If I remove the flower outside the setup (not the one inside the 1 block space), all bees will go to work and produce honey combs. This issue does not exist in the case of vanilla bees in my testing world.

Honey dipper is honestly the best way. Basically you’re cutting out the process of scanning for a flower and instead setting the location of the flower for the bee. Since we removed the possibility for bees to forget their flower location when exiting OUR hives and apiaries this means their flower position will remain constant until the flower ceases to exist. However vanilla hives keep that logic intact. As for flower finding: vanilla uses a series of for-loops that go through block positions starting from the closest position and circling outward. However that logic in itself takes about 300ms on average to execute. Ours instead uses built in java APIs to stream the positions. Ours cuts the average logic run to about 90us. That’s a massive difference. However we’re at the mercy of how the API loops through the positions and short circuits. This means bees may pick spots that are within the 5 block radius but not locations the bee can actually access. In fact even vanilla logic would allow for a bee to pick a flower that it cannot access. This is because the logic doesn’t run the pathfinding to determine if the selected spot is accessible before selecting it. It makes sense however that would be the case Bc doing so would add significant overhead. Remember: vanilla was not developed with the intent of being modded and as such changing some things about vanilla can have unintended consequences. Or they sacrificed performance to accomplish a task Bc they didn’t want to take the time to rewrite a massive chunk of their code base to support a small addition.

In any case. Until I am able to figure out the best way to rewrite pathfinding so we have massive performance gains I refuse to sacrifice performance so that things function a little bit better.

Regarding the honey dipper issue, I have mentioned in issue #205. TLDR: The honey dipper didnt work for me even I upgraded to 0.6.6a in a 5x5 box setup. Modded bees are still returning to that particular flower after entering and exiting hives. (IDK if its a personal problem or not). Yet, the pathfinding problem aforementioned in the 1 block setup is solved after the upgrade.

Excellent. I am glad you were able to experience the same thing as I described above, but not rreally :). They do this with outside flowers or not, as I mentioned, in ATM6 Sky. I have tested multiple times in Sky Bees, ATM6 and ATM6Sky, and they do not clip through walls in SkyBees as I have shown, so, I believe your issue may not be related. This issue is not about them finding their pollinating blocks, or about path finding to them. You can fix your issue by using the Honey Dipper introduced fairly recently to Resourceful Bees. Right click on bee, then flower and then hive to set them.

Sorry I am a noob to coding or related stuff. Im using mac to play sky bees via curseforge app. And I manually replaced the 0.6.5b file by 0.6.6a in the mods folder on the version 3 fixed sky bees profile. Under this circumstance, how should i create a test bed like you have mentioned? Or do i need to locate the files that store the bees pollinate block data and upload it here?

I’ll test it with what you’ve provided me so far. If I’m unable to reproduce are you playing this on a server I could come on to and see first hand the issue?

Im playing in my single player world.

Do you have a test bed I can use to see/reproduce the honey dipper issue? I haven’t been able to reproduce the issue of them going back to a flower they weren’t told to go to.

for reference this is where position is set when scanning for a flower:

https://github.com/Resourceful-Bees/ResourcefulBees/blob/8ebf2d509454c659c1dea52bdc3c98ff069ffff9/src/main/java/com/resourcefulbees/resourcefulbees/entity/goals/BeePollinateGoal.java#L46

This is where it is set when the honey dipper is used. The only difference being one is automated the other is player specified:

https://github.com/Resourceful-Bees/ResourcefulBees/blob/8ebf2d509454c659c1dea52bdc3c98ff069ffff9/src/main/java/com/resourcefulbees/resourcefulbees/item/HoneyDipper.java#L73

No worries. I’ll test and see if I can repro

https://youtu.be/fZqTaoIjoTs
I recorded a video about the bee behavior. Please have a look, sorry for the low quality in exchange for the faster upload speed.

https://youtu.be/pBWAPP9L9_k
Another vid fyi

I was not able to reproduce this issue with the same setup

But what about in the one block setup in the second vid? The mod bees are looking at the flowers they cant reach whereas vanilla bees do not have the same issue

Desagas is right. And I forgot that they reset the position if the pollination was interrupted. (I added a things that prevents it from happening with the new misleading performance mode option that doesn’t actually improve performance from testing. At least not significantly)

anyway. Let’s revisit the vanilla logic vs our logic:

vanilla uses a series of for loops as you can see here:

for(int i = 0; (double)i <= distance; i = i > 0 ? -i : 1 - i) {
            for(int j = 0; (double)j < distance; ++j) {
               for(int k = 0; k <= j; k = k > 0 ? -k : 1 - k) {
                  for(int l = k < j && k > -j ? j : 0; l <= j; l = l > 0 ? -l : 1 - l) {
                     blockpos$mutable.setAndOffset(blockpos, k, i - 1, l);
                     if (blockpos.withinDistance(blockpos$mutable, distance) && p_226500_1_.test(BeeEntity.this.world.getBlockState(blockpos$mutable))) {
                        return Optional.of(blockpos$mutable);
                     }
                  }
               }
            }
         }

vanilla starts at the position closest to the bee and flips around as it circles outward.

our logic, which I won’t paste here since it’s visible in our source code, uses the stream API. Basically Minecraft has a BlockPos class which we supply a bounding box (list basically) consisting of all the block positions within a 5 block radius plus the bees current position. We then tell it to filter the list based on a predefined logic check and then return any result from the filtered list. Bc of how this API works we don’t have control over the order of the positions and which result is returned. In addition neither us nor vanilla activates a pathfinding process to determine if the selected position is accessible by the bee. (As in the bee isn’t trapped in a box and the flower is outside of it) the reason this isn’t checked is Bc it would essentially double the number of pathfind a bee does (or more!)

Because of the inefficiency in pathfinding for Minecraft entities with 500 vanilla bees I average a tick time of about 200ms with tps of about 5. And with our logic the mean tick time is about 130ms with tps of about 7. Think about the impact of doubling the pathfind logic just so bees don’t target blocks they can’t access and tell me if it’s worth the trade off?

Also. If you put a vanilla bee in a small 2x2 box and put a flower outside that box I guarantee you the vanilla bee selects it and tries to go to it.

But my problem is, even there are flowers in a 1 block setup or 2x2x2 box, the bees are not trying to pollinate on those flowers. Instead, they gathered at the corner trying to reach the flowers in other boxes which are unreachable (got bounding boxes ard them) So this is normal?

I don’t understand how I can clarify this any further. I don’t have a computer available as I’m at work or I would draw a sketch to show the difference in logic.

let me try to paint an image in your head that shows it.

say you have a bee at 0,0,0. Vanilla checks for flowers in a 5 block radius as do our bees.

So with vanilla logic it would start looking at 0,0,0 and then circle outward until it got to the 5 block radius. Either 5,5,5 or -5,-5,-5 etc.

with our logic it streams through a list of positions and the short circuits the stream when a match is found. we don’t have control over which position is the first one in the list or which one is last or which one is selected. So it could start at the bottom left corner of the bounding box or the top right etc. it could start with positive z working to negative or it could start with positive x working to negative etc.

this means that every single bee using our logic will start looking at the same spot in the bounding box and iterating through until a match is found. Therefore it is most probable that our method is not starting at the closest potion to the bee but rather the furthest position from the bee. The difference however is that our way is significantly faster than vanillas way of doing it.

does that make things any clearer or easier to understand? Does it make sense to you that I am not going to sacrifice entity performance so that the bee starts at the position closest to itself working outward just so that bees don’t target the same flower position as another bee or so that they don’t target a flower that is outside their enclosure when there is one inside the enclosure?

bees are already extremely inefficient. There are servers that won’t even host a pack that has our mod in it specifically Bc it has our mod in it and entities are highly inefficient. Can you see why I would prioritize efficiencies over player convenience?

Seriously. Use a honey dipper and tell the bee which flower to use. Or remove any flowers outside of the enclosure that they could possibly get to. next update will have the “performance mode” renamed to “manual mode” or something similar. And bees when that mode is enabled bees will always retain the same flower position regardless if they fail pollination or not. It’s literally the best thing I can do as a compromise without sacrificing entity performance until I can gain improvements elsewhere.