Optimization idea: abstraction

Post your ideas and suggestions how to improve the game.
netmand
Filter Inserter
Filter Inserter
Posts: 262
Joined: Wed Feb 22, 2017 1:20 am
Contact:

Re: Optimization idea: abstraction

Post by netmand »

StephenLynx wrote:
Fri Mar 13, 2020 5:06 pm
You could just perform the initial calculation on the first time the area is a given distance from vision and that would be it. Reusing that data afterwards would be trivial.
I was hoping to have an academic discussion about your idea of abstraction, and how we could use it to optimize the game. It appears I'm not going to get it. When the idea is challenged, you're just saying the same thing over and over instead of having a working discussion that overcomes challenges put to the idea. While you assert your beliefs and brag about your experience, the reality is very very different.

You must think I'm totally ignorant and must be tired of repeating yourself. So I guess I'll just leave it at that... Except for one parting comment: If you think you can ignore a train, any active part of the factory doesn't interact with the logistic network, and fluid flow can be consistent at all; you are ignoring how much stuff needs to be processed every single cycle of the game.

bobucles
Smart Inserter
Smart Inserter
Posts: 1654
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: Optimization idea: abstraction

Post by bobucles »

My suggestion doesn't change literally anything as far as the player is aware.
Magic makes a lot of things possible. That doesn't mean it's possible. There are existing solutions like clusterio, that's as close as it gets to magic box factory abstraction.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 11423
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Optimization idea: abstraction

Post by ssilk »

