Rurumeto Posted August 1, 2019 Share Posted August 1, 2019 I'm assuming this is either me being dumb or a bug in the new release but, when a dupe has max priority on cooking, there are materials in my cooking device (which is most definitely not producing disgusting mush paste,) the cooking device (once again certainly NOT a microbe musher,) is on priority 9, and the dupe is standing around idling. Why do they just sort of... stand there... and starve... when I re-set the priorities on the musher and re-do the cooking orders they'll go and cook but otherwise they wander around staring at this task begging to be fulfilled and say "yup, nothing for me to do." Why are you like this my dupes... why..? Link to comment Share on other sites More sharing options...
FriedrichPierce Posted August 1, 2019 Share Posted August 1, 2019 It's not just your dupes, bro! Mine too I think they should add "feed themselves" as a priority tooOr something like "meal time" Link to comment Share on other sites More sharing options...
Gunhaver Posted August 1, 2019 Share Posted August 1, 2019 You have to undo the cook queue if it's on infinite and set it for infinite again. This also happens with other machines that can be set for infinate. This is likely a bug. Maybe it's like when the dupes will do production orders untill 1 is left and just let it sit. Link to comment Share on other sites More sharing options...
KittenIsAGeek Posted August 1, 2019 Share Posted August 1, 2019 Yeah, I've noticed that as well. I think it has to do with fractional amounts. When its very close, it'll round the display up to the next number. So you'll see, for example, 100kg of copper ore in the rock crusher. However, its actually below that value enough that the rock crusher won't run -- but its close enough that the rock crusher won't initiate a delivery command. I suspect its an unintended side-effect of the efforts to fix the "dupe repeatedly delivers micrograms" bug. Link to comment Share on other sites More sharing options...
Mutineer Posted August 1, 2019 Share Posted August 1, 2019 Assuming that you have access to raw materials. You might be missing some component before you look for bugs. Link to comment Share on other sites More sharing options...
Gunhaver Posted August 1, 2019 Share Posted August 1, 2019 No, it's happened to me various times. Plenty of said ingredient(s) (even inside the machine). I also made sure other dupes were set to high priority deliver. The cook will is stand there even when set to top priority cooking with all other errands disabled. As soon as I uncheck continuous and reselect it. Bam! It starts working again. It seems to be triggered by an unknown process and only affects one queued item at a time (until lt happens with another recipe). I've had my cook keep making BBQ and refuse to make grissle berry untill I've disabledd and reenabled continuous. With kilms it will often leave one In Queue. Unclick it and reclick 1 and it will work. Occasionally the egg cracker will do this too. It won't register an egg you clearly have untill you reset the order. Link to comment Share on other sites More sharing options...
Aelfled Posted August 1, 2019 Share Posted August 1, 2019 Latest patch says they removed some causes of this happening Link to comment Share on other sites More sharing options...
Siromatik Posted August 1, 2019 Share Posted August 1, 2019 2 hours ago, Ipsquiggle said: Fix for several cases where fabricator buildings would stop being worked even when there were open orders Weirdly this one is coming back regularly, I hope to never see it again ! Link to comment Share on other sites More sharing options...
Gurgel Posted August 2, 2019 Share Posted August 2, 2019 9 hours ago, KittenIsAGeek said: Yeah, I've noticed that as well. I think it has to do with fractional amounts. When its very close, it'll round the display up to the next number. So you'll see, for example, 100kg of copper ore in the rock crusher. However, its actually below that value enough that the rock crusher won't run -- but its close enough that the rock crusher won't initiate a delivery command. I suspect its an unintended side-effect of the efforts to fix the "dupe repeatedly delivers micrograms" bug. This happens when the checks whether a job can be fulfilled and how much still needs to be fetched are calculated differently. Then you can have a case where the first one still says "not enough" and the second one says "amount to fetch: zero". This is pretty hard to fix, but easy to test for by debug code. 3 hours ago, Aelfled said: Latest patch says they removed some causes of this happening They probably have to fix this by adding a condition that checks whether the amount to fetched is zero, but there still needs something to be fetched. One possible fix is to have one more fetching of a small amount and then declare the materials to be complete. Or to put a generous "fuzzyness" to the checker, where, say, 1/10'000 missing counts as "enough there". Link to comment Share on other sites More sharing options...
Nebbie Posted August 2, 2019 Share Posted August 2, 2019 1 hour ago, Gurgel said: This happens when the checks whether a job can be fulfilled and how much still needs to be fetched are calculated differently. Then you can have a case where the first one still says "not enough" and the second one says "amount to fetch: zero". This is pretty hard to fix, but easy to test for by debug code. They probably have to fix this by adding a condition that checks whether the amount to fetched is zero, but there still needs something to be fetched. One possible fix is to have one more fetching of a small amount and then declare the materials to be complete. Or to put a generous "fuzzyness" to the checker, where, say, 1/10'000 missing counts as "enough there". Lambdas are indeed an approach. The trouble with them is that in cases like this, they can lead to exploits if "enough here" means "a little extra left in a storage compactor", cause if you can reliably replicate this in some kind of production loop (of which there are many in ONI) that has 100% mass efficiency in a cycle, then you can create a machine that spits out whatever there's "enough here" of. Ultimately they need to kill this at the source, and fix the calculation differences. I've seen some pretty weird stuff even with building tiles, where suddenly there's only 799.95kg of mafic rock being delivered, and just yesterday I saw a storage compactor holding something like 2.15555597 mealwood seeds (I'm not sure if you can plant .15555597 of a seed, but I suspect you can). I'm not sure how either of these happened, as they're well outside the scale of a reasonable lambda on a floating point calculation, so there would have to be some serious compounding of errors going on. ONI probably needs more safeguards on mass calculations. Link to comment Share on other sites More sharing options...
Gurgel Posted August 2, 2019 Share Posted August 2, 2019 1 hour ago, Nebbie said: Ultimately they need to kill this at the source, and fix the calculation differences. That would mean upgrading to double calculations or fixed-point. They are not going to do that. Also your concerns about some fuzziness here being exploitable is badly misplaced. It it is small enough, it does not matter and that, incidentally, is the standard way to fix this. Only fools compare float numbers for equality. Link to comment Share on other sites More sharing options...
Aelfled Posted August 2, 2019 Share Posted August 2, 2019 The ship has probably sailed on fixed point but it should really be what all mass is calculated in Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.
Please be aware that the content of this thread may be outdated and no longer applicable.