Version 1.1.71

[FactorioBot]

Minor Features

• Added preferred audio device output setting.
• Added the current binary architecture to the main menu version string.

Optimizations

• Added native support for M1 Macs.

Bugfixes

• Fixed a crash when canceling deconstruction of a pipe to ground while the GUI was open. (103728)
• Fixed entity ghosts would draw wires even if prototype of inner entity disabled it. (103765)
• Fixed incorrect panning of CyclicSound (for example, flamethrower turret's stream sound). (103865)
• Fixed that ScriptRendering requested string localisation during on_init when it was not available. (103745)
• Fixed Generator tooltip ignoring fluid emissions multiplier. (103847)
• Fixed that teleporting cars between surfaces would create the build effect smoke. (103972)
• Fixed a crash related to undoing mining of another forces entities after the other force had been deleted. (103966)
• Fixed it was possible to acquire forbidden items in the Transport belt madness levels. (103331)
• Fixed that linked-belt was missing from the collision mask defaults. (103849)
• Removed 'Fuel emissions' label from Burner info panel. (103942)
• Fixed that expansion parties could destroy spidertrons while building new bases. (103872)

Modding

• Added Alt reverse selection support for selection tools. (102470)

Scripting

• Added LuaGuiElement::close_dropdown().

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

[Shuisman]

• Added native support for M1 Macs.

Wow! That’s fantastic! Does it use metal?

[Xorimuth]

• Added native support for M1 Macs.

Wow! That’s fantastic! Does it use metal?

No, still on openGL.

[jodokus31]

• Added native support for M1 Macs.

Wow! That’s fantastic! Does it use metal?

No, still on openGL.

Still nice. Need to try it, how it performs graphically

[Xorimuth]

• Added native support for M1 Macs.

Wow! That’s fantastic! Does it use metal?

No, still on openGL.

Still nice. Need to try it, how it performs graphically

Not sure about relative graphics performance but I’m getting ~20% UPS improvements.

[jodokus31]

• Added native support for M1 Macs.

Wow! That’s fantastic! Does it use metal?

No, still on openGL.

Still nice. Need to try it, how it performs graphically

Not sure about relative graphics performance but I’m getting ~20% UPS improvements.

I never used my M1 for factorio so far, because it's rather dedicated to something else. But it seems to get a valid option now and it might beat my 5600X. At least, when graphics on OpenGL are fine enough. OpenGL on Linux is a bit stuttery sometimes.

[ptx0]

OpenGL on Linux is a bit stuttery sometimes.

that's actually an issue with Xorg, which goes away in Wayland (to be replaced with other issues, especially in hybrid graphics systems, e.g. laptops)

[ptx0]

Optimizations

• Added native support for M1 Macs.

weird, almost like everyone in the thread asking for it and saying how easy it would be, was correct

[Xorimuth]

Optimizations

• Added native support for M1 Macs.

weird, almost like everyone in the thread asking for it and saying how easy it would be, was correct

How do you know it was easy?

[sedroc]

Optimizations

• Added native support for M1 Macs.

Thank you. Factorio now runs much faster. However, I seems like that the Steam beta version for 1.1.71 is not a universal binary and only runs in x86_64 mode, while the full download from the website is a universal binary and runs as arm64. Anyone else having this issue?

[Nidan]

Optimizations

• Added native support for M1 Macs.

weird, almost like everyone in the thread asking for it and saying how easy it would be, was correct

How do you know it was easy?

If you take the switch support as a given, I'm inclined to agree with "easy". Without it however... FFF370 puts it at at least three month, after that the article becomes unclear on how much time was for general ARM support (e.g. multiplayer, the paragraph about undefined behavior) instead of switch specific things (e.g. performance, UI, controller support). The next time point mentioned is six month as "fully playable". The truth is probably somewhere in-between. The FFF goes on to list things that were done in the following year, but those sound switch or Nintendo related to me, rather than necessities for ARM support.
So, was it easy? It certainly was more effort than some people made it sound.

Other projects can get away with not caring about all the little details that end up breaking factorio's determinism. E.g. at work I was tasked with porting our product to ARM. I ended up having to fix two or three compile errors; including time spent on the build system it took about three or four days.

[jodokus31]

OpenGL on Linux is a bit stuttery sometimes.

that's actually an issue with Xorg, which goes away in Wayland (to be replaced with other issues, especially in hybrid graphics systems, e.g. laptops)

I tested with Gnome on Wayland, and it's not really better there. Not sure, whats the problem, but it might be that, NVidia is not very well supported for Wayland. I guess, I just wait...I'm ok, how it works on Xorg currently

[ptx0]

How do you know it was easy?

because they said they wouldn't do it, because it was too much work.

ergo, they did it because it wasn't too much work.

ipso facto, it is easy.

[ptx0]

I tested with Gnome on Wayland, and it's not really better there. Not sure, whats the problem, but it might be that, NVidia is not very well supported for Wayland. I guess, I just wait...I'm ok, how it works on Xorg currently

search for my wayland troubleshooting thread and try some of the ideas there if you like, but from what i know, Nvidia uses EGLstreams for composition stream management etc, and Gnome relies on the GBM API with zero support for EGLstreams.

there this commit (https://gitlab.gnome.org/GNOME/mutter/- ... uests/2067) that seems like it was merged 11 months ago and could have fixed some issues.

but honestly from my birds eye view it looks like the APIs have subtly different behaviour and that it might not work until nvidia's GBM support itself matures: https://download.nvidia.com/XFree86/Lin ... E/gbm.html

currently, GBM on NVIDIA is implemented by making it into a wrapper that executes EGL calls. can't imagine that works out so well.

on the other hand, i've got a hybrid graphics Linux laptop with AMDGPU and Nvidia instead of Intel. I had really poor luck on an XPG laptop that used Intel+NVIDIA. With AMDGPU+NVIDIA, I can pump all the stuff through the AMD and get low latency, tear-free graphics output.

for the Intel+NVIDIA laptop, there was just no way I could find to get better performance because the laptop didn't have a mux chip to allow switching the LCD directly to the NVIDIA. so all the GPU stuff had to be done on the NVIDIA and then framebuffer copy over to the Intel output, which introduced a LOT of issues. you can determine this is your issue by trying to run it on external graphics display for those laptops where the HDMI port is wired directly to the discrete GPU.

[Xorimuth]

How do you know it was easy?

because they said they wouldn't do it, because it was too much work.

ergo, they did it because it wasn't too much work.

ipso facto, it is easy.

I think you’re treating wube as a single person when in fact it is a group of individuals. Some devs (rseding and posila iirc) stated at one point that it wasn’t currently planned because no one on the dev team was interested in putting in the work to make it happen. Not because it was “too much work”, just because it was “a non-zero amount of work” and no one at the time used macOS so no one wanted to do that work.

All that’s changed is that one person decided that it was worth it to them to put in the work to make it happen. And the M1 work may well have benefited from some of the almost-two-years worth of work put in by Twinsen for the Nintendo switch.

[ptx0]

And the M1 work may well have benefited from some of the almost-two-years worth of work put in by Twinsen for the Nintendo switch.

you mean, it made it easier to do? it didn't take 2 years for the M1, like it did for the Switch.

i think you believe i'm insulting Wube by saying it was easy. that's not what I'm doing.

the employees who didn't want to do it, didn't want to spend the time on it. obviously, someone redid the math and found out it's a lot easier to do, without draining too much time/resources.

everything they do has an opportunity cost.

[peternlewis]

Optimizations

• Added native support for M1 Macs.

Thanks so much for doing this!

[urmet]

hope for actually seeing an arm64 headless linux build one day is increasing

[jodokus31]

I tested with Gnome on Wayland, and it's not really better there. Not sure, whats the problem, but it might be that, NVidia is not very well supported for Wayland. I guess, I just wait...I'm ok, how it works on Xorg currently

search for my wayland troubleshooting thread and try some of the ideas there if you like, but from what i know, Nvidia uses EGLstreams for composition stream management etc, and Gnome relies on the GBM API with zero support for EGLstreams.

there this commit (https://gitlab.gnome.org/GNOME/mutter/- ... uests/2067) that seems like it was merged 11 months ago and could have fixed some issues.

but honestly from my birds eye view it looks like the APIs have subtly different behaviour and that it might not work until nvidia's GBM support itself matures: https://download.nvidia.com/XFree86/Lin ... E/gbm.html

currently, GBM on NVIDIA is implemented by making it into a wrapper that executes EGL calls. can't imagine that works out so well.

on the other hand, i've got a hybrid graphics Linux laptop with AMDGPU and Nvidia instead of Intel. I had really poor luck on an XPG laptop that used Intel+NVIDIA. With AMDGPU+NVIDIA, I can pump all the stuff through the AMD and get low latency, tear-free graphics output.

for the Intel+NVIDIA laptop, there was just no way I could find to get better performance because the laptop didn't have a mux chip to allow switching the LCD directly to the NVIDIA. so all the GPU stuff had to be done on the NVIDIA and then framebuffer copy over to the Intel output, which introduced a LOT of issues. you can determine this is your issue by trying to run it on external graphics display for those laptops where the HDMI port is wired directly to the discrete GPU.

Thanks for the infos
I rechecked, with Gnome on Wayland, which is installed in parallel. It doesn't work any better there. Last time, I also had this flipping around, that the loading bar looked like loading backwards. But its gotten a lot better than last time. But still sometimes it is stuttery and not really fluid. The "use-flip-presentation-model" didn't do anything for me. Since, I'm not so familar with Gnome, I also rather wait, until they add Wayland support to XFCE4, but I was just curious, if wayland is such an eyeopener as hoped.
This is the thread you are referring I assume:
viewtopic.php?f=182&t=102650
According to posila, there is still some work to do regarding SDL_VIDEODRIVER=wayland
I cannot claim, that I have too much knowledge of all this stuff, though

[ptx0]

I rechecked, with Gnome on Wayland, which is installed in parallel. It doesn't work any better there. Last time, I also had this flipping around, that the loading bar looked like loading backwards. But its gotten a lot better than last time.

you should try a KDE Plasma environment, though i can understand not wanting to put all that on a Gnome system.