Fishing ships try to deliver food to unreachable dock

:arrow_forward: GAME INFORMATION

:point_down: These details are CRITICAL; DO NOT skip them or your issue may not be reviewed.

  • GAME BUILD #: 47820
  • GAME PLATFORM: Microsoft Store
  • OPERATING SYSTEM: Windows 10

:arrow_forward: ISSUE EXPERIENCED


It is quite simple: Imagine a fishing ship on deep fish in coords X, Y which is a pond/mass of water that has ANOTHER mass of water nearby. The two water masses are NOT connected. If the closer dock to coords X, Y is a dock in the OTHER mass of water, the fishing ships will indefinitely attempt to deliver food to it, effectively halting production. However, the ships do not show as idle.

:arrow_forward: FREQUENCY OF ISSUE

:point_down: How often does the issue occur? CHOSE ONE; DELETE THE REST!

  • 100% of the time / matches I play (ALWAYS) NOTE: I have only seen this one, but I bet my programmer’s reputation it happens 100% of the time the above conditions are met. :slight_smile:

:arrow_forward: REPRODUCTION STEPS

:point_down: List CLEAR and DETAILED STEPS we can take to reproduce the issue ourselves… Be descriptive!

Here’s the steps to reproduce the issue:

  1. Start a skirmish game in the new Volcanic Island map.
  2. Locate two contiguous masses of water that are disconnected from one another.
  3. Locate deep fish in one mass of water that is close enough to a dockable position in the other mass of water.
  4. Build a dock in said position.
  5. Build a dock in the other mass of water, at a greater distance of the previously located deep fish when compared to the distance from that deep fish to the dock from the previous step (that is in the other mass of water). Build a fishing ship from this new dock and send it to collect fish from the located deep fish spot.
  6. Watch as it indefinitely tries to deliver the food to the inaccessible dock.

:arrow_forward: EXPECTED RESULT

:point_down: What was SUPPOSED to happen if the bug you encountered were not present?

This is something up for discussion, I think, depending on the sprint work at hand and how much effort you can imprint into correcting it.

Option 1: Ideally, the fishing ships should know which docks are accessible and which ones aren’t. This is the most work: Every time a new dock is added, it needs to be assigned to a distinct mass of water. This of course, assumes an algorithm capable of identifying distinct masses of water. Every fishing ship that is spawned is provided with the mass of water identifier they were created in. Whenever they need to deliver food, they will iterate through the collection of docks that exist in with the mass of water identifier, and determine by Pythagoras’ formula the closest one, thereby automatically avoiding even trying to deliver to docks that are in other masses of water.

But if there is no time in the sprint to fulfill the above algorithm, then simpler ones can be devised. Keep reading.

Option 2: If there are time or resource constraints, this is a good enough option: Continue using the current algorithm to decide which dock to deliver to, but if the pathfinding fails to reach the destination, change dock: Make the fishing ship attempt delivery to the second nearest dock, etc. until a dock is reachable or it is all out of docks.

You can add a bit of simple machine learning here to make sure calculations are only done once, therefore minimizing the performance hit, which the game has several and doesn’t need any more right? :slight_smile: :joy: Have each fishing ship have a collection of bad dock identifiers/pointers. Next time it is time to decide which dock to deliver to, make sure any unreachable docks are added to this collection, and make sure the ship always exclude those docks on future deliveries. This is a simpler solution because it does not require an initially-run algorithm to distinctly identify masses of water, nor is there a need for an algorithm to assign a mass of water identifier to each built dock. The fishing ships automatically learn by themselves which docks can and cannot use.

If you opt for this, you could improve the algorithm at a later sprint by sharing the list of bad docks among all fishing ships that are created using the same dock. Kind of a hive mind, like the Borg. :smiley:

Option 3: If you guys are just too lazy (nah, just kidding), the simplest solution is to attempt different docks if the fishing ship gets stuck at a fixed coordinate for a preset amount of time. "Going to dock A to deliver. Moving, moving… stuck, ok, so second nearest dock. Moving, moving, moving… stuck, so 3rd nearest dock, etc. You get the idea. But this is hardly a solution. This I consider a workaround only. Might be a solution if you add the machine learning described in option 2. But if you do this, this option pretty much becomes option 2. It all depends on the timer here vs the algorithm that determines if a fishing ship got stuck. If not much of a difference, then this option and option 2 would become the same in practice.

:arrow_forward: IMAGE

:point_down: ALWAYS attach a PICTURE (.jpg, .png, .gif) or VIDEO (.mp4, YouTube link) that highlights the problem.

:arrow_forward: GAME FILES (SAVE / RECORDING)

:point_down: Attach a SAVE GAME (.aoe2spgame) or GAME RECORDING (.aoe2record) of the match where you encountered the issue. Link it below if using an external file service.


Hey @webJose
Luckily this bug is being tracked by our team already. Thanks for the report though!