Deadlock989 wrote:
Fri Mar 13, 2020 6:37 am
This is just a flood of gibberish.
ssilk wrote:
Fri Mar 13, 2020 5:59 am
Detect that part of production, that is deterministic.[
It is literally all deterministic. Because if any part of it wasn't then none of it would be. That's what deterministic means.
Well, I mixed deterministic for "calculateable". You can calculate the throughput of a belt based construction for maximum filled belts quite precise. Versus you cannot do that if you want to calculate the throughput if the belts are below the maximum filled, because the throughput then will flutter too much.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

Zanthra
Fast Inserter
Fast Inserter
Posts: 119
Joined: Fri Mar 25, 2016 8:18 am
Contact:

Re: Optimization idea: abstraction

Post by Zanthra »

If you have a set of assemblers making red science from iron plates and copper plates, what is the method to provide the abstraction.

The challenge I see is how to determine the state of the intervening iron gear belt from a given tick in the future. Say the player walks away from the factory, it gets abstracted away, but then they come back and decide they need iron gears for something, and are coming to the red science to pilfer them from the belt. When and how is the exact position and number of iron gears sitting on the intervening belt calculated. If you know of a way to do that from a given time in the future, cheaper than actually simulating the production of the iron gear assemblers and the consumption of the red science assemblers, along with the timing of inserter arms and the like, then there may be potential here.

StephenLynx
Inserter
Inserter
Posts: 31
Joined: Thu May 04, 2017 10:55 pm
Contact:

Re: Optimization idea: abstraction

Post by StephenLynx »

Zanthra wrote:
Fri Mar 13, 2020 7:36 pm
If you have a set of assemblers making red science from iron plates and copper plates, what is the method to provide the abstraction.
You see how many buffered inputs you can have and at which point these inputs turn into a subproduct, like the gears. When you stop the simulation, you place the buffered inputs further from the end as possible to avoid rushing the production. Then you also see how long does it take for items to start coming out of the simulation and add that as a buffer for finished products. The rest is just producting items in the same rate with the same productivity bonus.

You don't need to place the gears and iron plates exactly where they would be, you only need to place them somewhere the production wouldn't be sped up.

Zanthra
Fast Inserter
Fast Inserter
Posts: 119
Joined: Fri Mar 25, 2016 8:18 am
Contact:

Re: Optimization idea: abstraction

Post by Zanthra »

So to be clear, your abstraction would not 100% match the factorio simulation since walking away and returning after some time, objects on belts would not be in the same location as if you stayed in visual range of them the whole time?

Nemo4809
Long Handed Inserter
Long Handed Inserter
Posts: 94
Joined: Thu Jan 16, 2020 10:49 am
Contact:

Re: Optimization idea: abstraction

Post by Nemo4809 »

Zanthra wrote:
Sat Mar 14, 2020 2:37 am
So to be clear, your abstraction would not 100% match the factorio simulation since walking away and returning after some time, objects on belts would not be in the same location as if you stayed in visual range of them the whole time?
IMHO a 100% match isn’t necessary. A less efficient throughput replacement is acceptable.

This way players can’t use it to cheat. When they choose to use the abstraction, they are choosing to sacrifice throughput for UPS efficiency.

Zanthra
Fast Inserter
Fast Inserter
Posts: 119
Joined: Fri Mar 25, 2016 8:18 am
Contact:

Re: Optimization idea: abstraction

Post by Zanthra »

I didn't say it was necessary, I just want to be clear on what we are talking about here. Sacrificing accuracy for speed is an interesting trade-off, but a completely different discussion than the challenges of how to make an accurate abstraction without actually running the whole simulation.

StephenLynx
Inserter
Inserter
Posts: 31
Joined: Thu May 04, 2017 10:55 pm
Contact:

Re: Optimization idea: abstraction

Post by StephenLynx »

Zanthra wrote:
Sat Mar 14, 2020 2:37 am
So to be clear, your abstraction would not 100% match the factorio simulation since walking away and returning after some time, objects on belts would not be in the same location as if you stayed in visual range of them the whole time?
If you are taking a more loose approach, yes. Otherwise you could only simulate when all the inputs are 100% saturated and everything is already as buffered as possible. That way you always know where things would be when you stop simulating. But I think anything that wouldn't make a difference if all the inputs are fully saturated for a while after the simulation is stopped is acceptable.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1991
Joined: Fri Nov 06, 2015 7:41 pm

Re: Optimization idea: abstraction

Post by Deadlock989 »

Goalposts successfully moved. Suddenly we're talking about factories getting a bit more shit if they move off screen. Brilliant.

So we've now successfully transitioned from "You can magically do everything, literally everything, much cheaper at 100% verisimilitude for absolutely zero extra processing cost and exactly the same end results" to "You can maybe do some very specific things cheaper sometimes but only if they involve fully compressed belts in absolutely ideal situations, and only if you literally avert your eyes from it, and only if you accept a massive loss of accuracy".

I mean, Wube could actually turn it into a selling point. "Factorio - the Night At The Museum Edition. Build your factory in Schrödingeresque hellscape where everything behaves differently when no-one is looking. Featuring deep strategy: choose exactly which belt to stand over because you want it to work better."

Zanthra
Fast Inserter
Fast Inserter
Posts: 119
Joined: Fri Mar 25, 2016 8:18 am
Contact:

Re: Optimization idea: abstraction

Post by Zanthra »

StephenLynx wrote:
Sat Mar 14, 2020 3:03 am
Zanthra wrote:
Sat Mar 14, 2020 2:37 am
So to be clear, your abstraction would not 100% match the factorio simulation since walking away and returning after some time, objects on belts would not be in the same location as if you stayed in visual range of them the whole time?
If you are taking a more loose approach, yes. Otherwise you could only simulate when all the inputs are 100% saturated and everything is already as buffered as possible. That way you always know where things would be when you stop simulating. But I think anything that wouldn't make a difference if all the inputs are fully saturated for a while after the simulation is stopped is acceptable.
Even with compressed belts it is challenging to know what state the system will be in some number of ticks in the future. This is why in relation to the red science assembler setup: When and how is the exact position and number of iron gears sitting on the intervening belt calculated? For a perfect abstraction, one that can substitute for the actual simulation with no noticeable effects, it has to be 100% identical for any tick in the future you want to deabstract it at.

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 1105
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: Optimization idea: abstraction

Post by boskid »

Deadlock989 wrote:
Sat Mar 14, 2020 9:46 am
I mean, Wube could actually turn it into a selling point. "Factorio - the Night At The Museum Edition. Build your factory in Schrödingeresque hellscape where everything behaves differently when no-one is looking. Featuring deep strategy: choose exactly which belt to stand over because you want it to work better."
and "due to latency (in MP), game state does not yet know you are watching here, but since you are watching, we will produce some broken graphics of assemblers maybe working but not really, so please choose if you want latency hiding or nice graphics in all cases"

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 4361
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Optimization idea: abstraction

Post by eradicator »

Zanthra wrote:
Sat Mar 14, 2020 11:11 am
a perfect abstraction, one that can substitute for the actual simulation with no noticeable effects, it has to be 100% identical for any tick in the future you want to deabstract it at.
Oh yea. You just need to know the exact starting state and then you can tell the abstraction to calculate the exact state it will have 1 tick later! It wouldn't even be slower than what we have now!

___
On a much much smaller scale, theorecically. If an assembler had an energy buffer of n>1 ticks. Would there be any relevant benefit in incrementing the crafting process only every n ticks instead of every tick? Sort of a "working sleep mode".
Author of: Hand Crank Generator Deluxe, Screenshot Hotkey 2.0, /sudo
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
Klonan
Factorio Staff
Factorio Staff
Posts: 4518
Joined: Sun Jan 11, 2015 2:09 pm
Contact:

Re: Optimization idea: abstraction

Post by Klonan »

eradicator wrote:
Sat Mar 14, 2020 11:41 am
On a much much smaller scale, theorecically. If an assembler had an energy buffer of n>1 ticks. Would there be any relevant benefit in incrementing the crafting process only every n ticks instead of every tick? Sort of a "working sleep mode".
Sure, it would work, but the assembling machine update is pretty much just 'increment the recipe progress', so it already doesn't take very much time to update at all.

The things that are worth optimizing are the complex things that interact with other entities,
Inserters, Units, Pipes, etc.

And those can't be optimized by a simple `update every n ticks` system

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 874
Joined: Wed Jul 12, 2017 5:45 pm
Contact:

Re: Optimization idea: abstraction

Post by Oktokolo »

Not even beacons are easy to abstract, it seems...

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 4361
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Optimization idea: abstraction

Post by eradicator »

Klonan wrote:
Sat Mar 14, 2020 12:26 pm
eradicator wrote:
Sat Mar 14, 2020 11:41 am
On a much much smaller scale, theorecically. If an assembler had an energy buffer of n>1 ticks. Would there be any relevant benefit in incrementing the crafting process only every n ticks instead of every tick? Sort of a "working sleep mode".
Sure, it would work, but the assembling machine update is pretty much just 'increment the recipe progress', so it already doesn't take very much time to update at all.
Yea. I was just pondering the "Schrödingeresque" idea by @deadlock. Wondering if it's possible to completely remove the recipie incrementation when nobody is looking. Which depending on the recipe duration and scale of the factory migth have been interesting (beacon-less assemblers wouldn't be more expensive than speed-beaconed ones anymore?), but i guess when inserters start adding/removing stuff to the inventory the assembler has to wake up anyway?
Klonan wrote:
Sat Mar 14, 2020 12:26 pm
The things that are worth optimizing are the complex things that interact with other entities,
Inserters, Units, Pipes, etc.

