Friday Facts #88 - Combinators

Regular reports on Factorio development.
Zeblote
Filter Inserter
Filter Inserter
Posts: 973
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #88 - Combinators

Post by Zeblote »

dee- wrote:
Remembers me of the lost race of making raster images (PNG) ever bigger to allow better zoom levels/details for images, where a vector image (SVG) could provide endless zoom while retaining the sharpness and details.

Wait - it's exactly the same that happends here :shock:

I'd really love to see the game entities implemented as vector 2D image arrays / do-it-right-3D objects with animation to break this cycle. VRAM usage would plummet.
It doesn't look like any of the machines could be vectorized without either making them look worse or take even more space though.

Albert
Factorio Staff
Factorio Staff
Posts: 55
Joined: Tue Apr 09, 2013 5:35 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by Albert »

Eirikaine wrote:These HD will be awsome but HD mean precision and i think this Steam Engine if really weird and really broken x)
If you look right on the bottom right, the part who look like an egg must be flying because the arm if passing through the central axis of this part.
(in the picture, the red lines help to see the collision point)

My eyes are probably fucked up but this seems really weird to me lol
Help me to find out how it can work if i'm seeing this in a bad way :)
Here a low-res-fast render with different perspective, and the piece itself in red.
I hope it helps to understand the mechanics.
Attachments
steam-engine-mechanics.jpg
steam-engine-mechanics.jpg (194.49 KiB) Viewed 8703 times

Zeblote
Filter Inserter
Filter Inserter
Posts: 973
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #88 - Combinators

Post by Zeblote »

glex wrote:
Eirikaine wrote:These HD will be awsome but HD mean precision and i think this Steam Engine if really weird and really broken x)
If you look right on the bottom right, the part who look like an egg must be flying because the arm if passing through the central axis of this part.
(in the picture, the red lines help to see the collision point)

My eyes are probably fucked up but this seems really weird to me lol
Help me to find out how it can work if i'm seeing this in a bad way :)
Here a low-res-fast render with different perspective, and the piece itself in red.
I hope it helps to understand the mechanics.
That makes sense, but these will still intersect every rotation:

Image

Albert
Factorio Staff
Factorio Staff
Posts: 55
Joined: Tue Apr 09, 2013 5:35 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by Albert »

Zeblote wrote:
glex wrote:
Eirikaine wrote:These HD will be awsome but HD mean precision and i think this Steam Engine if really weird and really broken x)
If you look right on the bottom right, the part who look like an egg must be flying because the arm if passing through the central axis of this part.
(in the picture, the red lines help to see the collision point)

My eyes are probably fucked up but this seems really weird to me lol
Help me to find out how it can work if i'm seeing this in a bad way :)
Here a low-res-fast render with different perspective, and the piece itself in red.
I hope it helps to understand the mechanics.
That makes sense, but these will still intersect every rotation:

Image
That's right.
I will personally punish our engineer. Sorry about that. consider the steam engine in alpha stage. : )

starholme
Fast Inserter
Fast Inserter
Posts: 201
Joined: Tue Oct 21, 2014 7:25 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by starholme »

glex wrote:
Zeblote wrote:
glex wrote:
Eirikaine wrote:These HD will be awsome but HD mean precision and i think this Steam Engine if really weird and really broken x)
If you look right on the bottom right, the part who look like an egg must be flying because the arm if passing through the central axis of this part.
(in the picture, the red lines help to see the collision point)

My eyes are probably fucked up but this seems really weird to me lol
Help me to find out how it can work if i'm seeing this in a bad way :)
Here a low-res-fast render with different perspective, and the piece itself in red.
I hope it helps to understand the mechanics.
That makes sense, but these will still intersect every rotation:

Image
That's right.
I will personally punish our engineer. Sorry about that. consider the steam engine in alpha stage. : )
Maybe it's supposed to make that terrible grinding crunching noise every time? ;)

Rage
Long Handed Inserter
Long Handed Inserter
Posts: 90
Joined: Sat Aug 09, 2014 2:08 am
Contact:

Re: Friday Facts #88 - Combinators

Post by Rage »

starholme wrote:
glex wrote:
Zeblote wrote:
glex wrote:
Eirikaine wrote:These HD will be awsome but HD mean precision and i think this Steam Engine if really weird and really broken x)
If you look right on the bottom right, the part who look like an egg must be flying because the arm if passing through the central axis of this part.
(in the picture, the red lines help to see the collision point)

