Friday Facts #402 - Lightspeed circuits

[mrvn]

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).

I agree there is no way to get around each outpost needing a radar (if it wants to send something). But why should each outpost require their own channel?

To recap: The wireless transmission just replaces one (pair of) wire between all senders and receivers on a surface. With channels each channel replaces one such network of wires.

So do you actually have a separate wire going long distance from your main base to each outpost? That would be a lot of wires going into the main base and require a large switching circuit there to handle all those wires. Well, you can still use that switching circuit like now except all the long distance wires just go into a radar instead. Lots of radars at the switch board but if you want that many separate channels that's the price you pay for it in the simplest channel implementation.

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.

I don't think this has to be as difficult and confusing as you say. The radar would have a widget to choose an existing channel or to create a new one. That can be sorted alpanumerically and have a search button and everything to make using it as a human simple. Each time you create a new channel it would also get an ID that would be displayed somewhere when the channel is selected in the radar or in the list of channels. Lots of ways to show that ID. The ID would remain constant for that channel over time.

Now for the circuit interface you would simply select channels by ID. The name is just for humans. So the "Set channel" mode would have a selector what signal to use, e.g. "S" and then sending S=3 would select channel with ID 3.

Now it is easy to loop through all channels with a clock. The only messy bit is skipping channels you aren't interested in. If you want to scan only channels 7, 23 and 42 then you have some work to do to generating those IDs in a loop. Or just use 3 radars/antenna.

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.

The thing is that with a radar that has multiple channels you can write a mod that has scanning radars and non-scanning antennas and set their power requirements any way you like. It's easy to disable the GUI popup for the radar so the antenna part can't be used in it if the prototype has no way to disable it in the first place.

A radar with channels gets you what you want, although with some modding, while a radar without channels will not get you channels no matter what. I know what I want. Let the game devs work on channels and some modder can make you your separate antennas in an hour. Surely the existing wireless mods will jump at using the new radar to implement their mods if it's capable enough.

[mmmPI]

I agree there is no way to get around each outpost needing a radar (if it wants to send something). But why should each outpost require their own channel?

Because otherwise you need to do the thing that people wish to avoid when suggesting multi ID radar, aka multiplexing , be it with a clock or not.

To recap: The wireless transmission just replaces one (pair of) wire between all senders and receivers on a surface. With channels each channel replaces one such network of wires.

Wireless transmission replace a green and a red wire between all radar.

So do you actually have a separate wire going long distance from your main base to each outpost? That would be a lot of wires going into the main base and require a large switching circuit there to handle all those wires.

No because there is only 2 color of wire unlike many channel as proposed when considering giving a name to every single network. I run 2 wire and the wireless transmission is meant to alleviate that in case of minimalist setup.

Now of course if your habits is to run 2 red wire and 2 green wire because you need all those data absolutly and can't do with a machine only half fast, then having the ability to not run any wire at all may become an incentive to you that seem to use circuit a lot, to a do a bit more efficient circuit, so you could fit all datas in the single wireless network.

I don't think this has to be as difficult and confusing as you say. The radar would have a widget to choose an existing channel or to create a new one. That can be sorted alpanumerically and have a search button and everything to make using it as a human simple.

Each time you create a new channel it would also get an ID that would be displayed somewhere when the channel is selected in the radar or in the list of channels. Lots of ways to show that ID. The ID would remain constant for that channel over Now for the circuit interface you would simply select channels by ID. The name is just for humans. So the "Set channel" mode would have a selector what signal to use, e.g. "S" and then sending S=3 would select channel with ID 3.

Now it is easy to loop through all channels with a clock. The only messy bit is skipping channels you aren't interested in. If you want to scan only channels 7, 23 and 42 then you have some work to do to generating those IDs in a loop. Or just use 3 radars/antenna.
time.

That don't sound simpler to me than just considering all radars are connected by an invisible red and green wire.

This sound more confusing that anything else that was proposed on this page, and still requiring multiplexer, so pretty pointless considering the main argument to multi channel ID is to skip the need for multiplexer altogether to make things simpler.

