Friday Facts #402 - Lightspeed circuits

[kadashov]

I would add a separate antenna for wireless transmission.

[bobucles]

I would add a separate antenna for wireless transmission.

Would it add any new features that a wireless radar can't already do? Or rather, is a wireless antenna needed because the radar gets in the way of some vital function?
I could see there maybe being a need for a local vs. global network. For example every outpost has a tiny combinator rig doing its thing, and if they all collided on the global network it'd be a real mess. But that sort of thing can be resolved by just not wiring into the global network, right?

[mmmPI]

I would add a separate antenna for wireless transmission.

Would it add any new features that a wireless radar can't already do? Or rather, is a wireless antenna needed because the radar gets in the way of some vital function?
I could see there maybe being a need for a local vs. global network. For example every outpost has a tiny combinator rig doing its thing, and if they all collided on the global network it'd be a real mess. But that sort of thing can be resolved by just not wiring into the global network, right?

You could have the radar act more as "radar" as in detecting things, like ennemies, or damaged vehicule or players in their vicinity and brodcast them in the circuit network.

And the antenna to act as a "transmitter" that you could set up to be local or not ,for its wireless transmission, using channel named like train station , with the possibility of being unique or not, maybe cross planet . And such antenna could be wired to the radar, so as to broadcast on a planet or another place on the same surface, if ennemies are detected in any other planet, so as to send some space platform there or something.

There's different ways mods inplemented wireless transmission. Sometimes as a radio signal repeater with a range, so it's an upgrade versus the wire , but not as strong as a late game tech that would also allow inter planetary transmission. The current system seem not "sandbox-friendly", as it would cost a lot of energy and scans things if radars are used just as transmitter , but reducing energy consumption must be easier to mod than creating efficient wireless transmission. I think a 1x1 radar that do not scan nor consume energy that player could just use them to transmit data would be used, but the fact that on the game there is only a 3x3 that cost energy and has 2 channels, it makes for a challenge/puzzle. It's already a lot for players who do not use combinators at all, for those who do, it's a like a balance in game for what would be otherwise a very strong mechanism. It's simple and "inefficient" in gameplay so as to put the player in charge of making a good system with simple bricks, "how to make the most of the limited bandwith" . and also "the limited bandwith do not require complicated protocol, everyone can easily try to use".

[Silari]

The final changes to make everything function correctly took about 1 hour to write, and worked correctly the first try. That's not supposed to happen and left me with doubts.

There's nothing scarier than code that works the first try, for the simple fact it's much less likely that you wrote it perfectly the first time than it is that you're simply not finding the horrible mistake you made.

[wild_dog]

I don't think radar signals are for people who are already using factory-wide signal networks. They are probably primarily intended at players who use circuit-wired rail blueprints "because", never use it, until at some point late in they find a usecase and then find out there are too many gaps in their network where they had to do a few meters of rail manually and their circuit network doesn't connect.

Yeah, it's a really funny use case. The feature for people who don't need the feature

Dury is right. Wireless network with one channel is either good for beta-testing testing or has very niche player usage.
Players who use combinators intensively, need more channels.

Players who use combinators intensively and need more channel can build caching multiplexers.
https://twitter.com/notch/status/1396378829971771400

[Seelo]

Wouldn't radars having channels actually make the circuits easier, outside of just transmission? Right now you can build many separate networks, your main concern is the chaos of cables it involves. If you add an entity with channels you add a way to simplify that chaos by separating the networks spatially (just plug every network to it's own respective radar.

Transmitting a lot of data a long distance was and still is a challenge, which makes you work on multiplexing or figuring out how to achieve your logic with less data channels needed.

It kind of baffles me how an item that just cuts long distance wires spawned a discussion about simplifying one of the challenges of the circuits.

Radars should just be a transmission device. Hell, they might make power switch useful now, with circuits deciding to "dial up" and connect to the radar network by powering their radar when a condition is met.

If I had to change a thing about radars in this FFF it could be a toggle that disables the scanning feature and allows you to just transmit circuit data at a lower power draw.

[mmmPI]

Wouldn't radars having channels actually make the circuits easier, outside of just transmission? Right now you can build many separate networks, your main concern is the chaos of cables it involves. If you add an entity with channels you add a way to simplify that chaos by separating the networks spatially (just plug every network to it's own respective radar.

Yes, it would then cause what you describe ( i think) "just plug every network to its own antenna". Which would be a shame for the wiring game, especially if it was the poor radar that have to do that with its 3x3 footprint and power draw. It would then make sense to have lot of radars next to each other to isolate networks.

