Circuit network features for 0.15
-
- Burner Inserter
- Posts: 18
- Joined: Sat Apr 09, 2016 5:53 am
- Contact:
Re: Circuit network features for 0.14
Nice, Glad I caught this poll. Though it looks like my choices are not getting that much popularity lol
I will say that for those who want the option "Continuous wire building while running, somehow (?)" there is a mod that will trigger manual crafting automatically if you have the mats & don't meet the minimum stacks of the selected item. Its called HandyHands and is what I use to keep my wire stocks full when i am building my logic network. Devs could look into that
I will say that for those who want the option "Continuous wire building while running, somehow (?)" there is a mod that will trigger manual crafting automatically if you have the mats & don't meet the minimum stacks of the selected item. Its called HandyHands and is what I use to keep my wire stocks full when i am building my logic network. Devs could look into that
Re: Circuit network features for 0.14
Wow, you can only select up to 5 options in the poll
I selected the things most important to me (read train contents, control trains, set assembler recipes, arbitrary-delay combinator, and modulo combinator), but there's definitely more stuff I want:
* Bitwise combinators (although modulo lets you efficiently implement some of these if you're careful about controlling inputs)
* Some way to efficiently manage hooking remote outposts up to the circuit network. This could be autolaying circuit wire, transmitting circuits via rail, wireless signals via some mechanism (I'm not quite sure about using radars). Ideally, this should propagate signals with no delay (my circuit network uses a multiplexed circuit selector to propagate each outposts' contents individually), and it should be possible to have nearby long-distance networks that don't touch (e.g., multiple wireless channels, multiple parallel long-distance poles, circuitless rail components, etc.).
* The ability to do combinator operations across input wires (e.g., if EACH_red > EACH_green, out EACH = 1 or output EACH_red / EACH_green to EACH).
* ≥, ≤, ≠ in the decider combinator.
* A mechanism to precisely control the number of items an inserter moves (this is hell if your number is not a multiple of inserter stack size).
Controlling trains more smartly probably needs a close look at the SmartTrains mod to figure out what the minimum viable constraints are. The most important bits are:
* Some sort of train identifier, ideally customizable in the form of a constant-combinator-like set a single (multiple?) signal (so multiple trains could have the same signal representing a SmartTrain-like line number).
* Autorefueling (probably easiest done as some sort of condition "fuel is low")
* The real kicker is a circuit network-controllable "conditional goto" (maybe look up OpenTTD for UI inspiration?)
The urexample of a powerful smart train system is the ability to have trains that can look at your current iron/copper/coal/stone/oil supply, say "hey, I need more of that, let's go!", look at your outposts, and pick one to go to. Ideally this should be doable without a mod.
I selected the things most important to me (read train contents, control trains, set assembler recipes, arbitrary-delay combinator, and modulo combinator), but there's definitely more stuff I want:
* Bitwise combinators (although modulo lets you efficiently implement some of these if you're careful about controlling inputs)
* Some way to efficiently manage hooking remote outposts up to the circuit network. This could be autolaying circuit wire, transmitting circuits via rail, wireless signals via some mechanism (I'm not quite sure about using radars). Ideally, this should propagate signals with no delay (my circuit network uses a multiplexed circuit selector to propagate each outposts' contents individually), and it should be possible to have nearby long-distance networks that don't touch (e.g., multiple wireless channels, multiple parallel long-distance poles, circuitless rail components, etc.).
* The ability to do combinator operations across input wires (e.g., if EACH_red > EACH_green, out EACH = 1 or output EACH_red / EACH_green to EACH).
* ≥, ≤, ≠ in the decider combinator.
* A mechanism to precisely control the number of items an inserter moves (this is hell if your number is not a multiple of inserter stack size).
Controlling trains more smartly probably needs a close look at the SmartTrains mod to figure out what the minimum viable constraints are. The most important bits are:
* Some sort of train identifier, ideally customizable in the form of a constant-combinator-like set a single (multiple?) signal (so multiple trains could have the same signal representing a SmartTrain-like line number).
* Autorefueling (probably easiest done as some sort of condition "fuel is low")
* The real kicker is a circuit network-controllable "conditional goto" (maybe look up OpenTTD for UI inspiration?)
The urexample of a powerful smart train system is the ability to have trains that can look at your current iron/copper/coal/stone/oil supply, say "hey, I need more of that, let's go!", look at your outposts, and pick one to go to. Ideally this should be doable without a mod.
Re: Circuit network features for 0.14
Yes, it does, but it would still need a lot of combinators if you have the goto rules.vipm23 wrote:In theory, with this and train reading, you could make an automated request/delivery system with this that only ships the items requested instead of a designated loadout. Heck, it's already been done with Smart Trains, it just needs a lot of combinators.
The problem with your suggestion (which is not a bad suggestion after all) is that you would have to copy these schedules from train to train, which is tedious and extremely error prone.
If you have a main supply line, it will probably contain all of your outposts, and it will have several trains running on it. That means that every time you open a new outpost, you'd have to modify the train schedule and then copy/paste it to every other train (which might be all over the map)! It's really not practical at all for anything but the smallest of setups.
You can take my word for it, because I've run a single-train-line system with 50 outposts and 20 trains, and that could have easily been two or three times as big.
We need to be able to store a "train schedule" (or "logical train line") independently, and then be able to put trains on these schedules as we go.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick
-
- Burner Inserter
- Posts: 13
- Joined: Fri Mar 04, 2016 11:44 pm
- Contact:
Re: Circuit network features for 0.14
i think the " soundblock " would be great to play around with ...but i want it with several waveforms to choose from. ..adsr,lfo,filter etc. to be build like in reactor....
Re: Circuit network features for 0.14
Shift-click works to copy-paste schedules, last I checked. Doesn't help when you need to rewrite many trains, though.siggboy wrote:The problem with your suggestion (which is not a bad suggestion after all) is that you would have to copy these schedules from train to train, which is tedious and extremely error prone.
Re: Circuit network features for 0.14
Yes, the shift-clicking is not the problem. It's doing it for 30 different trains, everytime you add a new outpost. With the trains all over the map. That maybe works for a toy setup, or on a map with 5 trains -- but not on anything sizeable (and let's be honest, these kinds of setups are created by enthusiuasts who want to build BIG).jcranmer wrote:Shift-click works to copy-paste schedules, last I checked. Doesn't help when you need to rewrite many trains, though.
The "urexample" (nice word, BTW :) is a logistic network of trains; which has been built (hint, hint :), but is currently not possible without SmartTrains. If it was possible with Vanilla it would be amazing.The urexample of a powerful smart train system is the ability to have trains that can look at your current iron/copper/coal/stone/oil supply, say "hey, I need more of that, let's go!", look at your outposts, and pick one to go to. Ideally this should be doable without a mod.
Last edited by siggboy on Fri Aug 12, 2016 7:17 pm, edited 1 time in total.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick
Re: Circuit network features for 0.14
Well... one huge Option is missing: viewtopic.php?f=6&t=27673
Being able to adjust/override the damn Inserter Stack Size bonus depending on Circuit Signal!
The thread is already 8 pages long and no response.
For me that comes in second place after being able to read Train Contents, because 0.13 completely wrecked everything with the Stack Sizes.
Also when setting an Assembler Recipe with Circuit Signals should become a thing... please make it possible to force switch recipes on Furnaces on Circuit Signal as well. The automatic Selection of a Recipe for Smelting would then be overriden by the Circuit Signal.
Being able to adjust/override the damn Inserter Stack Size bonus depending on Circuit Signal!
The thread is already 8 pages long and no response.
For me that comes in second place after being able to read Train Contents, because 0.13 completely wrecked everything with the Stack Sizes.
Also when setting an Assembler Recipe with Circuit Signals should become a thing... please make it possible to force switch recipes on Furnaces on Circuit Signal as well. The automatic Selection of a Recipe for Smelting would then be overriden by the Circuit Signal.
Re: Circuit network features for 0.14
If you mean by that that "zero" should be a possible signal value, then I'm all for it. It can be very inconvenient that it is not possible (and "zero" is the same as "NULL").y.petremann wrote:Something that anoy me a lot is that nulified signals become not present, so for example if you implement a modulo operation on all color signal
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick
Re: Circuit network features for 0.14
Completely forgot about that.... It's certainly something I'd want to see even more than having red and green wire signals as separate inputs.MeduSalem wrote:Well... one huge Option is missing: viewtopic.php?f=6&t=27673
Being able to adjust/override the damn Inserter Stack Size bonus depending on Circuit Signal!
The thread is already 8 pages long and no response.
My Mods: mods.factorio.com
-
- Manual Inserter
- Posts: 2
- Joined: Fri Aug 12, 2016 8:01 pm
- Contact:
Re: Circuit network features for 0.14
There are plenty of train logic features that would be great. Read train contents, if(train at station), when(train empty), when(train full), etc.
Re: Circuit network features for 0.14
Weird how many votes timer combinator got, considering you can just add a single decider to a constant combinator to get the same function.
If you use something like a basic resource from circuit network, like a train signal or a chest or whatever, you don't even need the constant combinator.
If you use something like a basic resource from circuit network, like a train signal or a chest or whatever, you don't even need the constant combinator.
Re: Circuit network features for 0.14
I voted for "Assembling machine: set recipe" not because I would like to have it in assemblers (though it would be nice) but because it would be very usefull for refineries. I usally have 2 lines of refineries that are activated when I'm low on petroleum for advanced oil processing or when I'm low on heavy oil for classic oil processing.
Otherwise wireless signals sounds great !
Otherwise wireless signals sounds great !
Re: Circuit network features for 0.14
I voted for timer not because I wanted a timer (which is so simple and common that it really should be on a list of common combinator gadgets) but because I wanted the delay combinator (which is simple, but extremely space-inefficient for delay > 1). My kanban factory required 3-tick delays, for example.Drury wrote:Weird how many votes timer combinator got, considering you can just add a single decider to a constant combinator to get the same function.
Re: Circuit network features for 0.14
That's another case to be made for actual "black box" circuits (21928). For if we have that, and really good UI (inside the black box) for making circuitry, stuff like this can be made into "circuit blueprints" and then put inside a black box.jcranmer wrote: I wanted the delay combinator (which is simple, but extremely space-inefficient for delay > 1). My kanban factory required 3-tick delays, for example.
That would eliminate the need for many specialized combinators, because it would become actually viable to make the more high level functions yourself (no more space constraints).
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick
Re: Circuit network features for 0.14
If we get event-based signalling and the ability "pulse" outputs, then I'll want inserters/assemblers/anything-that-does-an-action to be triggerable on pulses.
Example, an inserter in front of a full belt would start the move operation when 'triggered'. (It probably gets stuck if it can't put the item down). An inserter in front of an empty belt does nothing when triggered.
An assembler that has the right ingredients already might also wait for the trigger before starting manufacturing.
Ideas for long distance wiring: Create a new entity that has the placable-while-running feature from power lines, but auto-connects using red and green wires instead of copper wires. This "relay tower" could also carry copper wire (and connect things to the power grid), but shouldn't provide a power area. Probably craft it from red wires, green wires, steel, and green circuits to make it accessible earlyish, but you need Assembler 3s to automate production of it. This balances fancy circuit blueprinted factories to later game, but still makes hand-built fanciness available. It should probably support a fairly large wiring range (but I don't know how that would interact with the range limit on red/greens).
Example, an inserter in front of a full belt would start the move operation when 'triggered'. (It probably gets stuck if it can't put the item down). An inserter in front of an empty belt does nothing when triggered.
An assembler that has the right ingredients already might also wait for the trigger before starting manufacturing.
Ideas for long distance wiring: Create a new entity that has the placable-while-running feature from power lines, but auto-connects using red and green wires instead of copper wires. This "relay tower" could also carry copper wire (and connect things to the power grid), but shouldn't provide a power area. Probably craft it from red wires, green wires, steel, and green circuits to make it accessible earlyish, but you need Assembler 3s to automate production of it. This balances fancy circuit blueprinted factories to later game, but still makes hand-built fanciness available. It should probably support a fairly large wiring range (but I don't know how that would interact with the range limit on red/greens).
Re: Circuit network features for 0.14
The wires themselves have no range limit. The red/green wire can reach as far as the copper wire can (depends on the poles you're connecting with it).hovis wrote:It should probably support a fairly large wiring range (but I don't know how that would interact with the range limit on red/greens).
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick
Re: Circuit network features for 0.14
I think for long-distance circuit logic I'd prefer the wireless idea using radar. Imagine every circuit-enabled entity had a button in it's UI to connect wirelessly to a specific circuit network by channel number (they already have their IDs coded in apparently). Could have a little antenna sticking out of the little circuit box thing they normally get when wired up.
Also, since green and red wires are free from blueprints since they'd be annoying to implement... Why not have green and red wire generally free always? Rename green/red wire items to something like "Red/Green Wiring Tool," make it resemble a crazy contraption of some description and have it never deplete when placing down circuit wires. Would be super easy to implement (except for graphics I guess), convenient and a bit more consistent with blueprint logic. You'd remove a tiny bit of tedium of crafting those things while wiring things up which is cheap and fast anyway, so I don't think it would matter too much. Just a consistency thingamajib.
Also, since green and red wires are free from blueprints since they'd be annoying to implement... Why not have green and red wire generally free always? Rename green/red wire items to something like "Red/Green Wiring Tool," make it resemble a crazy contraption of some description and have it never deplete when placing down circuit wires. Would be super easy to implement (except for graphics I guess), convenient and a bit more consistent with blueprint logic. You'd remove a tiny bit of tedium of crafting those things while wiring things up which is cheap and fast anyway, so I don't think it would matter too much. Just a consistency thingamajib.
Re: Circuit network features for 0.14
The sound box sounds really great, I can't wait to make a Beethoven.
I voted for "map signals to keyboard input" because it would make a new step in the automation related tasks. For example, before creating a new mine, it would be possible to make a simple order and let the circuit make a train with the needed resources: mining drills, belts... I think a good way to implement the idea might be not to restrict the orders to numeric keys. A special construction would enable to make a list of orders, each of one related to a signal to emit. Being in the range of the construction would make its orders to appear in the available actions. Mapping the most used actions to shortcuts like numeric keys would be really great of course. Using the radars to enlarge the range of the orders would enable to control far actions.
I don't get the point on making conditions to launch rockets as in the current game, one is enough and the other ones are for fun. So the autolaunch option currently suffices to my mind.
I voted for "map signals to keyboard input" because it would make a new step in the automation related tasks. For example, before creating a new mine, it would be possible to make a simple order and let the circuit make a train with the needed resources: mining drills, belts... I think a good way to implement the idea might be not to restrict the orders to numeric keys. A special construction would enable to make a list of orders, each of one related to a signal to emit. Being in the range of the construction would make its orders to appear in the available actions. Mapping the most used actions to shortcuts like numeric keys would be really great of course. Using the radars to enlarge the range of the orders would enable to control far actions.
I don't get the point on making conditions to launch rockets as in the current game, one is enough and the other ones are for fun. So the autolaunch option currently suffices to my mind.
Re: Circuit network features for 0.14
Instead of using the circuit network to control trains, wouldn't it make sense to just have a "goto schedule line IF" rule in the schedule? The conditions could even support reading contents of a specific item type (for filtered train wagons)
Like in openttd:
Ignore the non-stop part, in openttd this tells trains to not go through any stations on the way.
Like in openttd:
Ignore the non-stop part, in openttd this tells trains to not go through any stations on the way.
Re: Circuit network features for 0.14
Another voice for red/green selection, maybe something like this:
Both, Red, Green
Technically there are more possibilities which can be imagined for the input side:
Red + Green, Red - Green, Green - Red, Red, Green
The ability to subtract signals within a single combinator would be pretty powerful. Technically you could go crazy, why not Red * Green, or Red % Green, although combinators with complex wire combining arithmetic would become positively cryptic so it would probably be best to only have 3 options.
In the screenshot I suggest using two buttons per input which can be clicked on or off, but it could use a single button which cycles between three options:Both, Red, Green
Technically there are more possibilities which can be imagined for the input side:
Red + Green, Red - Green, Green - Red, Red, Green
The ability to subtract signals within a single combinator would be pretty powerful. Technically you could go crazy, why not Red * Green, or Red % Green, although combinators with complex wire combining arithmetic would become positively cryptic so it would probably be best to only have 3 options.