I would expect event.item to be the same for both left and right variants, but not event.tile?

The following prints 'hazard-concrete-left' when building both left and right hazard concrete.

0.17.59 added 'Network message segment size can be configured in server-settings.json' These settings: "minimum_segment_size": 25, "minimum_segment_size_peer_count": 20, "maximum_segment_size": 100, "maximum_segment_size_peer_count": 10 But the extra settings ...

OK, thanks.

The last two logs I uploaded use non-asynchronous or blocking saving. Is the problem likely fixed for blocking saving too?

I've been playing around with this issue and may have found a way to reproduce it, or at least a similar issue. If I run the freeplay scenario with this server-settings.json: { "name": "", "description": "", "tags": [ ], "max_players": 0, &...

Are you, by any chance, using an HTTP proxy? As in, is it possible that Factorio connects to the matching server through a proxy? One with NTLM authentication, even? I also host a web server on the same machine that uses nginx as a reverse proxy. But as far as I'm aware the Factorio processes shoul...

Very interesting. I also see that for you it happened four seconds after starting the server – was that just luck or can you somehow reproduce it? I think that was just bad luck, I have not been able to reliably reproduce it in test conditions. But it happens about twice per day for my real servers...

Sorry I don't know what EINTR is.

In my experience when factorio receives a signal it logs it, for example something like this: So I don't think a signal was received at the same time.

I have a bunch more log files where stdin has failed which I have attached. I would like to draw attention to factorio-current (1).log which contains this 4.103 Info ChildProcessAgent.cpp:60: Child 11684 exited with return value 0 4.332 code:35, 23; error:1408F10B:SSL routines:ssl3_get_record:wrong ...

I host multiple servers and for these servers I communicate with factorio using stdin / stdout, for example to link game chat with discord chat. Since 0.17.53 I keep getting errors with broken pipes when trying to send messages to factorio using stdin. The pipe seems to break typically 6 - 12 hours ...

Steps to reproduce: 1. spawn worm: /c local p = game.player local pos = p.position pos.y =-10 p.surface.create_entity{name='small-worm-turret', position = pos, force = 'enemy'} 2. Change player force biological ammo modifier: /c game.forces.player.set_ammo_damage_modifier('biological', 0.5) 3. Obser...

Steps to reproduce: 1. Create scenario with following code in control.lua script.on_event( defines.events.on_player_created, function(event) local player = game.get_player(event.player_index) local button = player.gui.center.add {type = 'button'} button.style.disabled_font_color = {0, 0, 0} end ) 2....

Thank you

Currently it doesn't appear to be possible to get or set the server's name, description or tags with /config get or /config set. It is possible to edit those values with the gui that pops up with /config. However, for my use case, I'd like to be able to edit the values from the server console, so I ...

Rseding91 wrote: ↑Sat Mar 09, 2019 9:49 pm "logo.png" is not a valid file path so no I expect it to show nothing.

Interesting. What would the correct file path be then?

I must say I'm a little confused as the exact same code in 0.16.51 gives me this.

I tested again in 0.17.9 and it still crashes for me, same error.

Even if it doesn't crash for you, wouldn't you expect it to show the sprite?

It would be nice if rendering.draw_text supported rich text.

Using a SpritePath with the path 'file/' causes a crash to desktop. I've tested the same code and it works in 0.16.51. Code: script.on_event( defines.events.on_player_created, function(event) local player = game.players[event.player_index] player.gui.center.add {type = 'sprite', sprite = 'file/logo....

OK. It struck me as odd that players with spaces can be banned via /admin but not via game.ban_player.

But as long as this is known, I'm happy to keep waiting patiently.