Deadlock989 wrote: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.