Originally posted by AntaroNx

Does the endgame become gambling on high rarity parts that otherwise get recycled into another chance of becoming high quality because rng?

I don't like it, and I play gacha games. Hopefully this can be turned off. The module is fine, no need to change it for the sake of change.

Originally posted by MindWorX

To make things clear, the quality content is exclusively part of the expansion. The non-expansion binary works the same internally, it just doesn't allow any mod to define anything other than the normal quality.

This feels a bit icky to me. I get why, they want to encourage more people to get the expansion, but it also means fragmenting mods more since they now have to deal with supporting both vanilla or expansion. Many might just opt to default require expansion. I know it wont impact many, me included, as we will just get the expansion. But it feels like the wrong decision.

Only comparison I can make is something like StarCraft II, where each DLC added new things, but all engine features were still fully available to modders. The only limitation was the use of assets new assets and obviously mods that just replicated the expansion would be removed.

Originally posted by Menolith

The names in particular feel rather out of place. "Epic" and "Legendary" are evocative of your usual fantasy setting which is very much at odds with Factorio's smoggy quasi-dieselpunk aesthetic.

Originally posted by Weppet

I'm a bit torn on quality. On one hand it could be a fun way to design around absurdly powerful items, on the other it doesn't feel like Factorio. The quality indicator seems out of place too, but maybe it's just a place holder.

How do stacks work now? One stack for each quality?

Originally posted by UnGauchoCualquiera

On the the last gif (the lake one)

> always charge at a roboport that is closer to the destination than the robot is

Wouldn't that actually make them perform much worse in the much more common scenario of a perfect grid?

The perception of bots flying over available roboports but continuing on low energy might actually be worse than simply looping back and forth.

Example:

Given a fully covered 5x5 grid and a bot that travels diagonally from 1,1 to 5,5.

If it turns out mid flight at say 3,3 that it doesn't have enough juice it will try to recharge at 5,5 instead of the closer roboport at 3,3 and continue.

Originally posted by EpicRaginAsian

Wait so is weekly FFF back?

Originally posted by Deranged40

For these 'smarts' we use a quite simple heuristic, factoring in not just how close the roboport is, but also how many other robots are currently charging there.

/u/factorioteam can you confirm that this will take into consideration "free spots" and not just blindly "how many are charging?" They seem very similar at first, but with modded roboports, we can have way more than 4 robots charging at once. So I just wanted to make sure that calculation will still consider open spots

Originally posted by BraxbroWasTaken

Will a mod be able to adapt to whether or not the expansion is installed w/o requiring it as a hard dependency?

I assume the dependency will be the same as adding the expansion to the mod’s dependency list, so it’ll support optional and hard dependencies? Kinda like how all of the base game’s content is in __base__?

Originally posted by mrbaggins

It is quite clear, that there were things in the inventory which Scott just didn't want to show yet, so he just pasted the icon over.

You fool! Their location still tells us where they go in the tabs! Assuming one of the ones between roboports and combinators is the "Real" redwire, there's something there (Another colour? Or maybe coloured lamps or a new combinator. Leaning toward coloured or other variant lamps honestly.)

The other 5 after nuclear fuel are a bit harder. From memory of the inventory/tabs, the only thing after intermediates would be more science packs, then you're into the combat tab, so I'd probably guess new weapons/armor/toys

Originally posted by alexbarrett

Will it be possible to buy the expansion DRM-free on factorio.com then register it on Steam, like we did back in 2016?

Originally posted by AcherusArchmage

Achievements were added June2016 so anyone who owned the game beforehand and either didn't play again, or always played with achievements disabled (often due to certain world settings or with mods) wouldn't have them obtained no matter how easy they were.

Some other games that have achievements that SHOULD be 100%, such as "start the game" are often at 74-95%, even lower if achievements came in at a later date.

Originally posted by Weppet

The main problems with big networks right now are (for me): resources get pulled from all over the base and bots migrate, this results in massive travel time and recharge time. I imagined this would be solved by being able to allocate bots to roboports and with the scheduling change. Sure, some resources might still be exchanged between lines of production but only if it's faster to do so, from what I understand.

Or are you also talking about UPS advantages?

Originally posted by Weppet

I love it, does this mean that we can do bot megabases with one big network instead of many smaller ones? It seems that the queue system could really get rid of the problems that big networks have.

Originally posted by Darkhogg

Most of these additions are stuff I have at some point thought about, both problems and possible solutions, so I'm really glad they were addressed!

It would be amazing if bots did do some amount of pathfinding, it would not be that hard or complex (computatially sdpeaking) to implement an algorithm that chooses where to go based on max possible distance before needed to charge to some extent.

But at the very least, the game should make sure bots don't start looking to recharge when the can complete their assignment before running out of battery!!!

Originally posted by alexbarrett

If I understood everything correctly, actives robots will have properties for estimated idle time & position. Does this mean that:

1. When a personal robot is constructing an entity: the estimated final position will be at the constructed entity's position.
2. When a personal robot is bringing an item to the player's inventory: the estimated final position will be the player's position.

I assume also that once a task is added to a robot's queue, it will remain there and not get dynamically reassigned.

Does this mean that if a player stands e.g. very close to a full chest and deconstructs it, the game will assign tasks to empty the chest to the personal robots, and if the player then walks far away from the chest the personal robots would then a very long task queue ahead of them? Would the estimated idle time be updated when the player moves?