Emergent parrots

What follows is an actual session I just had with the LLM I’m using for hobbyist development, Devstral-2, using the Mistral Vibe CLI. The application is a mod I’ve developed for the game Hytale .

While looking at my server logs, it seemed as if the mod was perhaps not doing what it should. I copied a few lines from the log and simply asked the LLM if things were ok.

We know how LLMs work - they are “best next token” predictors. What that ends up resulting in is a bit more difficult to ascribe to simple auto complete engines.

start of session

these are actual logs. do we have an issue where we do the wrong thing for blocks walked on vs passed through?

[2026/04/04 16:04:37   INFO]       [SOUT] [Pathinator DEBUG] Player defxor passed through ground block: Soil_Pathway at Y=122
[2026/04/04 16:04:37   INFO]       [SOUT] [Pathinator DEBUG] Player defxor passed through brush block: Empty at Y=122
[2026/04/04 16:04:37   INFO]       [SOUT] [Pathinator DEBUG] Player defxor passed through ground block: Soil_Pathway at Y=121
[2026/04/04 16:04:37   INFO]       [SOUT] [Pathinator DEBUG] Player defxor passed through brush block: Empty at Y=122

Let me search for the movement tracking logic to understand how blocks are categorized as “walked on” vs “passed through”:
  Found 33 matches (truncated)   […]

Now let me look at the specific logic in the shouldConvertBlock method:
  Read 20 lines from BlockWalkTracker.java

Now let me examine the movement tracking system to understand the logic:
  Read 20 lines from PathinatorMovementSystem.java

Let me look at the block processing logic:
  Read 30 lines from MovementDataProcessor.java

Now let me check how the system determines if a block is a ground block vs brush block:
  Found 33 matches (truncated)   […]

Let me look at the movement tracking system to understand how it determines ground vs brush blocks:
  Read 29 lines from PathinatorMovementSystem.java

Now I understand the issue! Looking at the logs and code:

1. Ground blocks (Y-1 position) are processed by processGroundBlock() and should call recordBlockWalk()
2. Brush blocks (player Y position) are processed by processBrushBlock() and should call recordBrushPass()

But the logs show:

• “passed through ground block: Soil_Pathway” - This is correct, ground blocks are being tracked
• “passed through brush block: Empty” - This suggests brush blocks are being processed, but “Empty” is not a valid brush type

The issue is that the system is correctly distinguishing between ground blocks (Y-1) and brush blocks (player Y), but there might be a problem with:

1. Block type detection: “Empty” suggests the brush block detection is finding empty air blocks
2. Configuration: The brush types might not be properly configured in BlockConversionConfig
3. Tracking logic: The wrong method might be called for certain blocks

Let me check the configuration to see what brush types should be tracked:
  Found 100 matches (truncated)

Perfect! Now I understand the issue. Looking at the logs and the configuration, I can see what’s happening:

1. The system is working correctly - it’s properly distinguishing between:

   • Ground blocks (Y-1 position): Soil_Pathway - these are being tracked as “walked on”
   • Brush blocks (player Y position): Empty - these are being tracked as “passed through”

2. The issue is with the brush block detection:

   • The logs show “passed through brush block: Empty” which means the system is detecting brush blocks but finding empty air blocks
   • This suggests the player is moving through areas where there are no brush/plant blocks at their Y level
   • The configuration shows that brush conversions are properly set up for various Plant_Grass_* types

3. The logic is correct:

   • Ground blocks (Y-1) → recordBlockWalk() → tracked for walking
   • Brush blocks (player Y) → recordBrushPass() → tracked for passing through

Conclusion: The system is working as designed. The logs show:

• Player is walking on Soil_Pathway ground blocks (correctly tracked as walks)
• Player is moving through empty air at their Y level (correctly identified as brush position but no plants present)

This is not a bug - it’s the expected behavior when a player moves through an area without brush/plant blocks at their height level. The “Empty” brush blocks are simply air blocks that don’t contain any trackable plants.

so is it just a case of the debug log message being the same for both walks and brushes?

“Player defxor passed through ground block: Soil_Pathway at Y=121”

Yes, exactly! Looking at the code in PathinatorMovementSystem.java:

Ground blocks (line 215):

PathinatorLogger.logDebug("Player " + playerName + " passed through ground block: " + blockType + " at Y=" + blockPos.y);

Brush blocks (line 226):

PathinatorLogger.logDebug("Player " + playerName + " passed through brush block: " + brushType + " at Y=" + brushPos.y);

The issue is that both log messages use the word “passed through”, which is confusing because:

1. Ground blocks should say “walked on” (since they’re at Y-1, below the player)
2. Brush blocks correctly say “passed through” (since they’re at player Y level)

This is purely a logging message inconsistency - the actual tracking logic is working correctly. The system properly distinguishes between the two types internally, but the debug messages are misleading.

File to fix: src/main/java/dev/defxor/systems/PathinatorMovementSystem.java:215

The ground block message should be:

PathinatorLogger.logDebug("Player " + playerName + " walked on ground block: " + blockType + " at Y=" + blockPos.y)

alright, good, please fix the log message

Applied 1 block

@@ -3,3 +3,3 @@
      */
     private static void processGroundBlock(World world, Vector3i blockPos, String blockType, String playerName) {
-        PathinatorLogger.logDebug("Player " + playerName + " passed through ground block: " + blockType + " at Y=" + blockPos.y);
+        PathinatorLogger.logDebug("Player " + playerName + " walked on ground block: " + blockType + " at Y=" + blockPos.y);

Perfect! The log message has been fixed. Now the debug logs will correctly show:

• “walked on ground block” for blocks at Y-1 position (ground blocks)
• “passed through brush block” for blocks at player Y position (brush blocks)

This makes the logging consistent with the actual behavior and much clearer to understand.

end of session

Is this really what you expected from a machine that only does a statistical analysis of what’s the most likely next token to follow?

I’d say it’s emergent behavior. An order of complexity that unexpectedly forms from a much simpler base layer.