The thing is that with a radar that has multiple channels you can write a mod that has scanning radars and non-scanning antennas and set their power requirements any way you like. It's easy to disable the GUI popup for the radar so the antenna part can't be used in it if the prototype has no way to disable it in the first place.

A radar with channels gets you what you want, although with some modding, while a radar without channels will not get you channels no matter what. I know what I want. Let the game devs work on channels and some modder can make you your separate antennas in an hour. Surely the existing wireless mods will jump at using the new radar to implement their mods if it's capable enough.

Aren't you aware there already exist mods with multi channel radar ? and mod with antenna ? and mod with non scanning radar ? I like those mods ! they are great ,i have played with many ! But here we are considering the non-modded game experience for players i thought.

Edit : This is part of the space exploration mod it works like multi ID channel for radar :
https://mods.factorio.com/mod/aai-signal-transmission

[mrvn]

So do you actually have a separate wire going long distance from your main base to each outpost? That would be a lot of wires going into the main base and require a large switching circuit there to handle all those wires.

No because there is only 2 color of wire unlike many channel as proposed when considering giving a name to every single network. I run 2 wire and the wireless transmission is meant to alleviate that in case of minimalist setup.

Now of course if your habits is to run 2 red wire and 2 green wire because you need all those data absolutly and can't do with a machine only half fast, then having the ability to not run any wire at all may become an incentive to you that seem to use circuit a lot, to a do a bit more efficient circuit, so you could fit all datas in the single wireless network.

If you only run one pair of wires across your map then you only have one big network and you would only use one channel and probably name that "default" or whatever the default name will be. Because why change it if you ever only have one. Don't touch it at all and just use the defaults the game already will have.

The whole wish to have multiple channels is for games where you have more than one pair of wires going long distance where they must not touch.

The proposed radar with no channels alleviates that use case of a minimalist setup with just 2 long distance wires. A far too limiting setup many people feel.

I don't think this has to be as difficult and confusing as you say. The radar would have a widget to choose an existing channel or to create a new one. That can be sorted alpanumerically and have a search button and everything to make using it as a human simple.

Each time you create a new channel it would also get an ID that would be displayed somewhere when the channel is selected in the radar or in the list of channels. Lots of ways to show that ID. The ID would remain constant for that channel over Now for the circuit interface you would simply select channels by ID. The name is just for humans. So the "Set channel" mode would have a selector what signal to use, e.g. "S" and then sending S=3 would select channel with ID 3.

Now it is easy to loop through all channels with a clock. The only messy bit is skipping channels you aren't interested in. If you want to scan only channels 7, 23 and 42 then you have some work to do to generating those IDs in a loop. Or just use 3 radars/antenna.
time.

That don't sound simpler to me than just considering all radars are connected by an invisible red and green wire.

This sound more confusing that anything else that was proposed on this page, and still requiring multiplexer, so pretty pointless considering the main argument to multi channel ID is to skip the need for multiplexer altogether to make things simpler.

If you don't need channels then you never have to touch them. Surely there will be a default channel and each radar will default to that channel when build. Just attach your red or green wire and you are ready to go.

If you don't need channels you never have to bother with them and nothing changes for you at all if the game supports channels for radars. It only affects those people that want to do more.

The thing is that with a radar that has multiple channels you can write a mod that has scanning radars and non-scanning antennas and set their power requirements any way you like. It's easy to disable the GUI popup for the radar so the antenna part can't be used in it if the prototype has no way to disable it in the first place.

A radar with channels gets you what you want, although with some modding, while a radar without channels will not get you channels no matter what. I know what I want. Let the game devs work on channels and some modder can make you your separate antennas in an hour. Surely the existing wireless mods will jump at using the new radar to implement their mods if it's capable enough.

Aren't you aware there already exist mods with multi channel radar ? and mod with antenna ? and mod with non scanning radar ? I like those mods ! they are great ,i have played with many ! But here we are considering the non-modded game experience for players i thought.

Edit : This is part of the space exploration mod it works like multi ID channel for radar :
https://mods.factorio.com/mod/aai-signal-transmission

