Friday Facts #402 - Lightspeed circuits

[mcmase]

The engineer digging might be related to hostile fauna activity. Maybe digging moats or trenches to make perimeter defense more effective?

Engineer will be making initial landfall on new planets with EXTREMELY limited supplies. Roboport networks may not be possible until some infrastructure is built up, in which case the engineer might need some personal equipment to be able to build defensive perimeters fast enough?

That's an interesting possibility, and the only one I've seen so far! My mind is drawing a blank...

[picklock]

Another FFF with innovations that I would like to try out immediately.

I already use signals over long distances. So the transfer of these signals via radar is a great relief for me. Now I no longer have to lay long wires.

I also like the fact that the external lines are retained when cutting and pasting if possible.

All in all, another great QOL feature.

The last topic in the FFF doesn't affect me as much now, I'm not a fan of the quality topic as it was presented.

[MiniHerc]

There are a lot of ways to do it, but we wanted to keep it simple. So we decided that there is just a single radar channel for each surface (still separated between red and green). This means, you don't have to configure anything, you just connect the wire and you are ready to go. If the radar loses power the circuit connection is severed.

So just make it default to channel 0/1 and allow additional channels in the GUI. One channel per surface is sad times.

[Dschimmi]

Radar Transmission is a great feature to come! Love you guys for that (for the Bridges i will love you more). My "annoying thing" when it comes to circuits is the thing that you are limited to the "Items" why can't we just rename a signal? if we have more than one signal for electronic circuits we need to use red and green channel, but what if we need more? i would just rename them to whatever reminds me what this signal is doing.

[Akato]

But adding 8 channels would be, ... you know better.

You can't have, say, radar A transmitting to radar B, while radar C transmits to radar D.

I would rather have option to set 8 channels, so we get 8 independent wireless networks.

One channel is enough for most people's use cases. However those who need 8 channels, or 60, or even 1000, can do circuit network magic to transmit an arbitrary number of channels through a single cable using a scheduling system and a global clock. It won't take too many combinators and someone's going to post a set of blueprints for anyone to download, taking advantage of the parametrised blueprints described earlier. The only cost will be a bit of a delay making circuits not as responsive, but even with 60 channels that's only a 1 second delay at most.

Come on, Multiplexing is not hard enough to be considered magic

[Amarula]

There are a lot of ways to do it, but we wanted to keep it simple. So we decided that there is just a single radar channel for each surface (still separated between red and green). This means, you don't have to configure anything, you just connect the wire and you are ready to go. If the radar loses power the circuit connection is severed.

My first thought was sure this is just how it works when you have wires running from pole to pole to pole. Except... when you don't connect poles, you can create separate networks, so you can distinguish supply and demand between different outposts needing the same signals. It is a little more complex but I do like the idea of seeing and being able to select a given network.
Side note: when I connect a chest to a network, I can see which network it is, but when I connect to a combinator I have to know what I am doing because the ID doesn't show. It would be very nice if everything that connects to a network shows which network(s).
More great stuff keep it coming!

[FuryoftheStars]

But adding 8 channels would be, ... you know better.

You can't have, say, radar A transmitting to radar B, while radar C transmits to radar D.

I would rather have option to set 8 channels, so we get 8 independent wireless networks.

One channel is enough for most people's use cases. However those who need 8 channels, or 60, or even 1000, can do circuit network magic to transmit an arbitrary number of channels through a single cable using a scheduling system and a global clock. It won't take too many combinators and someone's going to post a set of blueprints for anyone to download, taking advantage of the parametrised blueprints described earlier. The only cost will be a bit of a delay making circuits not as responsive, but even with 60 channels that's only a 1 second delay at most.

Not sure why you quoted me in all of that. I don't care and it wasn't what I was commenting on. The poster I quoted thought that "one channel" meant red & green would be combined into one signal, making them indistinguishable from each other on the receiving radars. The segment you actually quoted was supposed to be a more defined example to them on what "one channel" actually meant.

[aaron311]

First off, I LOVE what you're doing with the expansion. Secondly, I LOVE your latest series of FFF.

None of the following criticisms are intended to detract from either of these.

I was super excited to see the wireless signal transmission feature of the Radars until I read this:

So we decided that there is just a single radar channel for each surface (still separated between red and green). This means, you don't have to configure anything, you just connect the wire and you are ready to go. If the radar loses power the circuit connection is severed.

