Will this be Possible in 0.13?

[silverkitty23]

So I noticed there was an expanded interface for circuit network connectivity stuff. Does that mean it will possible to make new types of combinators in 0.13? For example, an arithmatic that knows modulo, or deciders that do logic gate operations?

I'm hopeful for the possibilities, but I wonder about the efficiency of a Lua behavior that has to fire every single tick for every single New Combinator

I looked through all the present mods, and I saw a couple things that emit signals (based on no input), and a LuaCombinator which doesn't seem to act like a combinator at all, so I'm pretty sure it's not possible in 0.12 to just make a new combinator which works like an arithmatic or decider with slightly different rules (that or no one wants such a thing besides myself, which seems... unlikely). Actually, since most "new ideas" for combinators can, in theory, be made by the two combinators types we have, if you stack enough of them and wire them up right, I'm kinda surprised there isn't a 0.12 mod to make, say, a modulo combinator that spawns a bunch of invisible combinators stacked in the same spot to do the job - which makes me wonder if even THAT is possible?

I know Twinsen is against adding new types on combinators into the base game ( http://www.factorio.com/blog/post/fff-122 ), which is why I'm interested in whether we can do it with mods (since those evaporate all Twinsen's reasons for not wanting to add to the base game: overwhelmed by too much content? your fault for adding the mod. Factorio philosophy is few things in different ways? Yeah, okay, but given what people add in mods, this isn't unusual. Cleaner toolbar and inventory? Those are dictated by playstyle, not by what is available (shouldn't even be a reason not to add things to base). End game factories like to make all possible things? again, your fault for installing the mod).

[silverkitty23]

guess no then?

[bobingabout]

If nobody responds, it's more likely that nobody knows the answer... or someone who does(Devs) just hasn't seen the question

[Rseding91]

No, the conditions on combinators are still fixed to <, >, and =

[kyranzor]

but I wonder about the efficiency of a Lua behavior that has to fire every single tick for every single New Combinator

Well, don't run the update for the custom combinator every tick. You have the option of only running it every X tick, so use that to your advantage to time-multiplex them or just have a slower update rate.

You can do some amazing stuff with Lua and using a custom constant combinator to set the outputs of the lua process.

[DaveMcW]

The modulo operation can be done in 5 combinators and 2 ticks.

F = A mod B

Tick 1
C = A * B
D = -1 * B
E = A

Tick 2
F = C / D
F = E

[silverkitty23]

Technically *everything I can think of* (that isn't NP-complete) can be done with enough combinators and time... but I'd still love to be able to make new combinators in mods (since they won't make new combinators in vanilla) to save space and complexity and time. You know, for the same reason I'd rather write in a high level language than in assembler.

So I was hoping the wiring interface would mean I could operate directly on the red and green signals (or even the sum signal) hooked up to a "new" combinator and have it output the result of a calculation on them (which is why I posed this as a question about 0.13 rather than an "idea and suggestion" in a different subforum).

I suspect the other avenue - the one with hidden combinators that are attached to your visible object - may be be possible anyway (perhaps even in 0.12), though it would mean difficult to plan-for delays because any custom combinators would take random number of ticks instead of 1 like the regular arithmatic/deciders

---

Of course, ideal world would be like (in no particular language):

Code: Select all

class modulo_combinator extends custom_arithmatic_combinator {
    function op( inputs[] ) {
         return inputs[0] % inputs[1];
    }
}

class xor_combinator extends custom_decider_combinator {
     function op( inputs[] ) {
          // assuming your language does not have a native xor op
          if ( inputs[0] && inputs[1] ) return false; 
          if ( inputs[0] || inputs[1] ) return true;
          return false;
     }
}

where op() is an abstract function defined in custom_X_combinator, and as long as your code in op() is short enough, it works just like an arithmatic or decider. or, rather, it always works like that, but if your code is too complex, then you're massively hitting the UPS and people won't want your mod anymore.