And those can't be optimized by a simple `update every n ticks` system
Yes. Perfectly clear. I specifically asked for the assembler because it's a perfectly closed system during crafting. Other such systems might be inserters while they're "in swing" (but that would be visible). Assembler and mining drills seem to be the only machines where you wouldn't see the resulting "jumpiness" of the internal progress without opening the gui.

Anyway thanks for confirming that the benefit is too small ;).
Author of: Hand Crank Generator Deluxe, Screenshot Hotkey 2.0, /sudo
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

Sopel
Long Handed Inserter
Long Handed Inserter
Posts: 51
Joined: Mon Sep 24, 2018 8:30 pm
Contact:

Re: Optimization idea: abstraction

Post by Sopel »

Factorio doesn't update assembler progress every tick. Just when product is made or something else happens. At least that what one of the devs told me on reddit when I brought up the topic.

As for the "abstraction".
To even make it feasible I think it would require the user to specify an area and the graphics to be changed to not reflect the internal state, like a warehouse or something.
The big problem though is how to produce stuff. For a simple case it could calculate max rate and output items based on proportion of input items. Though in general it's problematic for many reasons:
- You CANNOT simulate the build to see whether it will work forever and never stop. If belts are turing complete (i think there was a post on reddit where someone made logic gates with belts and splitters) you cannot do it in general in any way.
- The build may have different parts that produce different items based on how many items you supply. For example having an overflow when there's >80% of some fluid going into something else.
- The general performance depends on small stuff, like for example on which side of the belt items are being input.
- Circuit networks in general are impossible to abstract because circuits are turing complete.

The only solution I see is having predefined entities that skip steps, but it sounds like a pain to balance and may impact immersion. Mods are for that.
One could also make something more dynamic based on heuristics like from Max Rate Calculator but it would be broken by design.

edit.
Having recipes which take more and produce more in one iteration would already help with UPS a bit. See https://mods.factorio.com/mod/SchallRecipeScaling But it has to be opt-in as it increases latency

Rseding91
Factorio Staff
Factorio Staff
Posts: 11354
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Optimization idea: abstraction

Post by Rseding91 »

Sopel wrote:
Sun Mar 15, 2020 4:29 pm
Factorio doesn't update assembler progress every tick. Just when product is made or something else happens. At least that what one of the devs told me on reddit when I brought up the topic.
Yes it does and always has.
If you want to get ahold of me I'm almost always on Discord.

Eketek
Inserter
Inserter
Posts: 37
Joined: Mon Oct 19, 2015 9:04 pm
Contact:

Re: Optimization idea: abstraction

Post by Eketek »

Seems to me that the there are a few potential optimizations closely related to the topic which might be a bit more realistic for common cases:

There may be performance to gain simply by identifying factory modules which are isolated from the rest of the factory and processing them separately from the chunks they occupy.

If a factory module is exhibiting highly periodic behavior (every entity in the module performs the exact same sequence of actions on a recurring basis), then updates can be performed by capturing a complete cycle (or computing it on another thread) and re-playing that until something interferes.

Frosti85
Manual Inserter
Manual Inserter
Posts: 4
Joined: Thu May 14, 2020 11:08 am
Contact:

Re: Optimization idea: abstraction

Post by Frosti85 »

I had the same idea, but then I realized how pointless this would be.

Imagine now you have this abstracted green chip factory, which makes like 1k green chips per minute, whatever.

Now you can place many ob these blackbox factories.

But in the end, you will be playing the same game, just that you have multiplied all the numbers by a factor of 1000. It would be totally pointless.

You could just change all the items, so that 1 green chip would become 1000 green chips.

That would be the end result of this.

You already have the blackbox green chip factory. It's called the assembler. It makes 1 green chip out of some ingredients, in a black box way.

The end result of the abstraction you suggested, would be to just increase the numbers.

This would only work for very basic factories without any circuit logic or more complex stuff. And these basic factories are basically assemblers in the end.

It would just increase the numbers.

Post Reply

Return to “Ideas and Suggestions”

Who is online

Users browsing this forum: No registered users