That's exactly what I'm talking about and using. Those mods are there because spamming wires everywhere is just annoying and they do have channels because replacing just one wire pair globally just isn't enough.

Clearly the devs learned that wireless transmission is something people want. Saddly they haven't learned that people have more than one long distance wire network.

[Qon]

For me, having more channels means I can develop a protocol for global communication through channel 1, build it and then experiment with designs for v2 on channel 2 and then deploy that to new outposts without having to remove everything running on v1 channel 1 first. And I can have 2 or more prototypes being developed in parallel to compare them without them interfering with each other and the legacy networks that are already deployed. I can make systems communicating via a protocol over a single shared signal, but no one can make a legacy system that wasn't designed for interference from v2 of the protocol not get disrupted by the development, testing and deployment of v2 without also compromising how v2 is designed. So while actually building a factory the single channel is a limitation that can't really be worked around unless you start with the end game solution and never update your solution for sharing a channel.

[mmmPI]

I am still not convinced that adding ID to channel on radars would not cause a situation where players have a strong incentive to build arrays of radars. Which is worse in my eyes than both current situation with minimalist approach or antenna approach with dedicated entity for multi channel.

I have quite well understood how easier it would make things. Repeating it over and over doesn't make this point stronger to me in regard to the previous. Because it doesn't adress it.

I'm not against multi channel entity for the sake of it, i just think that simply adding sticking it to the radar is not the best possible choice. To me that's like some player need chairs, some others want ladders, a chair that is the size of half a ladder, would not be very useful.

[Qon]

I am still not convinced that adding ID to channel on radars would not cause a situation where players have a strong incentive to build arrays of radars. Which is worse in my eyes than both current situation with minimalist approach or antenna approach with dedicated entity for multi channel.

I have quite well understood how easier it would make things. Repeating it over and over doesn't make this point stronger to me in regard to the previous. Because it doesn't adress it.

I'm not against multi channel entity for the sake of it, i just think that simply adding sticking it to the radar is not the best possible choice. To me that's like some player need chairs, some others want ladders, a chair that is the size of half a ladder, would not be very useful.

I agree.

I'm asking for channels, but I agree that radars are not the best fit. Shortwave mod has a 1x1 entity that doesn't require power and has 2^32 channels for every signal type. I prefer that, so I'm using that mod.

Energy free wireless connection isn't necessary, but 300kW seems like too much when used for each small production cell a fraction of the radars always discovered area.

Combinators are already too big to fit if used extensively, and radars with channels would be a reason for having several in close proximity. But that just makes the power draw and size even bigger problems.

[wizcreations]

The two inserters behind the Foundry grabbing gears from on top of the Foundry look weird clipping through the Foundry graphic.

Inserters

Untitled.png (327.79 KiB) Viewed 931 times

[FuryoftheStars]

The two inserters behind the Foundry grabbing gears from on top of the Foundry look weird clipping through the Foundry graphic.

Untitled.png

28783

Because this is a 2D game faking 3D, you can't have them behind the Foundry on one side while on top of them on the other....

[MeduSalem]

The two inserters behind the Foundry grabbing gears from on top of the Foundry look weird clipping through the Foundry graphic.

Untitled.png

28783

Because this is a 2D game faking 3D, you can't have them behind the Foundry on one side while on top of them on the other....

You can do it, but it would require the foundry sprite to be cut into pieces and parts of it put on different layers to have more freedom over the drawing order. The devs likely think it is not worth the effort (and I agree with that).

[FuryoftheStars]

The two inserters behind the Foundry grabbing gears from on top of the Foundry look weird clipping through the Foundry graphic.

Untitled.png

28783

Because this is a 2D game faking 3D, you can't have them behind the Foundry on one side while on top of them on the other....

You can do it, but it would require the foundry sprite to be cut into pieces and parts of it put on different layers to have more freedom over the drawing order. The devs likely think it is not worth the effort (and I agree with that).

You're not helping....



