Version 2.0.38

[FactorioBot]

Changes

• Space platform "request missing materials for construction" will no longer request items for entity ghosts which can't yet be built. (122185) This should help to prevent over filling of hubs while larger platforms are being built.
• Increased minimum sprite atlas size to 4096 even when sprite resolution is set to medium. (127086)

Bugfixes

• Fixed a lua doc error with LuaSchedule::add_wait_condition(). (127153)
• Fixed a crash when changing the station in some wait conditions. (127123)
• Fixed that the mining dril status would be incorrect when out of resources and pointing at an entity to be deconstructed. (125167)
• Fixed that inserters would not show target full for space platform hubs. (121920)
• Fixed a crash when opening the changelog while trying to connect to a multiplayer game. (118795)
• Fixed that LuaSchedule::add_record() did not support rail_direction. (127171)
• Fixed that vehicle weapon tooltips did not show bonuses. (122386)
• Fixed achievement steamrolled can be earned while driving remotely. (120247)
• Fixed lab was not creating trash inventory of proper size when LabPrototype::trash_inventory_size was given. (127218)
• Fixed that the side menu buttons did not update when a player would change forces. (122088)
• Fixed that the filter selection GUI would get closed when a ghost buffer chest was built. (122514)
• Improved issue with fast moving bots sometime appearing on screen instead of flying in from off screen. (124268)
• Fixed issue which sometimes resulted in incorrect lightning protection visualisation for marginal setups (126780)
• Fixed cutting tiles marked for deconstruction could produce superfluous deconstructible tile proxies (124155)
• Fixed Steam achievements synchronisation issues. (118242)
• Fixed that having a camera widget on screen would cause issues with the rail plan finder. (122679)
• Fixed that resources with no minable products would not show a name when hovering in the map view.
• Fixed some almost transparent pixels in the car and production group icons. (127227)
• Fixed that researching a technology would cause the input fields in constant combinators and requester chests to lose focus. (123241)

Modding

• Added the "infinity-cargo-wagon" entity type.
• Added the "proxy-container" entity type.
• Added SpiderVehicleGraphicsSet::default_color.
• Unified entity_renderer_search_box_limits to 6 from all sides due to reduced update rate optimization of robots.
• Reduced light_renderer_search_distance_limit to 20 to compensate for entity_renderer_search_box_limits change.

Scripting

• Added LuaSchedule::get_records(), set_records(), clear_records(), get_interrupts(), set_interrupts(), clear_interrupts().
• Changed LuaSchedule::add_record() to purely add without any extra behavior.
• Changed LuaSchedule::add_record() to accept index saying where the record is added.
• Added LuaProxyContainerControlBehavior.
• Added defines.inventory.proxy_main.
• Added LuaEntity::proxy_target_entity and proxy_target_inventory.
• Added LuaEntity::get_cargo_bays().
• Added LuaPlayer::add_pin().
• Added LuaPrototypeBase::factoriopedia_description read.
• Added factoriopedia_alternative reads to all LuaPrototypes that support it.

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

[Hares]

Modding

• Added the "infinity-cargo-wagon" entity type.
• ...

107796: Infinity Cargo Wagon and Infinity Fluid Wagon

[Hares]

Bugfixes

• ...
• Fixed achievement steamrolled can be earned while driving remotely. (120247)
• ...

"Fixed achievement steamrolled couldn't be earned ..." or "Fixed so (that) achievement steamrolled can be earned ..."

[adam_bise]

"Fixed that the filter selection GUI would get closed when a ghost buffer chest was built. (122514)"

Thank you!

[EustaceCS]

Changes

• Space platform "request missing materials for construction" will no longer request items for entity ghosts which can't yet be built. (122185) This should help to prevent over filling of hubs while larger platforms are being built.

Gentlemen (and ladies, if any), this looks weird.
Why can't foundations have maximum priority and modules (and probably intermediates and other consumables, if requested) minimum priority for ground-to-air logistics?
It's confusing enough already.

Not if like current state of affairs is representing bigger problem, since I have to fill shipping lists manually anyway.
Players don't always eke out hundreds of space platform modules per minute into their stockpiles, you know.

[robot256]

Not if like current state of affairs is representing bigger problem, since I have to fill shipping lists manually anyway.
Players don't always eke out hundreds of space platform modules per minute into their stockpiles, you know.