Transmitting a lot of data a long distance was and still is a challenge, which makes you work on multiplexing or figuring out how to achieve your logic with less data channels needed.
It kind of baffles me how an item that just cuts long distance wires spawned a discussion about simplifying one of the challenges of the circuits.

You can expect players to never be satisfied , when you add something it's not enough and too much at the same time. When you go to simplify something it's dumbed down too much but still to complex and not fancy enough and so on.

Radars should just be a transmission device. Hell, they might make power switch useful now, with circuits deciding to "dial up" and connect to the radar network by powering their radar when a condition is met.

If I had to change a thing about radars in this FFF it could be a toggle that disables the scanning feature and allows you to just transmit circuit data at a lower power draw.

I think that is the stance that was choosen, radar as just transmission devices, but it is not known if doing so is a different mode that stop scanning/ power draw, it could very well be the case and as such the radar would act as an antenna. But on the other hand, the radars as revealed have way less incentive to be placed next to each other, since they all are from the same planetwide network, placing a second radar next to the first one is only saving 1 wire, it cannot be used to isolate (many) networks the same way as antenna would. So the scanning feature overlapping supposedly is less going to happen than it would with different channels entity. Even if there is no lower power draw mode, i think the radar is still a fit entity for the feature that it received. And i like the idea of the player powering up/down the radar when needed with automation and power switch

[Drury]

Wouldn't radars having channels actually make the circuits easier, outside of just transmission? Right now you can build many separate networks, your main concern is the chaos of cables it involves. If you add an entity with channels you add a way to simplify that chaos by separating the networks spatially (just plug every network to it's own respective radar.

Transmitting a lot of data a long distance was and still is a challenge, which makes you work on multiplexing or figuring out how to achieve your logic with less data channels needed.

It kind of baffles me how an item that just cuts long distance wires spawned a discussion about simplifying one of the challenges of the circuits.

Radars should just be a transmission device. Hell, they might make power switch useful now, with circuits deciding to "dial up" and connect to the radar network by powering their radar when a condition is met.

If I had to change a thing about radars in this FFF it could be a toggle that disables the scanning feature and allows you to just transmit circuit data at a lower power draw.

My whole angle is that it's a neat feature that ultimately doesn't change much. If the idea is to help people from placing long distance wires, well that's noble and all, but there's no need to bother since wires are free and effortless. If the idea is to improve on long distance transmission, well there's still only one channel so it's not much better than one wire - in fact, with the power of two wires, it becomes obsolete.

The multiplexing talk is just to highlight the actual problem with long distance transmission. Personally I don't actually think radars could solve this even with multiple channels. Like, now you can have 200 radars each tuned to a different channel with no lag? Maybe this is a problem worth looking into instead.

Also, I don't agree with the premise that circuit entities should be as simple as possible so we can have the "fun" of literally designing entire compute arrays from scratch just to know how much stuff exists or fits somewhere. I'm not sure the devs do either. They wouldn't be adding that magical "selector" combinator packed with a bunch of funky compute features literally telling you how much stuff fits somewhere if that were the case.

[cj_1601]

With these insane crafting speeds can we see easy access to a option to reduce game speed? It was already difficult to troubleshoot setups that ran at 'max speed' before. Looking at the demo video in this post, I can't tell what is going on at all. That or some feature built in to show detailed crafting statistics so it's easier to find where your bottlenecks may be. Or better yet, both features. Yes, I know it can be done with command lines and/or mods, with these new speeds it would only stand to reason yo have such capability in the base game.

[mrvn]

I would add a separate antenna for wireless transmission.

Would it add any new features that a wireless radar can't already do? Or rather, is a wireless antenna needed because the radar gets in the way of some vital function?
I could see there maybe being a need for a local vs. global network. For example every outpost has a tiny combinator rig doing its thing, and if they all collided on the global network it'd be a real mess. But that sort of thing can be resolved by just not wiring into the global network, right?

I want the radar to emit a signal every time it uncovers a chunk listing the X/Y coordinates, dX/dY relative to the radar and a count of alien nests, worms, biters and spitters. Signal for ores, rocks and trees could also be included.

[mrvn]

If I had to change a thing about radars in this FFF it could be a toggle that disables the scanning feature and allows you to just transmit circuit data at a lower power draw.

You can mod the radar prototype for that. Non-scanning radars have been a thing for a while.

