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:
Sat Mar 07, 2020 1:08 am
Only calculate what's coming in the area and how much it should come out.
Maybe you should re-read your own original post. Are you really calling this not a change and not a simplification?

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

Re: Optimization idea: abstraction

Post by Deadlock989 »

Blockchain. Add some blockchain.

User avatar
darkfrei
Smart Inserter
Smart Inserter
Posts: 2794
Joined: Thu Nov 20, 2014 11:11 pm
Contact:

Re: Optimization idea: abstraction

Post by darkfrei »

netmand wrote:
Thu Mar 12, 2020 4:21 pm
StephenLynx wrote:
Sat Mar 07, 2020 1:08 am
Only calculate what's coming in the area and how much it should come out.
Maybe you should re-read your own original post. Are you really calling this not a change and not a simplification?
The endplayer cannot see any difference, just the production will be precise only near the player, all another stuff just as middle/nominal production speed. Is it really easy?

netmand
Filter Inserter
Filter Inserter
Posts: 262
Joined: Wed Feb 22, 2017 1:20 am
Contact:

Re: Optimization idea: abstraction

Post by netmand »

I'm trying to derive some value out of this. While I don't think abstraction in-of-itself is a good idea, The thought of combining large parts of the factory has some appeal.

I just can't think of a way where this helps UPC. To me this sort of ask will hurt UPC and require more processing power.

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 »

netmand wrote:
Thu Mar 12, 2020 6:33 pm
I'm trying to derive some value out of this. While I don't think abstraction in-of-itself is a good idea, The thought of combining large parts of the factory has some appeal.

I just can't think of a way where this helps UPC. To me this sort of ask will hurt UPC and require more processing power.
It depends on how it’s done. If we use the black box model, you can save a lot of UPS.

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

Re: Optimization idea: abstraction

Post by StephenLynx »

netmand wrote:
Thu Mar 12, 2020 6:33 pm
I just can't think of a way where this helps UPC. To me this sort of ask will hurt UPC and require more processing power.
Instead of processing hundreds of entities like inserters, items, belts, assemblers, you process one thing.

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

Re: Optimization idea: abstraction

Post by Deadlock989 »

You just have to believe.

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:
Thu Mar 12, 2020 8:28 pm
netmand wrote:
Thu Mar 12, 2020 6:33 pm
I just can't think of a way where this helps UPC. To me this sort of ask will hurt UPC and require more processing power.
Instead of processing hundreds of entities like inserters, items, belts, assemblers, you process one thing.
How so? Are you telling the devs to make assemblers that only make Advanced Circuits? How are you connecting them? Are these connections pre-built too? Will they accommodate all permutations of logistical delivery? Of course not, right? Then you are wanting the program to identify and abstract on the fly, tasking the program to build and unbuild these abstractions as needed. All that takes processing power too.

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

Re: Optimization idea: abstraction

Post by StephenLynx »

netmand wrote:
Thu Mar 12, 2020 9:49 pm
How so? Are you telling the devs to make assemblers that only make Advanced Circuits? How are you connecting them? Are these connections pre-built too? Will they accommodate all permutations of logistical delivery? Of course not, right? Then you are wanting the program to identify and abstract on the fly, tasking the program to build and unbuild these abstractions as needed. All that takes processing power too.
Because you can infer the result and you can cache this inferential information. And no, you don't have to account for literally everything in the game. You can limit the cases. I am repeating myself here, read the thread.

Jap2.0
Smart Inserter
Smart Inserter
Posts: 2242
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: Optimization idea: abstraction

Post by Jap2.0 »

I, too, think that if we believe hard enough we can use machine learning to make blockchain-based abstractions.

StephenLynx wrote:
Thu Mar 12, 2020 4:02 pm
netmand wrote:
Thu Mar 12, 2020 3:50 pm
There's a cadre of players that will rebel if the game is made any simpler.
You should read the thread. I opened by saying this wouldn't change anything at all as far as features or mechanics go.
Yet you continue it by saying that we have to make assumptions which we do not know will be true to implement this, thus inherently changing the mechanics.
There are 10 types of people: those who get this joke and those who don't.

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 »

