Thoughts about circuit network (while I'm just on it)

[ssilk]

I wrote some wiki-page today: https://forums.factorio.com/wiki/inde ... etwork/Bus
I think especially the pic shows, what's really going on in a green wire:

Why I'm begining to draw pictures? It is to explain some needs for the next version: https://forums.factorio.com/wiki/inde ... torio_0.11

There is also more information I remembered:
* This is from November last year: https://forums.factorio.com/forum/vie ... 678#p11678
* There is also this: https://www.factorio.com/blog/post/fff-39

For those which this is TL;DR I places a short summary at the end.

Let's just begin...

The patch bay

What is a patch bay? Basically this: http://en.wikipedia.org/wiki/Patch_panel
It has much similarities to http://en.wikipedia.org/wiki/Router_%28computing%29

And what I want to solve is this problem:


I want to have it looking more like this instead:


Why is this a problem? Because of the number of signals! There are many yet (not enough place to put it on screen and with every item the list grows).

So let's put the things together (very vague of course, there are no facts here!):
* We become several new devices. New devices means, that they need to be transfered via the circuits.
* They need to generate also new signals.
* I want to pic out some of those signals to form them to a new signal. Which also adds more signals.

Let's say for example: If it is night and if there are enemies around I want to fire a new signal to turn on for example extra steam-engines for keeping up the power over night. What I don't want is to create this signal in all of the pumps, no, I want one signal and the pumps are simply turned on/off if this signal is > 0. There are several of those useful possibilities and I would like to use them.

The problem with those pumps are: They are miles away. Now it is big task to cable red/green wire to this power plant. I've made too many Factories to know, that cabling over long distances is no fun. Instead I use the patch bay to plug my new signal from the cables into the wireless signal of the logistic network. Voilla! The signal is transfered without need to cable it further.

Smart modules

We have currently only the smart inserter. I want more things to react on signals then that.

The smart modules have a physical representaion in the game: They look a bit like the current modules. And you can plug it into the above mentioned patch bay. The patch bay is connected to some wires and also to wireless bus. I choose the "program", which should run on the module. The module has one ore more input-signals and one or more output signals. So now I can connect a single signal from the incoming wires/wireless to the input-signal of the module and the output signals back to the wires/wireless, and give it also eventually a new name.

Usage:
- Basic logic modules (AND, NAND, NOR...), currently it must be handled quite complicated.
- Timer modules: When Signal X is true, then switch on for X seconds. Useful for handling doors or lines of doors and thousands of more stuff.
- Regulating modules: If the difference between X and Y is too high, then give a signal Z on output, which depends on the difference. This is useful, if you want to switch off whole parts of the mining sites to spare the drain-power. Or to regulate the inserting into a closed circle (https://forums.factorio.com/forum/vie ... f=8&t=4573).
- And eventually own modules, programmed in Lua. Shouldn't be too difficult.


Ok. I repeat:
- I suggest some kind of patch bay, which enables me to route signals from different wire/wireless to a (new) signal on another.
- An modules, which enables me to make calculations on the signals to create new signals.

[DerivePi]

I've been thinking about posting something like this for a couple weeks now. Thank you for putting it together!

A couple other thoughts to ponder:
- I still like the idea of manually placing the wired link. Instead of wireless, I propose an upgrade to the data lines. Perhaps a multicolored cable with multiple, addressable lines that would connect from patch bay to patch bay in each base/outpost (like a fiber optic line). Then, from the patch bay, the individual devices would be connected.
- Really want to reuse red and green cables after dismantling them
- Provide an option to automatically add the data-line when erecting the long range power poles (I know, I don't want it wireless but I do want it automatic - I'm allowed my silliness)
- Make the patch bay dynamically addressable - ie. you can set the addresses and functions for any patch bay from any other connected patch bay (very similar to the post office idea here https://forums.factorio.com/forum/vie ... ice#p19731 )

Other devices to make addressable:
- Pump/valve - yes
- Power switch - What happens when you switch off a roboport and disconnect 2 robonets? Module count getting too low - turn on the independent module factory.
- Train stop - tell the train to stop / go - may even want to consider reading the name of the train that is currently at the stop so that the export station can know what to load onto the train
- Smart splitter - so that we don't need 10 smart inserters to fully load a fast belt off of a sorting line (currently sorting is only efficiently done with robots - I argue that robots should not be the best solution when dealing with bulk deliveries

Why would we use it?
My current goal in the game is to devise a train station that will receive and deliver material dynamically. Whether the train is delivering copper ore or advanced circuits doesn't matter if properly designed. A sorting station can take in all material and sort it into the correct outputs. If the train needs to return with empty barrels for oil shipping, the circuit network should be able to know that (there is a convoluted way to do this now) and place the empty barrels on this train but not place barrels on the train that is returning to an iron mine site. If the sorting station is receiving too much of a material it needs to signal upstream so that material shipping is stopped or slowed so that it doesn't jam.

Ultimately, I'd like to be able to order material to be delivered to an outpost so that I don't have to travel back to the main base when I run out of ammo.

At this point in the game, I believe all of these things are possible but not yet practical.

[The Phoenixian]

Alright, I'm having some problems understanding this so I'd like to propose a usage scenario to see if I can wrap my head around it that way.

Let's say I've set up four large scale iron mines: Mine Plazmataz, Mine Ferrocity, Mine Anti-Anemia, and Mine Thievery.

So let's say I set it up so that when each mine is near depleted and no longer bringing in enough resources to keep my smelters working at full capacity, the next mine in the sequence would come online?

Could I set Mine Ferrocity to activate after Mine Plazmataz is depleted?

If Mine Anti-Anemia is on a particularly large field and I want to keep pollution low, could I set it to activate in sections so that only so many electric miners are active at any one time?

And lastly, when I'm starting on Mine Thievery, could I send a signal, whether by alerts or just a lamp turning on, to alert me that it's time to set up a new series of mining outposts?

Would there be a way for me to supply ammo and repair packs as needed?

How would your tools allow me to do this with the system you are proposing?

[ssilk]

Good questions.

Ok, I have some requirements:
- let's say the current substation (the pole with the transformer) is - besides the smart inserter - then able to turn the power in its supply-area on and off. That is mentioned in kovarex's post I linked above.
- it is indeed a quite good idea from DerivePi to connect all patch-bays "magically" together, with an own smart bus.
- I assume, we are speaking from iron ore only, so replace it with any other resource if needed.
- I rename the four mining outposts simply to 1, 2, 3 and 4.

So, what I need to do is this:
- I need to turn on enough outposts to gain enough iron.

How I would do that:
- I measure at my furnaces, how much iron ore I have. It should be always a bit too much. There are many different methods to do that, but the easiest method is, to measure how much iron ore is stored. Why should I store iron ore? That's no way around it! We need some time between regulating and measuring, and this time needs to be buffered.
- We need such kind of measuring also in the outposts. I cannot measure yet, how much iron ore is left under the miners, so I need to measure the throughput or measure, if there is something stored. There are many ways.
- So we have "empty buffer"-signal from the main station and the "outpost depleted"-signals from the outposts. With the patch bay I route now all those local signals to the patch bay smart bus and name it "need iron". What happens is, du to the nature of the smart bus, that the values of the signals are added.

Let's say the main station says "empty buffer". Then it adds a 1 to the bus. If no outpost is depleted yet, the value of the "need iron" signal remains at 1. Now it seems to be easy to take this "need iron"-signal in the first outpost and send it to the substations and program the substations so, that they turn on, if "need iron" is lower than 2. In other words: Turn the miners on, if the main station needs iron.

When the first outpost gets depleted, he sends also a 1 into this signal and the value is then 2, if the main station needs iron. In other words: The second outpost knows then, that he should begin to work.

And so on, until the fourth outpost. I think there is no special deal to route the signal and add a lamp in your main station, which turns on, if the "need iron"-signal is > 4.

So, how could I turn on/off a particular field of miners?
Well, that's about the same idea: You need to split the electrical power for your miners into different electrical networks, that's not a big deal with the substations. Then you need to switch on the next network, if the previous is depleted, so you need to measure the throughput somehow.

Did I forgot something? I hope it's understandable?

@DerivePi: I'm not sure if this adressing is really needed. Take into account: with a patch bay there is no real need for different colored wires anymore. I could route all I need to another signal in the wire, or LogNet.

[MF-]

This again?? Let me write until I consider the post too long and then stop abrutply
Well.. Actually.. Allright... since factorio's target group has shifted a bit, asking the same question perhaps makes sense.
Still sounds like a request that gets replied to "doesn't fit, make it into a mod"

@ motivation picture
So, that's how you think it might look... Why? Analogue signals would decay over distance and mis-report.
And digital could be easily multiplexed / packetized.

Enforcing these complex configurations on everyone rises the already-steep learning curve.
(Unless I missed a solution that would provide some sort of "backwards compatiblity")

@ wireless
What would be the rationale for keeping the network partially wired?
Obviously the technology would allow fully wireless setup in that case.
Also.. in a hybrid wired-wireless network big debugging issue arrises, since you can't follow the wires and see what was destroyed anymore.

@ picture "what I want to solve"
Nah, that's rather clean and tidy. Most of the cables are even tied into a trunk.


You know my counter-proposal.
Some sort of "insulated power wire" would be introduced for precise power wiring.
Then there would be a CCnet-receiver that would hold the GUI of a smart inserter
and transmit energy from a nearby pole into the "insulated wire", which then would be connected to the operated aparatus.
This device would be standalone by default, but I would allow machines to be augmented with it as a module
to allow simple operation and deal with the learning curve issues.

Both logical and analogue operators would operate on these insulated-wires power signals
(would have their surface areas sectioned into "pads" as a mechanism for choosing which wire is which)

And then there would be a CCnet-transmitter for broadcasting the computed results back onto the network

[ssilk]

@ motivation picture
So, that's how you think it might look... Why? Analogue signals would decay over distance and mis-report.
And digital could be easily multiplexed / packetized.

Ok, you got me, I lied. In truth it is a bus. Could be transferred via multi-wires (like in the pic), or one single wire (the green wire, you know?), or over electromagnetic wavelengths (roboports). Or we use a protocol. MIDI is also a good example how to transfer many signals over one wire. In the end it doesn't matter how the signals are transferred. My pic goes araound the idea, that there are many signals inside and that many stuff should be manageable in future.

Enforcing these complex configurations on everyone rises the already-steep learning curve.
(Unless I missed a solution that would provide some sort of "backwards compatiblity")

But I don't wanted it to make more complicated as it is now. Makes me kind of sad, that it is seen in the total different way, cause I really don't know, how to explain it easier, what this bus is looking like inside.

What would be the rationale for keeping the network partially wired?

Good question. One is, that I want to keep the suggestion as partial as possible. That means not to change things, which don't need to be changed. And there are some setups thinkable, which don't need the patch bay, especially when they are very local, in a small area. The patch bay is useful for global available signals, if you want to handle many (dozens) of signals or many more stuff I don't know yet. The wires are useful if you want to create simple stupid stuff, like now.

Also.. in a hybrid wired-wireless network big debugging issue arrises, since you can't follow the wires and see what was destroyed anymore.

You mean, when you patched the wrong signals? Well, that's bad luck. you will have the problem always. That's why I suggest to be able to name the signals, cause that makes debugging easy.

@ picture "what I want to solve" Nah, that's rather clean and tidy. Most of the cables are even tied into a trunk.

Ok, it should be looking much uglier. I don't wanted to search for more complex setups, cause we all know what I meant, or?

Some sort of "insulated power wire" would be introduced for precise power wiring. ... Isssues.

I don't see that as counter proposal, for me that would be another cool way to switch something on/off, but not to transfer information from an outpost 1000 tiles away.

Both logical and analogue operators would operate on these insulated-wires power signals
(would have their surface areas sectioned into "pads" as a mechanism for choosing which wire is which)

Don't see the point against this suggestion. Yours is a completely new suggestion.

[MF-]

EDIT: Quality Assurance tests barely passed. Post done.

Enforcing these complex configurations on everyone rises the already-steep learning curve.
(Unless I missed a solution that would provide some sort of "backwards compatiblity")

But I don't wanted it to make more complicated as it is now. Makes me kind of sad, that it is seen in the total different way, cause I really don't know, how to explain it easier, what this bus is looking like inside.

Remember we've discussed this before, right?
I know about midi, comparison to it was fine for me. Replacing "item count" signals with universal channels does feel like a complication. It gets better when you name the channels, yes... But then trouble arises when you separate or join circuit networks. Why should an idetical name "copper" on both network imply, that you wan't those summed?
Also I don't see any appropriate machine whose GUI cold be abused to set the channel name. (but you definitely don't want to select the channel on each chest manually...). On the other hand, one defining point will cause trouble when splitting networks.

I'd prefer some system that at first works like the current circuit networks and then the more advanced features are researched and unlocked. "All logic in a box" still feels like a too big technological leap, though.
+ logic tiles lying on a ground feel much easier to inspect and debug than blackboxes (yeah.. obvious minecraft/redpower influence)

Also.. in a hybrid wired-wireless network big debugging issue arrises, since you can't follow the wires and see what was destroyed anymore.

You mean, when you patched the wrong signals? Well, that's bad luck. you will have the problem always. That's why I suggest to be able to name the signals, cause that makes debugging easy.

No.. when biters destroy something.
When that happens, then the layout of missing machines hints you how to repair the damage.
On the other hand....
Were it a wireless patchbay blackbox, good luck remembering where it was and what was the configuration or purpose.

Some sort of "insulated power wire" would be introduced for precise power wiring. ... Isssues.

I don't see that as counter proposal, for me that would be another cool way to switch something on/off, but not to transfer information from an outpost 1000 tiles away.

I didn't suggest any "wireless" stuff, because I dislike teleporting (no matter whether of matter or information)
I remember the wireless range of roboports not really being great, so you may need quite some re-transmission towers along the way to that remote outpost. Powered (ouch).

Both logical and analogue operators would operate on these insulated-wires power signals
(would have their surface areas sectioned into "pads" as a mechanism for choosing which wire is which)

Don't see the point against this suggestion. Yours is a completely new suggestion.

Kinda.. Like if current circuit network was "tier 0", mine "tier 1" and yours "tier 2 + teleportation"
Not saying patchbays are wrong.. I just think such signal processors should be optional and quite expensive.
(Meaning that everyone building a complex circuit-driven contraption gets a choice whether to use one expensive blackbox ....or...... a large field covered by simple logic tiles) It's obvious which group I belong into.

[ssilk]

Remember we've discussed this before, right?
I know about midi, comparison to it was fine for me. Replacing "item count" signals with universal channels does feel like a complication.

Hmmmm... Makes me thinking, that all of what I have been thinking in the last month was for nothing. But well, you're right, if you think this step from a cable to "many cables" like in the first pic to a bus (like MIDI) should be made easier: Yes! But I was sure, most players even get to the point, that this is a bus or will understand, what a bus is. Well.
I took this pic also, because of the patch bay, which works also with cables, and in most cases (old telephone), it is quite similar: A big cable comes in, inside a lot of smaller cables and now the cables needs to be patched from input to the output.
Perhaps this is also a misunderstanding? Look, this is what I mean:

A patch panel (patch bay) with 24 ports. You need normally 2 of them. The upper is the incoming signals, the lower the outgoing. Inbetween you plug short cables. This is for example useful, to plug the ports of our rooms in my bureau to the switchports.

It gets better when you name the channels, yes... But then trouble arises when you separate or join circuit networks. Why should an idetical name "copper" on both network imply, that you wan't those summed?

Ha! this is the reason why the routing is needed. You take the copper-signal from a green wire and iron-signal from red wire and name the result "metals".

I'd prefer some system that at first works like the current circuit networks and then the more advanced features are researched and unlocked. "All logic in a box" still feels like a too big technological leap, though.
+ logic tiles lying on a ground feel much easier to inspect and debug than blackboxes (yeah.. obvious minecraft/redpower influence)

Nobody said, that the end-reslt shouldn't look like so... and for me the smart inserter is such a big black box...

No.. when biters destroy something.

Then the robots will hopefully rebuilt it...

Were it a wireless patchbay blackbox, good luck remembering where it was and what was the configuration or purpose.

Good point. But for me it needs a physical representation.

I didn't suggest any "wireless" stuff, because I dislike teleporting (no matter whether of matter or information)
I remember the wireless range of roboports not really being great, so you may need quite some re-transmission towers along the way to that remote outpost. Powered (ouch).

Hm, one of those super magic stuff... I don't care realism here. The patch bays are connected through some magic fiber wire or let's say it has a tower and antennas, whatever. It really doesn't matter.

Like if current circuit network was "tier 0", mine "tier 1" and yours "tier 2 + teleportation"
Not saying patchbays are wrong.. I just think such signal processors should be optional and quite expensive.

Yes, why not? But remember: This is because I want to connect the things. I really don't know what comes out in the end, but I played through enough scenarios, that I can say "well.. not bad".

(Meaning that everyone building a complex circuit-driven contraption gets a choice whether to use one expensive blackbox ....or...... a large field covered by simple logic tiles) It's obvious which group I belong into.

Well, you remember the modules I mentioned above: They should be able to be used standalone (not in a patch bay). You figured it already out: place such a module on ground, plug in cables and now you can make very simple switching-stuff. Separating electric networks makes then much, much sense. But If you want to have it more complicated, copy complicated wiring, if you want to transfer the signals far, far away, well, then the patch bay is your friend.

[MF-]

I took this pic also, because of the patch bay, which works also with cables, and in most cases (old telephone), it is quite similar: A big cable comes in, inside a lot of smaller cables and now the cables needs to be patched from input to the output.
Perhaps this is also a misunderstanding? Look, this is what I mean:
--- picture too high ---
A patch panel (patch bay) with 24 ports. You need normally 2 of them. The upper is the incoming signals, the lower the outgoing. Inbetween you plug short cables. This is for example useful, to plug the ports of our rooms in my bureau to the switchports.

I don't mind such devices in the real world, I can see how useful it might be. But I really doubt GUIs of their factorio coutnerparts could be small, easy or non-confusing.

I see only one "row" of connectors in the picture, which means there is no "upper" or "lower" one.
Oh wait... could that be ethernet again? It's a poor example then, since in ethernet cables don't split or merge.

Let's now imagine, that those shiny cylinders on the inner/upper side of this device are connectors too.
Then you might be able to put "single wires" into the white area between them and route individual signals.
Since that could get messy really easily, I would have to put a sticker on everything (input, output, and all the little routing wires too). Otherwise I'd lose my ability to understand or modify existing installations.
And even then, changing the routings would probably involve me running around the facility with sticky notes and pen for days to relabel all occurences properly.
Factorio would automate most of those tedious tasks of course (channel allocations and labeling), perhaps that's why it's so hard to come up with a real-world analogy that would work nicely?

Ha! this is the reason why the routing is needed. You take the copper-signal from a green wire and iron-signal from red wire and name the result "metals".

I voiced my prefference to keep dedicated "item" signals for those who like to keep it simple.
I never said I would be against the dedicated signals part.
Creation of the "metals" signal is in my proposal hidden under "analog gates" (summing/diminishing/multiplying..),
since the CCnet-receiver would also have and "analog export" option to output an analog signal instead of digital one.

.... Thinking about it... CCnet-receiver, technically speaking, consists of a channel extractor and a thresholding unit,
which means it may provide three connection pads "input, middle, output", where the middle could be tapped to obtain the analogue value of the selected channel.

Also: It's not just that example that makes generic channels so useful.
Generic channels also allow you to have copper-status signals from all mining facilities in one cable easily.

Another useful gates might be minimum and maximum.
I gave a brief thought to using generic channels for performance counters (Device that would connect an inserter and count how many items were transferred), but I expect that would cause issues with large numbers after a while.

Nobody said, that the end-reslt shouldn't look like so... and for me the smart inserter is such a big black box...

"Black box" means to me, that I can't see what it's doing by walking and looking around.
Smart inserter can only pose as an end-node in the circuit network, which only qualifies it for being a small box.
I do admit, that using two conditions and a logical operation is not truly transparent, but the final result is not hidden, since it's indicated by the position of the inserter's arm, so it's not really black either.

Were it a wireless patchbay blackbox, good luck remembering where it was and what was the configuration or purpose.

Good point. But for me it needs a physical representation.

But for me connections (wires) need physical representation too.

Hm, one of those super magic stuff... I don't care realism here. The patch bays are connected through some magic fiber wire or let's say it has a tower and antennas, whatever. It really doesn't matter.

Even unlimited range teleportation? That sickens me.
I actually like getting my hands dirty putting up all the wiring.

Well... unless the current militarized factorio posed too big danger to free-standing power poles.
In that case I would choose trains for long-range information transportation, using a dedicated "e"mail carriage.
That would involve the said mail carriage, a module to write network contents onto it and a reader+latch module to unload and broadcast.

Well, you remember the modules I mentioned above: They should be able to be used standalone (not in a patch bay). You figured it already out: place such a module on ground, plug in cables and now you can make very simple switching-stuff.

I don't want to lose the fun of engineering up a complex setups on my lawn using only simple gates,
100% blackbox-free .

[DerivePi]

Here is a layout of what I am thinking for the Patch Panel.

http://i.imgur.com/tqUEloc.jpg - (zoom out to about 75%)

In my latest game, the "Toggles" I have in my Material Relay Station function act as a minimum/maximum switch. When the amount of FE ORE in my Sorting Station reach, say, 4,000 the toggle empties the Smart Chest of it's one FE ORE. When the amount is reduced to , say, 1,000, the ore is reinserted into the smart chest.

[MF-]

Comparing the "before" and "after", the only difference I see is information teleportation.
Your drawing of a patchbay also suggests merely the teleportation bit, not touching the digital/analogue operations.

I understand that cheating the on engineering part might be desirable for the current militant factorio fanbase, though

[DerivePi]

For most people, I find pictures make things clearer.

As I previously posted, I am not a fan of wireless for circuit networks (I don't think we need to introduce Star Trek concepts into this discussion either) and I desire that there still be a "wired" connection between patch bays. Global-1 in my sketch is a "wired" connection between patchbays. The dashed lines indicate that the subbases can communicate directly because they are connected through the Global-1 "wire". As for digital/analog operations, "Yes, the game is not aiming for realism, but good gameplay," and I'm OK that hot water runs the steam engines and error checking on signals is ignored. A game that didn't cheat on engineering would simply not be fun. (arguably, engineering is a cheat on reality).

Here are some previous posts that tie into this:

https://forums.factorio.com/forum/vie ... 7619#p7619

https://forums.factorio.com/forum/vie ... 6248#p6240


I would like to hash out a little more of the "smart module" concept.

[MF-]

Oh, then I'm sorry for misunderstanding what your pictures were to say.
Is it a "simple" multicable / cable trunk, then? Like "coloured cables v.s. bundled cable" concept from minecraft mods?
PS: now I also understand those dashed arrows in your picture..... those indicate that communication is possible, even though there is no direct physical wiring.

I thought ssilk linked "our" past discussions in the OP.... now I see those links weren't what I assumed them to be.
So thanks for digging up the links and adding them. If you actually read any of that, then I admire you.
One way or the other... you've got my attention.

[DerivePi]

I've been thinking a bit more on this.

I think the best addition to a circuit network would be a "Circuit Requester Chest" as follows:
- Instead of telling the smart inserters directly what to do, the requester chest tells the connected smart inserters what it wants. Any item that those inserters encounter from that list are then operated on. Filters could still be set to limit which items the smart inserters recognize and a second connected wire could be used to provide "AND" logic. In my mind, the second wire would be connected to a timer so that the inserters would be dormant while the requested items are shipped to the outpost with the "Circuit Requester Chest" (the connected smart inserter(s) would be at another station).

Some thoughts on logic modules:
- I am thinking of items that are separately produced and could be plugged into smart chests and smart inserters
- Functions of these modules could include:
-timers
- logic gates (currently AND is implemented for 2 wired connections)
- instead of crafting what type of smart chest you want, use modules to upgrade a circuit chest to a provider, requester, storage, etc... for both the circuit network and robot.
- Considering the hassle of separately adding items to each smart device, perhaps you guys have a better way

[ssilk]

Ok. This is going into a complete different direction.

Well, I want to bring this back to the basic idea. I searched around a lot to find something, which can explain what I mean. I found this:



This is the backside of the Reason rack view. It's a program to make music. There are many similar and simpler programs - of course! - which make the routing with wires, but I choose Reason, cause I love this program. (Now Reason 8 cames out and of course I'm on the beta-teste list).

The idea is: one cable in the pics above is one signal. I can use this signal to form other signals out of it (in Reason they call it devices, I called it modules). I can route the signals to other inputs (modules) and together with other signals I can create any signal I want. An AND-gate is just one of the most simple things.

In Reason I can of course plug in many MIDI-keyboards, it also can use the computer keyboard to play music. That are the red and green wires (and logistic network) as input-sources. I can output the generated signals to some different speakers or into an external MIDI-device to hear the sound. That is here also red/green wires and logistic network. But well, it's just the beginning. My idea will make the input- and output-routing so easy, that it is no problem to add more inputs or outputs.

Which is yet a problem.

So, basically I can do unlimited stuff and it will be easy to mod this, it will be easy to expand this, it makes Factorio ready for things, we yet can imagine.

So I can explain some things with that, but I just leave this open. I wanna bring the game into that direction, go away from a programming view (logic gates? that's is just the lower end of what I mean), and instead going into patching, pluging in, combining, which is in my eyes also more fun.

[DerivePi]

ok, I wanted to explore the ingame possibilities a little more so I came up with this schematic concept

http://i.imgur.com/0lMrLFE.jpg

On the left, I've listed inputs and outputs (current and future?) and on the right, I've got 2 illustrations of how Factorio tasks might just be accomplished using a patch bay with modules.

I must say it is a bit complicated and I understand MF-s concern that implementing such a system would be difficult and would have a considerable learning curve. I can also now appreciate just how much more tinkering such a system would allow. I think implementation of this type of patch bay would have to come with additional ingame tasks that would require more delicate balancing and finesse.

Very much looking forward to the multi colored light. I can imagine the shenanigans that will allow.

[ssilk]

@DerivePi: This is about exactly as I thought of it! Incredible! Even the different data-types you have thought of.

It is a bit complicated, but tinkering. But eventually there are some ways to shorten this stuff.

And this is in my eyes the important point: Most (I carefully don't say all, but quite a lot more) of other systems can be emulated with this one.
Maybe this isn't clear?

My opinion is: This has never been built in any game I know. Maybe partly... It's not so complicated to program, but is it then playable?
But we can try it out, how to play with that.
Making it easier is then only a task of continuous changes.

I can compare this also: Electronic music is strongly influenced by this:

See this: http://en.wikipedia.org/wiki/Doepfer
There are only some specialists, which know how to make music with that.

Reason on the other hand is easy to learn and understand, most of the routing is made automatic, but they implemented this Doepfer system (on the backside of the rack). You can use it nearly as the original - if you want! That's the point. I knew Reason since 1999. The usability improved since then unbeliveably. Nearly any other music making system implements also this Doepfer system. In one or the other form.

There are parallels here.

[MF-]

@DerivePi: This is about exactly as I thought of it! Incredible! Even the different data-types you have thought of.

really.. my response is the same as ssilk's,
because the main differnce between our ideas is the placement of such modules.
ssilk wants them in a big black boxes that information-teleport between themselves,
I want them lying on the ground to ease inspection

My ideas comes from the programmig side, so I call them logical and analog gates,
his comes from the music side so he arguments with MIDI and music software.
Now it occurs me that the only difference is thus him trying to hide the truly fun parts in blackboxes and teleportation

[DerivePi]

I'll take all of the "incredibles" I can get

For me, laying things out on the ground is very confusing. The attached link is my WIP train station which is meant to ID the train (using a tagged item in the first wagon) and then load it with specific return items. Although the schematic is "sort of" readable thanks to labels and such, the actual ingame construction is super confusing. Of course, there is something magical about watching the toggle switches flip, the timers run their course and the system resetting when a new train arrives.

https://forums.factorio.com/forum/vie ... f=8&t=4842

I think the next step is to develop a core set of modules (clock, summation, argument, logic...other thoughts?) that will handle different data types based on context.

[ssilk]

Now it occurs me that the only difference is thus him trying to hide the truly fun parts in blackboxes and teleportation

Uhm, no. Did I say that? I think this is a misunderstanding.

Modules/Logic gates/whateverthatmodifiesthesignals should be able to work on their own.

BUT

At some point you don't want to place over and over again the same gates. And you want to tell the coop-player: "This thing blinks red, if power too low". For that you need to put the things into something like a black box and write a name/description on it. Or let's think to blueprints: At some point you don't want to repeat placing your 500th solar module.

That's the reason, why I need to put the things into a box.
... maybe I should have made two posts out of it...