I hate this. (Okay I'm being extreme but there, I said it! ) There needs to be some way to select among "channels" for the sender and receiver at the very least, such that you can have different "channels" on the same surface (isolated signals each).

Why? Well, suppose you want to relay from one rail stop to another "all the current unfilled logistic requests of the remote network". Well, crap, now the signal types going between the two rail stations can be "any type". The type is just as important as the quantity for relaying to the "sender" the type of good I want. Forcing there to be only two global channels of 'red' and 'green' prevents this wireless transmission from being useful at all once my number of stations > 2. To me, this is a case where allowing further configuration (channel selection) probably does not hurt much (since you already have red/green separation) and easily makes the feature much more powerful in many respects.

I love your stuff even if you 'press ahead' with this (obviously wrong) decision. (Okay now I'm just trolling.)

Anyway, back to the factory <3 <3 <3
Aaron

[Nick-Nack]

I'm really happy about all the love shown for circuit networks!

Hopefully there will be also a way to place blueprints via the circuit network. I know there are Recursive Blueprints and Recursie Blueprints+ which already do great job and gave us things like Micro Factries or self expanding bases in the first place, but their interface unfortunately is still a bit clumsy. Also, this becomes way more important with multiple planets than it was before.

Similarly, some kind of communication for circuits between planets would be really nice

[vulduv]

By "one channel" you mean the values of red and green cable will be added, transmitted, received and a single list of values will come out?

So storing the number of available trainloads in green and requested trainloads in red still needs a complete network wiring?!

No clue if this was added after you posted your comment. But your answer is answered in the post itself now.

So we decided that there is just a single radar channel for each surface (still separated between red and green)

I'm also quite curious how the "light speed crafting" was implemented. As I've thought about the issue of crafting more than one item per tick before. And my thoughts were to just use 2 fixed point integers. One for the crafting progress per tick, and the other being the current progress. Add the former to the latter, (multiplied by how much power the machine is getting, of course.) then just read the upper, whole-number, portion of the latter integer each tick, to see how many crafting operations were just performed.
I'd imagine that would be quite fast. Though I don't know any of the other code in factorio that would surround it, so Rseding almost certainly had a better solution in this case. But it's fun to think about.

Also another fun thought while on the topic of performance. Now that a crafting operation can be done multiple times per tick, couldn't the factory simulation theoretically run at a much lower tickrate? Currently it runs at 60 updates per second. But if it ran at 30 or 20 ups instead, then the cpu and ram would have up to 2 or 3 times as much time to go through and update the states of all the entities in the factory. Improving performance.
Obvious issue, the speed of circuit networks is directly tied to the tick rate. So changing the tick rate of the game would break most advanced circuit networks. And then there is actually changing all the code to make such a thing happen. Which gets even more complicated if one were to try and have different things run at different tick rates.
So I'm very much NOT expecting the tick rate of the game to change. But again, it is fun to think about. And probably good to keep in mind for anyone making this genre of games. You don't need everything to run at a really high tickrate.

[XANi]

Now we only need "required materials for ghosts" signal/combiner to make fully automated global train logistics without much fuss!

First off, I LOVE what you're doing with the expansion. Secondly, I LOVE your latest series of FFF.

None of the following criticisms are intended to detract from either of these.

I was super excited to see the wireless signal transmission feature of the Radars until I read this:

So we decided that there is just a single radar channel for each surface (still separated between red and green). This means, you don't have to configure anything, you just connect the wire and you are ready to go. If the radar loses power the circuit connection is severed.

I hate this. (Okay I'm being extreme but there, I said it! ) There needs to be some way to select among "channels" for the sender and receiver at the very least, such that you can have different "channels" on the same surface (isolated signals each).

I'd love if we would be able to have some "non-pass thru" signals to configure the radar. Aside from channel ID we could have one for turning radar on/off for those needing to save UPS because of megabase/weak PC.

I'm really happy about all the love shown for circuit networks!

Hopefully there will be also a way to place blueprints via the circuit network. I know there are Recursive Blueprints and Recursie Blueprints+ which already do great job and gave us things like Micro Factries or self expanding bases in the first place, but their interface unfortunately is still a bit clumsy. Also, this becomes way more important with multiple planets than it was before.

Similarly, some kind of communication for circuits between planets would be really nice

Baby steps, first we'd need to get something in vanilla to read what current ghosts need to be built. There are mods for it but doing it in Lua only have a performance impact.

[quyxkh]

All excellent. At the back of my mind I've had this hankering for circuit connections on rail segments, you could have red/green on each of the two rails, by default connected to every attached rail segment but with a switch controller, either an entity or a tool, that can connect/disconnect attached rails' circuits.

[cronjob]

Are you sure this is the player? The arm seems to be quite high in the air, even if the player is as close the the foundry as possible. So either this type of power armor also affects you size, or this is more like a Fallout Powerarmor, more of a vehicle than personal equipment.

My first thought is it's high in the air due to being airborne, perhaps via a jetpack? Also the "excavator arm" I think is just chunky armor with an industrial aesthetic. May or may not be related to any kind of digging functionality.

At any rate I'm excited to see what it is! Also the radar network and wire cut-paste are very welcome additions.

[Wingysam]

Is there a mod that implements the radar feature in the current version of the game?

[gambo]

as a vanilla player, that foundry crafting progress bar makes me so happy to look at lol

[jgilmore42]

Would it be bold ask for an "integrated circuit" a box 2x4 tiles which opens a virtual surface (a sort of space platform of a fixed size, one chunk , 32x32 tiles ). Box has 4 inputs and 4 outputs wires connectors. Only combinator's items are allowed to place inside the "integrated circuit box".

Factorio's combinator style logic can take up a lot of space, be horrible to move around, and impossible to understand later or properly document.

None of which is really solved by your suggestion, IMHO. Well, except for the taking lots of in-world space bit. Which would actually make documentation and understanding HARDER, not easier. Since that's the primary problem with factorio's circuit network logic once you have more than one combinator, it would be a detriment rather than a benefit.

Combinators and working with whole dictionaries (key/value pairs, anyone?) at once is really hard to wrap your mind around. Something simpler would be nice.

Coming from the world of the ancient game "Robot Odyssey" by "The Learning Company" which is now abandonware and is playable online at https://robotodyssey.online/# , I think that there's a better way to do things.

I like the clocked logic in Robot Odyssey, and adapting that to analogue (intensity) wouldn't be that hard. (Pretty sure the math on that has already been done.) Put a "label" on the I/O pins to grab (or add) one value from the surrounding red/green network, and it'd interface to the existing circuit network just fine.

Or, in other words, if you're going to invent a sandbox to make logic in, you may as well make it make fcking sense instead of this stupidly complicated, opaque, and hard to document combinator bullcrap.

[Dmytrozern]

Beautiful QOL features. Both are gonna save me sooo much time.

Will we have a laser beamer or interplanetary radar to move circuit signals between planets?

[robot256]

[

I'm also quite curious how the "light speed crafting" was implemented. As I've thought about the issue of crafting more than one item per tick before. And my thoughts were to just use 2 fixed point integers. One for the crafting progress per tick, and the other being the current progress. Add the former to the latter, (multiplied by how much power the machine is getting, of course.) then just read the upper, whole-number, portion of the latter integer each tick, to see how many crafting operations were just performed.

I think there was a mod that halved the speed of everything so you could run at 120 UPS. You can also double the speed of everything and run at 30 UPS. The new behavior will make that a lot more effective.

Edit: Global Tick Time Scale https://mods.factorio.com/mod/GTTS

[malecord]

Uhm... I dunno if I like having just one transmisison channel for wireless signals. I mean, it's still better than none, but having at least 2 would be better imho. At least, I'm using 2 in my games... because like everyone I have 2 cable colors running through my railways. Yes, I'm one of those weirdos who like to micro optimize with circuit nwtworks rather than scaling horizontally (I do strange stuff like on demand ourpost refill, on demand ore train request without mods and stuff like that).

For the blueprintable circuits... I guess having a dedicated connector entity would do the trick. That is a pass through entity which sole purpose is to connect modular blueprints. Kind of a special combinator that can be programmed with labels... and descriptions. When a blueprint is laid down, the connetor entity would be automatically connected to same entities in range with the same label.

But honestly I don't know how what the use case there would be for that. I always made blueprintable all in circuit solutions, I never made anything modular. And in case it was a consumer/producer, I always used a combinator as gateway (if anything, to filter out non relevant signals running on that color).

[Drury]

A couple of years back I was experimenting with making my own "train dispatch system" (which later became fashionably known as a "logistic train network") and ran into a lot of the limitations of circuits that I had to work around, especially the lack of filter combinators necessary to make a computer for measuring stack sizes (so the system would know how much of a given resource fits on a train) and the lack of the ability to send data from multiple stations down the same wire (which I worked around using what I later learned was called a "multiplexer").

I'm hyped to return to that now that filter combinators were confirmed a couple of FFFs back, but this new radar solution doesn't seem too useful in comparison. It's just a QoL thing so you don't have to drag wires to every station, which blueprints already provide at no extra cost (you still need the pylons for power anyway). I would straight up not bother with the radar transmission at all - why bother wasting the resources to craft them and the power to run them, when powerline circuits are free on both accounts? Besides, it doesn't remove the need for a multiplexer anyway since there's only one channel.