eradicator wrote:
Wed Mar 11, 2020 9:31 am
I'm sorry, but as a modder that is all laughable to be polite. No personal offense meant, i realize you're not a modder and just enthusiastic.
Sorry, but that's quite offensve. I've modded several stuff, helped improving many mods and libs. And wrote a little mod myself.
(Maybe I'm a bit out, of what can be done with a mod, since I have no time for that since 2 years, but the abilities of mods have improved, not declined.)

Of course I know how difficult this is, but to say "impossible" is too simple, after scribling my ideas about it on half a page.
That's just offensive.


Laughable is, how you think that a non-deterministic behavior should be simulated in a game, where nearly everything is about that; it's the essence of Factorio. Devs are with my opinion. (*)

This is a too theoretical discussion, so I deleted my statements to your arguments (some have already been answered), because nobody knows how it really is, until someone tried. Yes, I know that this is far beyond, of what a mod should do (but does anybody mean, this will be implemented into vanilla the next 2-3 years???) and there are many difficulties, but still possible and no need for offense. :)


(*) And to repeat the idea (because I think it's misunderstood):

Detect that part of production, that is deterministic. That is only possible for belt driven production and when that is full production or no production (and some more preconditions). Simulate full production and look, if this fragile deterministic state is left somehow to switch simulation off.

And you might see now (**), this is a kind of game in game to keep that fragile determinism running. And not many would love that, because it is quite complex. But that part of game in game is the only sense I can see in this suggestion, I called that concept "factory streets" and it could be read as fifth post in this thread.

... And it would help, if the devs would implement, that you can turn off complete parts of a factory just by turning the power off (inserters doesn't turn off when unpowered). Because belts are not power driven, the simulated part could recover and simulation can restart.

(**) it is difficulty to see, because it is even a game in game, without the whole optimization stuff: A factory street - in my sense of view - is some factory part, that needs to be marked out and feed with full input belts and there is no full compression on output belts. And in that case this part has an inbuild production/speed/efficiency-bonus.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

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

Re: Optimization idea: abstraction

Post by Deadlock989 »

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.

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

Re: Optimization idea: abstraction

Post by bobucles »

I'm pretty sure we had this discussion a long time ago. The big issue with abstracting the factory out is that you no longer have a factory to look at. It's just a black box with inputs and outputs. You can do the same thing with gigantic magic cheat boxes, but who wants to build their factory out of those?

The closest equivalent is Factorissimo, where you plop down big boxes that have mini factories inside. The only thing that matters on the outside are inputs and outputs. Abstracting it down would basically remove the inner world and not render it at all.

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 12:50 am
Because you can infer the result and you can cache this inferential information. And no, you don't have to account for literally everything in the game. You can limit the cases. I am repeating myself here, read the thread.
Check out your terms: infer, cache, limit. These all take as much if not more processing.
You are also misleading yourself in assuming that I haven't read all posts here. We should progress the discussion into how to make abstraction work, not repeat an idea that doesn't.

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

Re: Optimization idea: abstraction

Post by StephenLynx »

bobucles wrote:
Fri Mar 13, 2020 1:18 pm
The big issue with abstracting the factory out is that you no longer have a factory to look at. It's just a black box with inputs and outputs.
Read the thread. My suggestion doesn't change literally anything as far as the player is aware.

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

Re: Optimization idea: abstraction

Post by StephenLynx »

netmand wrote:
Fri Mar 13, 2020 2:23 pm
Check out your terms: infer, cache, limit. These all take as much if not more processing.
How does a cache uses "as much if not more processing"? You could argue it uses more ram. But how does it uses more processing? Why do you think we have cached shaders, cached web pages both on servers and clients?

And how does a limit would use more processing than not limiting it?

I know I have enough software development experience to talk about the things I am talking about. Do you know enough to refute it?

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

Re: Optimization idea: abstraction

Post by Deadlock989 »

StephenLynx wrote:
Fri Mar 13, 2020 2:26 pm
I know I have enough software development experience to talk about the things I am talking about. Do you know enough to refute it?
There's nothing to refute. It's all just waffle.

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 2:26 pm
How does a cache uses "as much if not more processing"? You could argue it uses more ram. But how does it uses more processing? Why do you think we have cached shaders, cached web pages both on servers and clients?

And how does a limit would use more processing than not limiting it?
Regarding cache:
Adding more data to cache increases processing requirements. The need to "infer" or rather rebuild non-pre-defined entities to represent pieces of the factory, storing them in cache, tracking which parts are abstracted, then merging results with the rest of the unabstracted factory presents another level of processing that is not being accounted for here. You can't treat an abstraction like an assembling machine; a train could be running through it. We still need to measure the production and consumption of the items within the abstraction. Dare I mention, fluid dynamics?

Regarding limits:
We can write a function that yields a result, but if the results need to be limited, the function will also need to check values along the way and add processing to yield results within the limit.

netmand
Filter Inserter
Filter Inserter
Posts: 262
Joined: Wed Feb 22, 2017 1:20 am
Contact:

Re: Optimization idea: abstraction

Post by netmand »

If abstraction as proposed were viable, the result would be a gateway to parallel processing. Which isn't happening. Not for a long time.

So then we're left with abstraction resulting in a simplification...

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

Re: Optimization idea: abstraction

Post by StephenLynx »

netmand wrote:
Fri Mar 13, 2020 3:19 pm

Regarding cache:
Adding more data to cache increases processing requirements. The need to "infer" or rather rebuild non-predefined entities to represent pieces of the factory, storing them in cache, tracking which parts are abstracted, then merging results with the rest of the non-abstracted factory presents another level of processing that is not being accounted for here. You can't treat an abstraction like an assembling machine; a train could be running through it. We still need to measure the production and consumption of the items within the abstraction. Dare I mention, fluid dynamics?

Regarding limits:
We can write a function that yields a result, but if the results need to be limited, the function will also need to check values along the way and add processing to yield results within the limit.
While calculating what has to be added to the cache surely requires processing, it would heavily compensate to the data that doesn't need to be processed anymore due to the optimization. We are talking about dozens and dozens of entities being checked several times per second. Fetching from the cache is trivial because you can index the abstractions by map areas being entered/left. The only merge with the rest of factory that would happen would be putting the abstraction products into a belt. And you can isolate areas that can be treated like some sort of assembling machine. For example: you check if the part being abstracted has to interact with a logistics network. If so, you don't abstract. Mind you, just because you are abstracting entities in an area, that doesn't mean you have to abstract the whole area. It's not hard to see what's interact with what. If the train is just going through the area but doesn't interact in any shape or form with the assemblers, directly or indirectly, then you just ignore the train. And measuring the production and consumption of 1 thing is much faster than processing 30, 100, 200 things. About fluid dynamics, if the flow is consistent, you can still abstract it.

And checking the limit is still faster than processing everything outside that limit in this case. You place something. This something checks if it interacts with something else. If in this interaction group you find something that will not be abstracted, like a combiner, you mark that group as not being able to be abstracted. That is not hard and if you know about that group and you place something else that interacts with the group, you stop right there.

You are ignoring how much stuff is processed every single cycle of the game. Any optimization must be compared against the work that will be saved by the abstraction. But I see lots and lots of people here completely forgetting that and just saying that this abstraction will also require processing. Forgetting all the inserters, all the belts, all the assemblers, all the individual items going around them that have to be processed dozens of times per second. While this abstraction doesn't even have to be calculated immediately. 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.

Post Reply

Return to “Ideas and Suggestions”

Who is online

Users browsing this forum: Bing [Bot], Nosferatu