My eyes are probably fucked up but this seems really weird to me lol
Help me to find out how it can work if i'm seeing this in a bad way :)
Here a low-res-fast render with different perspective, and the piece itself in red.
I hope it helps to understand the mechanics.
That makes sense, but these will still intersect every rotation:
pic
That's right.
I will personally punish our engineer. Sorry about that. consider the steam engine in alpha stage. : )
Maybe it's supposed to make that terrible grinding crunching noise every time? ;)
We've finally discovered the true reason why the biters hate us. It's not the pollution, it's the damn noise!

User avatar
Drury
Filter Inserter
Filter Inserter
Posts: 782
Joined: Tue Mar 25, 2014 8:01 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by Drury »

Oh but wasn't pollution always implied to encompass factors like noise and vibration? Can't think how else purely electric machinery would be polluting.

Oh and, Steam Engines do not pollute at all! Weird but true. It's the sodding boilers that give them a bad name.

Eirikaine
Burner Inserter
Burner Inserter
Posts: 10
Joined: Sat Apr 11, 2015 7:38 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by Eirikaine »

glex wrote:
Eirikaine wrote:These HD will be awsome but HD mean precision and i think this Steam Engine if really weird and really broken x)
If you look right on the bottom right, the part who look like an egg must be flying because the arm if passing through the central axis of this part.
(in the picture, the red lines help to see the collision point)

My eyes are probably fucked up but this seems really weird to me lol
Help me to find out how it can work if i'm seeing this in a bad way :)
Here a low-res-fast render with different perspective, and the piece itself in red.
I hope it helps to understand the mechanics.

Ohhh okay i didn't took that possibility in count ! I have to show this to my teacher ! :O
But I'm glad to see that I was right for the bottom collision :P

Doesn't it make a possible huge up of the productivity of the engine with this gearing now working as intended ? :P :P
Interested by modding, multiplayer and often active on IRC
No native English speaker.

User avatar
jockeril
Filter Inserter
Filter Inserter
Posts: 356
Joined: Sun Feb 08, 2015 11:04 am
Contact:

Re: Friday Facts #88 - Combinators

Post by jockeril »

lancar wrote:Today's friday facts gave me a headache :/
I agree - I had to sleep on it and read it two more times to get an idea of what to do with those combinators... but now I'v got some ideas :)

I can't wait to try them out ! :mrgreen:
[request] RTL support please

My mods

Formally Hebrew translator for FARL & EvoGUI mods

join me on
- Twitter[@jockeril],
- Twitch.tv/jockeril,
- Youtube/jocker-il (or JoCKeR-iL)
- and steam !
Image

User avatar
jockeril
Filter Inserter
Filter Inserter
Posts: 356
Joined: Sun Feb 08, 2015 11:04 am
Contact:

Re: Friday Facts #88 - Combinators

Post by jockeril »

MeduSalem wrote:
MF- wrote:That could be a way to go. What would be in such archive? Some kind of "generic solutions"? Will that exist?
I imagine the Data Archive to be something like an "uplink" that comes once you have blueprints available. That uplink gives access to the Archive in which you may store whatever blueprints you like or download whatever blueprints you need to this map instance.

So if you happen to use a build quite often then you make a blueprint of that, upload in the Data Archive access point and then in the next map/game you start you will have it available once you researched the specific technology level. So no need to re-invent the wheel from scratch.

Might eventually be used for sharing blueprints with other players too if someone wants to think about more stuff that could be done with that.
This could be the equivalent of KSP .craft files (for sharing your ship/plane builds) or Minecraft ComputerCraft programs... It's a good idea and I support it !

#devs - please make blueprints sharing available in the game (maybe files in a folder ? ), there is a mod that gives you the ability to import a blueprint by copy-pasting a string but it's not so practical in my opinion.

You could make it available in a kind of archive cabinet that we would craft (a green circuit + some iron + some empty BP's) - we could pull any BP from it, view the BP schematics when hovering over them in the cabinet inventory, make another and name it (parallel to folder name) to add BP's to the inventory to have them available to share... :)
[request] RTL support please

My mods

Formally Hebrew translator for FARL & EvoGUI mods

join me on
- Twitter[@jockeril],
- Twitch.tv/jockeril,
- Youtube/jocker-il (or JoCKeR-iL)
- and steam !
Image

Zeblote
Filter Inserter
Filter Inserter
Posts: 973
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #88 - Combinators

Post by Zeblote »

I hope the next post tomorrow has more details about the new hd textures ! :D

