[MOD 0.15] Circuit Network Switch

[theRustyKnife]

Circuit Network Switch

Description:

Basically what the power switch does but with circuit network. It works literally like connecting and disconnecting two networks with wires, just automatically based on a circuit condition.

Details:

• Name: Circuit Network Switch
• MOD Version: 0.2.0
• Factorio Version: 0.15
• Latest Release: 24.04.2017
• Website: https://mods.factorio.com/mods/theRusty ... ork-switch
• Author: theRustyKnife
• License: MIT

This thread is meant for questions and discussion only - please post bugs and suggestions on the mod portal or GitHub. Thanks


Downloads on the mod portal

Changelog

##0.2.0##
* Updated for Factorio 0.15

##0.1.6##
+ Added icon

##0.1.5##
+ Added base dependency
+ Allowed rotation and added vertical sprites
* Reversed the order of changelog to prevent unnecessary scrolling

##0.1.4##
+ Added some sprites (bastardized deciders)
* Fixed a crash?

##0.1.3##
* Switches don't emit light when on anymore
* Reduced energy usage to 1kW to match the other combinators
* Performance improvement

##0.1.2##
* Minor performance improvement

##0.1.1##
+ Added proper recipe and tech
+ Added locale

##0.1.0##
+ Initial release

[theRustyKnife]

Version 0.1.6 is released:
+ Added icon

[vipm23]

Does this connect input all wires to output all wires, or does it only connect red to red and green to green? Or is something else?
Are the middle connections the ones that control the switch?

[theRustyKnife]

Does this connect input all wires to output all wires, or does it only connect red to red and green to green? Or is something else?
Are the middle connections the ones that control the switch?

Yes, the center is what controls the switch.
The other two connection points are connected red-to-red and green-to-green.
Cheers TRK

[theRustyKnife]

Version 0.2.0 released.
Changes:
* Updated for Factorio 0.15

[Nightinggale]

I found one or two bugs related to blueprints.

I figured out a way to make a memory cell out of two switches and a decider combinator. After confirming that it works as intended in my setup (might need update signal to be present for more than one tick) I made a blueprint and started placing more and that's when the problems started.

Bots will not place the switches. All other entities are placed as intended. Might need a line or two to unlock bot placement.

When I manually place them on ghosts, only the center tile works. The two ends will not accept wire connections. This is likely the reason why bots fail to place wires as well.

Mining and placing on empty land (no ghosts) will make them work as intended.


The switch is awesome when it works. It really simplifies a bunch of signal logic, which in turn means less tick delays and easier to not get lost in your gigantic combinator maze.


Another thing. I wonder how hard it would be to convert this into a memory module of it's own. Something like giving it an A and B end and onTick it copies the signals from A to B if the center condition is true. If the center condition is false, then maintain the signals on B. I thought about hacking a decider combinator to do this, but having data input and enable signal on different wires is significantly better in many cases and you can connect input to control if you only need one wire, making it a one entity fits all cases memory entity.

[theRustyKnife]

Quote

I found one or two bugs related to blueprints.

I figured out a way to make a memory cell out of two switches and a decider combinator. After confirming that it works as intended in my setup (might need update signal to be present for more than one tick) I made a blueprint and started placing more and that's when the problems started.

Bots will not place the switches. All other entities are placed as intended. Might need a line or two to unlock bot placement.

When I manually place them on ghosts, only the center tile works. The two ends will not accept wire connections. This is likely the reason why bots fail to place wires as well.

Mining and placing on empty land (no ghosts) will make them work as intended.


The switch is awesome when it works. It really simplifies a bunch of signal logic, which in turn means less tick delays and easier to not get lost in your gigantic combinator maze.


Another thing. I wonder how hard it would be to convert this into a memory module of it's own. Something like giving it an A and B end and onTick it copies the signals from A to B if the center condition is true. If the center condition is false, then maintain the signals on B. I thought about hacking a decider combinator to do this, but having data input and enable signal on different wires is significantly better in many cases and you can connect input to control if you only need one wire, making it a one entity fits all cases memory entity.

Hi,
The blueprint situation is actually fairly complicated and will likely require me to rewrite a lot of the code... That doesn't go along very well with my time schedule, which is really full lately, even without accounting for the immense amount of work that had piled up (again) for Factorio mods.
Thank you for the detailed report tho, it's certainly going tobe help once I get around to fixing it.

As for the memory cell idea, I do quite like it - I can imagine many scenarios where it would be helpful. However, I can see some issues with the implementation of such system:

- The output would have to be made using a constant combinator, which can only have a fixed number of slots - that would mean that there would either be an upper limit on how many signals the cell can store or the combinator would have obscene number of output slots, which is (unless something has changed since 0.14) really slow to work with.
- It would probably be quite important to make the update cycle run every tick (similar to this mod), but with the amount of slow API calls this concept would probably need, it would be hard to maintain some decent framerate once many cells are placed.

It sounds like a good challenge, but obviously, I'm first going to focus on my existing mods, some of which (like this one) are terribly neglected at this point

Cheers TRK

[Nightinggale]

