In the WorkManager.ResolveAssignments method,
the following loop exists
int i = 0;
for (i = 0; i < toAssign; i++)
{
if (commitable.Count == 0)
break;

AssignWorkToPawn(current, commitable.Dequeue());
toAssign--;
}
This both decreases the number it wants to assign and also increases the indexing variable meaning it will only run the AssignWorkToPawn function, toAssign/2 times when this for loop runs. This makes it so the top assignments are not necessarily assigned first as when this loop concludes it puts the assignment to the back of the queue. Removing toAssign--; would fix this.

Oh yeah I see what you mean, good catch! This might explain some odd assigning behavior I've been noticing, I'll have to look further into this. Thanks for the report!

This fix has now been pushed to release.

Sorry to bother you with another bug report about priority but it seems that occasionally the priority of rules immediately after a conditional rule that doesn't meet it's target allocation is lower priority than it should be. I tried to look at the code again but unfortunately I couldn't find a simple one line fix.

Have you set Commitment or Incremental on any of your work specs? These features are a bit opaque and may result in the behavior you report. If not, could you elaborate on your configuration? Screenshots of your work tab, and work specifications up to the offending one. I'll also try to include some debugging tools in the next version.

I really appreciate the bug reports, and your efforts to locate the bugs in the code!

I am able to replicate it without Commitment or Incremental. The fastest way I have found to recreate the priority thing is to have 2 pawns, create an assignment for Firefight, with minimum 1 pawn, target of 2. Set a condition for a specific pawn (lets say A) so that it can only assign it to one of the pawns. Then create two new assignments below it, assign both of these to everyone with no conditions, put the one directly below it on Patient and the one below that on Doctor. When resolving assignments the following schedule will occur
A) Firefight: 1, Patient: 2, Doctor: 1
B) Patient: 2, Doctor: 1
I believe something about the fact that it is unable to assign to its full target of both pawns for some reason sends the assignment directly after it to the back of the list. So it assigns firefight, then doctor, then patient when it should be firefight, patient, then doctor.

It may be caused by this statement in WorkManager.ResolveAssignments running after the first item has already been removed by assignmentList.Remove(current)

else if (assignmentList.Count > 0)
{
var spec = assignmentList[0];
assignmentList.RemoveAt(0);
assignmentList.Add(spec);
}

But I am not sure if simply removing this block would cause problems with commitment or incremental since I haven't quite figured out how those are meant to work

Ah yes I see what you mean, that is indeed not the intended behavior. I agree with your observation of where it might be going wrong, and I think I may have an idea why it happens.

My theory is that the maxCommitment loop doesn't check if there are any actually applicable pawns available, causing it to reach maxCommitment without doing anything, meaning the assignmentList.Remove(current) statement on line 220 is executed, removing the Firefight work from the list. Then, the loop end, the lines you pointed out are executed, moving the now zero-positioned Patient to the back of the list. I'll have to do some debugging to verify this though.

Thank you for the detailed description of your setup, I'll use it for debugging the issue.

That did indeed appear to be the issue, I have released a fix for this now. Please let me know if this resolves your issue, and thank you for the help.

The work tabs names will be placed in the wrong place.

1.5x:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3470580518

1.0x:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3470715007

@OrAZion Can you elaborate further? Maybe provide a screenshot of the issue?

it seems to have to do with gui scale. normally they are in the right place for me but on 1.5x gui scale they do this

@OrAZion Thank you for the screenshot. I can reproduce it with @OceanicOxen's suggestion. I'll look into this issue as soon as possible, but it might take a while as the text rotation requires some tricky matrix fiddling that I honestly don't fully understand. I also see an issue with the lower part of the X buttons in the priorities list has been cut off, but I am unable to reproduce this with GUI scaling.

@OrAZion This issue should now be resolved with the latest update, thank you for the bug report.

The following 2 error are visible continuously when I press 'Exclude Pawns' button. And I can't exclude anything. Could you check about this?

1)
Exception filling window for Lomzie.AutomaticWorkAssignment.UI.ExcludeColonistsWindow: System.NullReferenceException: Object reference not set to an instance of an object
[Ref 98B54AD5] Duplicate stacktrace, see ref for original
UnityEngine.StackTraceUtility:ExtractStackTrace ()
(wrapper dynamic-method) MonoMod.Utils.DynamicMethodDefinition:Verse.Log.Error_Patch2 (string)
Verse.Window:InnerWindowOnGUI (int)
UnityEngine.GUI:CallWindowDelegate (UnityEngine.GUI/WindowFunction,int,int,UnityEngine.GUISkin,int,single,single,UnityEngine.GUIStyle)

2)
Mouse position stack is not empty. There were more calls to BeginScrollView than EndScrollView. Fixing.
UnityEngine.StackTraceUtility:ExtractStackTrace ()
(wrapper dynamic-method) MonoMod.Utils.DynamicMethodDefinition:Verse.Log.Error_Patch2 (string)
Verse.Widgets:EnsureMousePositionStackEmpty ()
(wrapper dynamic-method) MonoMod.Utils.DynamicMethodDefinition:Verse.Root.Update_Patch1 (Verse.Root)
Verse.Root_Play:Update ()