[Request]: An entity that can mimic an amount of combinators

[logaritm]

Well this is not really a request and more of a question if it is possible, anywho what i was thinking is something like first you plop down an entity that functions in the same way as Factorissimo building and inside it you build a combinator network, when done you somehow "save" the content and after you can make more entities that perform the same function as the combinator network but can't be "opened" and changed, in a way it's kinda like designing and then building circuit boards.

[Deadlock989]

My gut reaction, without investigating it properly, is that it could be possible but will be quite unfriendly for performance. There's Factorissimo which uses mini-surfaces and then there have been a few different wireless combinator mods, this idea is sort of a blend of the two. They're all very resource-hungry. The wireless mods I've looked at work by maintaining lists of inputs and outputs (or senders and receivers) and have to trawl through them on-tick or on-Nth-tick, which might be fine for a handful of "circuit boxes" but won't scale well, and they've all had quite severe limitations compared to real circuit networks. Let's say you made a box which has all the combinators to make an RS-latch inside - for every new instance of a box that you plonk down, there'd have to be another copy of the original surface and another set of inputs and outputs on the global list. It would be difficult and maybe memory-hungry and not great for UPS. Factorissimo is already demanding enough but you might reasonably want to place tens or hundreds times more circuit boxes than entire assembly plants. There are probably data structures suited to this sort of thing which might be an improvement on previous attempts, but ultimately anything done with Lua scripting is going to start chugging sooner than you'd probably like.

Would be awesome to have better support for this kind of thing in the API - e.g. the ability to "fix" an entity's connection to a very distant circuit network or one that's not even on the same surface - but it's quite a big thing to ask for and I get the feeling that there's not much room for it, if any, on the current roadmap.

[eradicator]

I actually built an experimental "black box combinator" mod once which did exactly that. But abandoned it because in the end i didn't like the idea of not being able to open it up again after blueprinting.

@Deadlock:
No lua code required. You just take a blueprint and set all the entity positions to {0,0}. So performance is equal to vanilla combinator network of the same size and composition. No on_tick or anyhting.

[logaritm]

I actually built an experimental "black box combinator" mod once which did exactly that. But abandoned it because in the end i didn't like the idea of not being able to open it up again after blueprinting.

you should have followed up on it, and i think that not being able to access the box after saving is a good balance trade off as long as you can build functioning copies

[logaritm]

[quote="eradicator"]I actually built an experimental "black box combinator" mod once which did exactly that. But abandoned it because in the end i didn't like the idea of not being able to open it up again after blueprinting.

@Deadlock:
No lua code required. You just take a blueprint and set all the entity positions to {0,0}. So performance is equal to vanilla combinator network of the same size and composition. No on_tick or anyhting.[/quote]

you happen to have that code laying around?

[eradicator]

you should have followed up on it, and i think that not being able to access the box after saving is a good balance trade off as long as you can build functioning copies

I don't care for that type of unusability "balance". It makes blueprints virtually useless for sharing. And besides that is by far not the only problem left to solve for that concept. And the saying goes "the last 10% of the work requires 90% of the time" ;). I do have the code, but it's too messy to share. It does exactly what i explained above though. Edit entity positions in a blueprint and replace combinators with non-colliding version.

[thelordodin]

My gut reaction, without investigating it properly, is that it could be possible but will be quite unfriendly for performance. There's Factorissimo which uses mini-surfaces and then there have been a few different wireless combinator mods, this idea is sort of a blend of the two. They're all very resource-hungry. The wireless mods I've looked at work by maintaining lists of inputs and outputs (or senders and receivers) and have to trawl through them on-tick or on-Nth-tick, which might be fine for a handful of "circuit boxes" but won't scale well, and they've all had quite severe limitations compared to real circuit networks. Let's say you made a box which has all the combinators to make an RS-latch inside - for every new instance of a box that you plonk down, there'd have to be another copy of the original surface and another set of inputs and outputs on the global list. It would be difficult and maybe memory-hungry and not great for UPS. Factorissimo is already demanding enough but you might reasonably want to place tens or hundreds times more circuit boxes than entire assembly plants. There are probably data structures suited to this sort of thing which might be an improvement on previous attempts, but ultimately anything done with Lua scripting is going to start chugging sooner than you'd probably like.

Would be awesome to have better support for this kind of thing in the API - e.g. the ability to "fix" an entity's connection to a very distant circuit network or one that's not even on the same surface - but it's quite a big thing to ask for and I get the feeling that there's not much room for it, if any, on the current roadmap.

You've made some really great mods and maybe you can do this one.
I have a tested idea how can this be made with perfomance equal to native combinators. But I don't have time to implement it.

There is just one think which caused perfomance issues in factorio: on_tick event.
If a mod don't have on_tick event then most likely it won't hurt perfomance at all.

Factorissimo IS bad at it because it transfers goods from/to factory in on_tick event.