[mrvn]

Wouldn't radars having channels actually make the circuits easier, outside of just transmission? Right now you can build many separate networks, your main concern is the chaos of cables it involves. If you add an entity with channels you add a way to simplify that chaos by separating the networks spatially (just plug every network to it's own respective radar.

Transmitting a lot of data a long distance was and still is a challenge, which makes you work on multiplexing or figuring out how to achieve your logic with less data channels needed.

It kind of baffles me how an item that just cuts long distance wires spawned a discussion about simplifying one of the challenges of the circuits.

Radars should just be a transmission device. Hell, they might make power switch useful now, with circuits deciding to "dial up" and connect to the radar network by powering their radar when a condition is met.

If I had to change a thing about radars in this FFF it could be a toggle that disables the scanning feature and allows you to just transmit circuit data at a lower power draw.

My whole angle is that it's a neat feature that ultimately doesn't change much. If the idea is to help people from placing long distance wires, well that's noble and all, but there's no need to bother since wires are free and effortless. If the idea is to improve on long distance transmission, well there's still only one channel so it's not much better than one wire - in fact, with the power of two wires, it becomes obsolete.

The multiplexing talk is just to highlight the actual problem with long distance transmission. Personally I don't actually think radars could solve this even with multiple channels. Like, now you can have 200 radars each tuned to a different channel with no lag? Maybe this is a problem worth looking into instead.

Also, I don't agree with the premise that circuit entities should be as simple as possible so we can have the "fun" of literally designing entire compute arrays from scratch just to know how much stuff exists or fits somewhere. I'm not sure the devs do either. They wouldn't be adding that magical "selector" combinator packed with a bunch of funky compute features literally telling you how much stuff fits somewhere if that were the case.

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.

[mrvn]

With these insane crafting speeds can we see easy access to a option to reduce game speed? It was already difficult to troubleshoot setups that ran at 'max speed' before. Looking at the demo video in this post, I can't tell what is going on at all. That or some feature built in to show detailed crafting statistics so it's easier to find where your bottlenecks may be. Or better yet, both features. Yes, I know it can be done with command lines and/or mods, with these new speeds it would only stand to reason yo have such capability in the base game.

You can single step your construction in the editor or run for N ticks. I too sometimes wish the Speed Control (or other) mod would include that feature for in-game though.

Is there a mod that can do that?

[Drury]

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.

[TheRaph]

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.

Well, no, I'm not sure it is the player. But it seems awfully close to the foundry to be another building, and not on the scale of most buildings, especially newer ones. So yeah, it was definitely giving me some sort of player backpack/armor vibes but again, to what end would the player build a dig-arm to carry around on their backs...?

Especially the idle animation. Buildings don't have idle animations when they aren't active... this to me is the biggest indicator that it is the player.

Do you think it could be an update to spider throne instead?

[Lur_id]

Hello. I have a few questions about military.
1. Does we can see new type of turrets: rocket turret or grenade launcher turret?
2. Will you be reworked different types of damages? I mean combat capsules, and their physical(tier 1), laser(tier 2), and electric(tier 3) damage. Or poison damage from Poison capsule?
3.1 Does we can see new research to damage boost all capsule types? Or maybe it can be merged to actual endless research, with new ballance? Maybe artillery endless researches can be merged in one?
4. Will unique types of enemies appear on the new planets? Is there a possibility of settling unique types of enemies on the planets visited by the player, through "stealth" incubation on a space platform? (Considering that lava biters can't take root on an ice planet, for example).
Its many-many questions about updating, improve and fixing military technologies. I would like to see one of 4 new planets dedicated about weapons, artillery, large amount of enemies and military technologies.

And general questions:
1. Factorio 2.0 (without Space Age DLC) will include only one planet - Nauvis?
2. New types of Foundries will be available only with Space Age DLC?
3. How will work presence or absence of DLC existence for different players in one multiplayer save?
3.1 Will the host be the one to set the rules (advanced research tree) for entire multiplayer save/map?

Finally, I want to thank you, the developers, designers and your entire team, for working on new content. I can't even imagine the amount of new features in Factorio 2.0. Thank you.

[FuryoftheStars]

The way I see it, when you consider the fact that you can still run long range wires as needed, this is your extra channel.

[EustaceCS]

I'll die to dehydration from all the drooling over FFF teased features well before expansion release.
Too much cool stuff.

[gGeorg]

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.

[Qon]

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.