-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Color customization to work priorities #86
Conversation
Adds settings for colors for each Work Priority Level. 2-9 colors can be defined and each level is assigned the next color. If the max priority level is greater than the number of colors, the last two colors are blended together for the remaining levels.
static settings caused certain values to be lost on relaunch when the settings menu is open (just maxPriority, but there aren't many global settings)
# Conflicts: # Source/Core/Settings.cs # Source/Utilities/DrawUtilities.cs These conflicts were made by me and merged.
A bonus rewrite of Settings so it's not all static and so settings aren't lost. I found max priorities was reset when you reload the game and open the settings. I hoped this would make saving my color list cleaner, but it requires a copied list since it is set to null for some reason? |
…ifferent, for the shown Job priority. e.g A job type with priorities 3,3,3,1,3 would show as 3 (with the asterisk as before). Before this was just the highest priority, which is often the odd one out (at least how I set it up).
Oh snap, whenever I update my master, this pull request points to the new stuff. Oh well. Another commit on a different thing - just changes the shown job priority to be the most common sub-priority, instead of the highest. I found that I would have crafting at priority 3 but increased the medicine crafting to 1, it would show 1 even though most of the work is priority 3. So this changes has it show 3 instead. |
…of TryGetValue Tries SO HARD to get the value, it is set to 0 if there is no key. I said TRY, you return FALSE meaning NO VALUE - no reason to change MY value, tyvm. Just use ContainsKey instead, meh.
…jobs with only one sub-job set. e.g. If you set "Feed prisoner" to 1, but the rest of Warden to blank, it will show blank for the Warden job.
Noticed it filtered out 0-priority tasks, and I thought this new method should include them. A job will show blank if most sub-jobs are blank - with the little asterisk showing there is an exception as before. Also bugfix concerning Dictionary usage. TryGetValue doesn't mean "do or do not, there is no try", it means it avoids try/catch shenanigans. Terrible name I think. |
thanks for your contributions :) I've been rather busy lately, but I'll try and make some time to review them soon (tm). |
…ties. i.e. incrementing a column or job increments all sub-jobs, instead of writing the new value from the work type. There are potential issues and questions of design/intent. Incrementing/Decrementing a column is now bounded by the min and max sub-priority, so if one giver is at one, other won't be decremented. This is done to preserve the ranking, although it then means some won't decrement to 1. Incrementing a single pawn's worktype now increments all workgivers, but with no wrap-around checks, so some high priority tasks are blanked while the other workgivers are still active. This is all okay for me, (so many priority levels) but there could be a config option to overwrite giver priorities so that other givers may rise. Now, there needed to be new Pawn_Extensions since wrap-around checks occur differently: In addition to GetPriority(worktype), there's GetMinPriority, GetMaxPriority, AnyGiverMissingPriority. Some occurences of GetPriority(worktype) were changed if it looked right, some were not. These should be reviewed.
Oh snap here I am again. I thought I saw this pull request closed so I pushed again. Tacking on another commit, I guess! NEW STUFF - Incrementing a worktype now increments all the workgivers individually, instead of resetting them to the worktype's priority. There are a few minor concerns since wrapping is bounded by a range of priorities, and I wonder if that's not what someone would want so maybe it needs config options. There should also be review on the usage of GetPriority (more in the commit message) |
… where it was last and I see no problem keeping it
…onists work. GetVanillaPriority needs to check if workSettings have priorities, via EverWork.
Adds settings for colors for each Work Priority Level. 2-9 colors can be
defined and each level is assigned the next color. If the max priority
level is greater than the number of colors, the last two colors are
blended together for the remaining levels.