Friday Facts #402 - Lightspeed circuits

[MeduSalem]

I guess for most of my circuit network stuff having 1 channel for each green/red will suffice.

Mostly I am going to use it for trying to dynamically adjust the priorities of trainstops for outposts depending on how much ore there is left in an outpost in relationship to total ore of all outposts so that all outposts will be drained more or less equally fast.
For all other outpost uses the 2.0 train schedule stuff with interrupts will likely be good enough for me to do without circuit network.

If there will be more uses (wireless) circuit network for me depends on how writing/reading from the wireless network works like.


But I get that other people may have greater circuit network needs; so I think additional transmission channels could probably be a thing for research.


Also as other people, I wonder how circuit network transmission between planets will be like.




And holy damn... that crafting speed on the Foundry is ridiculous. The flickering looks sooo bad it hurts my eyes. I hope you consider changing the animation of that or something. Or as someone already wrote in the thread... have a static animation & just display a static items/sec number once it is that fast. ^^

[FuryoftheStars]

And holy damn... that crafting speed on the Foundry is ridiculous. The flickering looks sooo bad it hurts my eyes. I hope you consider changing the animation of that or something. Or as someone already wrote in the thread... have a static animation & just display a static items/sec number once it is that fast. ^^

I also feel like the speed at which those (what I assume to be Q5) (new) stack inserters are flicking around at is ridiculous. I know that's probably a me thing, but the whole setup (to include the belts, even) running at that speed just looks like crap to me.

[mrvn]

To multiplex channels onto the radar you need a clock. And beware the fool that uses a local clock to demultiplex the data. One power outage and the clocks will get out of sync.

That's the issue though, right? You're not removing the issue of multiplexing, you're just shifting it from groups of signals to channels.

If the radar has multiple channels then there is no need to multiplex signals onto a single channel. And you can give the channels nice names like: Ore Remaining, Accumulator Storage, Trash Items. No need to multiplex them and then get confused what signals at T=3 where supposed to be.

[mrvn]

To multiplex channels onto the radar you need a clock. And beware the fool that uses a local clock to demultiplex the data. One power outage and the clocks will get out of sync.

You hit the nail.
To enable multi channel wireless communication, you need connect those location with a wire.

No, you just send the clock on the radar as the T signal. Then the destination can pick out the right channel with a decider "T=X: each". You only have to deal with the fact that you only get a signal some of the time so you probably want to latch it.

[mrvn]

To multiplex channels onto the radar you need a clock.

Wrong.

And beware the fool that uses a local clock to demultiplex the data. One power outage and the clocks will get out of sync.

In fact, you should avoid clocks if you know how because these are just some of the issues you might come across.
You can fairly easily prevent power outages from being possible so that is a very minor point.

Giving time slots on a clock is just very inflexible. When having a varying amount of endpoints to mux and demux from and to and when trying to dedicate communication time to endpoints at a flexible as-needed schedule with flexible as-needed lengths of time and with endpoints signaling that they are requesting the channel with different queuing priorities, a clock is a disruption to all those goals. Also my clockless de/mux system allows dynamic end point grouping to broadcast to and aggregate data from.

Oh, you want to reimplement an ethernet HUB with a broadcast domain (everything on a surface) and collision detection and all that stuff. Now talk about complex.

I rather just have channels on the radar where I can name one set of signals "Remaining ore" and be done with it. Even if you don't have any collisions stuffing all long distance signals into a single red/green pair gets annoying fast. Try finding the copper ore count when you have 200 signals on the wire that change and thus swap positions every second. Not to mention half the signals will be invisible because my screen size is too small to fit them all.

[mmmPI]

To multiplex channels onto the radar you need a clock.

Wrong.

And beware the fool that uses a local clock to demultiplex the data. One power outage and the clocks will get out of sync.

In fact, you should avoid clocks if you know how because these are just some of the issues you might come across.
You can fairly easily prevent power outages from being possible so that is a very minor point.

Giving time slots on a clock is just very inflexible. When having a varying amount of endpoints to mux and demux from and to and when trying to dedicate communication time to endpoints at a flexible as-needed schedule with flexible as-needed lengths of time and with endpoints signaling that they are requesting the channel with different queuing priorities, a clock is a disruption to all those goals. Also my clockless de/mux system allows dynamic end point grouping to broadcast to and aggregate data from.

