I get about a 10s interruption each time JobGiver_OptimizeApparel.TryGiveJob postfix runs for my pawns with Royal Titles. Forcing very specific outfits helped remove the lag some of the time when drafting/undrafting but not all of the time and the hitch still pops up pretty frequently. I've even been strict on not storing gear I won't equip in ChangeDressers, I think I have a normal amount of apparel stored up for a 16 pawn colony.
I've looked quite a bit at the code and understand in general but I'm not 100% on why this is the current approach. As I understand it, the normal JobGiver_OptimizeApparel.TryGiveJob checks all of the apparel in pawn.Map.listerThings.ThingsInGroup(ThingRequestGroup.Apparel) which is not the same list of apparel you'd like to check. This is where my confusion sets in, because apparel in change dressers is fair game for bills and caravans (this is another thing that confuses me, when WeaponStorage and ChangeDressers dump their inventory for caravan loading, AFAIK, this is not necessary). So, I have a couple of possible suggestions that I'd be happy to try to implement in a PR (or even just a hack in my own version).
1) Stop overriding the results of JobGiver_OptimizeApparel.TryGiveJob, instead, override the contents of pawn.Map.listerThings.ThingsInGroup(ThingRequestGroup.Apparel) in the prefix to whatever gear you'd like and then swap it back in the postfix (this would also have the benefit of being a little more future proof because you're not so dependent on the internals of the apparel optimization system and you benefit from any code optimizations made).
2) Refactor the ApparelUtils.FindBetterApparel method to be more functional (remove the ref parameters so it is easier to memoize and cache) and build data structures that allow you to ignore calculating apparel scores that don't require an update.
3) Use threading to dispatch a new job after you've calculated the best apparel without blocking the UI thread.
4) A combination of 2 & 3 where some threaded-task system is calculating best apparel and the JobGiver_OptimizeApparel.TryGiveJob is just an interrupt to create a job reflecting this apparel
5) Remove this harmony patch entirely because it might not do anything helpful (this is more a question of my understanding of the patch).
I get about a 10s interruption each time
JobGiver_OptimizeApparel.TryGiveJobpostfix runs for my pawns with Royal Titles. Forcing very specific outfits helped remove the lag some of the time when drafting/undrafting but not all of the time and the hitch still pops up pretty frequently. I've even been strict on not storing gear I won't equip in ChangeDressers, I think I have a normal amount of apparel stored up for a 16 pawn colony.I've looked quite a bit at the code and understand in general but I'm not 100% on why this is the current approach. As I understand it, the normal
JobGiver_OptimizeApparel.TryGiveJobchecks all of the apparel inpawn.Map.listerThings.ThingsInGroup(ThingRequestGroup.Apparel)which is not the same list of apparel you'd like to check. This is where my confusion sets in, because apparel in change dressers is fair game for bills and caravans (this is another thing that confuses me, when WeaponStorage and ChangeDressers dump their inventory for caravan loading, AFAIK, this is not necessary). So, I have a couple of possible suggestions that I'd be happy to try to implement in a PR (or even just a hack in my own version).1) Stop overriding the results of
JobGiver_OptimizeApparel.TryGiveJob, instead, override the contents ofpawn.Map.listerThings.ThingsInGroup(ThingRequestGroup.Apparel)in the prefix to whatever gear you'd like and then swap it back in the postfix (this would also have the benefit of being a little more future proof because you're not so dependent on the internals of the apparel optimization system and you benefit from any code optimizations made). 2) Refactor theApparelUtils.FindBetterApparelmethod to be more functional (remove the ref parameters so it is easier to memoize and cache) and build data structures that allow you to ignore calculating apparel scores that don't require an update. 3) Use threading to dispatch a new job after you've calculated the best apparel without blocking the UI thread. 4) A combination of 2 & 3 where some threaded-task system is calculating best apparel and theJobGiver_OptimizeApparel.TryGiveJobis just an interrupt to create a job reflecting this apparel 5) Remove this harmony patch entirely because it might not do anything helpful (this is more a question of my understanding of the patch).