Messages

Just offering some feedback.  I'm not sure on loading times ATM (I got distracted - don't ask!) but will try again and report on that.  I HAVE noticed an error popping up that seems to be related to Fluffy's Mod Manager. 

That log looks like it's related to ModCheck, a precursor to my Mod Manager. In any case, some incompatibilities with mods that directly touch mod loading are perhaps to be expected.

it's also worth checking if a HediffDefOf class exists (it does). Most (if not all) defs that are directly referenced in the code will have a 'DefOf' class associated with them. Annoyingly, it appears that SensoryMechanites is not exposed, so you'll have to go with Kiwy404's suggestion.

Alternatively, you can create your own DefOf class by applying the [DefOf] attribute; any public static members will then get populated by the game - which actually uses exactly the same DefDatabase<Def>.GetNamed( x ) method behind the scenes.

@lorebot, sure, that sounds doable.

@Everyone; Work 'Favourites' are back, and better than ever!

Please check out the latest pre-release (https://github.com/FluffierThanThou/WorkTab/releases). It should work fine with existing games, but I'd like a little bit of feedback before I release it to the masses on steam.

@Canute, JT: yeah, I missed something which means the bug still occurs. I know this, and even flagged it for myself, and then completely forgot to actually do something about it. Sorry!
@lorebot; Yep, managing chickens (or other egg-laying livestock) can be a bit of a pain. Personally, I tend to keep male chickens separate, and only farm chickens for eggs (their meat potential is horrid). When the number of chickens starts dropping, I'll let the males do their thing for a while, then seclude them again. Not ideal, but it works.

A better way of managing egg layers has been on my agenda, but I haven't put any serious effort into it.

A few (random) other comments;
re: butchering "at random"; the Manager butchers the youngest juveniles and the oldest adults first. The underlying assumption is that the goal is to have as much breeding age livestock as possible.
re: different jobs; you're right, there's no way to create multiple jobs for one species. You're also right about the reason, doing so would mean I have to track which animals and designations belong to which job, and it just gets to be horribly messy down from there. Note that 'egg management' probably also implies that I have to keep more detailed records, which may mean it's infeasible - or at least not worth the effort. E.g. when doing something like you suggest (assign x animals to area 1, overflow goes to area 2), I need to make sure that the specific animals assigned to each area are the same each time the job is done.
re: (un)fertilized eggs; huh, I'm actually not sure. I assumed all egg-layers share the 'chicken mechanics', but come to think of it that's not how it works in real life, is it?

the problem is that how many ticks count as a day is defined in a constant. That means that the compiler doesn't even consider it a variable, but just puts the actual count there. For modders, that leaves no trace of where this value is used. We can manually find most places in vanilla code (probably in the dozens, if not hundreds) and patch them, but that would obviously be a ton of work.

What makes it really problematic is a) mod support; you'd have to explicitly make patches for every single mod that uses time, and more importantly, b) other systems. Anything with a time period attached to it would need to be checked. Whether that is the time it takes to build things (defined in ticks), or the chances of things happening (defined in chance per day).

I'm not going to say it's impossible, because nothing is impossible - but it is properly hard.

Changing the flow of time in RimWorld is one of the few things that is truly hard for modders to do. I'm not aware of any mod that does it.

