Wayfinding seems to not work as expected

[HappyStarfish]

Hello!
Are the wayfinding functions possibly still incorrect at the moment?
I set a route to an anomaly, but my ship never gets there.
Wayfinding is a very important factor for me. I am blind and am currently making the game playable for blind people with the help of AI by implementing an alternate UI and Screen reader support.
If this sounds interesting to you, I would be happy to present it to you at some point.

[tuomount]

Did you try both FTL routing and regular movement routing? I am sure that FTL routing will avoid moving to anomaly, but I am not sure about regular movement. This could be fixed so that if route ends explicitly on space anomaly, it would move there. No the idea is that it avoids space anomalies, since there can be dangerous events.

But yes, I am more than happy to help with this.

[HappyStarfish]

First of all, thank you so much for your answer! I'm enjoying your game a lot, it's genuinely awesome!
I'm afraid it's not because of the anomalies. I also had the same problem when I traveled to a planet that I wanted to colonize.
Admittedly, I only tried it with ftl. The AI believes that it is an error in the source code. But that doesn't necessarily have to be correct, haha.

[tuomount]

I just looked for code and it checks if target is blocked and is not dangerous tile and it is able to move there. Space anomalies are considered as dangerous tile. So if you are seeing following message: fleet.getName() + " has encouter obstacle and waiting for more orders." that dangerous tile prevents fleet to move there. If that's the case I need to think what would be good work around for this. Any way I have assigned to 0.29.0 so I try to get this fixed into next version.

[tuomount]

Idea how AI handles these is that it moves close to those anomalies and will explore only if AI is using military fleet or scout fleet and it will take regular moves to explore anomaly. That regular move is basically same as human player uses mouse or keyboard to move the fleet.

[HappyStarfish]

That sounds like an interesting approach. It would definitely be worth a try.
You could also consider introducing an aggression style for ships that influences behavior during dangerous routes or autoexploration. Then the entire system would have a logical background. I don't want to simplify the game itself.

For the sake of completeness, even if I can't say anything about the quality as I'm not a programmer myself, I'm sending you in an extra post what the AI says about the problematic lines in the source code.
As I said, that really doesn't have to be true and should be treated with caution. But if it helps you understand the problem better, it might be useful.
And I really can't say it often enough. Thank you very much for taking our specific problem into account! This really means a lot to me!

[HappyStarfish]

Claude said:

Issue: Route oscillation & silent route cancellation on blocked tiles
(affects both "Route FTL" and "Route Moves")
Open Realm of Stars v0.28.2 (same code present on master / 0.28.2-SNAPSHOT)

Summary

When a fleet's planned route crosses a tile that becomes blocked mid-travel
(ion storm drift, deep space anchor deployed, another fleet parking,
starbase built, etc.), the route is silently cleared inside the turn-end
loop. The problem affects both route types:

• Route FTL (COMMAND_ROUTE_FLEET, "Route FTL" SpaceButton)
• Route Moves (COMMAND_ROUTE_MOVE, "Route Moves" SpaceButton)

Both paths run through the same Route.makeNextMove() and through the same
turn-end loop in AITurnView.java; the only difference is the speed
variable at the top of the loop. Hence the bug is pathfinding-related,
not speed-related.

This produces two observable problems:

1. Human player: fleet stops without any clear feedback that its destination
   was abandoned. On the next turn the player re-plans the same route to
   the same target; generateMultiPathRoute() produces essentially the same
   detour; and the fleet oscillates between the same two squares forever
   until the player notices.

2. AI (CHALLENGING): makeReroute() in MissionHandling. java keeps issuing a
   fresh AStarSearch or a new simple Route toward the same mission target
   after the route has been nulled, so the same detour is regenerated turn
   after turn against the same blocker. Same oscillation pattern, but the
   AI never "notices" because nothing cancels the mission.

Root cause is the same in both paths: Route.makeNextMove() returns false the
moment it hits a blocked tile, and every caller reacts by setting
fleet.setRoute(null). The multipath information that was already computed
(including the waypoints in Route.nextPoints) is discarded wholesale, even
though only ONE of the waypoints is blocked.

Reproduction (human)

1. Own a fleet with any drive (the bug is independent of FTL vs. regular).
2. Have an ion storm, space anomaly, or any other blocked tile sit between
   the fleet and a target several sectors away.
3. Select the fleet, click "Route FTL" (or "Route Moves"), then click the
   target on the map. The UI shows a multipath route bending around the
   obstacle (generateMultiPathRoute did its job).
4. End turn a few times. As soon as the obstacle sits on one of the route's
   waypoints when the fleet arrives there, the fleet stops. Only the
   generic " has encouter obstacle and waiting for more orders"
   message is produced; the route is gone.