As for the memory cell idea, I do quite like it - I can imagine many scenarios where it would be helpful. However, I can see some issues with the implementation of such system:

- The output would have to be made using a constant combinator, which can only have a fixed number of slots - that would mean that there would either be an upper limit on how many signals the cell can store or the combinator would have obscene number of output slots, which is (unless something has changed since 0.14) really slow to work with.
- It would probably be quite important to make the update cycle run every tick (similar to this mod), but with the amount of slow API calls this concept would probably need, it would be hard to maintain some decent framerate once many cells are placed.

I'm not certain it would be such a problem. I tried doing a bit of research and while I failed to find official documentation for this specifically, I get the impression that the API has read and write wire signals and that they are given as arrays of (signal name, int) objects. This means it might be as simple as have onTick and if the control condition is true, read input and then assign that array to output.

If output stays the same if not updated with an API call:
Do nothing if control is false
Possibly cache output and only update if input is different from cache. It's possible this can help the game's internal wire cache.

If output is lost if not updated every tick:
output cached array

Since it's all about moving an array, the code doesn't have to consider the number of signals. Besides it seems that the number of signal slots in a constant combinator is an int set in the GUI code. If moving everything would demand too many resources, vanilla decider combinators wouldn't have the output signal "everything".

I looked at AAI programmable structures at some point and it has clearly marked wire read and write code. It's still on my TODO list to go back there and dig deep into the details. Obviously if you are uncertain of how it's done, looking at a mod where you know it's working is not a bad approach

[theRustyKnife]

Quote

As for the memory cell idea, I do quite like it - I can imagine many scenarios where it would be helpful. However, I can see some issues with the implementation of such system:

- The output would have to be made using a constant combinator, which can only have a fixed number of slots - that would mean that there would either be an upper limit on how many signals the cell can store or the combinator would have obscene number of output slots, which is (unless something has changed since 0.14) really slow to work with.
- It would probably be quite important to make the update cycle run every tick (similar to this mod), but with the amount of slow API calls this concept would probably need, it would be hard to maintain some decent framerate once many cells are placed.

I'm not certain it would be such a problem. I tried doing a bit of research and while I failed to find official documentation for this specifically, I get the impression that the API has read and write wire signals and that they are given as arrays of (signal name, int) objects. This means it might be as simple as have onTick and if the control condition is true, read input and then assign that array to output.

If output stays the same if not updated with an API call:
Do nothing if control is false
Possibly cache output and only update if input is different from cache. It's possible this can help the game's internal wire cache.

If output is lost if not updated every tick:
output cached array

Since it's all about moving an array, the code doesn't have to consider the number of signals. Besides it seems that the number of signal slots in a constant combinator is an int set in the GUI code. If moving everything would demand too many resources, vanilla decider combinators wouldn't have the output signal "everything".

I looked at AAI programmable structures at some point and it has clearly marked wire read and write code. It's still on my TODO list to go back there and dig deep into the details. Obviously if you are uncertain of how it's done, looking at a mod where you know it's working is not a bad approach

I think you misunderstood me a bit - There's not much of a problem for me to write the code (apart from the lack of time), I know pretty well how to implement it.

Disclaimer: The last time I tested the following things was somewhere in the 0.13/0.14 era, so they might have changed since then.

What I'm concerned about is the interface between Lua and C++. When the cell would be in write mode, there are certainly at least a couple API calls that would have to be made every single tick only to get the signals from the input circuit network. I don't know about any way to check if the signals on that network have changed since the last tick, that wouldn't require accessing LuaCircuitNetwork.signals on the input. Furthermore, there are no events for wire connection/disconnection, so you would have to actually call LuaControlBehavior.get_circuit_network to obtain the current LuaCircuitNetwork. Also, all of that would have to be done twice - once for each wire!

Then there's the output. That could potentially be made less intense by only setting the signals that need to be set, depending on how much faster would the check be over just setting it no matter what. The check would also add some overhead to the cases where it actually has to be set, so that would have to be considered as well. Same as the input, it will only be necessary to run this when the cell is in write mode, but it will have to run every tick when it is.

Also, AAI doesn't have to run it's code every tick, which makes it much easier to maintain good performance. Since with combinators you often need exact timing, you can't wait for a memory cell to update at some point, considering that there wouldn't even be any status indication or anything. That is the same reason why this mod updates every switch on every tick (and also why the update script is kind of unreadable ).

TL;DR: Coding is not an issue, performance might be.

That being said, it's certainly not something that would stop me from at least trying it out, but I do like to mention the downsides upfront, just to be clear. Once I get all my mods up to date, I'll give this a shot (unless someone does so before then) and maybe it'll turn out well .

Cheers TRK

[theRustyKnife]

I feel silly now

Reading that post again made me realize that the solution to all the problems is actually rather simple: Just connect the input to the output with wires when the cell is in write mode, similarly to how this mod does it. Then only set the output to what's on the input when write mode switches off and clear it when it switches back on.
Yes, if you were to rapidly toggle write mode on and off, it would still be very performance heavy, but I think that's acceptable.

Cheers TRK

[Nightinggale]