That's precisely the reason for this change. Imagine your space platform calls for 50 stacks of platform and 100 stacks of buildings, and you have most of the buildings available in your mall but only a small amount of platform. The platform might get highest priority, but when it runs out the hub still fills up with unbuildable buildings and the platform that's assembled after has nowhere to be delivered.

Now your buffer of items stays on the ground until enough platform is sent and placed. I guess there could be an issue if there enough platform for 1 furnace to be placed and it sends up 50 (and repeats with enough items to fill up the hub), or if it sends up each furnace in a separate rocket. Or is there another problem with the logic you are trying to point out?

[EustaceCS]

I guess there could be an issue if there enough platform for 1 furnace to be placed and it sends up 50 (and repeats with enough items to fill up the hub), or if it sends up each furnace in a separate rocket. Or is there another problem with the logic you are trying to point out?

That's a million dollar question.

In my brain, before 2.0.38 ground-to-air auto-queueing worked like:
- if there's a rocketful of %ITEM_NAME% in a Logi Network in which a READY Rocket Silo with Auto Fulfil Requests enabled
-- if any amount of %ITEM_NAME% is requested by space platform on orbit above said Rocket Silo
--- then gather a rocketful of %ITEM_NAME% in Rocket Silo and launch to that Space Platform AS SOON as %ITEM_NAME% quantity in active Rocket = requested quantity of that item (which may AND WILL lead to premature launches of semi-full rockets, if trying to solve auto shipping problems with lame wirings)
- keep polling otherwise

Which leads to a lot of headache if you're trying to build more than one platform at once.

While it's inconvenient as hell, I have to accept begrudgingly that this behaviour is similar to how average Requester Chest with only minimal amount requested set works:
- if you ask, say, minimum of 1 of %ITEM_NAME% to be delivered there without defining maximum,
-- stupid bots would grab from one to min(current_max_item_stack, %ITEM_NAME% quantity at grabbing point) units of %ITEM_NAME% and drop ALL these into a chest
--- without carrying extra units away

-------------------------------

