So Tynan, care to explain the AI optimizations?

[Ramsis]

Just figured I'd ask seeing as you've been working your butt off on it and I know we're all curious on what you've fixed/changed in regards to how people function and do things in game.

[Geertje123]

If you reply, Tynan, could you also explain what changed about the windturbines?

"Expanded/refactored code for wind turbine wind area."

[Ramsis]

Fingers crossed.

[thefinn]

If you reply, Tynan, could you also explain what changed about the windturbines?

"Expanded/refactored code for wind turbine wind area."

That would be refactoring the calculations of how fast the turbine turns when something is in the way - what the power reduction is I'd imagine.

[Tynan]

If you reply, Tynan, could you also explain what changed about the windturbines?

"Expanded/refactored code for wind turbine wind area."

Haplo's original code used a big complex algorithm to yield all the coverage cells. I replaced it with a simpler one that just generates a rectangle in front and back and iterates over their cells.

As for the AI optimizations, lots of things, big and small. You shouldn't notice much difference aside from big gains in speed.

I made a bunch of auto-colony-generation test cases so I can press one button and, say, the game will generate one of every work table, each with one of every bill type, 15 colonists with all work typed enabled, and a gigantic stockpile filled with every item in the game. This produces consistent, repeatable cases which I can invoke easily and on which I can compare performance, which is essential because performance tuning is guided by constant profiling.

In terms of actual optimizations, among others:

-Various peephole optimizations, largely about replacing foreach loops with simpler for loops to eliminate the need to allocate (and thus garbage collect) the 24-byte iterator object every time. When the foreach is inside a doubly or triply nested loop this can actually make a big difference.

-Hauling got the biggest overhauls. Now, instead of checking every haulable thing on the map against every possible hauling destination, they game keeps a central list of everything that should be hauled from where it is now. This is actually kind of complicated. Not only can things be in or out of storage, but they can also be designated for hauling or not, forbidden, unreachable. Worst of all is handling the storage zone priorities, because these mean that even if something is in storage it might still need to be hauled. For this case I thought for a few hours about different solutions and eventually made a central scanner that continuously scans every stockpile and checks to see if the things could potentially be hauled to a higher-priority stockpile.

-I did a fun optimization on the code that scans over the cells of a stockpile to find somewhere to block a haulable. Instead of checking every cell to find the closest one, we scan for closest but then, if we're found one, we break out of the loop early after checking 1-5% (random) of the cells in the zone. Combined with shuffling the zone cells, this creates a double benefit: we have to scan far fewer cells if we find one early, and the colonists will now not always drop items in the perfect closest cell. It looks a bit more natural when there is some randomness to where in the stockpile they drop the item.

-Some optimizations to growing. For example, we now don't check the temperature of every possible growing cell, but rather we check the temperature only of one cell in the growerthing(e.g. hydroponics basin) or zone, on the theory that if you can't plant in one cell you can't plant in any of it.

-The crafting AI made big lag spikes when there were lots of bills and lots of ingredients but none of the ingredients could be used for those bills, because it was scanning every ingredient for every bill over and over every time a pawn thought. I thought I might have to do some deep optimization but a simpler solution seems to have brought this well under control: simply ignore bills which have been scanned and failed to find ingredients in the last ~8 seconds. This will create AI failures sometimes when they scan for work just after the necessary ingredient is spawned/placed, but I think players won't notice and it'll look natural enough.

-A bunch of calcluations that fire was doing every frame have been refactored as well as spaced out to intervals so they're only done every 150 ticks. The overall behavior is the same.

Lots of other things too!

[Ramsis]

If you reply, Tynan, could you also explain what changed about the windturbines?

"Expanded/refactored code for wind turbine wind area."

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOORDS
Lots of other things too!

Thanks for taking the time to explain all that Tynan, that's all really great news! Is there any chance that the test system you made will be usable for players to toy with at any point? I feel modders who do game overhauls would probably find some use with it.

[Tynan]

All the test commands are available. It's not designed to be moddable though. In fact it would be rather hard to do, though you could easily copy/paste the code to make a very similar system.

[DeMatt]

-Some optimizations to growing. For example, we now don't check the temperature of every possible growing cell, but rather we check the temperature only of one cell in the growerthing(e.g. hydroponics basin) or zone, on the theory that if you can't plant in one cell you can't plant in any of it.

...Hmm.  This might be a problem if you're in the habit of creating non-contiguous growing zones (encompass both areas, delete the part connecting them)...

I mean, mine don't cross environment boundaries (my set-of-potato-plots is all outside, for instance), but the potential is there.

[Dr. Z]

Colonists will now not always drop items in the perfect closest cell. It looks a bit more natural when there is some randomness to where in the stockpile they drop the item.

Could look a bit messie too in my imagination, I always wondered why they don't haul the item to the farest away cell so they don't have to walk over the already deployed items again and again and be slowed down. Also what DeMatt says, one growing zone placed in different tempratures IS possible.

These are the two things I thought of during your post, all the other things are great improvements and I appreciate that you're taking your time to speak to the community. Keep up the good work.

[OVIE]

Colonists will now not always drop items in the perfect closest cell. It looks a bit more natural when there is some randomness to where in the stockpile they drop the item.

Could look a bit messie too in my imagination, I always wondered why they don't haul the item to the farest away cell so they don't have to walk over the already deployed items again and again and be slowed down.

I find myself setting up (and later expanding) dumping stockpiles in order to reduce the amount pathing over chunks. Kind of annoying, but it's not terribly concerning.