I wonder about the timing in that approach. Say we have a unit scanner running in a loop and it displays info for miners for one tick. We put up a memory module, which triggers on minerID == 4. The loop reaches ID 4 and next tick it's ID 5. Now comes the questions: when will the output be updated and will it contain the data from miner 4 or 5 once it goes to display the memory?

Perhaps the answer to the question isn't the most important, but rather the fact that we know the answer and can plan combinator setup accordingly. For instance if it stores ID 5 and we really want to store ID 4, then we can set up a combinator to always output everything in front of the data input, which would create a lag of one tick on the input relative to the control input. What's really important is that we can predict what it will do and it's not sometimes 4 and sometimes 5.

A memory, which only really use CPU power when it switches on or off sounds awesome for some setups. First thing, which comes to my mind is input for crafting combinators. Assembler production starts over whenever a new signal turns up, meaning to get a decent productivity, the input should freeze for ideally minutes, or 10k+ ticks.

However I can't think of a situation where low CPU power in on state is beneficial. Why use memory, if it's overwritten all the time?

[Nightinggale]

I have an idea for an improvement, which I could really use. Add a checkbox to invert the control signal for each wire. Right now a wire is connected

Code: Select all

if (control == true)

Replace that with

Code: Select all

if ((control == true and checkbox == false) or (control == false and checkbox == true))

This will allow setups like green is connected on true while red is connected on false (or the other way around), meaning you can connect both to the same combinator and then decide which circuit to use for that combinator.

Right now I use two switches for this, each with just one wire connected. It use up a lot of space and is a hassle to set up. Even worse it has a not insignificant risk of not having the right trigger condition on both, which results in combinator logic bugs.

[infinitysimplex]

Hi there /

I found one or two bugs related to blueprints.

I figured out a way to make a memory cell out of two switches and a decider combinator. After confirming that it works as intended in my setup (might need update signal to be present for more than one tick) I made a blueprint and started placing more and that's when the problems started.

Bots will not place the switches. All other entities are placed as intended. Might need a line or two to unlock bot placement.

When I manually place them on ghosts, only the center tile works. The two ends will not accept wire connections. This is likely the reason why bots fail to place wires as well.

I've read in the forums that blueprints do not allow overlapping ghost entities. Since the end connectors are ghosts, and the middle part also becomes a ghost when blueprinted, the connector-ghosts cannot be placed, I guess. If you "just"need a blueprintable setup, no matter the size, see below.

I have an idea for an improvement, which I could really use. Add a checkbox to invert the control signal for each wire. Right now a wire is connected

Code: Select all

if (control == true)

Replace that with

Code: Select all

if ((control == true and checkbox == false) or (control == false and checkbox == true))

This will allow setups like green is connected on true while red is connected on false (or the other way around), meaning you can connect both to the same combinator and then decide which circuit to use for that combinator.

That's called a "multiplexer": https://en.wikipedia.org/wiki/Multiplexer

Right now I use two switches for this, each with just one wire connected. It use up a lot of space and is a hassle to set up. Even worse it has a not insignificant risk of not having the right trigger condition on both, which results in combinator logic bugs.

You can implement that with just one switch:

Multiplexer made from one switch and one arithmetic combinator.

Switch-Multiplexer.jpg (234.7 KiB) Viewed 11040 times

In words: Say you have two incoming wires, "Red" (in my screenshot, the wire from the chest on the top left) and "Green" (from bottom left). You want the switch to multiplex between them.
First, connect Red to the input of the switch. Connect Green to an arithmetic combinator that multiplies "Each" with -1 and outputs "Each" (in other words, it inverts all signals from that wire). Connect its output to the input of the switch as well, but with the same wire colour as Red.
On the output side, connect the output of the switch to your target (in my setup, the requester chest). Also connect the original wire from Green to your target. It has a different colour than the switch output, so Green's souce signals will not be "contaminated" (otherwise, you'd get a negative feedback cycle). The signals from both output wires need to be added, but combinators, requester chests etc. do that automatically. So for these applications, this solution is one combinator smaller than your two-switch-solution. But it's pretty annoying to set up, so I wouldn't do it, unless you really need that space.

If you just want blueprintable solutions, here you go:

Multiplexer:

Multiplexer made from vanilla combinators only.

Combinator-Multiplexer.jpg (332.17 KiB) Viewed 11040 times

Blueprint string:

Code: Select all