5. Re-plan the same route to the same target — same detour, same blocked
   tile, fleet goes nowhere. Repeat indefinitely.

Test evidence (both route types reproduce)

The bug has been reproduced live with both command types on v0.28.2,
against a space anomaly at (64, 16) which was the route destination.
Excerpt from a session log (Scout fleet, FTL speed 3, regular speed 1):

Turn 59 - Route Moves (regular) set from (63, 15) to (64, 16), ETA 1
Turn 60 - Route Moves (regular) re-set, ETA 3
Turn 65 - Scout reaches (63, 15), adjacent to the anomaly
Turn 66 - Native message fires:
"Scout #0 has encouter obstacle and waiting for more orders."
Fleet is stuck at (63, 15), route == null.

The same symptom occurs with "Route FTL". Both command paths hit the same
else { fleet.setRoute(null); ... } branch in AITurnView.java that emits
exactly that message string.

Relevant source (all paths unchanged between 0.28.2 and current master)

---

FILE: src/main/java/org/openRealmOfStars/starMap/Route.java

/**

• Move a bit closed to end
• @param starMap to check if sector is block or not. If this is null

•    then blocked check is not done
  

• @param speed Movement speed
• @return true if move was possible and false if not
  */
  public boolean makeNextMove(final StarMap starMap, final int speed) {
  for (int i = 0; i < speed; i++) {
  if (getDistance() > 0) {
  double dx = startX + getMx();
  double dy = startY + getMy();
  int sx = (int) Math.round(dx);
  int sy = (int) Math.round(dy);
  if (starMap == null) {
  startX = dx;
  startY = dy;
  } else if (!starMap.isBlocked(sx, sy)) {
  startX = dx;
  startY = dy;
  } else {
  return false; // <-- hard-fail on first block
  }
  if (endOfPoint() && nextPoints != null) {
  startX = endX;
  startY = endY;
  endX = nextPoints.get(0).getX();
  endY = nextPoints.get(0).getY();
  nextPoints.remove(0);
  if (nextPoints.size() == 0) {
  nextPoints = null;
  }
  }
  }
  }
  return true;
  }

Observation: the method has full knowledge of a multipath route (nextPoints)
but does not attempt to skip a blocked segment; it bails out on the first
blocked sector even if the blocker sits exactly on a waypoint that could be
re-routed around.

---

FILE: src/main/java/org/openRealmOfStars/game/state/AITurnView.java
(also used for HUMAN fleets at turn end — see call around line 3492)

} else if (fleet.getMovesLeft() > 0
&& !fleet.isStarBaseDeployed()) {
int speed = fleet.getRoute().getRegularSpeed();
if (speed == 0) {
// Need to make makeNextMove at least once
speed = 1;
}
for (int k = 0; k < speed; k++) {
if (fleet.getRoute() == null) {
break;
}
// Make sure fleet can actually move
if (fleet.getRoute().makeNextMove(game.getStarMap())
&& !game.getStarMap().isBlocked(fleet.getRoute().getX(),
fleet.getRoute().getY())
&& !game.getStarMap().isDangerous(fleet.getRoute().getX(),
fleet.getRoute().getY())) {
// Not blocked so fleet is moving
MissionHandling.moveFleetFTL(game, fleet.getRoute().getX(),
fleet.getRoute().getY(), info, fleet);
...
} else {
fleet.setRoute(null); // <-- full route discarded
if (info.getMissions().getMissionForFleet(
fleet.getName()) == null) {
// Movement was blocked, giving a message
Message msg = new Message(MessageType.FLEET,
fleet.getName()
+ " has encouter obstacle and waiting for more orders.",
Icons.getIconByName(Icons.ICON_HULL_TECH));
...
}
}
}
}

---

FILE: src/main/java/org/openRealmOfStars/ai/mission/MissionHandling.java

private static void makeReroute(final Game game, final Fleet fleet,
final PlayerInfo info, final Mission mission) {
if (fleet.getRoute() == null) {
// Fleet has encounter obstacle, taking a detour round it
if (fleet.getaStarSearch() == null) {
// No A star search made yet, so let's do it
AStarSearch search = new AStarSearch(game.getStarMap(), fleet.getX(),
fleet.getY(), mission.getX(), mission.getY(), 7, true);
search.doSearch();
search.doRoute();
fleet.setaStarSearch(search);
makeRerouteBeforeFTLMoves(game, fleet, info, mission);
} else {
makeRerouteBeforeFTLMoves(game, fleet, info, mission);
}
}
}

