Guest Posted October 21, 2021 Share Posted October 21, 2021 Factories stop after each server restart. When will this be fixed? Players are forced to launch thousands of factories after server restart. Link to comment Share on other sites More sharing options...
Honvik Posted October 21, 2021 Share Posted October 21, 2021 Worse is finding which toon did what to what factory too! ugh its a pain. Link to comment Share on other sites More sharing options...
Verliezer Posted October 26, 2021 Share Posted October 26, 2021 It is even getting more worse. I encountered multiple transfer units in a running state but actual doing nothing. Checking a thousand transfer units and all industry after each patch will definitly make me stop playing until they fix this. Link to comment Share on other sites More sharing options...
space_man Posted October 27, 2021 Share Posted October 27, 2021 Feature. Not bug. Link to comment Share on other sites More sharing options...
Guest Posted December 11, 2021 Share Posted December 11, 2021 UP Link to comment Share on other sites More sharing options...
Warlander Posted December 11, 2021 Share Posted December 11, 2021 On 10/21/2021 at 3:39 AM, SneakySnake said: Factories stop after each server restart. When will this be fixed? Players are forced to launch thousands of factories after server restart. Its a small price to pay for starting them and not needing to touch them once a week. At least you dont have to micro manage it with charges and things like mining units. It also makes sure you have all the talents to run it vs having people with pushes start it for you or makes it harder to skirt the industry talents. Link to comment Share on other sites More sharing options...
Leniver Posted December 11, 2021 Share Posted December 11, 2021 18 months that this bug is existing. There were times when this happened less frequently. Since Demeter, which was sold to us to save server resources, it has become worse and worse. In addition to the factories now the auto-miner are doing the same. Factories can be scripted and issues ~95% detected via script, but not with auto-miner. Link to comment Share on other sites More sharing options...
Warlander Posted December 11, 2021 Share Posted December 11, 2021 (edited) Lol you have 100% automation and a jame every week or two is cramping your style? You would hate to work in an actual industry. Even when I did printing you were lucky if it didnt jame each minuite, every couple mins, or at best once an hour. Lol. Must be hard being an industrialist vs a miner in the old system sitting around and having to start some machines every 1-2 weeks and banking. At least now you only have to blow charges on your tile to get free ore. Edited December 11, 2021 by Warlander Link to comment Share on other sites More sharing options...
Guest Posted January 12, 2022 Share Posted January 12, 2022 6 months have passed, the problem has not been fixed.................. Link to comment Share on other sites More sharing options...
Maxim Kammerer Posted January 12, 2022 Share Posted January 12, 2022 On 12/11/2021 at 5:09 AM, Warlander said: You would hate to work in an actual industry. Working in an actual industry is a job you get payed for. DU is a game we pay for. GraXXoR and Moulinex 2 Link to comment Share on other sites More sharing options...
NQ-Deckard Posted January 12, 2022 Share Posted January 12, 2022 25 minutes ago, SneakySnake said: 6 months have passed, the problem has not been fixed.................. Actually, a multitude of causes and edge cases leading to this have been fixed. But clearly there may be a few more, will look into it again. Endstar 1 Link to comment Share on other sites More sharing options...
Emma Roid Posted January 12, 2022 Share Posted January 12, 2022 If I look at my factory, it seems that every production that is running and finishes during the patch period gets in an error state. Pending elements, or products that need a long runtime seem to be fine. Aleksandr and NQ-Deckard 2 Link to comment Share on other sites More sharing options...
Sawafa Posted January 12, 2022 Share Posted January 12, 2022 Quick solution to fix this problem without the need of actual stop/starting the machines: Just remove some materials from the input container of the error state machine and place it back again. This should trigger the right state for the machine and fix the problem. Repeat the same for all stopped machines. At least it worked in such manner all MILLIONS previos times, I just wasn't able to check if it still works such way. But some times machines are completely stopped, and this solution will not help in such cases Link to comment Share on other sites More sharing options...
Guest Posted January 12, 2022 Share Posted January 12, 2022 18 minutes ago, Sawafa said: Quick solution to fix this problem without the need of actual stop/starting the machines: Just remove some materials from the input container of the error state machine and place it back again. This should trigger the right state for the machine and fix the problem. Repeat the same for all stopped machines. At least it worked in such manner all MILLIONS previos times, I just wasn't able to check if it still works such way. But some times machines are completely stopped, and this solution will not help in such cases it seems to work ... Link to comment Share on other sites More sharing options...
Kveen00 Posted January 12, 2022 Share Posted January 12, 2022 I like this one, it gets you the next day and shuts everything down for another day or so while the lines re-prime. Link to comment Share on other sites More sharing options...
Kveen00 Posted January 12, 2022 Share Posted January 12, 2022 1 hour ago, NQ-Deckard said: Actually, a multitude of causes and edge cases leading to this have been fixed. But clearly there may be a few more, will look into it again. The problem appears to be how the machines update container contents (or not) during updates. There is definitely a randomness factor so I can understand how it is difficult to troubleshoot, but it appears to be directly associated with a function or trigger associated with container inventory checking (or lack thereof) under certain conditions when the server is in maintenance. We really do want this fixed, it is a HUGE issue, and there are plenty of people in the community willing to help, Please engage with the factory operators and we can work with you on troubleshooting this. It is probably a tough one to find, but you have a lot of people running thousands of machines so the player base sample set is fairly large. Kind of the point of beta right? At the end of the day we still get the 'unknown server error' stoppage and the transfer unit is not working with no error stoppage every single server maintenance. Last one was over 50 machines stopped for me, this one was over 25 'unknown server errors' plus both Inconel and screws (the entire production sets for both) being shut down by transfer unit failure. That is what I know about right now, tomorrow I will have found one or two more broken transfer units after some assembler shuts down for missing ingredients and I trace it back through the supply chain. I know some people have more, but I only have about 500 transfer units running, and it is simply not practical (and REALLY not fun) to check them all manually and the transfer unit issue is not detectable by script given the current LUA API since there is technically no error, it just does not work. SUPER frustrating. Link to comment Share on other sites More sharing options...
Kveen00 Posted January 12, 2022 Share Posted January 12, 2022 1 hour ago, Sawafa said: Quick solution to fix this problem without the need of actual stop/starting the machines: Just remove some materials from the input container of the error state machine and place it back again. This should trigger the right state for the machine and fix the problem. Repeat the same for all stopped machines. At least it worked in such manner all MILLIONS previos times, I just wasn't able to check if it still works such way. But some times machines are completely stopped, and this solution will not help in such cases I am guessing there is an event that is sent from a container to linked machines when the container inventory is updated telling the machine the container inventory has changed, but this event or trigger is lost when the server is in maintenance, so the machine code assumes one thing about container inventory but the actual inventory may be something else. That generates out 'unknown server error' condition since the machine thinks the container inventory is one thing but it is actually not what the machine thinks it is. That is also consistent with transfer units simply not triggering and refilling containers that are emptied out while the server is in maintenance. If we assume the transfer unit would normally trigger based on an event from a container inventory changing, but that event is lost during server maintenance, it would explain the observed transfer unit failures where they are just not working but also not in an error state. The machines on the other side of the container would eventually enter a 'jammed missing input ingredient' state but since that does not modify the container contents, it would not trigger the upstream transfer unit. Link to comment Share on other sites More sharing options...
Sawafa Posted January 12, 2022 Share Posted January 12, 2022 28 minutes ago, Kveen00 said: is not detectable by script given the current LUA API Actually, you CAN detect the problem. Not directly though. Just store how much of the resources should be present in container buffers and check it via LUA. If there is not enough of resource found in corresponding container you can raise an error flag. But in general, yes, this is so huge issue... I simply do not want to check all my machines... And I have thousands of them... I am tired of this... Almost every single patch since... I actually don't remember when it started... may be it was even in Alpha versions?.. Link to comment Share on other sites More sharing options...
Kveen00 Posted January 12, 2022 Share Posted January 12, 2022 1 hour ago, Sawafa said: Actually, you CAN detect the problem. Not directly though. Just store how much of the resources should be present in container buffers and check it via LUA. If there is not enough of resource found in corresponding container you can raise an error flag. But in general, yes, this is so huge issue... I simply do not want to check all my machines... And I have thousands of them... I am tired of this... Almost every single patch since... I actually don't remember when it started... may be it was even in Alpha versions?.. Sure, should have put the 'directly' in front of the API reference, and while the approach you suggest works for single item containers, it is unworkably tedious for multiple item containers, which constrains factory design to ONLY using single item containers. I agree that single item containers are typically the best approach for many things, but the fact that it creates a artificial design constraint to address a single code error seems a tad bit silly. Between todays update and the previous one my jam detection script was getting CPU overloads every time I tried to run it, but it worked fine before 2 updates ago, and again works fine after todays update, same script same factory, so who the heck knows if your detection script is even going to work after the next update which brings us back to the thing we all agree on....can we please fix this NQ? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now