Open veger opened 1 month ago
Expensive Mode
Expensive mode is gone, so the code that reads RecipePrototype
and TechnologyPrototype
need to be adjusted.
Trigger Technologies Milestone analysis and similar code needs to read technology triggers from the prototype and respect that.
Beacons Beacons will define how they stack with each other. Need to read the prototype and apply the effects appropriately. It's still a bit unclear to me how this definition of stacking applies to different type of beacons.
Quality
EffectTypeLimitation
and Effect
Asteroid Collector
There is probably a new prototype. How similar will it be to MiningDrillPrototype
? What data defines the distribution of different asteroids? For larger asteroids you spend ammo to break them down before you can grab them. How do we want to model that whole area?
Weight Rocket logistic will rely on items having weight. Should somehow be used in throughput stats. "e.g. 1.5/s = 1200s per stack = 0.1 yellow belts = 20000s per rocket"
Fusion Reactor The neighbor bonus of the fusion reactor will be a lot more complex than a simple "2x5" grid configuration. Also according to the FFF the effect of neighbor bonus is higher plasma temperature instead of more of that. Definitely different from a normal reactor. Maybe even a new prototype.
Spoils Probably it's too much to make calculations based of that, but since some science packs are more efficient when less spoiled, this effectively influences the whole cost analysis. cost analysis currently uses the total amount of required science packs as a basis, but with spoils you need more of some packs than in theory. Do we want to allow the user to define the "default spoilage" of certain items?
Stack Inserter The new stack inserter changes the items/s a belt can transport. The stack inserter itself will also need a different calculation of items/s. Not sure how much realism there is currently (inserter capacity 2 is 2x the speed from box to box, but not when belts are involved). How much accuracy do we want to have?
Planets How should we handle different planets? There might be buildings that can only be built on certain planets. Do we want the user to be able to assign a planet to each sheet? Is it enough to have the planet-specific science pack as a milestone, or is "being able to travel to planet X" also interesting as a separate milestone?
Additional Productivity
CraftingMachinePrototype
already has a base_productivity
. I remember some statement from a FFF that there will be a (configurable) max productivity bonus due to recycling. And there will be per-item (or per-recipe?) bonus productivity as technology effect.
Recycling I assume the recycling machines are just furnaces in a trench coat with no extra work, but who knows?
You covered everything I'd thought about on my own, and several things I'd forgotten. Here are my thoughts:
Expensive Mode :+1:
Technology triggers
Accessibility and milestone analyses already support using any FactorioObject
as a source for items. There isn't a way to configure this externally, but I have local changes that make SE's arcosphere collector a source for SE's arcospheres, and the accessibility calculations work properly. Cost and automation analysis aren't as happy, though.
If we extend this to technologies, we can say that Oil processing is unlocked by Mechanics.mining.basic-fluid-crude-oil, and that the rocket launch trigger depends on Mechanics.launch.item-name or both Special.launch and Item.item-name, depending on how it's implemented in-game.
Beacon transmission effectivity
For base game beacons, this should be a new array in EntityBeacon
and a relatively simple change to ModuleTemplate.GetModulesInfo
.
YAFC doesn't currently support crafters with multiple types of beacons. My best guess is that for multiple types, a crafter finds all the beacons that affect it and then does beacons.Sum(b => b.profile[beacons.Count] * b.transmissionEfficiency * b.modules.Sum(m => m.effects))
.
Quality Quality is both super simple and super complicated:
data.raw
and generate five items, recipes, or entities.
Module
and most derived types of Entity
.module_category
property, but some categories may only have one module (EI's Guass module, for example) and some mods may have too many categories to be feasible in the dropdown.Select*ObjectPanel
will need an option for a similar row, depending on why things are being selected. It can't be automatic; NEIE and Dependency Explorer never care about quality.Asteroid Collector I hadn't thought about this at all, but my current thought is to treat it like a miner, that produces output from nothing. They have diminishing returns depending on count and variable returns depending on platform speed, but I don't have any good ideas for modelling that. Maybe just a setting and a notice like we currently have for fission reactors? It would be nice to model ammo consumption for breaking larger asteroids, but we don't have any similar models, e.g. energy/ammo consumption for killing biters, or repair pack consumption for the walls.
Weight :+1:
Fusion Reactor I think this is a separate setting (so fusion and fission can be configured separately) for 1xN or 2xN, along with radio buttons for "rectangular" (max 3 neighbors, as for fission), "offset" (max 4 neighbors) and "staggered" (half have 3 neighbors, half have 5 neighbors).
Spoils I'd overall prefer to ignore this, but one thing that we could do is designating one member of a link as "this member consumes 25% of the total output", to account for 25% spoilage. I haven't thought about how to get the solver to handle this.
Stack Inserter :+1: This probably "just" needs in-engine modelling, along with modelling the inserter improvements in FFF-419.
Planets
I'd put this as low priority work, but it's also work that can be done and tested immediately.
We can implement this for SE (for surface types) or Exotic Industries (for specific surfaces), and it should be pretty accurate to what Space Age will require. In both mods, some resource entities are only present on certain surfaces, and some crafting entities can only be built on certain surfaces. That said, I tried briefly in SE to lock Mechanics.mining.basic-solid.se-holmium-ore
behind Technology.se-rocket-launch-pad
, but the only interesting recipe that uses holmium ore is already locked behind a technology that depends on that technology.
Milestones have to be FactorioObject
s, so "Access to this (type of) surface" would have to be a synthetic FactorioObject
, probably with changes to the dependency analysis to allow another type of dependency.
Additional Productivity
Configuring the productivity techs this will be a pain for the user, but we can just spit out a VirtualScrollList
with one item for each productivity technology, and then alter Product.GetAmount()
to be aware of those settings and use the right one. (per-item is easy, per-recipe means each Product
needs to know what Recipe
it belongs to.)
YAFC already uses base_productivity
, but it's probably worth checking to see whether it uses it correctly.
Recycling The recycler is probably a furnace in a trench coat, yes. This will require improved detection of special recipes, so we treat (most) recycling as an item source in the same way that we treat barrel emptying as a fluid source (see #134). The engine could reverse the single-output recipes, but then the recycler would have to figure out whether to decompose SE's Low Density Structure using the initial recipe (copper, steel, plastic, and glass) or the improved recipe (beryllium, steel, plastic, and glass.)
You guys thought of much more changes than I initially had in my mind, very nice! (and very scary, as we need to change quite a bunch of things to make Yafc at least usable, let alone fully covering all the changes...)
I started to comment on your ideas already in my mind, but then realized this becomes messy fast... Should we split this off into separate tickets/discussions first. To stay on topic on each subject?
I would keep it all in this one issue until we have more information about API changes and can start implementing and testing it. Quality definitely deserves its own issue later on, it's just too big. The other topics could be split off when we have more information about API changes, can play around with it in the real game, and the discussion becomes more focused on possible UI changes. I don't know how much sense those detailed discussions make before we know the facts.
Just for keeping track of possible topics that need adaption it's not worth to split this into a multitude of issues, in my opinion.
Module Categories
Via a post by KiwiHawk in the Omni discord, we have news of allowed_module_categories
:
allowed_module_categories
will be a field on every machine that takes modules
This seems like it shouldn't be too hard to implement. It may also help with some of the pY module issues.
As Factorio 2.0 is released (quite soon from a software development point of view), I guess we need to prepare for this as well.
Some of the announced features will have (quite) some impact, I am thinking about Quality for example. For the other things I wonder if the impact is big (or if there is any).
Let's use this ticket to brainstorm a bit and figure out our plans with respect to Factorio 2.0 and maybe make a list of (breaking) changes with impact here?