NPCs crafting in faction camp can't finish mission & provided crafted items until all crafting missions done

[AmarinReyny]

Describe the bug

So, I have a faction camp set up, and I had some NPCs craft some things for me. One of the crafting missions was going to be done in a few hours, while the other was going to take over two days to complete. So, I go out to scavenge for more materials, which takes several hours, and when I return, I find that the first crafting mission is done. Great, right? Except, I can't actually get them to return with the crafted goods. The option is grayed out, and pressing enter on it does nothing. Also, not sure if this is related, but the menu where I select missions and stuff has "finish crafting" listed twice, and both times it's listed has the same problem.

Steps To Reproduce

1. Create a faction camp with multiple NPCs
2. Send two NPCs on crafting missions with disparate times needed for completion
3. Wait for one of the crafting missions to become done
4. Try to select "(Finish) Crafting"
5. Observe that you can't

Expected behavior

I expect NPCs who are done with their crafting missions to be able to come back with their produced goods when I select the finish crafting option.

Screenshots

Versions and configuration

OS: Windows
OS Version: MINGW/CYGWIN/MSYS2 on unknown Windows version (actually windows 8.1 Pro, but the game report doesn't seem to be able to figure that out)
Game Version: 95019f2 [64-bit]
Graphics Version: Tiles
Game Language: System language []
Mods loaded: [
Dark Days Ahead [dda],
Disable NPC Needs [no_npc_food],
Bionic Professions [package_bionic_professions],
Aftershock [aftershock],
Blaze Industries [blazeindustries],
C.R.I.T Expansion Mod [crt_expansion],
Magiclysm [magiclysm],
XEAS [XEAS],
Gun Cotton [guncotton],
DinoMod [DinoMod],
Youkai Enemies [Youkai_Disco],
Mining Mod [Mining_Mod],
Mole Mutation [dig_a_tunna],
More Survivor Stuff [more_survivor_stuff],
Mythical Martial Arts [MMA],
More City Locations [cityside],
No Rail Stations [No_Rail_Stations],
Compatible Nimian Manufacture Guns [NM_wpns],
No Fungal Monsters [No_Fungi],
Fuji's Military Profession Pack [fuji_mpp],
Magiclysm No Class Limit [magiclysm_no_class_limit],
Mutation Changes [Mutation_Changes],
Portable Autodoc [portable_autodoc],
SpeedyDex [speedydex],
Stats Through Kills [stats_through_kills],
Stats Through Skills [StatsThroughSkills],
Useful Helicopters [useful_helicopters],
Arcana and Magic Items [Arcana],
return_the_nut [return_the_nut],
Hydroponics [hydroponics],
Cooler Versatility [coolervers],
Chris K's Knives [ChrisKsKnives],
Custom Spells [Custom_Spells],
Reproduction mod [perverts],
Custom Bionics [custom_bionics],
Magiclysm Runes in Arcana Recipes [Custom_ArcanaRune],
Deconstruction Plus [Deconstruction_plus],
Core Data Changes [core_data_changes],
Arcadia Mapgen [custom_arcadia_mapgen]
]

Additional context

No response

[PatrikLundell]

I think may be need for some more info:

• What were the crafting jobs, and from where (i.e. from the base, or, when not, from which expansion) were they ordered?

Edit:
Another question:
Do you have more than one instance of any expansions you're orders were given from?

[AmarinReyny]

I think may be need for some more info:

• What were the crafting jobs, and from where (i.e. from the base, or, when not, from which expansion) were they ordered?

Edit: Another question: Do you have more than one instance of any expansions you're orders were given from?

Both were from the base. One was to craft wooden panels from planks and nails (this was the one that was "done" first), and the other was to craft heavy wooden beams.

I don't have more than one instance of any expansion except for farms (specifically the second type that was added recently).

[PatrikLundell]

This is weird, as I'm never able to issue two crafting jobs from the same location (base/expansion). Once one crafting job has been issued, the menu doesn't allow me to select another (I've just tried to reproduce your situation, and after sending off the first companion the crafting selections don't appear when I access the board).

I'm using the standard set of mods, so it might have something to do with your rather extensive set.

The reason for the question about multiple identical expansions is that the wonky code might have trouble figuring out which expansion instance a job is issued from, but that's obviously not the issue here, and the newer farm expansion is safe from that perspective anyway since it doesn't provide any crafting for the code to screw up.

[AmarinReyny]

This is weird, as I'm never able to issue two crafting jobs from the same location (base/expansion). Once one crafting job has been issued, the menu doesn't allow me to select another (I've just tried to reproduce your situation, and after sending off the first companion the crafting selections don't appear when I access the board).

I'm using the standard set of mods, so it might have something to do with your rather extensive set.

The reason for the question about multiple identical expansions is that the wonky code might have trouble figuring out which expansion instance a job is issued from, but that's obviously not the issue here, and the newer farm expansion is safe from that perspective anyway since it doesn't provide any crafting for the code to screw up.

Huh. Weird. Well, I know that when I was using the 0.F Stable version, and the 0.E stable before that, it let me issue multiple crafting jobs - and even multiple crafting jobs of the same type - from the base. Expansions have never let me issue multiple crafting jobs at the same time, though.

I'm not sure if the mods would have anything to do with it, though, since, to my knowledge, none of the mods I use have any effect on basecamp missions. Also, IIRC, a lot of the code for the basecamp missions are in C++ rather than JSON, so I don't think mods would be capable of messing with that anyway.

[PatrikLundell]

Hm, yes, you're correct. I was able to send off two companions on tinder making in 0.E2 stable (although their return looked a bit weird: one of them might have been morphed into a canteen cooking job, somehow, possibly because you could issue a tinder making job from the canteen as well). Also, the second order did behave strangely in that instead of being finished after entering the batch size, it returned as if it wanted to issue yet another command.

Retrying (still on 0.E2 stable), I send off one companions to make pointy sticks and another to make tinder, with one job being 1 hour 20 minutes and the other 1 hour 40 minutes and fast forwarding 1 hour 30 minutes I get your situation, i.e. a "finish crafting" with one line saying "[DONE]" and another "[10 minutes left]", but with that "order" not being available for execution. Again, issuing the second order behaved in an odd way.

My 0.F attempt used an experimental version a number of days old, so it may be things have been changed since your 0.F stable version (there are several: I don't know what the latest number is).

Edit:
It seems the issue here is/was that you get a combined "[B] (Finish) Crafting" entry for all crafting jobs issued by the base, rather than one for each individual crafting job, and that combined job isn't finished until the last component job is finished.

[AmarinReyny]

Hm, yes, you're correct. I was able to send off two companions on tinder making in 0.E2 stable (although their return looked a bit weird: one of them might have been morphed into a canteen cooking job, somehow, possibly because you could issue a tinder making job from the canteen as well). Also, the second order did behave strangely in that instead of being finished after entering the batch size, it returned as if it wanted to issue yet another command.

Retrying (still on 0.E2 stable), I send off one companions to make pointy sticks and another to make tinder, with one job being 1 hour 20 minutes and the other 1 hour 40 minutes and fast forwarding 1 hour 30 minutes I get your situation, i.e. a "finish crafting" with one line saying "[DONE]" and another "[10 minutes left]", but with that "order" not being available for execution. Again, issuing the second order behaved in an odd way.

My 0.F attempt used an experimental version a number of days old, so it may be things have been changed since your 0.F stable version (there are several: I don't know what the latest number is).

Edit: It seems the issue here is/was that you get a combined "[B] (Finish) Crafting" entry for all crafting jobs issued by the base, rather than one for each individual crafting job, and that combined job isn't finished until the last component job is finished.

Huh... Interesting. Maybe, with the problem identified, a fix won't be too hard to make?

Granted, I have absolutely no idea. I don't know how to write C++ code.

In any case, until then, I can just use the Debug Hammerspace mutation to work around this problem.

[PatrikLundell]

Unfortunately, the current code is a weird mess that's in dire need of being rewritten completely (I've looked at it an have even made a crude work around for one of the issues in it). My guess is that whoever wrote it had a background in some scripting language and no experience with compiled code.

[AmarinReyny]

Unfortunately, the current code is a weird mess that's in dire need of being rewritten completely (I've looked at it an have even made a crude work around for one of the issues in it). My guess is that whoever wrote it had a background in some scripting language and no experience with compiled code.

Ah, damn... Well, I think I vaguely remember that someone was suggesting a complete overhaul of the code faction camps use anyway, as part of JSONizing it.

[PatrikLundell]

I'm not sure how much more of the base camp you can define in JSON: after all, you need code to actually make anything defined as a JSON structure do anything.

One thing that's been discussed as a long term goal is to remove crafting from the base camp JSON structure and have the base camps provide the same crafting capabilities that the PC has access to.

Another desired ability, that ties into the previous one, is to let player constructed (directly or via orders to companions to construct according to blueprints) furniture be recognized on equal footing with camp construction constructed ones.

Currently the JSON construction recipes explicitly has to tell the base/expansion that it has access to the functionality provided by "furniture" such as e.g. a stove, but it would be desirable if the code could figure that out by itself by "scanning" what's been constructed, ideally without regard for whether it's been constructed via a construction order, by the PC, or by a companion directly ordered by the PC. A problem there is that this scanning mustn't happen so frequently that it becomes a performance issue, but still would pick up the newly constructed kiln to allow the base camp to provide its capability to recipes "immediately" after construction.

A problem with using player crafting by companions is when the product is a liquid, as player crafting results in the player being asked which containers they'd want to use to store the results. That gets awkward for companions, and might require you to allocate the containers together with the ingredients, but that would probably require changes to the recipe code (there are some weird cases currently, such as sourdough, where the container is part of the recipe, but ideally a recipe should be able to use any suitable container, not either a single one or morphing whatever was used to the one defined with the result).

Yet another set of base functionalities, which probably will require code, would be to set up work flows for collecting eggs, milking animals, and processing the results (and, for that matter clean out animal droppings and potentially process those into something useful). Such functionality might use zones to allow them to be used without the need for a base (vehicle dismantling zones work fine on their own, for instance), but I wouldn't be shocked of a workflow layer on top of that would require a base.

A further development would be to support the third dimension, i.e. the construction of additional stories upwards and basements/mines downwards, with both the base and zones recognizing the third dimension: Sorting out loot would be capable of sorting things into the cool basement, for instance (zone functionality) and construction finding and using tools and building materials even if it's not on the same level.

[LeahLuong]

Came across this myself recently in 0.F-3:

Screenshots show both duplicated selections highlighted to demonstrate they are, in fact, duplicates & that 1 of the crafts is completed while neither selection is selectable. 1 follower is done crafting tinder while the other needs more time to finish heavy wooden beams.

[LeahLuong]

Sending a follower to hunt large game also produces duplicated entries on the bulletin board.

[LeahLuong]

Found a counterexample:

Strangely, I was able to recall both workers & their jobs were fully complete. This is what the bulletin looked like after:

Note how trapping is duplicated as well as hunting.

I'm unsure of the condition for being able to successfully recall these duplicated crafting tasks but it does seem exploitable. After the screenshots above, I sent 1 worker to craft wooden panels (over 1 day to complete) & another to craft tinder (a matter of a couple of hours). After the tinder job completed but before the wooden panels did, I was able to recall both workers for all of the tinder & wooden panels. As above, the options were yellow & the longer job was saying it still had time to go. I've also had it where a tinder crafter was stuck waiting for the other job to complete.

[PatrikLundell]

#55591 ought to do away with these issues, although it doesn't address them as such. The rework should cause the code to correctly identify mission and thus display them only once. I'm fairly sure the duplication of the trapping and hunting missions is caused by them being made available both from the canteen and the base, and believe they'd get triplicated if you had had a second canteen. The work on #55591 saw duplicated missions become single ones when a legacy (i.e. pre PR) save was loaded into the PR version. Trapping and hunting differs from "normal" crafting in that the legacy code doesn't flag them with where they're issued, so checks will find a match for each tab where it's available (the PR marks everything with their origins).

I don't know why a finished mission would be blocked by an ongoing one, but a guess is that the code somehow would find the longer mission and use that to set the availability flag (greying out, which also makes the UI not allow it to be selected). I think I saw (and, if so, fixed) a bug where a loop over missions set the availability flag directly for each iteration, rather than set it to available if any of the missions was available, but I'm not sure (there were a lot of things to do in that PR).