0eNrtWkuO4zYQvUrAZSAFIvXxZ9vZZjMeYBZBYNAWbROQSA1Fudto+AC5RRbJxXKSUFLapq0fqbEzcKc33S2JfCrWK1Y9VusVrJKCZIIyCeavgK45y8H811eQ0y3DSXlPHjIC5oBKkgIHMJyWVzFZ05gId83TFWVYcgGODqAsJi9gDo+/OYAwSSUlNVp1cViyIl0RoQb04Tgg47mayln5dgXnBj+FDjioPyL1jpgKsq6fIgcoe6XgyXJFdnhP1Ww15V/MpXoWVzh5eXdDRS6XjWXtqZCFunOyqB7hYnaQO8q25bJKp0hcesgrL9IMi8rSOfj79z/UTF7IrLDAfqpBs4MysWByuRE8XVKmMMB8g5OcHOuXsnqhlfmw/CFIrLuTqiuonK1Go/LxVhDCrgf4CoqKdUFlPV4NV/ANStDJSCyo3KVE0rUhK4ERK2fYbyNmccmIq2KJZ0QRUr0c/DiCDwVp4fFwwOFTM4f7dnsA2nn7Jnvg6dLVsBH8f41zdmfwS1EQOyacdg7gJQfoTFkLzMyMsOC0kjeX9DM2rflCRnxtaCKJMEq9z5zHhLnrHcll7cuiZAdNoJaAnUEYKjhz8QvRIMLZCQEZIAj87JbGaAjQPyH4BggZzSVP9PmT0/ygdf4mKRRHZ19g5TV9Bef5Yev8rqj0dCO0VURWKF90Ps4gEyuQTxemnECmViALDSQ4g8yqjWCR6No2Qnh6WcK3isGyUJTB6CoyBd6Slr0wOe8Fw5ej603p9Fe1y8fB1XVktsUju5wcvuVk9D50CdkToaPfKEf3VstJBxWTs3EpThI3wWnWJkIuAqvh8jfSTy6/q8e73NK68Oi6RDljVMR0pIr4DyN2cQ8VcY9QhUGnnkD9ZE0GgtxQYcysyIQf2WeQUr+hAx0j0d4vGKHXQSD0jLKW/whJa1goX+8CGJqFOYRdAkKQr4X6TUSnhPAstnO/RIAN8wc0BTIUERCNOih4335OMJGlURTpfRrLRkPrev1xqsl7H2lrcadmTkeBaqcgsFFL3qPlnenATvb78xKChhs3tArkdxbHd1FUXrei8vtDPeoiKeoqHhnOc7onbib4vnR1kzH7EhI2ZUGrUZNRKf/mraEEs1gN1zsqvmfVFcozQmI35XGRENfXmwieZ9UcSoqVoOvSESssBNFNmlr1iPKEP8f8mblrnOXKKr3F4mlGGfWLdgTvDy6nujmzkS2jn9u9HI3u07i+thy7ntFnvWektYxs6vu0K7inY/s9Fu0eOLlO6rMBNRYMPDcVo7Nx6uXj0NUfSX3HYdR1fkKejY55wKYPnN1GqiA4ru/z/do+Tdf9+QBtH28g66ChSEeGfKJRrZ+PJNT9/4PQtPWDoCWnfheJvkX35xGTVzhQcpGZWkbB6G8N/mefGgxXUtN6EY6rF9/vY4Pb1IvFbVVNVwaJbLrHxjUhGveV1MdHUvYfSbWfFhTf1Vl0rn0k56hD9kodZ+fgqR4//+GXIpE0S8hL1XNQtSyvHB8FAYrCAHphdDz+A+K/keA=

Memory Register:

Memory register made from vanilla combinators only.

Combinator-Memory.jpg (329.15 KiB) Viewed 11040 times

Blueprint string:

Code: Select all

