That's correct. The bot implementation is setup to explore an entire area and attempts to get all monsters loaded into view so the CR can kill everything.
Actual combat logic is handled by the CRs, which in the case of ExampleRoutine logic, doesn't try to full clear everything anymore.
The default behavior of full clearing in the CR we provide was removed for two main reasons:
1. A lot of vocal complaints about it being too inefficient/slow trying to kill everything in an instance, where more people just run though and kill a lot of monsters, but not all. The inefficiency complaints don't really matter, since it's user's job to make things work how they want if they don't like what we offer, but I agree with issues related to fully clearing an instance. GGG can easily track full clears since it's part of the achievements, so in the interest of trying to help users avoid a possible bot detection mechanic, it doesn't full clear anymore where as previous versions did.
2. If the CR tries to kill everything, and moves into range to kill everything, you see a lot of backtracking, which people always complain about. If you want to fully clear some areas and not others, you'd have to code that into the routine itself, as the logic we provide is for a generic case of grinding an area. The previous logic of trying to kill everything requires a design where you have to move towards your target under certain cases, which creates issues in some areas for ranged characters. In this game, combat logic changes based on the tileset you are in, so it's another example of needing really specific logic that we can't provide in a generic manner.
The underlying problem is there is no way to write one set of logic that works as it should across all areas in this game while doing the things people want (either full clear or not). Instead, you need logic that works per tileset to avoid a lot of issues that happen. In large open tilesets, you can have large combat ranges and attack distances, since there's not much of anything getting in the way. For small enclosed tilesets, like cavern and jail, you need really small combat ranges and logic that doesn't try to act too far, as you run into issues with walls, doors, and combat looping from there being multiple paths to a moving target.
There's two ways to solve the boss issue in corrupted areas:
1. Rewrite the CR (implement your own) to use a different combat model so it handles combat in each area a specific way that works for your setup (pretty much full clearing, while preventing infinite combat loops due to mobs moving behind walls).
2. Similar to the DominusFight plugin, make a task via a plugin that simply moves to the location of known bosses when in a corrupted area, so the CR enters combat and indirectly starts the boss fight.
So to summarize:
BasicGrindBot moves around the area, getting things into view for other logic to figure out what to do.
ExampleRoutine only handles "close by combat".
To have boss logic, you can either rewrite the CR logic to no longer handle "close by logic", or you can add a task so BasicGrindBot moves towards bosses, and then the "close by combat" takes care of them once in range (as shown by the DominusFight plugin).