Oh, you want to reimplement an ethernet HUB with a broadcast domain (everything on a surface) and collision detection and all that stuff. Now talk about complex.

I rather just have channels on the radar where I can name one set of signals "Remaining ore" and be done with it. Even if you don't have any collisions stuffing all long distance signals into a single red/green pair gets annoying fast. Try finding the copper ore count when you have 200 signals on the wire that change and thus swap positions every second. Not to mention half the signals will be invisible because my screen size is too small to fit them all.

Imagine you have 10 outpost, which have a name "I to 10" , then you have a central place, who broadcast on the channel [A] 7, and then next tick [iron ore] 1 , then the third tick outpost 7 output, [iron ore] 35 230. Congrats you just passed messages wirelessly without shared clock. You just have responsive outpost that can act as memory cell with adress and be read. It's not that complex when comparing with clocked mux and does't require reimplementing ethernet HUB nor collision detection and all that stuff.

You can use this to probe for remaning ore in an outpost when you want instead of having a fixed slot allocated on a clock that would say count up to 1000 and each oupost would be given its special frame to ouput the remaining ore. This is suited if you need all values with the same update interval all the time. But part of the challenge is making the most out of the limited bandwidth

[pleegwat]

To multiplex channels onto the radar you need a clock. And beware the fool that uses a local clock to demultiplex the data. One power outage and the clocks will get out of sync.

You hit the nail.
To enable multi channel wireless communication, you need connect those location with a wire.

No, you just send the clock on the radar as the T signal. Then the destination can pick out the right channel with a decider "T=X: each". You only have to deal with the fact that you only get a signal some of the time so you probably want to latch it.

You also have to account that if you are sending on clock 7, you need to latch the receiver on (probably) clock 8.

[Qon]

Giving time slots on a clock is just very inflexible. When having a varying amount of endpoints to mux and demux from and to and when trying to dedicate communication time to endpoints at a flexible as-needed schedule with flexible as-needed lengths of time and with endpoints signaling that they are requesting the channel with different queuing priorities, a clock is a disruption to all those goals. Also my clockless de/mux system allows dynamic end point grouping to broadcast to and aggregate data from.

Oh, you want to reimplement an ethernet HUB with a broadcast domain (everything on a surface) and collision detection and all that stuff. Now talk about complex.

I rather just have channels on the radar where I can name one set of signals "Remaining ore" and be done with it. Even if you don't have any collisions stuffing all long distance signals into a single red/green pair gets annoying fast. Try finding the copper ore count when you have 200 signals on the wire that change and thus swap positions every second. Not to mention half the signals will be invisible because my screen size is too small to fit them all.

My blueprint support the features I mentioned and more. Automatic collision checking with backoff of all except 1 endpoint in O(log n) time, clockless. Automatic ID and coordinate calculation of endpoints. Simple equation (circle/linear) evaluation for positional query, making the grid of endpoints basically work pixels of a GPU, visible on the map. Simple bitmask memory and also full RAM that can be de/muxed on as well as doing read and write operations from and to, to save group state and doing complex multi-state queries. Also nearest neighbor communication channels.

I already have this. But I've still argued for more channels on radars, because it's a convenience feature and making it better doesn't actually eliminate the need for my "router" blueprint anyways, since this is dynamic and more static channel connections on the radar can't do what my router can. Shortwave mod has a "signal type" and number for selecting channel, but it is configured via GUI only, there's no wire input that can rewire it to another channel. It's actually less dynamic since it doesn't require power so it isn't connected on some some dynamic condition.

[Unknow0059]

Finally the circuit wires get copypasted. Took long enough. These quality of life changes seem very random compared to how other kinds of decisions are made.

"It was affecting me rather than the entirety of the playerbase that has been using this, so I decided to finally fix it"

In the end it's a good outcome, but after a frustrating duration.

[Loewchen]

Finally the circuit wires get copypasted. Took long enough.

Circuit wires can be copy pasted since copy paste exists.

[mrvn]

Finally the circuit wires get copypasted. Took long enough.

Circuit wires can be copy pasted since copy paste exists.

Go read the FFF and you will know what he is talking about.

[mrvn]

And with channels in radars that whole big circuit contraption would look like this:

radar.png (32.39 KiB) Viewed 764 times