But Space Platform's Auto Request Construction Materials makes requests in which minimum requested amount is supposed to be equal to maximum requested amount.
Because each launch is a costy operation and should be used to the fullest, unless explicitly told to launch underweight rocket.
And tossing surplus %ITEM_NAME% , which was requested by a platform for no reason, only complicates things further.
Because you can't just ship extras back with some "Auto Trash Send Extras Back" checkbox on Platform (there's none, right?) nor with request to ship extras back to Cargo Pod (Cargo Pods can't explicitly request redundant materials and will try to nab ALL requested items - even if these are about to be built/socketed).
And none of that stuff is consumable usually anyway.

-------------------------------

Or where REAL minimum auto requested amount is equal to max(auto_requested_amount, %ITEM_NAME%_stack_size_for_rocket_shipping).

I play Space Age since release but I'm still quite clueless about how ground-to-air logistics works.

Now, 2.0.38 introduces additional condition into logics with which I'm clearly struggling with already: "do not request things which couldn't be built now".

As Auto Requesting did had SOME items culled from auto shipping already (read: module ghosts in building ghosts), which already led to necessity to literally count modules-to-be-shipped manually one by one, I can only assume that this practice has been propagated to buildings (and probably foundations) themselves.

Which MIGHT indeed save few clicks to people for which endgame (read: malls, hundreds of Science per second, etc-etc) starts within first few hours of playtime.

I'm not that hardcore - and I'm mildly panicking since it looks like things are about to get even more complicated on my dirty casual's small scale.
Not that it represents too much of a problem for me _now_ since Nauvis gives enough things to do for dirty casuals even without space logi woes.
(like sheesh... where am I supposed to find second Uranium patch? Are these "one-per-planet" (lol) now?)

[Muche]

A rocket delivering 50 electric furnaces even though the platform currently wants to build 4 is aimed at casuals.
A casual does not know yet if they'll need to build more of them, or will need to rebuild some of them due to asteroid damage.
That surplus amount is a spare they might need and saves them another rocket launch.

If you're placing a blueprint of a platform with carefully calculated ratios and enough firepower to not need replacements, you are not a casual anymore.

[EustaceCS]

A rocket delivering 50 electric furnaces even though the platform currently wants to build 4 is aimed at casuals.

I've premeditated few different variants of dialogues which could unravel from this specific branch but failed to find any worthy of advancing through.
Are you trying to transfer this clearly UX matter (with slight flavour of "UX for end user vs codebase unification" problem) into a personal argument?
Care to elaborate?
In context of message you (presumably) responding to and regardless of potential unraveling of our dialogue branch, your response implies that I'm either worse than casual or better than casual.
Which is not quite helpful for our common cause.

[Muche]

A rocket launching 50 furnaces even though a player wants to build only 4 on the platform should hint at them that they will need many rocket launches. And automate loading them, with the easiest option being bots.
Should they ignore that hint, manually load all rockets with minimum amounts of items possible, they might find themselves on another planet, unable to leave and unable to launch another rocket from Nauvis. Leading to a bad experience.

So if you are optimizing rocket launches because it's a challenge for you, it's your choice (and you are now more advanced than casual).
If you are optimizing launches because your base is too small to support more of them, please let us know how can those hints be less subtle.

[meganothing]

I guess there could be an issue if there enough platform for 1 furnace to be placed and it sends up 50 (and repeats with enough items to fill up the hub), or if it sends up each furnace in a separate rocket. Or is there another problem with the logic you are trying to point out?

That's a million dollar question.

In my brain, before 2.0.38 ground-to-air auto-queueing worked like:
- if there's a rocketful of %ITEM_NAME% in a Logi Network in which a READY Rocket Silo with Auto Fulfil Requests enabled
-- if any amount of %ITEM_NAME% is requested by space platform on orbit above said Rocket Silo
--- then gather a rocketful of %ITEM_NAME% in Rocket Silo and launch to that Space Platform AS SOON as %ITEM_NAME% quantity in active Rocket = requested quantity of that item (which may AND WILL lead to premature launches of semi-full rockets, if trying to solve auto shipping problems with lame wirings)
- keep polling otherwise

Which leads to a lot of headache if you're trying to build more than one platform at once.

While it's inconvenient as hell, I have to accept begrudgingly that this behaviour is similar to how average Requester Chest with only minimal amount requested set works:
- if you ask, say, minimum of 1 of %ITEM_NAME% to be delivered there without defining maximum,
-- stupid bots would grab from one to min(current_max_item_stack, %ITEM_NAME% quantity at grabbing point) units of %ITEM_NAME% and drop ALL these into a chest
--- without carrying extra units away

-------------------------------

But Space Platform's Auto Request Construction Materials makes requests in which minimum requested amount is supposed to be equal to maximum requested amount.
Because each launch is a costy operation and should be used to the fullest, unless explicitly told to launch underweight rocket.
And tossing surplus %ITEM_NAME% , which was requested by a platform for no reason, only complicates things further.
Because you can't just ship extras back with some "Auto Trash Send Extras Back" checkbox on Platform (there's none, right?) nor with request to ship extras back to Cargo Pod (Cargo Pods can't explicitly request redundant materials and will try to nab ALL requested items - even if these are about to be built/socketed).
And none of that stuff is consumable usually anyway.

-------------------------------

Or where REAL minimum auto requested amount is equal to max(auto_requested_amount, %ITEM_NAME%_stack_size_for_rocket_shipping).

I play Space Age since release but I'm still quite clueless about how ground-to-air logistics works.

Now, 2.0.38 introduces additional condition into logics with which I'm clearly struggling with already: "do not request things which couldn't be built now".

As Auto Requesting did had SOME items culled from auto shipping already (read: module ghosts in building ghosts), which already led to necessity to literally count modules-to-be-shipped manually one by one, I can only assume that this practice has been propagated to buildings (and probably foundations) themselves.

Which MIGHT indeed save few clicks to people for which endgame (read: malls, hundreds of Science per second, etc-etc) starts within first few hours of playtime.

I'm not that hardcore - and I'm mildly panicking since it looks like things are about to get even more complicated on my dirty casual's small scale.
Not that it represents too much of a problem for me _now_ since Nauvis gives enough things to do for dirty casuals even without space logi woes.
(like sheesh... where am I supposed to find second Uranium patch? Are these "one-per-planet" (lol) now?)

The change solves a problem with limited space on the platform hub. But items will block exactly the same space, whether only 1 or a whole stack is delivered. In other words, the problem solved here happens independently from overdelivery, i.e. whether that happens or not.

The problems overdelivery might present (for example too many unneccessary items sent there) will still happen identically with or without this change. The change may delay delivery of specific stacks, but it will still be whole stacks delivered.

The change is just removing a possible blocking condition without anyone needing to change a single thing in their factory.

Am I missing something?