Here are features of my implementation idea for combinators:
- Best perfomance equals to vanilla combinators
- Can be as balanced as vanilla
- Very user-friendly

Here is the implementation idea:
- Make an invisible copy of each combinator prototype with special collision mask which allows placing any number of entities into one cell (see attachment)
- There should be an entity "Compound combinator" inherited from Programmable speaker
- When you click on "Compound combinator" you are teleported to other temporary surface (like in Factorissimo).
- You can implement any layout inside it
- The surface should be created one per player. Layout in surface should be stored in compound combinator (see explanation below)

Now
- When you go out of it all your layout is rebuild with invisible combinators. And is connected the same way you did it.
And is located in the same tile that "Compound combinator" is.

- There should special entities "Compound combinator input" and ""Compound combinator output" most likely inherited from inserter - to be able to set an icon to it.
- With a special button you can show or hide inputs and outputs.
- When you show inputs and outputs - they are autoconnected to invisible combinators in layout and they can be manually connected to any other entities.
Inputs and outputs should be named, when you show them (there are ways to show text - i've seen sticky notes mod, but i didn't looked through code to figure out how exactly)
- When hidden - they are just invisible power poles. So you basically move them into the same cell.

Blueprints and layout storage:
I've tested this! (on v0.16.16): Programmable speaker is able to store AT LEAST 1 megabyte of any data in it's Alert message property.
So...
You can basically scan all the layout inside "editor" surface and than save it as text into that property.
And it's copied into blueprint... and is replicated with it.
- Of cource there is abolutely no problem to recreate the layout exactly as it was in editor surface from the text stored inside Programmable speaker entity
- This all is possible only just now - when Programmable speaker was introduced. It's a VERY unique entity for modders as there was no way back in v0.15 to store arbitary string data in entity: only programmable field have a field with type string
And it's really great that string size really big (seems like unlimited).

I called it invisible combinators.
Here is my source code, (you and others can use in any form you like - no licence obligations)...
And also a save file if it can help you to figure out what I'm speaking about.
It's not a finished mod, not even an alpha version... And I dont have time to finish in next 3-6 month at least, sorry... But maybe someone can.

Also if anyone wants to and have time to implement the mod - don't hestate to ask (here or pm), I'll try to answer and explain my sources or implemention details.

[eradicator]

@thelordodin
Yea, that was pretty much my approach, except for a few details like an editing surface (one is sufficient). Didn't test the speaker capacity, but 1M would be enough for many things i guess. That might be enough to push it into "barely usable" territory (personally i wouldn't call it "very user friendly" yet).

Btw you should add a free license if you want your code to be used (MIT maybe?). Just saying "no license" is so...fuzzy.

[thelordodin]

By the way, this is not the first time this moding idea was suggested: viewtopic.php?f=6&t=21928
That would be great if there was a poll for voting for mod ideas to be implemented.

@thelordodin
Yea, that was pretty much my approach, except for a few details like an editing surface (one is sufficient). Didn't test the speaker capacity, but 1M would be enough for many things i guess. That might be enough to push it into "barely usable" territory (personally i wouldn't call it "very user friendly" yet).

Why "barely useful"? I can't imagine future where Factorio team just abandons current architecture and go into entity framework approach (like Artimis or alike) and we get fine grained API where you can explicitly create "An entity, movable, with 2 inventories, circuit connection etc"
I did asked several times for a way to save data with entities
But each time its just abandoned (no answer).
Proof:
viewtopic.php?f=28&t=56007
viewtopic.php?f=25&t=49632
viewtopic.php?f=28&t=40510
viewtopic.php?f=28&t=49709
viewtopic.php?f=28&t=14898&p=213571
So it doesn't seem to change ever.

So I see only two possible futures: someone makes the mod this or simmilar hacky way or all just wait till it's changed forever.

@thelordodin
Btw you should add a free license if you want your code to be used (MIT maybe?). Just saying "no license" is so...fuzzy.

Ok, i've added this: http://unlicense.org/.

@eradicator
Do you thoughts about why that's hard/impossible to implement the mod this way other? (other than that using programmable speaker for that looks very odd)

[eradicator]

Why "barely useful"?

Because that's just my opinion. I don't like mods where you can see the hackiness from outside ;).

I did asked several times for a way to save data with entities
But each time its just abandoned (no answer).

I feel your pain. Infact i'm in one of those threads :P.

So I see only two possible futures: someone makes the mod this or simmilar hacky way or all just wait till it's changed forever.

You said yourself you don't have the time, and i don't have enough interest in the idea to polish it to my standards :P. So option 2 until someone who really wants to do this shows up, or until paid modding becomes a thing ;).

@eradicator
Do you thoughts about why that's hard/impossible to implement the mod this way other? (other than that using programmable speaker for that looks very odd)

I don't understand the question, the grammar is just too broken. Feel free to rephrase. Why is what hard?