Karaaz wrote: That would be ideal, but only if robots were smart enough not to run out in normal operation. Then it would be an issue only in special situations, such as a power outage or a destroyed roboport for example.

Another reason to do the fuel check I suggested.

immibis wrote: That's why they changed it so robots will just move slower, instead of exploding.

In my opinion, if a robot runs out of fuel, it should simply "fall," i.e. become the innert, "grabbable" version of itself on whatever tile it ran out of fuel.

We should make a definition for what is a combat drop, such as "is a request for weapons" and "has aliens in adjacent chunks" or "is near the player" -- something like that. Given the conditions, the robots know to coordinate such that they make drops simultaneously, ra...

A simple solution is available that should solve the issue of robots not following the roboport network's shape, robots getting lost in the wilderness, robots running out of fuel while pathing to a distant destination, and most annoyingly, robots giving up when they're only a few feet from their des...

This could be easily fixed. Whenever a robot first calculates its path to its destination, it checks whether it has enough energy to reach that destination. If it does not, it can choose a free refueling port nearest the line of destination, fartherest out from the current position. The robots will ...

We also experience this, it seems, any time a player dies in multiplayer (version .11.8). We currently have a "no dieing" rule. I will edit this to add a log next time it happens.

We should close this. It was probably related to the other desync bugs. I'll post a new bug when we hit problems in .11.5. Thanks!

Hello, Factorio v0.11.4, 64-bit linux. Proprietary AMD(ATI) graphics driver. Singleplayer open mode. (Edit: I've looked a bit closer at the error messages. Even though it didn't happen while directly manipulating a splitter, both return the line 37 seg fault, so it seems very likely that it's the sa...

I experienced a CTD in the conditions noted here, but also when picking up a corner belt while holding a belt, so this issue may not be just related to the splitter.

The new running animation looks better than the old one, not really realistic, but better ;) Agreed. It's getting there. But I noticed that since the camera's viewpoint is fixed on some moving part of the (left-right bobbing) animation, when running the whole scene on the screen vibrates and become...

I'll hopefully get more information to you tonight. Wasn't able to play over the weekend.

Could it be that the failed base placement causes a desync, like the aliens may move in different directions for each user after failing to place a building?

We've experienced errors like this. One temporary fix has been to change usernames. Yes, this means you will lose your inventory.

Greetings, On a two-player map over open internet, both running linux 64-bit version .11.3, we are experiencing a crash-to-desktop error. An error message can be seen in the terminal output saying "No room for enemy expansion for building." I didn't get the message quite right, and I will ...

Hmm, OK, thanks, I believe I understand. In addition to the global desync checks, it sounds like some things are checked for desync with greater resolution in the player's local area. Is that correct? So it seems at least a post-fix for this is to repair all of the affected items, but that during co...

Still ran into some desyncs. One desync I was able to reproduce was when I replaced a damaged belt. Repairing the belt first fixed the error, and we were able to continue playing. I think I remember seeing another post about damaged items causing desyncs. Hard to track and reproduce errors for the m...

Thank you, yes. I should have mentioned we've been operating at >150ms latency. We are attempting the game at 265ms, which is slightly greater than our maximum observed ping latency. I should have some results this evening.

We have encountered desyncs when transferring items, especially from chests indirectly, such as ctrl-clicking the chest to transfer all items, or even ctrl-clicking an item type to transfer. Perhaps it is just the volume of items being transferred with this type of usage? Often the only solution to ...

Previous post. and a few hours' research, fixed this on Fedora 19.