Friday Facts #88 - Combinators

[Zeblote]

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

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]

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.

[Zeblote]

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:

[Albert]

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:

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

[starholme]

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:

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]

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!

[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]

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

Doesn't it make a possible huge up of the productivity of the engine with this gearing now working as intended ?

[jockeril]

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 !

[jockeril]

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

[Zeblote]

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

[fsjd]

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]

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]

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.

[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?

[vedrit]

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]

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]

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]

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

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

[TheWrongCat]

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