0eNrtW8tu4zYU/ZWCy1YeiKSeXnQzCJBNN95kUQwM2aYdArKkUpJnjMAfMH/RRftj8yUlpdhWZD1IRrbgTDeTUUheXp1zeXkfygtYhDlJGI0yMH0BdBlHKZj++QJSuomCUPwu2ycETAHNyBYYIAq24knMy4Iomyzj7YJGQRYzcDAAjVbkG5jCg9EgYUdZlvPfnISUMyZPlZXo8MUAJMpoRkmpSPGwn0f5dkEYF31aHTCaPW9JRpdVJQyQxClfHUdiZy5xgj7ZBtjz/3h8mxVlZFmOIkO8RcbicL4gz8GO8tV8yVnsnA+vClGpGFhTlmZztbc6wgSmpgHihLCg3Bv8xufHeZbkahIPpcyofIdCLSj+YWRVBYvyJ+vwhU9GLaOYy6FsmdOseIR88kGQVkMb6aPt3hTt2eBoz26PNlZF2xwHbBIsnwXeKRFi5Nc9iEVVXn7V4KXcXIEa+BZ8VAG+eK4Pcwe0YYREdTn2xcQOxj05xq3z222DMJyEwTZpOFROybJzaOb1uNOJVA1Og2ifPdNoc3GOuP0lASvsbwp+B/rAw27g68PQa8HMPqm+Iku6IkzSIdlSZ+RV5qC+H9ZQ/PH9Xw3DfyiFJnuuWx5l8zWLt3MacRlgug7ClKhQY56tt9HYcTc5rpx5O9oOzb6pQ3t8y9cEvt9NPbb7qEbAIWx1L43zJR2Mq82Ac1MGHoZn4EGRgWv4d08Vfmsc+I83+qARlPJNjbtvalf2pna65UCkwrTfug1EckbgS13y7tnxjXvH//j+t5iQp4RvFsaMU5axnMjT6PUEXFYLTtBUioasKyL1NGAYZPfEOX1hkt8GF9QMhKzRAqFLU/tH72q9SiDUNHx5xOV8TpsvgEj7RrDuIsd7HCfHg7J3g3eVMAti/UIJGrMsNUSgpVaXKvK69hOHoCTilj7icMzS1BCIz0ZB/Jx4h/GGpgXezyTNJinHO9iQBsi9AnBTQVenfj1KpprQ6axNX6rmn1TrN4U1DTPCpArjX+N4RaISmJL4XLCOXNhTHX8rhrI4mgTfSEWE7Veq5P0SWPB1IpSpSBBe6lUClpCQcI7jsLrePa23Gtevw5xzdMYi4KhV3+C83lbqEJhVJSpv4aj3GY58nIW4SkJmb1Q5CfHEhUPTuTCiMgaRN3m7zaRdtQDPefVv5u3iO/mMQiMI2BFWld4Y7xWZiSLWHeGe1xo3YMkaPvTkkhi76hnvpaJr1Z1zT5lQXNKd425Ppu5Lgu7rpUL/n5RrBw3I1GMG3nmx/mnAHLWoAHQlKaivhCBZqEJQt1ps3kVu+jRObtpT1qw7yT4n2J7bisMmX9hEst8AIF2rgB84s70lAVi3ZmT+hE0E1Nfvl2744x5JWKmPIMrebRvJ+mdLoZMA77+R4Nep6/GkyK4zZEsC21raSII0pTsySVi8E6HGJdp+FW0pAy36HwZYBKw4oZfaOG3aMPJXzn82qfFaakEKerh1+CSLncjVKrWg95daZDJ7x3EqlRbtrBw5bW/v6WXl6GPkGoMGtk63x2zrfCFfJcdGd9InhGb9PJo9YX1PoxWbkp8dauZo+M77iLMr5WhNXzZI9xGxZGKNtXM19IG7H82Qmmo9P9m4HGv3cvFdpMuzUdLlBrYMOZ4G41W9mXskduyvtoY4Xt2MNX8J5aoxgS1JJiylmwmWHHyqfTxq3WmoJQ7HcDcUtqXzXqyS1+K2QBmrfajtNB8h54rkNRYshqjHn+QOUYlHPX9bInuWHKmguTxD3hVj5pNZd0TN76kaYOvSfA9FIii629PKH7wZIAwWhOsMPpfzp7/8QbYx2/ORHU9CSwO0LOTYFjRt53D4D3BP8wQ=

I originally made these for a team-mate in multiplayer, from vanilla combinators, because "no additional mods on the server". After I went through all the hassle (and felt like in my student days again), he didn't want to use them any more. So maybe they do something good for you. Probabyĺy not, but maybe. There are a lot of blueprints for memory circuits / registers on the forum, but I haven't used them so far. Most of them get confused when the control signal is also in the data signals, and I need to save everything on the data wire. I'm going to test the DISK-mod next and see what it does.

Thanks @TRK for the switch, looking forward to using that too. No worries about the ghost-entity-isssue, it's already useful as it is.

[Nightinggale]

Actually I have since come up with a vanilla memory, which is significantly smaller than that.
[img]Memory.png[/img]
The numbered boxes are all decider combinators, all with the same settings. If A == 1, then output * by value. The *-1 box multiplies A with -1 and outputs A.

First it needs to be set up, which is done by setting A=1 on the input for at least 2 ticks. After that it functions as following:
2 reads its own output. When it has A=1, it just loops the signals, which is the actual memory.

When writing, A=1 is set to 1. It then forwards this to both 2 and 3. 3 will pass the signals next tick while 2 will not since it now reads A=1+1. Output will then be from 3 until 1 stops outputting, in which case 2 will end up with just the output from 3, meaning A=1 and starting from the following tick, it's back to looping its own output.

The part right of the dotted line is optional. It removes the A signal and it prevents signals from entering the memory from the wrong end. Depending on the "outside world", this could be anything from makes no difference to absolutely needed. In some cases it can be skipped if output use green wires from 2 and 3 while the loopback is still red.

This can be set up as combinators in a single row, which allows building lots of rows, hence making a big memory bank. You can replace A=1 with anything you want, in which case you can have one wire, which goes to all memory cells, but the control signal will ensure that max one will be active at once. You can for instance use an AAI unit scanner and then use vehicle IDs, effectively store data for each vehicle. You can say loop all miners and then connect all outputs and that wire will have total ore hold of all miners. Personally I mainly use it for crafting combinators where each memory cell supplies 4 assemblers. This in turn means one wire, which connects to all assembler stations which in turn allows some combinators somewhere to set how many assemblers should produce each item according how many I have in storage and if I have the needed input items available.

I've read in the forums that blueprints do not allow overlapping ghost entities. Since the end connectors are ghosts, and the middle part also becomes a ghost when blueprinted, the connector-ghosts cannot be placed, I guess.

So basically you are saying we should bug the developers to add better ghost entity support in blueprints?

There are a lot of blueprints for memory circuits / registers on the forum, but I haven't used them so far. Most of them get confused when the control signal is also in the data signals, and I need to save everything on the data wire.

