Darkmatterx76 wrote: Tue Jun 23, 2026 8:33 pm
The other is that I truly beg for grass/ground to slowly heal after you destroy a biter base. The ugly scar staying forever sucks.
I know a mod isn't the same as something being in the base game, but I've been using this mod for years and it's excellent:
Omnifarious wrote: Wed Jun 24, 2026 12:13 am
I have a Pop_OS! 22.04 system, and it still has glibc 2.35. So Space Age won't launch on my system.
I was able to go through some contortions involving podman and a debian:12 container and get it to work, sort of. The graphics are really slow though because the nvidia drivers won't work properly inside the container.
Darkmatterx76 wrote: Tue Jun 23, 2026 8:33 pm
The other is that I truly beg for grass/ground to slowly heal after you destroy a biter base. The ugly scar staying forever sucks.
I know a mod isn't the same as something being in the base game, but I've been using this mod for years and it's excellent:
Omnifarious wrote: Wed Jun 24, 2026 12:13 am
I have a Pop_OS! 22.04 system, and it still has glibc 2.35. So Space Age won't launch on my system.
I was able to go through some contortions involving podman and a debian:12 container and get it to work, sort of. The graphics are really slow though because the nvidia drivers won't work properly inside the container.
Yet another example of Wayland making everything worse (many such cases)
Yeah this makes me think of why exactly factorio is even interacting with wayland, since wayland can handle factorio just fine without any issues. Like there should be no reason to interact with wayland from a game perspective, since wayland exists purely to make sure random programs such as videogames are not fucking with the graphics in any unintended user hostile way.
Steams Gamescope exists for a reason afterall.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 4:40 am
by sarge945
Darkmatterx76 wrote: Wed Jun 24, 2026 4:00 am
Thanks, I'll keep it in my back pocket. Want my achievements first.
Yeah, Wube should either include a bunch of mods in the base game, or at the very least, "whitelist" a bunch of mods so that people can still get achievements.
If they are going to refuse to add some significant qol features (like even distribution, bottleneck lite, etc) they should at least let people get achievements for using them.
GregoriusT wrote: Wed Jun 24, 2026 4:31 am
Yeah this makes me think of why exactly factorio is even interacting with wayland, since wayland can handle factorio just fine without any issues. Like there should be no reason to interact with wayland from a game perspective, since wayland exists purely to make sure random programs such as videogames are not fucking with the graphics in any unintended user hostile way.
Steams Gamescope exists for a reason afterall.
My issue is more that Wayland was billed as a "lightweight and modern X11 replacement" and then made itself needlessly complex, took forever to come out, and basically made the suckiest possible alternative to X11, to the point where X11 works better (in my experience at least), invalidating the whole point of having a simple and easy X11 replacement in the first place.
Every piece of software I know that has ever interacted with Wayland has had problems, and Factorio is no exception.
I guess by "modern" the Wayland developers meant "an unmaintainable overbloated mess of soyware", which would be pretty accurate.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 5:02 am
by Straugh
This is so close to what I proposed for 2.1 cutoff.
I still argue that vanilla should have inserters that go 8 directions like flamethrowers. Yes we can install a mod for this, but it is silly not to have this by default.
It we can pull an item from a 2x2 or larger entry from all sides, we can have larger chests. This eliminates cursed design hacky solves with cars and wagons.
Last is foundries should be able to do stone bricks if they can do plates.
This is a solid foundation.. Hopefully you will find inspiration to do another DLC. There is still plenty more that you could expand upon with water, flight, underground and worm holes.
Biter/spitter spawners will emit a cloud of damaging acid if they are blocked from spawning units.
Is this just the spawners, or does this effect happen with other spawn blocking situations, like biter eggs spoiling in a big square of storage chests that leave no space for it to actually appear?
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 5:17 am
by sarge945
Are any other mod developers having trouble with entity graphics with this update?
raiguard wrote: Tue Jun 23, 2026 9:30 pm
The "dynamic setup with filtered input-output ports" was the exact bug that needed fixing. Passing lubricant through a water-filtered boiler but not having it show up in the GUI made absolutely zero sense.
You can use a pump to restore the EM plant's ability to "suck" fluids.
Maybe there's any way to fix that with less disruptive methods? You seem to be fixing some fringe cases and as a collateral just make the normal behavior way less intuitive and convenient. Using extra pumps for crafters just so the can actually draw the fluid from the system is not the best choice.
Hell, you reworked the entire fluid system to make it easier to use and more intuitive, and now make these changes that also necessitate additional pumps in random locations.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 9:43 am
by kizrak
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 9:53 am
by Eulenberg
Im not a math person tbh, but isnt shared_probability for scrap recycling a huge nerf to fulgora scrap yield in general? in 2.0 you would roll on each item individually meaning 20% the time you would get gears etc... but you also could had a 1% to get holmium ore on that same piece of scrap, now there is only one roll due to the shared_probability system, if i understand correctly, massively nerfing the yield from scrap overall per processed piece of scrap
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 10:06 am
by Hares
Eulenberg wrote: Wed Jun 24, 2026 9:53 am
Im not a math person tbh, but isnt shared_probability for scrap recycling a huge nerf to fulgora scrap yield in general? in 2.0 you would roll on each item individually meaning 20% the time you would get gears etc... but you also could had a 1% to get holmium ore on that same piece of scrap, now there is only one roll due to the shared_probability system, if i understand correctly, massively nerfing the yield from scrap overall per processed piece of scrap
I suppose "no", the average yield should be the same. Previously, you had a chance to roll, i.e., gear AND concrete at the same time, but at the same time you just could get nothing.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 10:11 am
by dermiste
Sanqui wrote: Tue Jun 23, 2026 9:43 amFeatures
(...)
Circuit connectable entities with control gui on side now have settings groupped into "Input" and "Output" section.
Added option to select which wires (red, green or both) should be used by a circuit connectable entity for input, and separately for output.
Requester and buffers chests can now set requests and read contents at the same time.
(...)
Changes
(...)
Asteroid collector no longer ignores its own circuit output when updating filters from circuit network.
Assemblers no longer ignore their own circuit output when selecting recipe to craft from circuit network.
(...)
Hi, I really love this update and what you have done with the circuit network, most notably the ability to select the input and output wires. However I feel that this gain on expressivity and control is seriously diminished by this "machines can use their own outputs as inputs" aspect, it wrecks a whole bunch of my multiplexed-recipe-assembling-machines builds and so far I have found no practical use for this behavior. Sure enough I can "fix" it by adding a passthrough combinator to switch from red to green or vice-versa, but it adds an entity as well as a one-tick delay in signal propagation, which can force me to replicate this one-tick delay in other places with an other passthrough combinator and so on. It really feels like the whole circuit network has been made worse for no good reason, as I now have to spend time going over every connection when designing a build to check and uncheck the inputs and outputs just to avoid an assembler going Ouroboros with the most brain-dead tautology when the previous behavior was actually sensible.
Please consider reverting to the previous behavior, when assemblers/collectors/etc could not use their outputs as inputs.
Keep up the good work, and thanks again.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 10:13 am
by boskid
dermiste wrote: Wed Jun 24, 2026 10:11 am
Please consider reverting to the previous behavior, when assemblers/collectors/etc could not use their outputs as inputs.
No. Magic self-subtract was hard to discover, was inconsistent with other entities and was reported multiple times for being actually a bug because some players wanted to disable assemblers based on its own content and to their surprise found it does not work. There is no reversal of this change.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 10:39 am
by Walterin0
Is it intentional we can't do platform to platform transfers at the solar system edge? If so, can we look into changing it, it would open up some very new and interesting avenues for gameplay.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 10:57 am
by GregoriusT
Walterin0 wrote: Wed Jun 24, 2026 10:39 am
Is it intentional we can't do platform to platform transfers at the solar system edge? If so, can we look into changing it, it would open up some very new and interesting avenues for gameplay.
I wonder if that is a side effect of System Edge not having a surface and therefore the Platforms not even trying to operate their Logistics.
Walterin0 wrote: Wed Jun 24, 2026 10:39 am
Is it intentional we can't do platform to platform transfers at the solar system edge? If so, can we look into changing it, it would open up some very new and interesting avenues for gameplay.
I wonder if that is a side effect of System Edge not having a surface and therefore the Platforms not even trying to operate their Logistics.
Seems likely. Hopefully it will be changed, was looking forward to super fast ships delivering eggs and quantums to prom haulers who go back and forth.
dermiste wrote: Wed Jun 24, 2026 10:11 am
Please consider reverting to the previous behavior, when assemblers/collectors/etc could not use their outputs as inputs.
No. Magic self-subtract was hard to discover, was inconsistent with other entities and was reported multiple times for being actually a bug because some players wanted to disable assemblers based on its own content and to their surprise found it does not work. There is no reversal of this change.
I understand that and completely agree with it. Can you instead provide a migration that, for all circuit networks, checks if the machine is consumer or provider (or does it so in most cases)? I can see it be done the following way:
All input ports of combinators are consumers, all output ports are providers
All entities with all "Read X" off and any "Send Y" on are providers
All entities with any "Read X" on and all "Send Y" off are consumers
All entities with both "Read X" and "Send Y" on are entities in question
For each entity in question, check if network contains "defintely consumers" and/or "definetely providers".
If only kind is found, treat entity in question as the opposite for the selected network.
If the network still contains entites in question, do nothing and print warning with the total amount of such entites (and their position/surface/kind?).
Note to the above. As a result of such migration script, some entites should have some of their Input/Output red/green checkboxes being disabled.
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 12:25 pm
by vemusa
raiguard wrote: Tue Jun 23, 2026 9:30 pm
The "dynamic setup with filtered input-output ports" was the exact bug that needed fixing. Passing lubricant through a water-filtered boiler but not having it show up in the GUI made absolutely zero sense.
You can use a pump to restore the EM plant's ability to "suck" fluids.
Are you sure the thing you want to fix is "dynamic setup with filtered input-output ports", and not "passing lubricant through a water-filtered boiler"?
In other words, would you be happy if dynamic fluid was dead like space casino and hazard concrete recycling, but passing lubricant through boiler was still possible like LDS recycling and CLP recycling?
Also, I want to point out that "dynamic setup with filtered input-output ports" does not necessarily mean or imply passing filter-violating fluid through these ports.
For example:
This works in 2.0 , and is what I mean by "dynamic fluid setup with filtered input-output ports that does not rely on passing filter-violating fluid through these ports".
Finally, I don't think "just use a pump" can justify this much collateral damage. You can also just use a filtered pump to prevent your lubricant from passing through your boilers, right?
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 1:06 pm
by Eulenberg
is there some context on why we needed a centrifuge stack nerf? seems very arbitrary
Re: Version 2.1.7
Posted: Wed Jun 24, 2026 1:12 pm
by vemusa
Eulenberg wrote: Wed Jun 24, 2026 1:06 pm
is there some context on why we needed a centrifuge stack nerf? seems very arbitrary
![[space-age]](./images/smilies/factorio/space-age.png "Space Age"){kind=small}
Asteroid collector no longer ignores its own circuit output when updating filters from circuit network.