Jump to content

Factories stop after server restart


Mafioznik
 Share

Recommended Posts

  • Mafioznik changed the title to Factories stop after server restart
  • 1 month later...
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

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

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 by Warlander
Link to comment
Share on other sites

  • 1 month later...

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

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

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

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

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

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...