I know and I'm concerned about the same problem.

Thanks @TRK for the switch, looking forward to using that too. No worries about the ghost-entity-isssue, it's already useful as it is.

I agree. It's very useful as it is, but the lack of blueprint support makes it more useful for setups where you need one, but not as much for setups you want to copy because you want 30 of them and you have 2 switches in each. That's a lot of manual setup afterwards.

and felt like in my student days again

I have the same feeling with Factorio. Particularly when I need to get the timing right. An example would be to set up a circuit, which can be pipelined, meaning it has new data each tick, but it takes multiple ticks to complete. If it branches and one branch takes 5 ticks, then the others need to take 5 ticks as well in order to get the right data to merge. I then add one tick delays with combinators, which outputs the input. Ticks needed for each iteration is also an important performance factor in game time and much needed concerns if you plan to move vehicles manually. Factorio is likely the game where you can make best use of engineering degrees ingame. Most games have the engineering requirements in mod making only.

[infinitysimplex]

Hey, thanks for answering, I appreciate it a lot. TBH, I expected no one would bother reading such an unnecessarily long post, let alone answer.

So basically you are saying we should bug the developers to add better ghost entity support in blueprints?

I think we should bug them to add better real-entity support in the field, so these ghosts need not overlap in the first place. But I've no idea whether that can be done, let alone how much work it is. I'm fine with the game's progress, it's improving pretty well right now, so no hurries for me.

Actually I have since come up with a vanilla memory, which is significantly smaller than that. (...)