fsjd
Burner Inserter
Burner Inserter
Posts: 5
Joined: Mon May 25, 2015 9:04 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by fsjd »

Rage wrote: We've finally discovered the true reason why the biters hate us. It's not the pollution, it's the damn noise!
well, a lot of these things are handmade, including the factories that make other stuff, so its not surprising tolerances are rather loose/poor. oh, and hello everyone!

PaulV
Burner Inserter
Burner Inserter
Posts: 6
Joined: Thu Feb 12, 2015 10:18 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by PaulV »

I haven't read the 12 pages of posts in this topic, so someone may already have said this, but I don't think the combinators in their current form are a good idea. I like that it gives us the option of using combinatory logic to make smarter factory lines, but the problem for me is the scale. It's weird that we would need an entire building just to do an 'and' operation and that this building would be as big as a full-on assembler. Sure it's a game and in general liberties can be taken with scale, but this is overdoing it by a large factor. I think it would be much more pleasant to for example click on an inserter and have a section in that screen where you can place and connect logic operators between various inputs and outputs and then the software in the inserter uses that, instead of having these huge buildings that barely do anything.

Lupoviridae
Fast Inserter
Fast Inserter
Posts: 155
Joined: Mon Apr 20, 2015 6:26 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by Lupoviridae »

I would love to see a little red/green light on the decider combinators. Green when the condition is true, red when false (aka not outputting a signal). This would make it really easy to look at a large combinator array and determine it's status.

User avatar
Twisted_Code
Long Handed Inserter
Long Handed Inserter
Posts: 82
Joined: Sat Jun 06, 2015 1:15 am
Contact:

Re: Friday Facts #88 - Combinators

Post by Twisted_Code »

Looking good! I haven't gotten far enough into the game for any of the advanced logistics systems like the circuit network, but I can tell this is a really good addition to it. That said, does anyone happen to have a tutorial I can use for the circuit network when I get around to that part of the tech tree?
How to report bugs effectively (archived version)because everyone should know this.
The game's tech tree, a visual reference guide.

vedrit
Filter Inserter
Filter Inserter
Posts: 292
Joined: Sun Aug 03, 2014 2:25 am
Contact:

Re: Friday Facts #88 - Combinators

Post by vedrit »

Lupoviridae wrote:I would love to see a little red/green light on the decider combinators. Green when the condition is true, red when false (aka not outputting a signal). This would make it really easy to look at a large combinator array and determine it's status.
I like this idea!

NotABiter
Fast Inserter
Fast Inserter
Posts: 124
Joined: Fri Nov 14, 2014 9:05 am
Contact:

Re: Friday Facts #88 - Combinators

Post by NotABiter »

ratchetfreak wrote:However I think that it's best to not go bitwise with arithmetic and instead treat each signal as a 32-bit integral signal (if that is indeed the limit). Having the modulo operator would be a good help for extracting the bits (or even the decimal digits for a segment display.)
Currently their plans seem to still have a hole, and that is the lack of a storage cell that can store arbitrary values. If all you have is storage cells that store bits, then every step where you need to store a value you have to have a bunch of logic to break out all of the bits, a bunch to store all of the bits, and a bunch more to assemble them back into a value. Having single-cell '+' and '*' et al that operate on arbitrary values is nice, but those "powerful" cells are going to be lost in the giant sea of decoders/encoders/storage-cells needed to do some interesting things with them.