@bigheadzach; re: blueprints' version; I suspect I just forgot to update the forum page, but I'll have a look.
re: Mod Manager; yeah, I'm trying to use the steam api without checking if it's actually available. I'll get a fix out tonight.
@knainoa, lorebot; What lorebot says is correct, both the vanilla per-pawn medical settings (which is what you're changing in the medical tab) and Pharmacists' per-disease settings provide an upper bound to what can be used. If either of the two specifies Herbal Medicine only, no better medicine will be used.

@jpinard; an output_log, and if possible a save game would be extremely helpful.

Interesting, those were not exactly the kind of bugs I was expecting. Thanks for the feedback!

@viperwasp; I _have_ updated all my mods, both on GitHub and on steam. Are you sure you're on the latest version?

@TREH; thanks!

Regarding the updating in place, I actually had a discussion with Tynan about that, and I honestly think it was a bad suggestion to make. It goes against the expected workflow of Steam (where everything is always auto-updated by default), causes more work for modders, and splits up discussions and feedback across more places. There's also little to no benefit, as either way some part of the player population will need to find their mods again (either those staying on B19, or those sticking to 1.0). I take the view that mods should 'just work' for people who haven't taken any action to go back to a previous version, so I updated in place. People who went back to a previous version already have to select a beta branch, and are more likely to be computer literate enough to make manual installs for the mods they like.

That said, making backups should _always_ be the preferred approach. Whenever you start a new game, make a backup of your mod list, so that nothing any authors do on their steam mods can interfere with your game. You can always switch in a newer steam version manually if needed.

new BETA mod; Spatial Priorities;
https://github.com/FluffierThanThou/SpatialPriorities

=============================

Some spaces are more important than others

# Features
Adds a designator in the "Zone" menu that allows you to apply priorities to areas. Pawns follow the priorities you set in the Work tab, but will choose to do jobs in high priority areas (e.g. your medicine crops) before jobs in low priority areas (e.g. the hay fields).

In the core game, the priority of jobs is decided by (in order);
  1) Priority of the work type,
  2) Left-right order of the work type,
  3) Left-right order of the task (WorkGivers, normally invisible),
  4) Distance to the target.

This mod changes that to; 
  1) Priority of the work type (Work Tab support for workgiver level priorities is planned)
  2) Left-right order of the work type,
  3) Priority of the target area,
  4) Left-right order of the task,
  5) Distance to the target.

In other words, we evaluate all workgivers in the same worktype, with the same priority, at the same time. Within this 'batch' of potential jobs, we try to find the highest priority job.

# Notes
Adds a MapComponent;
- Can be safely added to existing games.
- Can be safely removed from existing games (although you will get an error when you load the game, the error goes away after saving without this mod active).

# Performance
Performance will vary, depending on how much you use priorities, and how often work is done in high priority areas. I'd love to hear feedback on how it runs in your game.

# Compatibility
This mod completely replaces `JobGiver_Work`, by replacing it in all `ThinkTreeDefs`. Any mods that rely on patching this class will be incompatible, but at the moment, I'm not aware of any mods that do this (I haven't looked very hard though).

@Epson; there was a bug in an earlier version of Mod Manager that made lists default to black instead of white, update, then either re-create the list, or change its colour.
@Viperwasp; thanks!

if I remember correctly, the support range is baked into the dll (it is a constant), so changing it is not trivial.

It's true that you don't need Stuffed Floors anymore if you play very close to vanilla (unless you're really in need of floors made from jade, uranium, or plasteel), but Stuffed Floors isn't at all obsolete. Even if it didn't add a ton of great aesthetic options for flooring, it was very useful for mods that add new stuff materials without accompanying floor options. This is especially clear if you're playing with the newly-updated Expanded Woodworking mod.

I agree, as a newcomer to rimworld I noticed a major difference once I added stuffed floors in b19. Previous I had extra menu tabs (e.g More floors extra floor tab) as well as floors all over the place in other menus. Adding stuffed floors consolidated this and has made it vastly easier.

I'm not sure what functionality from stuffed floors has apparently been included in Vanilla, but with my experience, the mod contributes a lot of QoL in its own right (especially with other mods).

Technically it was Architect Sense that got a lite version included in vanilla. Stuffed Floors still does the same; clean up floors categories a bit, and generate floors for stuffed materials (e.g. stone, wood, metals) in the core game and any added by mods. The game now ships with a few more pre-made versions of floors included, but still doesn't generate them for all stuffs. Stuffed Floors is definitely not obsolete.