Let me translate this message real quick:
Thanks for your time investment, really cool, you have just wasted a lot of your free time to report a bug, even thinking about some possible solutions. Sadly that specific bug already was tracked. Well there is no way for you to know that we already track this bug, since we do not even post it in our official tracked bugs section (pinned link in the forum: 📌 [OFFICIAL] Known & Tracked Issues, Real Link: Known Issues & Solutions – Age of Empires Support), since we have, at this point, realised there are just too many bugs for us to all post them there as well.
We hope you always stay positive and again invest your time thinking about possible solutions for issues that we get paid for fixing :smiley:

Fun aside:
Give us any way to see which bugs are tracked, so we do not report bugs that are already tracked. Would save us time we spend reporting/thinking about possible solutions etc when already tracked. At the same time: I would never again try to reproduce how some wired bug occurs, maybe it already is tracked, so why should I make a good report. One liner will do it as well…

1 Like

Darn, this is a very good point. Hopefully they listen. Yes, they should have an API that consults the tracked bugs whenever we start a new bug report. So even if it doesn’t have a bug report in the forum, it at least shows that the bug is tracked. Maybe we can even request that our report be linked to the tracked data.


Yeah, that type of thing can be a little frustrating, if/when it happens :wink:

I sometimes spend a decent amount of time on bug reports, and it’d be discouraging if I learned I just wasted a bunch of my time making one. Don’t think it’s happened too much (that I’m aware of), but maybe once or twice. Admittedly, even if the bug exists on a public list, it’s sometimes hard to look through it all

Regardless, it’s clear @webJose spent a good amount of time detailing everything out! Wow, good job. Including step-by-step instructions on how to reproduce the issue; much like I try to do… and even adding a lot of detail for expected results! That had to have taken a fair amount of time :dizzy_face:

Great idea! Even making it searchable via the forum search would be cool, so when we search for bugs before writing a report, we’d see it. They could make public-friendly wording for each bug that the API would tap into

Of course, who knows how much longer bug reports will be allowed on this forum? With PUP going on Steam’s forums, I wonder if all bug reports will shift to there someday (unfortunately). And if that happens, would an API still be possible… not sure

Respect for those 3 detailed solutions (they are seriously well thought)… You are taking babysitting the devs to an extreme :wink:

Yes please @ChristheCo

1 Like

You did a very nice job describing and reproducing the problem. Clearly you put work into it.

Unfortunately you had no way of knowing it was already tracked. Which is kind of silly. Using any bug tracking software (and if the devs don’t use one, they should) the bugs tracked should easily be made public. Might be other reasons why they don’t want to us know about all the known issues. :face_with_raised_eyebrow:

The proposed solutions are somewhat condescending and insulting though. Like your talking to a bunch of HTML boot camp graduates. They are incredibly basic ideas that any seasoned developer or college graduate should produce without much effort. And unless you know how the actual game engine work, you have no way of knowing if any of them are remotely applicable. And some of them I can already see you didn’t think through. Waiting for units to get stuck based on a timer - that’s probably how we get dancing miners and idle lumber jacks.

If your not a professional developer, or you don’t work on similar problems, I can see how you though this would be helpful (even with the level of snark). But imagine some off the street coming into your place of work, trying to give you incredibly basic tips on how to do your job (with that tone), having no idea of the details.

Did a good job impressing the public though.

Also, that is not machine learning. If you’re going to use buzz words, use something watered down, like Artificial intelligence. It also has more selling power nowadays.

Based on this issue I would assume a similar problem is present with villagers and various resource drop offs? Like lumber camps on two sides of a wood line, but not accessible. And that that issue is also tracked?

First of all, I have been nominated twice to Microsoft MVP in C#. Second, I have always worked with very basic professionals. College graduates?? They can’t even implement a quick sort.

And yes! That is a basic machine learning algorithm. Look for the matches game. It’s been around since the 70’s or 80’s. No, I am not talking neural networks which are programmed differently.

And no, I only know AoEII is programmed in C++. I therefore can only go so far with the suggestions. I know nothing about their way of tracking or pathfinding, and therefore cannot go beyond this.

So before you adress to me, do it respectfully, because chances are I am far better at programming that you. I am a moderator at 8 MSDN forums in the Spanish forums. Look me up.

1 Like

So you rant about my post saying that I assume how things are programmed and here you come making one. Yes, it might be shared code, but you know what? It may not be. So take your own advice for once.

I don’t know about respect, that reads very passive aggressive to me. I wouldn’t appreciate it, however different people will interpret it differently.

That part is honestly kind of sad.

Based on your description, I would say it’s a specialized search algorithm (unlike a generic alpha-beta). This is usually put under the more generic term Artificial intelligence, which also includes machine learning algorithms like Neural networks, but contains other methods as well. If however you were describing a well known approach which is specifically known as a machine learning algorithm, I can only apologize.

You are correct. I did assume something I shouldn’t have. However I was hoping that before I test it (because I’m just generally curious), that maybe I could get a confirmation before hand.

Would also be interested in seeing if this also happens in HD or was it introduced in DE. But this is probably not relevant here.

It seems I was wrong. When a closer lumber camp is not accessible, the villagers will drop off wood at the lumber camp further away. Interestingly enough, if there is a path to the closer lumber camp, even if it if farther to walk (leads past a different lumber camp), the villagers will drop off at the closest lumber camp.