The Features [Temporarily] Left Behind But Not Forgotten (Patreon)

There are some items on my still very long TODO list of potential features or changes for Cogmind which have always been inevitable, but myself being able to only work on one thing at a time, some of these items have continued to sit there, waiting their turn, in some cases year after year.

Some because they're simply not high priority (despite being desirable and I know they'll be implemented one day), others because they would require dedicating a sizeable chunk of time to complete, bubbling to the top of my list only to be postponed, sometimes repeatedly.

I do revisit these parts of my notes when relevant discussions pop up, leaving more comments or ideas for future reference, but doing so can be a sad process, as is having for so long always talked about these features in the future tense, especially when much of it is QoL that could improve various aspects of the experience for a lot of players.

Thus aside from the recent Beta 14 data optimizations I've shared information about, I decided now is also the right opportunity to front-load these developments to make sure they happen and we can enjoy them now. No longer will I have to say "that's coming in a future version," no more postponing--we'll have them NOW!

Okay obviously not everything that might fall under this category, but at least some of the bigger ones :P

Ground Swapping

Sometimes your slots are full, you've got a full inventory, and you want to attach something directly from the ground, but the autoswap feature won't do it for you since there's no suitable target based on the rule set. In cases like this, especially when your inventory is already full and more manipulation would be required to complete an attachment, it'd be really nice if you could just specify the target yourself. Fortunately there's an easy way to approach this in terms of input: Just repeat the attach command you used ('a' or LMB) a second time and it'll open a menu showing all the valid swap targets to let you pick one, either via mouse or keyboard.

In the demo below, a System Restoration Module on the ground has no suitable target slots for automated swapping, but here is swapped in manually for a Matter Filter, dropping the latter since the inventory is full.

I'm curious just how often this feature will be used. Sometimes with QoL it's hard to tell just how useful something is until it's actually available to make those parts of the interface that much smoother. This type of functionality has been requested before, and I can think of situations where I might've benefited, but we've also already internalized the need to drop something from inventory as part of a multistep process and handle it that way. This might be even bigger QoL than it seems?

Mouse Autopair Access

This one is relatively minor compared to the others, and technically not something that's been heavily requested, just something I've wanted to do.

Having swapped parts that you still have access to (inventory <-> attached), you can easily swap them back at any time via the normal swap menu ('/'+letter+Y, or Ctrl-RMB and the bottom option), and while this is really fast for keyboard users, mouse users have it a bit more fiddly with the extra Ctrl requirement and cursor movement. Well we already have the tick marks that represent an existing pair (and the momentary hover-to-display them all), so how about making it clickable too...

Even easier reswapping for mouse users, though naturally it was a fair bit of work to turn what was a mere visual indicator into a clickable button with the right behaviors. Worth it though, and it's in!

Grunt Hopping

Okay I admit this one technically counts as a bug fix. I never really saw it much myself, just a result of my own play style compared to that of some other players who have encountered it a lot more frequently, but under the right conditions you can see non-flying bots jump right over other bots. This despite the checks I put on the AI behavior ages ago to try to prevent this when it shouldn't happen.

The thing is it does and should happen sometimes, just not in a way that will affect gameplay (or be seen at all), only meant to keep general performance within acceptable limits by not forcing too many pathfinding recalculations on the AI and allowing even non-flying bots to pass others for free under the right circumstances.

Although traditionally called "grunt hopping" by the community, this behavior is technically even more noticeable and likely with multitile enemies, commonly seen with Crushers, as scary as that is.

While specifically working with multitile robot movement (for some other cool new stuff coming), during close examination of the AI movement code I discovered a theoretical hole in the logic that suggested where the jumping effect might still possibly circumvent the rules I'd originally put in place to stop it.

Armed with the theory, I was finally able to recreate this scenario for actual testing! Many players have reported it over the years, and I'd even seen it myself before on rare occasions, but time after time my explicit tests turned up nothing, I could never get the same results, an important contributing factor to why this issue lasted so long. (Reliably recreating an issue is an important precursor to properly addressing it.)

I don't have any recordings of those old jumps, and they're now gone from the game, so nothing visual to share here on that front :)

But I'm not going to let you off that easy, nope.

While working on this and other AI behavior I've decided that the concept of bottleneck surprises has some benefits for keeping combat more, uh, dynamic, so I've gone ahead and made some AIs a little smarter in some cases, albeit in a realistic fashion. That's all I'll say about that ;)

Multitile Robot Movement

Big friends good! Not everyone might share such sentiment before Beta 14, but I can safely say the new and improved multitile robot movement behaviors make them much more fun and cool to have around. (This perhaps needs to come with the corresponding caveat that big enemies bad! :D)

Multitile robots have been the primary thrust of the past week of development, and one of the primary major needs which has been repeatedly postponed over the past several years. It was literally next on the list to be worked on at the end of each Beta 10, 11, and 12, and every time got pushed back. Very happy to have this behind me now, especially when it comes to multitile allies which could sometimes be a pain to work with.

The multitile progress is actually a pretty big topic which I could write a full article about, but I also kinda want to surprise everyone with some of the implications and new features, so I'm just going to pick a couple of elements to mention here...

Pushing!

Pathfinding is obviously one of the biggest issues with large robots, as it's naturally going to be easier for them to get stuck amidst a sea of smaller robots, more so when moving as a group alongside you and others, so I've once again let Polymind work shine its light on regular Cogmind! (the first time I reported another direct benefit was regarding the upcoming ID Mask)

If you recall in the design for Polymind, when taking control of a multitile host you can push other bots out of the way as you move, wading through them. I spent a sizeable portion of Polymind dev time enabling multitile robot control (too cool to pass up!), so it's nice to see some of that work being repurposed here by enabling the AI for large bots to push around smaller robots as well.

Here you can see a big moth perfectly happy to make its way through a pile of friends:

Your big friends will be happy to push you out of the way, too :) (unless you're sieged--and stop thinking about cheese already!)

Caravans!

Large allies also simply take up a lot of space, meaning if they follow as closely as others normally do, it's even easier than usual to form clumsy balls of robots that are often unable to move very fluidly. While the ability to push helps somewhat with the fluidity problem (even if it is only one-way), we still encounter issues if and when there are multiple large bots in the same area, since they cannot push each other.

The solution is to spread them out, using a behavior similar to how unarmed or non-combat allies lag a little ways behind you to keep them out of harm's way. So if you do manage to start building an army of big boys, they'll form up in a sort of caravan to follow you around, and hang back as far as they need to depending on how many there are. If one closer to the front falls, the ones in back move up to fill in the space.

Above you can see the debug visualization for dots used to approximate positions for followers, yellow for non-combat support elements, red for each subsequent large ally. As is the case already with non-combat followers, the entire caravan is capable of backing up together if you decide to backtrack, to an extent, before it will reverse direction entirely.

Post-update multitile robots still need wider testing and maybe we'll see more adjustments going down the line depending on specific scenarios that pop up, but the fundamental issues should be resolved as a result of these and several other changes.

Another shot of Big Backup in action:

Beta 14

Well dang, the Beta 14 changelog is already... quite sizeable xD

Altogether it's easily enough to be a 13.1, or even a respectable 14 in its own right if we're not aiming for megareleases anymore, but if I do any releasing now, it will postpone Scraptown even further, which is probably a bad idea at this point :P. So I am doing my best to resist the urge to put any of this out there yet (not even a prerelease) and preparing to finally actually really put the Scrap in Scraptown. Also the Botcubes. But mostly the Scrap.