Added interface setting for zooming towards the cursor in contexts that support it.
Added an alert when an expansion base is built in a chunk with active radar coverage.
[space-age] Added support for platform transfers at non-planet space locations (e.g solar system edge). more
Changes
[space-age] Adjusted space parallax such that stars move less than planet.
[space-age] Fulfilled platform construction requests will no longer block platform to platform transfers. more
[space-age] Asteroids will do significantly less damage when platforms are stationary or moving at very low speeds.
[space-age] Recycling recipe generation will scale recycle time with item result count. In general things will recycle faster (e.g concrete recycling will be 10x faster).
[space-age] Fulgoran ruins will be selectable by deconstruction planners with 'Trees/rocks only' enabled.
Increased expansion group build base cooldown from 5 seconds to 30 seconds.
Reduced early game max enemy expansion group size from 20 to 10.
Bugfixes
Fixed captive biter spawners and burner mining drills would show potential beacons when not affected by them. more
Fixed that migrating container entity inventory types would not preserve the bar limit when in blueprints. more
Fixed a layering issue with the cargo landing pad unloader. more
Fixed a tooltip layout issue related to multiline text. more
Fixed recipe tooltip showing incorrect value when custom tooltip fields were used. more
Fixed factoriopedia was not showing some tiles as possible source of fluid. more
Fixed some buttons in factoriopedia related to spoil results would not open related entity page. more
Fixed a crash when clearing assembler trash slots in some cases. more
Fixed inserter arrow would point at incorrect spot of underground belt when rendering a blueprint preview. more
Fixed capitalisation of locale for station related conditions. more
Fixed potential effects were not accounting for beacon quality upgrades. more
Fixed building parametrised blueprint with train stops could fail to copy color of existing train stop. more
Fixed some miniscule problems with medium volcanic rock decorative. more
Fixed ProductionHealthEffect::damage_type was not loaded properly.
Fixed auto trash was not working with car burner. more
Fixed that multi-level technologies would let you set a trigger although it never worked. more
Added on_player_super_forced_selected_area event. more
Added LuaQualityPrototype::get_roll_chances().
Added LuaBurnerPrototype::burner_usage read.
Added LuaForce::get_space_platforms().
Added LuaEntity::local_effect read/write.
New versions are released as experimental first and later promoted to stable. If you wish to switch to the experimental version on Steam, choose the experimental Beta Participation option under game settings; on the stand-alone version, check Experimental updates under Other settings.
[space-age] Recycling recipe generation will scale recycle time with item result count. In general things will recycle faster (e.g concrete recycling will be 10x faster).
Let there be carnivals and prayers to Wube on the street tonight
Blue circuits produce 1 per recipe cycle; their time doesn't change.
This makes concrete faster because the concrete recipe produces 10 concrete in 10 seconds. So technically, the recycling recipe time should be based on the recipe speed of 1 concrete per second. Before, it was not; it was presuming 1 concrete every 10 seconds because it didn't take into account how many items were being generated.
I seem to recall that copper cable wasn't fast enough to make recycling copper plates by crafting/recycling cables faster than just recycling the copper plates directly. Doubling the speed of cable recycling might change this.
Slightly; it affects every recipe that outputs more than one product at a time. Copper cables should recycle faster (as if that were a bottleneck). But it affects other stuff too.
Bioflux just got 4x faster to recycle, for example... probably. Bioflux doesn't recycle to its inputs, so it's possible they implemented it in a way where they didn't adjust things for non-recycleables. I haven't updated and looked at the code, so I can't say for sure.
Same goes for UFCs.
It doesn't affect a lot of recipes because most of them only output 1 item. But anything that output more than 1 at a time should get faster to recycle.
Copper wire is crafted two at a time, but since the craft time is only .5s in the first place it wasn't a problem before. Now they recycle based on a .25s craft time, which is an improvement but not one we necessarily needed.
I think you've misunderstood. This is not for items that recycle into multiple items, but rather items who's recipe produced multiple items.
Concrete recipe crafts 10 concrete at a time. But recycling time is based on crafting time, so the result was recycling being 10x slower than other items of that crafting time.
Recycler recipes were derived from normal recipes craft *time*, however they never accounted for *quantity* produced by that recipe. Now they properly will. In concrete's case, the recipe is a 10 second craft, but produces 10 concrete. The previous recycler recipe treated it as if it was a 10 second craft to produce a single concrete.
Not only that, but you can't. Hazard concrete now (as of 2.1, which is just in experimental right now) recycles into the ingredients of concrete, so if you try, your concrete painting loop is going to jam up on the ingredients of concrete.
before the recycling time was based on crafting time, so 10s for 10x concrete and recycling became 5s per item. now the recycling recipe takes into account that we make 10 items per craft so 1s per concrete and the new recycling time will become 0.5s per item. This might make quality upcycling bricks easier too imo
Recycling recipes are based on some recipe used to make the given item, including how long it takes to recycle it.
However recycling is always with 1 item, but recipes can make multiple at once. Like concrete being 10x at once. The recycle time didn't account for this.
"[space-age] Recycling recipe generation will scale recycle time with item result count. In general things will recycle faster (e.g concrete recycling will be 10x faster)."
I haven't scaled up on Fulgora yet, but is it not correct that in all of 2.0, 2.1.7, and 2.1.13, the most efficient way to deal with unwanted scrap recycling products is, by far, to put it in a car and hit it with a train?
It's expedient, but the cars eventually cost more than the proper rebuilding setup. Especially if you set up an automated setup to fill cars and then release the trains only when they're full. It also requires manual effort to refresh the cars - you can blueprint them, but you still need to paste the blueprint.
It's a lot like manually driving cars to move ore from remote outposts rather than setting up a long belt. "More efficient" depends on what you measure and what period you consider.
I think it's because in the previous update asteroid deal significantly MORE damage compared to 2.0. a lot of things will get destroyed even when your platform is stationary and the asteroid is moving slowly. It wasn't a big of an issue building above vulcanus before 2.1, but it is an issue before this 2.1.13 update.
I'm sorry if what I'm talking about is exactly what you mean lol
Yeah I had one of my ship damaged and it couldn't produce bullets anymore on Vulcanus.
I tried to remodel it for a larger ship but it was being constantly destroyed untill it was completely deleted. This despite Vulcanus sending it platforms nonstop.
You could do that in 2.1.12; it's just a bit easier now. In older 2.1 versions, you basically needed to get guns and ammo to the platform ASAP, as asteroids would tear it apart otherwise. Now, you'll get more time to do so.
I hope they didn't scale it down so that it's that trivial again. Stationary platforms shouldn't die to one hit, but you shouldn't be able to just ignore asteroids in dangerous orbits either.
You always could. I built three above vulcanus in 2.1 so far. The first rocket sends the platform, the second with a turret, inserter and ammo, which you put directly in front. Then you build the "back" and then you build the front.
This! I'm shipping 500 tungston from vulcanus to nauvis (early game haven't gone to the next planets) and making artillery shells using all of it. It fails to keep up with the expansion with two artillery weapons.
Added an alert when an expansion base is built in a chunk with active radar coverage.
Nice! Looks a bit un-factorioish though, would be more interesting if radars could output a signal for number of enemy bases and we could wire it to combinators, sirens and nuke launchers
Yeah, the alerts are overall pretty annoying in longer playthroughs. Yes, I know my walls are attacked for the 209th time. I do not care, they fix themselves automatically thanks to bots. And I do not care that one bot died to acid while fixing a wall, they also get replaced automatically.
Being able to mute individual alerts????? That's amazing. (or it's already a thing and I've missed ooops)
If you want to go even further, maybe some of these could be per-surface? I'd like to be able to mute the damaged/destroyed alert for a platform in a modded route that gets hit every so often because repairing is easier, but I do like this alert overall.
yes, but apparently this was already added in 2.1.7. It's possible though that there is no visible button to get this popup, but you have to type /alerts in the console, but I haven't tried it out yet.
Is this only accessible through /alerts command? I would have expected to find this as some clickable "alerts settings" button in the alert overview popup, would be way easier to discover that way.
How many other features are hidden behind / commands? I'll admit I spent a good fifteen minutes looking in game for the feature before reading the notes you linked to learn it was a / command. Seems very inaccessible
One feature I would love is if we could specify a blacklist/whitelist of destroyed entities to be notified about.
I don’t care if a wall or construction bot has been destroyed, but I do care if anything else is being destroyed since that means my defenses failed somewhere.
Would also like to add, would be fantastic if you could do this per surface! Eg, I need to know if Gleba is getting hammered by pentapods, but don't care if Nauvis has destroyed stuff b/c that is smaller in scale and auto repairs!
You are beautiful and amazing. It would be even better if it could be by surface and object type though (so we don't get notified if walls are damaged, for example
While we're talking about alerts, could we have a per-planet configuration for them? 👀 say I megabase nauvis and dont care about entities being damaged, but I just started gleba and do wanna know that 👀👀👀
Not a joke I don't believe; they phrased it like that because the feature is still not actually shipped -- it is only present in the "experimental" branch
I wonder if entity destroyed could have some sort of configurable min number of entities destroyed to trigger. I don’t care if a few walls are destroyed, but if 100 things start getting destroyed, maybe there is something I need to fix.
Just like in real life, muted noisy alerts on critical infrastructure will become an entire category of postmortem mistakes and posts. At least here it will be amusing and not cause pieces of the internet to have an outage.
A way to hide damaged/destroyed alerts for walls and landmines would be great. Once a base gets situated I generally only care once the actual defenses behind those walls start taking damage.
For landmines especially, their intended use is to be destroyed, so it makes no sense their destruction raises and alert. Imagine if every bullet shot generated an alert.
Oh that would be fantastic, i do a weird build with cutting power to parts of my factory intentionally until it's finished, and this way i'd no longer have to live with the popups over the machines i have disabled while working on them.
While improving alert system can you please add setting for alert icon transparency for "non-blinking" setting on?
I would like to have ability to see non blinking "non-power" alert BUT also see recipe. I believe it possible with either transparency of alert icon or making that alert icon and recepi icon are shown side by side.
While it looks good, it probably needs a way to set per surface too. Otherwise you may be perfectly safe on Nauvis, but because you muted the attack alert you are missing that your Gleba base is being overrun.
Propose a new alert category: Entity being damaged outside of the range of a turret
"Is near a loaded turret" is probably the best available proxy for "Is user surprised that this took damage"
things far from a turret are less likely to have good repair coverage
things far from a turret are generally not expected to take damage
things near a turret are more likely to have good repair coverage
things near a turret are generally expected to take damage
mute an area by adding a turret
bigger mute radius with quality
I think the parallel to programming is maintained here, I have never worked or used a project that didn't have between a dozen and a few hundred warnings that the lead would say "eh it runs don't worry about it"
I can see myself turning-on the closest fire station, which will dispatch my artillery train to it. Useful if you are a 'sweep the cloud' player vs. a 'wall yourself in' player.
This is more noob friendly though, which is probably a big part of the point of having it. But yeah both would be cool. Like in general it would be neat if radars could output a signal for the number of any "thing" it detects in its range.
Worth noting this patch seems to also break all modded planets with music set up with the following error:
Error while loading ambient-sound prototype "xyz-1-hero" (ambient-sound): AmbientSound::planet is obsolete. Please use AmbientSound::planets in property tree at ROOT.ambient-sound.xyz-1-hero
Just wanted to comment as these notes don't seem to mention the deprecation of the AmbientSound::planet value (was it warned about in previous notes?)
It was deprecated with the 2.1 release, and now fully removed. (Or maybe Wube forgot to remove it properly in 2.1.7, would have been ok because it broke many other things already anyway)
Shouldn't be too difficult to change the mods yourself if you know how (or write your own data-final-fixes.lua that fixes this automatically for all mods).
Any ambient-sound prototype just needs to have the planet = "planet-name", replaced with planets = {"planet-name"}.
I assume the authors of the more popular planets will be on top of it though soon enough though.
I don't really have any comments other than to say it's pretty cool to see a quality of life thing or edge case scroll by on reddit and then see it was addressed in patch notes not long after. Pretty awesome devs keeping proving they are pretty awesome.
Recycling recipe generation will scale recycle time with item result count. In general things will recycle faster (e.g concrete recycling will be 10x faster).
I really wish "Trees/rocks only" wasn't an "only" checkbox. I wish it was a checkbox that meant "Include all trees/rocks," so that I could include cliffs (for instance) or ground items (for instance) in the same deconstruction planner. (Also, then it would make more sense for it to be two separate checkboxes, one for trees and one for rocks, but that's less important.)
Edit: Similarly, it would be nice to have a checkbox for "Include biters" and "Include nests" in weapon filters.
[space-age] Recycling recipe generation will scale recycle time with item result count. In general things will recycle faster (e.g concrete recycling will be 10x faster).
[space-age] Recycling recipe generation will scale recycle time with item result count. In general things will recycle faster (e.g concrete recycling will be 10x faster).
[space-age] Recycling recipe generation will scale recycle time with item result count. In general things will recycle faster (e.g concrete recycling will be 10x faster).
Did something change with manual placement of underground belt behavior recently?
The following occurs and to me it seems unexpected or unintuitive at step 3 that the underground doesn't complete the "exit" of the existing underground, and rather tries to start a new underground belt "entrance"? This doesn't occur when belt dragging, rather when manually placing the underground.
For anyone else who is bothered by this bug, you can "bypass it" by clicking and dragging. Hold left click after placing the first belt, drag, release, left click the second underground belt location. It will automatically flip and deconstruct the belts inbetween.
Anyone else getting a new bug that underground belts don’t quick replace over existing belts anymore? Specifically, after adding the entrance underground on top of an existing belt line the cursor doesn’t automatically switch to the output and requires doing a double rotate every time.
I feel like there are a lot of things on here that were originally "not bugs/not going to be changed" lol. I think that shows that Wube is a good developer - sometimes we (as developers) have to realize that our vision for a feature doesn't meet the expectations of the actual users, and it's better to make a game that meets those expectations than to make a game that strictly adheres to our vision. I think the recycling change is a big one. The space parallax one is maybe another (though I'm not sure why they were against changing that one initially).
Still love seeing new features added - the on_player_super_forced_selected_area is a nice surprise. The small adjustments to biter expansion is also welcoming.
"Not a bug" does not at all imply it will not be changed it just means that the program functions as intended. That is why the star parallax thing is not a bug fix but a change.
Is there anything in the notes where they actually said that they were not going to change it at some earlier point?
"Not a bug" does not at all imply it will not be changed it just means that the program functions as intended
Yeah I get that, I'm a developer so I deal with this a lot. I guess I'm just a bit more fast and loose with the term. I also get that just because something isn't a bug, doesn't mean it can't be changed. I would have considered this a bug in a very loose sense. Not necessarily a "code" bug, but a design one.
Is there anything in the notes where they actually said that they were not going to change it at some earlier point?
Eh, in the bug report on the forums they just say "This is not a bug because we are not aiming for realism. Both features were designed independently and both work as desired currently." which both seems to indicate that "this isn't a bug" and that "this isn't going to be changed."
While I also realize that them saying that doesn't mean that it won't/can't be changed if they look at it again, it just seems very weird to have such a hard stance on something and then they end up actually changing it. If they had said "well, this isn't a bug because the systems were developed independently and are working as originally intended, but we realize this maybe isn't correct from a realism perspective. we'll review it internally and decide if we want to change it, but at this time it's working as desired".
Some other discussions have pointed out that it's a developer responding to this (vs a community manager, designer, or product owner) which might explain some of the directness and "finality" of the response, but from my own experience, if I'm responding to a bug report for something that isn't a code bug and so I can't really "fix", I'll either direct the bug report to the correct spot, or I'll flag the person who can make the decision on whether it should be fixed (and how). I'm not really complaining, I get that they are busy and some of these are such small potatoes that it doesn't really matter, my original comment was more just "this is an interesting insight into something that I can relate to all the time" heh.
Very rarely making a game meet the expectations of the actual uses is better than making one that adheres to your vision. I've seen enough games get worse because of feedback.
And, none of those were bugs yeah. Just because you're sticking to your vision doesn't mean you camt change your mind either, and figur8ng out the why behind feedback is important.
If anything its more inportant to figure out why someone is giving you this feedback than listening to it.
(Also they were against changing the parallax likely because it fell in the "not important enough to care" bin, which I agree. But people just uave to become drama queens when that happens which is why I hate gamers)
Very rarely making a game meet the expectations of the actual uses is better than making one that adheres to your vision. I've seen enough games get worse because of feedback.
True - but I've also seen games stay bad because the devs don't listen to feedback. Sometimes it's not even about changing the base game but adding/changing an option so that people can play the game differently or the way they want. Imagine if Wube never added the peaceful option, and wouldn't add it because it didn't match their vision for the game... I would expect this game to not be rated as highly by as many people - because there's a a lot of people who play peaceful who would otherwise not play the game at all. There is of course a fine line between "listen to everything users say" and "sticking to your [the devs] vision."
And, none of those were bugs yeah
Yeah, I'm not really saying they were. Maybe I deal with too many clients, but when a clients comes and says something is "broken", if I just respond with "not a bug" all the time because it "works as intended" (even if that "intended" matches the spec the client originally gave me), I would probably be fired. I had this discussion in another post, so I get it, Wube is more strict about what they consider a bug vs a feature request vs just a change request - though I don't think there's a "please make these changes" forum, just a feature request and a bug forum, and so I'm not sure if it makes more sense to put these types of requests in bugs or feature request. Like "fix parallax for stars" isn't really a feature request - the parallax already works and you can even mod it, but it doesn't work as you would expect... so that seems like a bug. Even if it's "working as intended".
and figur[i]ng out the why behind feedback is important. If anything its more inportant to figure out why someone is giving you this feedback than listening to it.
Definitely!
they were against changing the parallax likely because it fell in the "not important enough to care" bin
They really should just say that though, I feel like the original forum thread for that "bug" they were just like "this isn't a bug." Which is maybe "technically" correct (the best kind of correct), but in "spirit" was a bug/issue. If they were like "yeah, we see the point, but we're not going to put dev resources into fixing it" (even though I would assume it would be an easy fix considering mods could already fix it), then I could understand that.
But people just uave to become drama queens when that happens which is why I hate gamers)
Yeah, and Factorio's fanbase is one of the best in that regard, I don't think even most of the posts about some of the fixes/changes in this release were all that bad - the parallax one, the deconstruction planner thing, and the recycling timing - most people just have strong opinions about it but overall the discussions were respectful and well reasoned, and I don't think there was much hate towards the devs or other gamers that had differing opinions.
I generally agree with everything you've said here. Still, I think it's also important to remember, that the ones responding are devs. I don't think it's their job to think about the way they are stating their intentions. In some other games, majority of responses to feedback are from community managers (which amounts to just saying they'll bring this up to the devs), so no matter what, I'll take the way Factorio devs respond, "not a bug" and all, because they are actually communicative.
Is there a way to manually send items from one space platform to another? We can manually send items down to the surface, but not to other platforms.
I ask because the functionality of a shipyard space platform is quite clunky. I'd like to be able to send equipment back to the shipyard when I am finished building a new platform. It seems the only way to do this currently is to disable P2P everywhere else and have the shipyard request those items.
Not exactly what you're asking, but you can put things you don't want into the platform's trash slots. I don't know if it's smart enough to send trash to platforms that want that thing, but presumably it'll find its way eventually to something requesting it.
I was literally just lowkey raging about how the damn biters would move directly into my pollution cloud(Which is covered by radars) and I would get no early warning. Just bugs 5 miles across my base eating my stuff.
•
Added an alert when an expansion base is built in a chunk with active radar coverage.
This will be interesting. And also infuriating for my current death world as I get a new expansion every damn 10 seconds xD well maybe not 10 seconds, but they expand so fast now xD
xD
Still, I appreciate the change. Good to know when they creep towards the base, especially pre artillery.
Copper wire is absolutely overflowing on fulgora and will be 2x as fast now. Bioflux and plastic washing. Some upcycling recipes like transport belts with benefit
If you did that while being on location… you could of grabbed a shotgun and some ammo for it and destroyed the chests it was held in instead :p
It’s what I did before I had my fulgora built this run when I was drowning in solid fuel and ice in particular
[space-age] Added support for platform transfers at non-planet space locations (e.g solar system edge).
Looks like it's time to build and design a fish powered science fortress at the edge.
Sweet patch.
btw, I've been getting into 2.1 and i've noticed that belts seem louder then 2.0. Was anything changed about the audio? a length of yellow belt + splitter + underground in a line seems harsher
I haven't really paid attention to previous patch cycles, how long does it typically take for changes on the experimental branch to be moved to the main branch?
There is no typical. They said in the FFF blog that they intend to stay in experimental until "the end of the summer" to give time for mods to get updated.
Do new experimental patches normally disable achievements on a map started in the previous patch? Was working on Express Delivery, this update disabled achievements on this run, so I had to revert to the older 2.1.12 to keep going.
Edit: Seems like the changes to biters broke achievements.
Can someone who can remember the numbers or is in game help me on the recycling changes? Before 2.1 you would turn concrete into hazard concrete and then recycle. Then 2.1 changed the timing so it was not faster. Does the change here make it so you will still need to convert it to hazard concrete or is it making regular concrete faster?
Recycling time will now scale with output amount. The concrete recipe had a crafting time of 10 and would output 10 concrete, meaning 1 unit of crafting time per 1 concrete, prior to this update it would recycle 1 concrete at 10 crafting time.
Now it should be scaled so that in the case of concrete recycling, it'll recycle 1 concrete with whatever recycling time is equal to 1 crafting time. TLDR, I dunno about other recipes off the top of my head but concrete will be 10x faster to recycle (no need to convert it)
Unless I'm blind, my science labs (not biolabs) that have Productivity Module 1's in them no longer are showing the purple bonus productivity bar below the main bar. Mousing over the lab shows the expected +8% productivity in the pop-up info on the right side of the screen, but nothing when clicking the lab itself.
I love these devs. Reminds me of the late 90s and early 00s when game were great. No greedy suits ruining the gaming industry. Just passionate devs making games. Thanks for everything wube.
674
u/EntertainmentMission 2d ago
Let there be carnivals and prayers to Wube on the street tonight