Account for critter lag by scaling critter effects with lag

[Zarquan]

One of the most annoying things to see in a base with lots of critters is when a rancher comes in and starts ranching and only gets a couple critters in the day because their AI is slow.

Perhaps this issue could be solved mathematically.  A rancher is supposed to spend a certain amount of time grooming a critter and they get a certain amount of groom duration.  What if the groom duration provided was increased based on the time the rancher tried to call the critter and the critter started moving?  

By recording the in-game time the rancher starts calling the critter and the time the critter hears the rancher and comes to the grooming station, you could apply a multiplier to the existing groom duration. 

I haven't measured it, but let's assume grooming takes 10 in game seconds and this gives the critter "groomed" for 2 cycles.  If the critter were lagging for 20 in game seconds, you could apply something approaching a 3x multiplier on the groom duration to take in to account the lag, making the groom buff last 6 cycles.  This mostly solves the problems caused by lag with almost no computational cost.

Spoiler

This exact approach actually makes critter lag a net benefit on each individual grooming, so a more advanced version of this would alter the multiplier based on the amount of time it took the critter to get to the grooming station. 

Suppose grooming takes 10 seconds to apply the 2 cycle buff and they lag for 20 seconds.  Once the critter is done lagging, it takes them 5 seconds to reach the grooming station and start grooming.  You could take these 5 seconds in to account by essentially saying the grooming took 15 seconds, so the grooming applies 4.67 cycles of "groomed."

The time numbers are obviously variable.  A higher level rancher would provide a larger base "groomed" duration. However, this is all simple constant time math that would partially solve the problem. 

This, supplemented with the ability to add to the grooming time before the buff ends, would pretty much perfectly solve the problem.  For example, if "groomed" duration has less than 1 cycle remaining, then the critter can be groomed again with the new "groomed" duration being added on to the previous one. 

A similar thing could be applied to drekko shearing, where lag increases the amount of material you get from the drekko based on the growth rate of the coat.

[Sasza22]

That`s an interesting approach. Maybe they could make the drecko just teleport to the grooming station after a set amount of time (as long as it can reach it). Additionally when a critter is low on calories but has enough food around itself but lagging the game could just switch a portion of it`s food into the product it makes while addjusting it`s calories so that the critters are more reliable in how they work even if the game can`t handle their movement.

Might be exploitable but should fix the critter lag for lategame a bit.

[Zarquan]

10 minutes ago, Sasza22 said:

That`s an interesting approach. Maybe they could make the drecko just teleport to the grooming station after a set amount of time (as long as it can reach it). Additionally when a critter is low on calories but has enough food around itself but lagging the game could just switch a portion of it`s food into the product it makes while addjusting it`s calories so that the critters are more reliable in how they work even if the game can`t handle their movement.

Might be exploitable but should fix the critter lag for lategame a bit.

My thinking on critter calories is that they should just eat their fill when they are hungry.  Keep the average kcal consumed per cycle the same, but they eat a ton when they do eat.

I'm not sure about teleporting dreckos.  Part of drecko ranching is building effective rooms.  If they teleport, then that challenge is removed.  Although I do wonder whether that should be a major challenge of ranching.

I also think that dying critters should get one turn at CPU time before they die.  Like, if a critter is drowning, before they die, they should get one turn at the critter AI after the time limit to move out of the liquid before they die.

This idea could be applied to other times AI lag causes problems too.  For example, when a dupe is lagging between each task, you could speed up the task based on the lag delay.

The main downside to this is that it probably would delay solving the underlying problems with performance.  But no matter what happens, I think there will always be some lag with the critters, so this patch would help.

[Timotheeee1]

would be much better to just give every species of critter its own dedicated AI thread. sure you might run into a situation where a dupe wastes time trying to grab some igneous rock right before it gets eaten but at least the game won't be as laggy.

[Zarquan]

41 minutes ago, Timotheeee1 said:

would be much better to just give every species of critter its own dedicated AI thread. sure you might run into a situation where a dupe wastes time trying to grab some igneous rock right before it gets eaten but at least the game won't be as laggy.

Generally, if you have a large numbers of critters, the ones you have a lot of are the ones you are ranching.  That means the critters of the species you are ranching would still take forever to get to the rancher. 

The goal here is to create a simple solution that solves the issue of lag making ranchers less effective.

[Sasza22]

3 hours ago, Zarquan said:

The goal here is to create a simple solution that solves the issue of lag making ranchers less effective.

The simliest thing i can think of is changing how a critter called by rancher is handled. Instead of it being on the same laggy thread they could by bumped to a higher priority one for the time they are called and groomed.

[Zarquan]

6 hours ago, Sasza22 said:

The simliest thing i can think of is changing how a critter called by rancher is handled. Instead of it being on the same laggy thread they could by bumped to a higher priority one for the time they are called and groomed.

That would be more complicated than what I am suggesting.  Basically, for my suggestion, all the devs would have to do is record the time the dupe starts calling the critter and the time the critter responds to the call and do some math.  The critter AI wouldn't need to be changed.

Not saying that what you are suggesting isn't a good idea.  But what I'm suggesting is three or four lines of code.