private static void makeRerouteBeforeFTLMoves(final Game game,
final Fleet fleet, final PlayerInfo info, final Mission mission) {
AStarSearch search = fleet.getaStarSearch();
int moves = fleet.getMovesLeft();
for (int mv = 0; mv < moves; mv++) {
PathPoint point = search.getMove();
if (point != null
&& !game.getStarMap().isBlocked(point.getX(), point.getY())) {
moveFleetRegular(game, point, info, fleet);
}
if (fleet.getMovesLeft() == 0) {
break;
}
}
fleet.setMovesLeft(0);
if (search.isLastMove()) {
if (search.getTargetDistance() > 0) {
fleet.setRoute(new Route(fleet.getX(), fleet.getY(), mission.getX(),
mission.getY(), fleet.getFleetFtlSpeed())); // <-- same target,
if (info.getAiDifficulty() == AiDifficulty.CHALLENGING) {
fleet.setRoute(game.getStarMap().generateMultiPathRoute(
fleet.getRoute())); // <-- same detour
}
}
fleet.setaStarSearch(null);
}
}

---

FILE: src/main/java/org/openRealmOfStars/starMap/StarMap.java
(multipath generator — runs only before the first move, never again)

public Route generateMultiPathRoute(final Route simpleRoute) {
Route result = null;
Route origRoute = simpleRoute.copy();
if (simpleRoute.getRawValue() <= 0) {
return simpleRoute;
}
if (isBlocked((int) Math.round(origRoute.getEndX()),
(int) Math.round(origRoute.getEndY()))) {
// shifts end point up to 6 tiles away from a blocked destination
...
}
...
Coordinate blocked = origRoute.checkBlockedCoordinate(this);
if (blocked == null) {
return origRoute;
}
...
// walks 90 degrees off the blocker, up to 6 steps each side, adds waypoints
...
}

(For the full method body see StarMap.java lines 3608-3726.)

Why the multipath waypoints do not protect the fleet

generateMultiPathRoute() only runs at route planning time (mouse-listener
click / AI mission start). The resulting waypoints are frozen into
Route.nextPoints. If any tile along that frozen path becomes blocked later
(ion storm drift, another fleet parking, deep space anchor deployed,
starbase built), Route.makeNextMove sees the block, returns false, and
every caller immediately nulls the fleet's route. The multipath logic never
gets a chance to route around the NEW blocker.

Suggested fix direction (not yet attempted — posted for discussion)

Two low-risk options that stay inside existing APIs:

Option A — "re-plan on block" inside AITurnView.java
When makeNextMove returns false and the route still has remaining
nextPoints or distance, try:

  Route retry = starMap.generateMultiPathRoute(
      new Route(fleet.getX(), fleet.getY(),
                (int) Math.round(fleet.getRoute().getEndX()),
                (int) Math.round(fleet.getRoute().getEndY()),
                fleet.getRoute().getFtlSpeed()));
  if (retry.checkBlockedCoordinate(starMap) == null) {
    fleet.setRoute(retry);
    // retry the same move this turn
  } else {
    fleet.setRoute(null);
    // send the existing "has encouter obstacle" message
  }

~15 LOC, contained in the turn-end loop, does not touch Route.java.

Option B — teach Route.makeNextMove to skip a single blocked waypoint
When blocked and nextPoints != null and the CURRENT endX/endY equals the
blocker, drop that waypoint and try the next one. Fails fast if all
remaining waypoints are blocked.

Both options kill the oscillation because the second regeneration uses the
CURRENT starMap snapshot (with the new blocker already in place), so it
produces a different detour — or cleanly cancels the route if no detour
exists.

Notes

• The problem surfaced while building screen-reader accessibility for blind
  players. Sighted players can at least see the fleet icon go stationary;
  blind players only get the generic obstacle message and cannot tell why
  the fleet refuses to move even after re-planning.
• Issue verified on master (0.28.2-SNAPSHOT, commit current as of
  2026-04-12). Route.java, AITurnView.java, MissionHandling.java,
  StarMap.java are byte-identical to the 0.28.2 release.
• No game-save is required to reproduce; any map with an ion storm works.

[tuomount]

I was able to get last move done, but problem is that space anomaly exploration happens on AI turn so it cannot show the text when exploring it. I need to add that space anomaly text into messages. Claude found the correct place where issue is, but reasoning was not 100% accurate. I don't think this was a bug, but feature. Also reason why generic obstacle message is shown is that if FTL is blocked it does not move at all, so it is not visible for player why route was blocked so I cannot tell why it was blocked. Idea is that player needs to move closer with regular moves in order to see what is causing the block. Of course it could be more described text while moving with regular moves.

Also Claude claims that multipath route does not get reroute if there is blocked/dangerous tile in middle of path. I need to check this one also since this could be true.

Any way this looks something that I am able to reproduce and will fix into next version.

[tuomount]

There is now fix in master. It still requires testing but it will be in next release.