Now wouldn't that be simpler?

[mmmPI]

Yes it would be much simpler no doubt, i think no-one argued that it would be more complicated so far. But it would also give an incentive to player to stamp array of radars next to each other.

[Aapjuh]

"..worked correctly the first try. That's not supposed to happen and left me with doubts."

I chuckled at this part, it hit home so hard.
~This can't be right..
~Something MUST be wrong..
~I bet it will break tomorrow..

[Hognose9]

I think it would be cool if satellites could be used for long distance communication.
If the wireless radar circuit range is the same as the radar range, then you'd still need a line of them to send signals really long distances.
But what if the radar could send a signal to a satellite, which then beams it back down across the entire planet.
This could also be a requirement to control bots on other planets.

[bnrom]

Having multiple nameable channels would be a huge improvement in usability over the current suggested feature of just a single channel per surface, and I don't yet see any meaningful disadvantages to providing that usability.

In terms of using the radar, having multiple named channels feels a lot simpler than trying to fit multiple channels worth of information into a single global channel. And I don't think there is any meaningful configuration cost to having multiple channels either; the first channel could always be selected by default.

One potential concern is that adding multiple channels per surface removes a potentially interesting and fun challenge from the game (namely pumping multiple channels worth of data through a single channel, e.g. by using a multiplexer). However, upon reflection, I don't think this concern is actually an issue.

• First, I don't think building a multiplexer is a particularly interesting or fun challenge, and inevitably most players will look up how to build such a thing / build it once, and then there is this constant on-going annoyance of having to configure, and reconfigure, and remember all the details of the virtual channels (e.g., channels 1-3 are ore, but then I added another base latter so channel 8 is also ore, but then I had to reconfigure the clock, etc...). The resulting circuits will likely be brittle, hard to understand and fiddly - and none of that seems fun.
  
  Second, if each radar can only use one channel (selected from the list of named channels) then people would still potentially want to build a multiplexer so as to allow the number of radars used to not scale with the amount of outposts, etc... One could even imagine a system where the channels have IDs that can be set via the circuit network, allowing the surface channels to be switched between via a clock. This setup would effectively recreate the effects of a multiplexer but have a huge amount more usability and debug-ability (for one, the channels would be named).

I think it would be far better to take the nameable multi-channel approach, and let the interesting complexity come from making channels and circuits easy to use, and then people setting themselves ambitious tasks enabled by such ease of use. Casual players would start to use circuits more, even potentially trying things only previously done by the most hardcore circuit users, and the hardcore circuit users would push their designs further still.

This approach of streamlining ease of use and letting complexity naturally arise seems to generally be the approach of the so far revealed 2.0 trains and combinators changes, and I think in general that this usability focus is great for the game.

[Qon]

And with channels in radars that whole big circuit contraption would look like this:

radar.png

Now wouldn't that be simpler?

Wrong. Like I said in the post you quoted, my router is dynamic. For the particular use case it's designed to handle, more static channel connections don't really help that much.

[Justderpingalong]

This one felt... surprisingly short.

One thing I will say however is that the simple addition of being able to hook radars into the wire network is GREAT. It should allow a full implementation of LTN, which I am glad for. However: I'd like to offer an improvement:

Currently, red and green circuits have a 'circuit ID'. What if we used this circuit ID to create distinct channels? Could be a simple if/else for both red and green. Either you use the circuit ID you're given as your channel, or you connect to a different circuit ID, of which you can copy/paste the numbers. Simple!

The circuit ID changes when you connect or split circuit networks. Would be horrible to program all receivers every time you play with the wires of the sender.

I genuinely didn't realize that the circuit ID changed every time you connected something. That'd obviously have to be fixed if this were to be implemented.

[mmmPI]

Having multiple nameable channels would be a huge improvement in usability over the current suggested feature of just a single channel per surface, and I don't yet see any meaningful disadvantages to providing that usability.

That's what i thought at first, that no multi-channel was a missed opportunity. And then the simplest option would be to just add a setting on radar like train station with name and unique ID.

But when considering just that single suggestion over the announced feature, i found it had shortcomings, it seem like a fix applied on something rather than a fully planned feature. Which is not adressing as well as possible the concern that would spark the suggestion to change the annouced feature which is to my eyes better integrated in the game than "the same just with channel ID" would be. A proper integration of channel ID (imo) require much more than what people seem to realize i thought. And you gave some points that may help illustrate what you may have missed as a meaningful disadvantage because i don't see them adressed, solved or waived over even mentionned.