That's a really clean and small set-up, thumbs up. It looks a bit like the D-latch I made for my friend when I started (https://en.wikipedia.org/wiki/D_latch). However, as you mentioned (I think), your circuit won't work if your write signal (i.e. A) is in your data. E.g., what if you want to store a value of "A=42" in your memory? Or even "A=-1"? What if you have 26 memory blocks that use "A..Z=1" as their write condition and you get data from the signal strings library (https://mods.factorio.com/mods/justaran ... nalstrings)? I had to split the write signals out of the data and handle them by a duplicate circuit, then merge them in at the end - one reason why it is so large. And my friend hasn't been using it, so I have little reason to remove the design-phase clutter. *cough*

Ultimately, I wanted a memory that could store not only item counts, but anything, even full-fledges programs if needed (write signals in the data would be common). Then, all you'd need to do, is, write a handy little compiler script, and then set the program through signals. There you go, arbitrary programs executed by circuits in-game. Of course, that needs a simple CPU, but the arithmetic combinators lend themselves to that easily. But you also need an instruction decoder, and a data fetcher, and an address decoder, and so on... You probably see why I dropped that idea and just looked for a Lua Combinator Mod (there is one for 0.15 now). After all, we already *have* full program execution in-game.

Oh, btw: My only vanilla application for memory is a far-away, autonomous storage for specific items. It should automatically detect how many items of its chosen types are scattered around in storage chests (they get dumped by messy / lazy team-mates in multiplayer all the time ), calculate the excess, and pull them in when logistic traffic is low. On the other hand, when on-base storage of the items is low, it should make them available in storage chests (so they get picked first) or push them out to the base. And since you don't want such stock-keeping to go on all the time, it should only do this once every few minutes (preferably also for outposts, via trains). It's easy to program such a thing, but hard to wire it into circuits.

My only *other* idea would be a completely dynamic assembling array that is assigned to production automatically, as needed.

This can be set up as combinators in a single row, which allows building lots of rows, hence making a big memory bank. You can replace A=1 with anything you want, in which case you can have one wire, which goes to all memory cells, but the control signal will ensure that max one will be active at once. You can for instance use an AAI unit scanner and then use vehicle IDs, effectively store data for each vehicle. You can say loop all miners and then connect all outputs and that wire will have total ore hold of all miners. Personally I mainly use it for crafting combinators where each memory cell supplies 4 assemblers. This in turn means one wire, which connects to all assembler stations which in turn allows some combinators somewhere to set how many assemblers should produce each item according how many I have in storage and if I have the needed input items available.

Kinda like that, just bigger. Whenever you hit a production shortage of any kind, you should just need to place a blueprint of the dynamic array somewhere within range, and the circuit control and bots should handle everything else. You'd never have to think about production management again; it's kind of a self-regulating FPGA. But you cant' do that in vanilla because assemblers can't be controlled with circuits. They can with mods, but then again, mods can also automate the blueprint-placing, so you could automate base expansion and building. Just make yourself obsolete, thanks to memory.
I haven't looked into AAI, though, so I can't talk about that.

I agree. It's very useful as it is, but the lack of blueprint support makes it more useful for setups where you need one, but not as much for setups you want to copy because you want 30 of them and you have 2 switches in each. That's a lot of manual setup afterwards.

As said, I'll check out some other mod options and report back how they relate to this one. Maybe there are nice combinations you could do with the switch, or fill in for the switch until it's blueprintable.

I have the same feeling with Factorio. Particularly when I need to get the timing right. An example would be to set up a circuit, which can be pipelined, meaning it has new data each tick, but it takes multiple ticks to complete. If it branches and one branch takes 5 ticks, then the others need to take 5 ticks as well in order to get the right data to merge. I then add one tick delays with combinators, which outputs the input. Ticks needed for each iteration is also an important performance factor in game time and much needed concerns if you plan to move vehicles manually. Factorio is likely the game where you can make best use of engineering degrees ingame. Most games have the engineering requirements in mod making only.

Yeah, factorio is really fun in that respect. <3 However... tbh, I'm a computer scientist, so people expect better stuff from of me than my buggy designs so far. But it's not like you really "make" circuits in computer science. Even a hobby electronics builder just types down a formula for the circuit, and the computer does the rest, down to circuit board prototyping. So, automate yourself.

[theRustyKnife]

Hi,

I'm glad to see that you're still enjoying the mod, despite my incompetence to keep the development at a reasonable pace

I just wanted to drop in and say that I'm still planning to fix the blueprint issues, but I have very little time for modding. Currently, I prioritize work on Crafting Combinator, which is taking a long time to update.
The good news is that as a side effect, I'm developing a library which should hopefully make it much easier for me to work on the mods in the future.

The problem with the ghost entities is not actually that they can't be saved in blueprints. It is to do with the fact that you would have to use a different item to place them. This is especially tricky with circuit-connected entities like this one as there is no way to save the connections, other then using these ghost entities (that I know of). In other cases, you can usually get around this with some hacking, but it's still a ton of hassle...

I don't think custom entity support is going to happen any time soon, mostly because of the extra work involved in creating some usable system for that while maintaining decent performance. There just are more important things for the devs to do. What I think could be implemented instead is support for mods to alter blueprints on creation and placement, and save custom data in them. I can imagine that being a lot simplier to implement and it would solve pretty much all the problems with blueprints that modders are facing now, albeit with a bit more labor involved.

Cheers TRK

[Nightinggale]

However, as you mentioned (I think), your circuit won't work if your write signal (i.e. A) is in your data. E.g., what if you want to store a value of "A=42" in your memory? Or even "A=-1"? What if you have 26 memory blocks that use "A..Z=1" as their write condition

Actually I picked A because it's short for address, not because it's first. Each memory cell is then written to with the signals A=1, A=2, A=3 etc. A is then not used for anything else, which means I will never come in the situation where I want to write a certain A value. This way you can have address space for more than a billion memory cells without being concerned about overflow and you just use one signal.

The only reason I can think of where it would make sense to use another signal as address is AAI vehicle IDs since that's what's the signal the scanner will provide. It's still the same though, as all will use the same signal, but different values.

Ultimately, I wanted a memory that could store not only item counts, but anything, even full-fledges programs if needed (write signals in the data would be common). Then, all you'd need to do, is, write a handy little compiler script, and then set the program through signals. There you go, arbitrary programs executed by circuits in-game. Of course, that needs a simple CPU, but the arithmetic combinators lend themselves to that easily. But you also need an instruction decoder, and a data fetcher, and an address decoder, and so on... You probably see why I dropped that idea and just looked for a Lua Combinator Mod (there is one for 0.15 now). After all, we already *have* full program execution in-game.

I will only make circuits with one specific goal until we get Programmable Controllers to a state where they can be used for real. I have high hopes for that mod.

My only *other* idea would be a completely dynamic assembling array that is assigned to production automatically, as needed.

Been there, done that. It requires a lot of thinking to get it right. The assembler starts over whenever you change production. This means you have to minimize the amount of times you actually do change production. Assemblers should be controlled individually or in small groups to prevent all of them producing the same thing, hence needing frequent production changes. Maybe use the signal values to provide different priorities to each group, possibly different thresholds as well. Do not try to build something where you miss the input, like belts before you make gears. Consider how to get resources to and from the assemblers (just saying bots is not good enough as requester chests will fill up with resources for the previous recipe). Consider if you should spread recipes between the assemblers in a way, which makes an assembler get all the recipes with the same inputs. For instance make one assemblers, which only gets recipes, which use either iron plates or gears (or both) as this will help on item transport. Make something, which can be expanded, like placing all assemblers next to the same 42 tile steel chest is no good if your logistics can't handle multiple chests.

It can be done and it's awesome when it works, but it's certainly not as easy as I first thought. I got like 2/3 of it working and then I reached a dead end because I couldn't expand without more or less starting over.

I'm glad to see that you're still enjoying the mod, despite my incompetence to keep the development at a reasonable pace

Sure you have made enjoyable mods. To me Factorio has ended up being a quest to make fully automated assemblers to provide everything I need without manually assigning recipes to them or manual crafting. Sadly I haven't had time to play in the last few weeks due to... well time constraints. I fully understand your development speed (regardless of how I wish it was different).

I just wanted to drop in and say that I'm still planning to fix the blueprint issues, but I have very little time for modding. Currently, I prioritize work on Crafting Combinator, which is taking a long time to update.
The good news is that as a side effect, I'm developing a library which should hopefully make it much easier for me to work on the mods in the future.

I say switches are luxury items, which are nice to have, but can be replaced with vanilla combinators if absolutely needed. Switches can also be manually placed as it is right now. Crafting combinators on the other hand are unique, replaceable and a candidate for being the best mod ever made for Factorio, at least for my playing style. I fully support your priorities

That library sounds like it could be really interesting. If I read between the lines correctly, it's intended to make wire connection points on entities, which can be blueprinted. If that's the case, then it will be a blessing to modders and maybe it will help against the pain of modded combinators, which have inputs and outputs on the same tile.

[infinitysimplex]

Actually I picked A because it's short for address, not because it's first. Each memory cell is then written to with the signals A=1, A=2, A=3 etc. (...) I will only make circuits with one specific goal until we get Programmable Controllers to a state where they can be used for real. I have high hopes for that mod.

Well, then your approach is totally sound. And I was going to use A for addresses, too. Seems like that's a common idea.

quote

My only *other* idea would be a completely dynamic assembling array that is assigned to production automatically, as needed.

Been there, done that. It requires a lot of thinking to get it right. The assembler starts over whenever you change production. This means you have to minimize the amount of times you actually do change production. Assemblers should be controlled individually or in small groups to prevent all of them producing the same thing, hence needing frequent production changes. Maybe use the signal values to provide different priorities to each group, possibly different thresholds as well. Do not try to build something where you miss the input, like belts before you make gears. Consider how to get resources to and from the assemblers (just saying bots is not good enough as requester chests will fill up with resources for the previous recipe). Consider if you should spread recipes between the assemblers in a way, which makes an assembler get all the recipes with the same inputs. For instance make one assemblers, which only gets recipes, which use either iron plates or gears (or both) as this will help on item transport. Make something, which can be expanded, like placing all assemblers next to the same 42 tile steel chest is no good if your logistics can't handle multiple chests.

It can be done and it's awesome when it works, but it's certainly not as easy as I first thought. I got like 2/3 of it working and then I reached a dead end because I couldn't expand without more or less starting over.

I see. Well, I expected it to be hard, and it's pretty far back in my queue anyway. But *that* sounds like a really frustrating experience. I was prepared to use recursive blueprints to make the thing fully expandable, but if you couldn't start out with that, it must have been a real pain in the a**. Thanks for all the detailed tips.

Btw, full computers have already been done: viewtopic.php?f=193&t=28662
I guess we don't need to re-invent the wheel every time we build something. Though I'm tempted to do it from scratch. Every single time. -_-

I'm glad to see that you're still enjoying the mod, despite my incompetence to keep the development at a reasonable pace

Sure you have made enjoyable mods. To me Factorio has ended up being a quest to make fully automated assemblers to provide everything I need without manually assigning recipes to them or manual crafting. Sadly I haven't had time to play in the last few weeks due to... well time constraints. I fully understand your development speed (regardless of how I wish it was different).

I just wanted to drop in and say that I'm still planning to fix the blueprint issues, but I have very little time for modding. Currently, I prioritize work on Crafting Combinator, which is taking a long time to update.
The good news is that as a side effect, I'm developing a library which should hopefully make it much easier for me to work on the mods in the future.

I say switches are luxury items, which are nice to have, but can be replaced with vanilla combinators if absolutely needed. Switches can also be manually placed as it is right now. Crafting combinators on the other hand are unique, replaceable and a candidate for being the best mod ever made for Factorio, at least for my playing style. I fully support your priorities

First of all, sorry for spamming your thread with a more or less unrelated discussion. ._. On topic, I fully agree with Nightinggale. Your mods are pretty useful, the switch-update is anything but urgent, and the crafting combinator is essential. Life's (time) constraints just have priority, so take any time you need. After that, make what you find most important.

quote

The problem with the ghost entities is not actually that they can't be saved in blueprints. It is to do with the fact that you would have to use a different item to place them. This is especially tricky with circuit-connected entities like this one as there is no way to save the connections, other then using these ghost entities (that I know of). In other cases, you can usually get around this with some hacking, but it's still a ton of hassle...

I don't think custom entity support is going to happen any time soon, mostly because of the extra work involved in creating some usable system for that while maintaining decent performance. There just are more important things for the devs to do. What I think could be implemented instead is support for mods to alter blueprints on creation and placement, and save custom data in them. I can imagine that being a lot simplier to implement and it would solve pretty much all the problems with blueprints that modders are facing now, albeit with a bit more labor involved.

Cheers TRK

Hm... The cable-blueprint-issue has been giving me quite a few headaches, even in vanilla. I think, precise cable connections in blueprints (for arbitrary cables) would be a great help already. After all, selective power connections becomes completely useless as soon as you use blueprints, because bots ignore that. It's a feature I have barely used. I the same vein, it keeps modders from adding additional wire colours (there is a mod that exchanges red and green for yellow and blue, but it's still only 2 colours). However, the custom entity issue and the custom blueprint data issue both seem to be "bigger things". I guess you're totally right with your estimation.

Unfortunately, I barely know anything about factorio modding, so I can't help out there. But if there is any other way we could help (testing or so), please just say so.