I've been thinking about the "Decider Combinator" (with the output set to "Input Count" and operator set to '<'), wondering if it could somehow be used to latch arbitrary values (by toggling the 2nd input between MIN_INTEGER and MAX_INTEGER), but I'm not exactly seeing an easy solution. (The immediate problem is that you need to somehow loop the output back to the input in order to "remember" the value, but you don't want to wire-add the remembered value to the original input value.) Maybe with two of them linked together with some fancy timing of the secondary inputs...

But that gets to another apparent problem, and that is one of timing. Is there going to be some sensible treatment of timing at some point? (Maybe there already is with these new 0.12 devices?) Sure, you have these elements that update every game tick - but if they are not synchronized (for each: compute new state; for each: output new state) and are instead executed in arbitrary order (for each: compute and output new state), that makes reasoning about any sort of combination of stateful devices much more challenging than I think anyone really wants. (Similar problems occur if the values "in the wires" are updated in arbitrary order with respect to the update of the devices -- i.e., if updates of wires and devices are interspersed during each tick.)

ratchetfreak
Filter Inserter
Filter Inserter
Posts: 950
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by ratchetfreak »

NotABiter wrote:
ratchetfreak wrote:However I think that it's best to not go bitwise with arithmetic and instead treat each signal as a 32-bit integral signal (if that is indeed the limit). Having the modulo operator would be a good help for extracting the bits (or even the decimal digits for a segment display.)
Currently their plans seem to still have a hole, and that is the lack of a storage cell that can store arbitrary values. If all you have is storage cells that store bits, then every step where you need to store a value you have to have a bunch of logic to break out all of the bits, a bunch to store all of the bits, and a bunch more to assemble them back into a value. Having single-cell '+' and '*' et al that operate on arbitrary values is nice, but those "powerful" cells are going to be lost in the giant sea of decoders/encoders/storage-cells needed to do some interesting things with them.

I've been thinking about the "Decider Combinator" (with the output set to "Input Count" and operator set to '<'), wondering if it could somehow be used to latch arbitrary values (by toggling the 2nd input between MIN_INTEGER and MAX_INTEGER), but I'm not exactly seeing an easy solution. (The immediate problem is that you need to somehow loop the output back to the input in order to "remember" the value, but you don't want to wire-add the remembered value to the original input value.) Maybe with two of them linked together with some fancy timing of the secondary inputs...

But that gets to another apparent problem, and that is one of timing. Is there going to be some sensible treatment of timing at some point? (Maybe there already is with these new 0.12 devices?) Sure, you have these elements that update every game tick - but if they are not synchronized (for each: compute new state; for each: output new state) and are instead executed in arbitrary order (for each: compute and output new state), that makes reasoning about any sort of combination of stateful devices much more challenging than I think anyone really wants. (Similar problems occur if the values "in the wires" are updated in arbitrary order with respect to the update of the devices -- i.e., if updates of wires and devices are interspersed during each tick.)
Looping a signal through a * and a + will be enough for the arbitrary single value storage:

Steady state is 0 on the "other" input on + and 1 on the "other" input on *. You branch from either outputs to read the value.

When clearing you set the *'s other input to 0. Setting the value means putting the other of the + to that value for 1 tick.

If you look up Little Big Planet 2 logic there were timing challenges where some gates delay propagation for a tick depending the the circuit (usually when it's in a loop).

Also the multiplayer model (and replay) requires that the arbitrary order is well defined.

NotABiter
Fast Inserter
Fast Inserter
Posts: 124
Joined: Fri Nov 14, 2014 9:05 am
Contact:

Re: Friday Facts #88 - Combinators

Post by NotABiter »

ratchetfreak wrote:that value for 1 tick
Ah yes, the old single tick pulse trick. (It's been a while since I've played Factorio and I forgot about that, even though I made stuff that depended on it.)
ratchetfreak wrote:Also the multiplayer model (and replay) requires that the arbitrary order is well defined.
Well, there's "well defined" as in "the game is computationally deterministic", and then there's "well defined" as in "we the players can know in advance whether or not a design is guaranteed to work in the game". I hope the Factorio team provides us with enough information to support the latter, because building stuff that may or may not work, or might work now but breaks after a save/load or after some one-would-think-unrelated game entity is placed/removed isn't a lot of fun. And I would hope that that information is provided sooner rather than later so the community can provide informed feedback.

In 0.11 I ran into problems on this front, where conditions which depended on data from both red and green networks were not reliable because sometimes data would get there across both networks at the same time and sometimes it wouldn't. And yes, the game is deterministic, so when it was working if you just did nothing - don't touch anything - it keeps working. But (IIRC) if you so much as connect an output wire up to an existing wire network, it can stop working correctly. Now admittedly I was pushing things - trying to make things happen in the fewest game ticks possible, playing with race conditions in the process. (But if Factorio isn't about optimizing stuff, I'm not sure what it's about. And currently what will and won't result in a race condition is not publicly defined AFAIK.) And that was while using inserters for logic. With 0.12 now supporting logic devices that naturally operate in game-tick time (there's a trick to make inserters do that to, but most people aren't aware of it), a lot more people will run into the issue of things breaking when you go "too fast".

User avatar
TheWrongCat
Burner Inserter
Burner Inserter
Posts: 7
Joined: Mon Jun 08, 2015 12:59 pm
Contact:

Re: Friday Facts #88 - Combinators

Post by TheWrongCat »

NotABiter wrote:building stuff that may or may not work, or might work now but breaks after a save/load or after some one-would-think-unrelated game entity is placed/removed isn't a lot of fun.
And yet Minecraft's Redstone systems got away with this for years :P

Post Reply

Return to “News”