The argument for is : "it would simpler".( to do .... ). But it's not even true in my opinion and i think your point shows why :

Second, if each radar can only use one channel (selected from the list of named channels) then people would still potentially want to build a multiplexer so as to allow the number of radars used to not scale with the amount of outposts, etc... One could even imagine a system where the channels have IDs that can be set via the circuit network, allowing the surface channels to be switched between via a clock. This setup would effectively recreate the effects of a multiplexer but have a huge amount more usability and debug-ability (for one, the channels would be named).

That is not corret, as if you have multiple oupost, the number of unique wireless transmitter is bound to scale with them. You will have at least as many radar as outpost wether or not they have unique channels.

The number of radar in the main base hypothetically can be just 1, and then switch to different channel for the different outpost but that is yet another modification required, that channel can have a name 1) and that this name be made dynamic 2).

However, in practice, how can you tell a radar to start using channel "defense perimeter north" using circuit ? To me that seem difficult. It would be possible if you have a list of every channel with name, and use the circuit to set which one to use via its number in the list because you can't transmit names by circuit. But then everytime you add a new channel it would be at the bottom of the list, it would be difficult to find them, all messy, or their number will change forcing you to reconfigure everything. That seem at least as "bad" same as what you described in your hypothetic clock system and ordering of frame.

And again as you say that would require a multiplexer to avoid scaling the number of radar to be twice the number of outpost and keep just (n+1) radars . It would also require complicated logic to change those channel via circuit, even if there was a way to do so, which is to me the reason why people would want multi channel in the first place, to skip the "complexity" of multiplexer. But you can't do that if you don't have twice as many radar as outpost. And this means you will have a place with many radars all next to each other to read the quantity from each outpost. This or the existence of a multiplexer is a no alternative to me.

Casual players would start to use circuits more, even potentially trying things only previously done by the most hardcore circuit users, and the hardcore circuit users would push their designs further still.

Casual player if they don't use multiplexer would be handed a feature that has strong incentive to create "ugly contraption" filled with radars. Just adding channel ID without changing the radar itself is not enough i think, its the "fix" that doesn't "fix" as well as the concept of antennas or dedicated entity designed only for that purpose that would be more adapted than the current 3x3-scanning-tile-power-hungry-radar.

Not sure what you refer to by hardcore, i'm not casual because i use combinators a lot, but that doesn't mean i'm super skilled with them, and regularly other user show me how to improve my things, for me it would make making large contraption with combinators ugly, compared to using modded smaller entity that wouldn't draw large amount of power or scan tile or be 3x3, when trying to design things only with combinators in editor mode. That may be hardcore, in such case the suggested feature is not usable enough, it would sit in between and force me to use clunky entity that seem not designed for the purpose i''d be using them. "too much for normal gameplay" "too little for editor mode gameplay". When it could be split into antenna and radar, if that was really the concern. Multi channel radar without any other change to me is the worst compared to full commitment to wireless signal with dedicated antennas, or curent minimalist approach that mimic the logistic network with only 1 channel per surface similar to 1 channel per logistic network.

[mrvn]

This one felt... surprisingly short.

One thing I will say however is that the simple addition of being able to hook radars into the wire network is GREAT. It should allow a full implementation of LTN, which I am glad for. However: I'd like to offer an improvement:

Currently, red and green circuits have a 'circuit ID'. What if we used this circuit ID to create distinct channels? Could be a simple if/else for both red and green. Either you use the circuit ID you're given as your channel, or you connect to a different circuit ID, of which you can copy/paste the numbers. Simple!

The circuit ID changes when you connect or split circuit networks. Would be horrible to program all receivers every time you play with the wires of the sender.

I genuinely didn't realize that the circuit ID changed every time you connected something. That'd obviously have to be fixed if this were to be implemented.

Say you have 2 circuit networks: ID 1 and ID 2. Now you add a wire connecting the 2 circuits. Now either ID 1 has to become 2 or ID 2 has to become 1or both become ID 3 because now you only have a single circuit network. Similar when splitting a network, they can not have the same ID. There is no way to fix this.