I have found that on occasion, when adding or removing machines from a group, the group is not updated. I have so far only seen this occur in a Shed (all sheds, to be specific), but I suspect it may occur in other "indoor" areas.

For example, in this group, I have a running machine group:

Adding new machines produces this "group":

Even though the machines are adjacent, the group is not correct considered as a unit.

Exiting and re-entering the area does not resolve the issue. I've only found two way to solve the issue:

1. Open the mod settings (GMCM) and hit "Save & Close" and this will refresh the group correctly
2. Move the chest to a new tile (with the Better Chests mod) and then move it back. If you just remove the chest the "vanilla" way (remove the items and replace it) it still will not refresh.

Given that I've only noticed the problem recently, after I installed the Better Chests mod, and that solution 2 as noted above works, this is almost certainly a compatibility issue between the two mods.

If you temporarily remove all mods except Automate, does placing an adjacent keg still not update the machine group?

If you temporarily remove all mods except Automate, does placing an adjacent keg still not update the machine group?

Sorry for the delay, I just ran the game with everything EXCEPT Automate and SMAPI removed, and was still able to reproduce the issue:

I started using Junimo chests around the time the issue popped up, so that would be my next guess. Here is the output of automate summary:

...
Machines connected to a Junimo chest:
      Distributed group:
          922 x Keg (processing)
          1 x Chest (7/9 full)
...

Placing new kegs next to the machine (as in my screenshot above) does not change this number, so they are not being registered. Running automate reset gets them to be included in the group (and then summary shows the larger, correct number) which I suppose is to be expected.

I haven't had a chance to take a look at the codebase yet, but I'd wager it's something to do with how Junimo chests are treated.

Sorry for the slow responses; I'm mostly working on the next game update for a while, so I'm not checking mod messages as often.

Can you create a zip of your save folder and attach it here?

No worries @Pathoschild thats understandable.

I've attached the save I've been using this with. It seems to only happen for machine groups after I add a junimo chest.

HoneyBee_302121886.zip

Was a cause found for this? I've started experiencing exactly the same thing since I started using junimo chests. I've tried removing a working machine and placing it back down both in the same place and in adjacent spaces. Neither triggers the machine to be recognised.

So far I've noticed it affecting kegs and casks.

Ran into this and noticed there hasn't been an update in a while, so thought I'd try taking a look.

With verbose logging on:

[00:42:11 TRACE Automate] Object list changed in Mountain, but no reload is needed.

That means it runs the hook, and presumably gets to this point in ReloadIfNeeded:

It's my first time looking at the code, but it at least appears to explain why moving the JC itself works; the condition is different when the added object is a container, i.e. a chest of any kind (ContainsOrAdjacent) vs. when it's a machine (IsConnectedToChest).

My guess would be that IsConnectedToChest is incorrect (i.e. returns false) for JCs. But looking at how that method is implemented, it's just some dictionary lookups, which is where I'm currently getting lost. Going by the comments, looks like it should pass the first check in there (one of the 8 surrounding tiles being an "active tile" since the overlay shows green), but apparently is not.

I do notice that JunimoMachineGroup has its own totally separate implementation from the base MachineGroup - might have something to do with that, and in particular the GetTiles implementation or the method used to build the tile map? Can't see anything in there that looks suspect, but it looks like that's where the rubber meets the road - it seems to be the only point in this particular call stack where JCs are treated differently from the regular kind.

There's no doubt that it's JC-related, by the way. If I take just a regular isolated chest and put a machine next to it, the machine immediately picks up what's in the chest. But if I have a chest connected to a JC, then putting a machine next to either the JC or the original "feeder" chest no longer works without a forced reload. I guess the presence of a JC anywhere makes the whole group a "junimo group". It's very easy to repro - place regular chest, place machine adjacent, place JC adjacent to machine, and then try to place another machine next to either original chest or JC.

Far from a conclusive answer - but maybe the added info will help someone else.

@focustense Thanks for the repro steps! They made testing much easier.

The issue is that ReloadIfNeeded didn't check if the tile was connected to the Junimo chest group (which is tracked separately from the per-location groups). That's now fixed in develop for the upcoming Automate 1.28.6. Thanks to everyone who reported it!