(I mean, I know that, but that wasn't the point. )

[MeduSalem]

You're not helping....



(I mean, I know that, but that wasn't the point. )

Well, I can't help it. It falls right into my discipline. At least somewhere studying geometry for over 10 years needs to shine. ^^

I know it wasn't the point, but I think people deserve a honest explanation for why the game is likely always going to have some minor graphical "artifacts". The proper explanation is "because it is not worth the effort", or it being an oversight. ^^

[Svip]

The two inserters behind the Foundry grabbing gears from on top of the Foundry look weird clipping through the Foundry graphic.

Untitled.png

28783

Because this is a 2D game faking 3D, you can't have them behind the Foundry on one side while on top of them on the other....

You can do it, but it would require the foundry sprite to be cut into pieces and parts of it put on different layers to have more freedom over the drawing order. The devs likely think it is not worth the effort (and I agree with that).

It's actually more trivial than that. You can just decide that any object with an y coordinate "higher" than the foundry's top position appears behind it, and everything else appears in front of it. Looks like inserters just have a higher z index than the foundry, but making it variable depending on their relative position is not too complicated. It of course depends on how the code is laid out, how likely that is. But you would not need to split the sprites for a simple fix like this.

[FuryoftheStars]

[...] I think people deserve a honest explanation for why the game is likely always going to have some minor graphical "artifacts". The proper explanation is "because it is not worth the effort" [...]

I feel like the bug thread in the "Won't Fix" category that I linked to kind of does that.

[mmmPI]

If there was a distinction between "can't fix" and "wont fix", i think there would be room for arguments about the technical viabilities of the suggestions. It's probably not recommended, because there could be many arguments asking to move from one to the other, and devs couldn't adress them all and explain, but in case,i thought there could be some puzzles that suggestions would then need to adress while in queue for devtime , before they go to next level and gain some points as a way to improve along the way. I thought of a boss at the end :

Inserters drawing logic boss level 3000

Physics.jpg (124.16 KiB) Viewed 750 times

with a little backstory :

The agile inserter sometimes will do some 360° loops to grab the stone. It defies drawing order, clipping, and physics. Legend says only suggestions that are also 3D masters can dodge some of the worst paradox, and prevent them to occur in the first place. It takes at least 3 dimensions to make sure that only logical things would be attempted for drawing ; But it comes with daring consequences, it could cause characters to get hit by inserters when they swing !
If the techniques of the 3D collision boxes are not properly executed then there may happen a moment where both the character and the inserter would be at the same location at the same time, and then there would be no way to draw the resulting state, that's the boss most feared attack. If this situation can occur, there will be graphical glitches. Because there shouldn't be 2 things like "power pole" and "inserter" being in a superposed state at the same place. There are some 2Ds master known to have beaten that boss in other galaxies without any 3D colision box, (those makes 2D master lose lots of their speed and performance ) , but they used controversial techniques such as "not placing moving things next to tall things", sometimes considered lame.

[Nidan]

If there was a distinction between "can't fix" and "wont fix", […]

And then we get posts pointing at any 3D engine showing that such situation could be properly rendered to get it moved out of "can't fix". Or on how to attach height information to every sprite and moving part and use the fixed perspective to reduce the ordering problem to minimizing y + z/2 or something like that, while running afoul of every place where perspective was faked in a different way… I think I can do without that, let's stick with layered sprites.

Inserters drawing logic boss level 3000

Trivial

Do a 360, then render the inserter above the remnants.

polerender.png (82.01 KiB) Viewed 734 times

[MeduSalem]

It's actually more trivial than that. You can just decide that any object with an y coordinate "higher" than the foundry's top position appears behind it, and everything else appears in front of it. Looks like inserters just have a higher z index than the foundry, but making it variable depending on their relative position is not too complicated. It of course depends on how the code is laid out, how likely that is. But you would not need to split the sprites for a simple fix like this.

Well I partly agree... taking Factorio's projection as an example... an object with Y coordinate nearer to the top of the screen is "more likely" behind an object with Y coordinate that is more closer to the bottom of the screen.

But I write "more likely" under quotes; because there is no absolute guarantee for that always being the case for each object.

It will be the case only for objects (or parts of the object) that have a tall "height".
Like is the case for those specific parts to the top center&right of of the Foundry sprite.

But it would likely not be true anymore for the parts of the sprite parts to the left of the foundry that don't look as tall. ^^
And it would look totally awkward for most other machines that are not as tall, like the Rocket Silo, Assemblers, etc.
Then you would have the opposite "artifact" where it looks like an inserter is grabbing "underneath" the machine sprite and people would complain that that looks stupid as well.

So a general rule only depending on Y coordinates of sprites cannot easily be applied without causing artifacts for either tall buildings or for short buildings. It is either one or the other and currently the devs give priority for better looks on short buildings (and rightfully so because most of them are rather... flat). ^^

It totally depends on how tall the individual parts of the objects are. And for that you kinda have to swallow the bitter pill (if you want a perfect solution) that it can only really be solved by cutting up the sprite and putting the specific conflicting parts on a different drawing layer so that they can be rendered in an individual order.


A "compromise" solution could be to have 2 layers for the inserters; one for tall buildings, one for short buildings. So you can decide whether you want to draw the inserters above or below machines. Then you would not have to cut the machine sprite into bits. But it would require an additional check for each inserter to see what the neighboring building is like to make that decision.
But it would only be a compromise, because if the building is not equally tall/short across its width there may be still be odd artifacts.

And damn it would be some real dark & messy code to fake it like that. Hence why I think it is not worth it. xD


Anyway the "height" of stuff really causes headaches if you go for pure sprite based graphics like Factorio does. ^^


So I don't wonder that many games which try to use 2D projections nowadays actually are still 3D polygon games with a locked camera angle; but because objects are actually 3d polygon objects you can always refer to the z-buffer for the polygons to determine the proper drawing order and don't have to mess around with layering issues of sprites. (apart from the other issues that sprite games have)

[FuryoftheStars]

Love that "after" image.

[ryanalpasta]

The only problem with crafting faster than light, is you live in the darkness. Hello darkness here I come.

[mmmPI]

And then we get posts pointing at any 3D engine showing that such situation could be properly rendered to get it moved out of "can't fix". Or on how to attach height information to every sprite and moving part and use the fixed perspective to reduce the ordering problem to minimizing y + z/2 or something like that, while running afoul of every place where perspective was faked in a different way… I think I can do without that, let's stick with layered sprites.

Now that you say so , there is already height information attached to prevent elevated rails above "tall things" , similar to 3D collision box. I didn't thought of those situations when neither the rails nor the tall things like refinery are moving in and out of their tile. " static 3D collision box" Whereas your funny picture illustrate very well what i think should happen with more realistic collision boxes on things moving out of their tile next to taller things in an attempt to be more precise, those i think, maybe wrongly , would being necessary for stricter definition of "what's visible at the top layer", to prevent 2 things overlapping or getting through each other, because otherwise it would look weird no matter what and there's no way to tell "what's at the top layer". I'm was speculating there. I'm not when saying i like the current layered sprites system.

So I don't wonder that many games which try to use 2D projections nowadays actually are still 3D polygon games with a locked camera angle; but because objects are actually 3d polygon objects you can always refer to the z-buffer for the polygons to determine the proper drawing order and don't have to mess around with layering issues of sprites. (apart from the other issues that sprite games have)

Those would not necessarily result in broken power pole if they surround a long handed inserter, but it would look glitchy still if they are allowed to clip through. Those games you refer to oftimes will allow such things and use a hitbox only at the floor level for the whole unit, like biters, but the individual teeth spikes and legs could still be a little outside the collision circle during some animation and clip through the neighbouring units. The shape of a rotating long handed inserter is terrible , one would have to measure what can fit underneath to really avoid all collisions and glitches and it's different in every swing with the pseudo random lottery picker shape of the belts used for the boss picture, i tried to make the worst situation i could think of

[FasterJump]

It's actually more trivial than that. You can just decide that any object with an y coordinate "higher" than the foundry's top position appears behind it, and everything else appears in front of it.

Is there a reason this can't be done? That looks simple enough.Why not render sprites from top (north) to bottom (south), the latter displaying over the former?