[0.15] Complex Combinator

[thelordodin]

The reason:
I hate circuit wires. I can't really see where it goes from and to. It's messy.

Description:
Preview screenshot: all the things inside red rectangle will be hidden by graphics and will be rendered as a single building.
- This combinator combines up to 16 operations in one unit
- It have 4 inputs and 4 outputs.
- Inputs support separate channels (so it's actually 8 inputs)
- It supports additional operations which can't be accomplished by vanilla combinators

Working features:
- Operations: + - * / min max (not deeply tested, but should work)
- Copy and paste - copies the program
- Export and import through edit box
- Blueprints supported the program
- Combinator is enabled with all the other combinators.
- Its quite expensive ({"iron-plate", 10},{"copper-cable", 20},{"electronic-circuit", 20})

Problems:
- Graphics are bad... (I'm really bad with graphics so I won't fix this myself...)

Your help would be appreciated and is needed:
- Graphics
- Testing
- Suggestions for balance
- With suggestions of new useful functions
- Any other feedback

Disclamer:
- This mod is really unstable and untested. You can kill your save, so make backups.

License:
- All code and content is absolutely free - use, copy, fork, do whatever you like (except for the images and code from original factorio - they have their own license)...

[martijnenco]

What can you do exactly in the "program string" box? Instert you own lua code? or is it the arethematic you just make in the combinator?

[thelordodin]

Hi.
It's just save of what is set in other boxes.

Implementing lua code in combinator is possible, but that would be much more complex programming (for user), because signals are not scalar values, so it involves manipulations with sets, so there gonna be variables, loops, iterators - etc and hi possibility to make a mistake. I don't think you wanna code that much inside small edit-box.

Also there is already a mod (Lua combinator) which allows to writing Lua code in it.

[thelordodin]

I think adding many many different operations, even complex ones, would be much easier for user.

[thelordodin]

Added new version : new graphic and bugfixes. Blueprints now supported

[Nightinggale]

This looks promising. I agree the wires can be hard to see, which annoys me as well from time to time. However I see far greater potential in this than some wires.

The math functions in the screenshot look ok and they can certainly be useful. However my experience tells me that decider logic plays a bigger role in the game than arithmetic combinators and as such I tend to end up with lots of decider combinators and few arithmetic combinators. If this mod is to shine, it needs some decider logic.

I propose the following:

• In addition to writing pin connection names (like r1), the argument should support ints as well. This would allow code like "max 0", which will filter out any negative values
• The enabled checkbox should support decider logic, allowing lines like o1 = + r1 if r1 > g1
• Support specific signals in logics, including anything, everything and each
• Support "for each r1, output g1 on o1" (as in o1 =+ g1, but only signals present in r1)
• Support using different inputs for data and conditions, like o1 =+r1 if r3 > 0
• Ability to name each input/output (which might be possible already)
• Add internal "connectors" to store temporal values. Looks like the idea is to write to output and then read output, but I can easily imagine using 4 outputs and perhaps up to 4 internals. The internals can be temporal memory used in on_tick() and deleted at the end of the tick.

I'm uncertain how much of this is a good idea due to possible performance issues. However I do know that it would greatly simplify programming complex wire signals and it appears to be easier to handle memory (just connect output to input). It also helps regarding signal latency. Vanilla combinators use one tick for each combinator and this mod can make a whole chain using those 16 lines.

I'm certainly keeping an eye on this one.

[thelordodin]

Hi!

It already supports constants. I.e. Max(signals,0) is supported, max(signals, signals) is supported too. But i dont remember if i tested them.

Its already possible to name inputs, intermediates (variables, internals) , outputs.

Using same name twice results in summ.

This combinator works every 16 ticks. Maybe i'll make it as a setting.

Number of lines may change to infinite...

[Nightinggale]

Maybe it would be a good idea to allow assigning the tick interval as well as how many lines it does every time it activates. Sometimes it might make sense to have it activate every tick, but only do 2 lines each time, meaning it takes 4 ticks to go through 8 lines. That would require memory of last or next line to execute and keeping this memory between ticks. This includes savegames and network.

What happens to output on ticks where it doesn't do anything? I assume it keeps the output, which makes me wonder: wouldn't it be a good idea to not clear output when calculations start? That way it will be a memory module by the fact that it can write to output and then next time it adds to the existing number. It could be interesting, but at the same time it needs a clear and/or overwrite command for that to work well.

[thelordodin]

Maybe it would be a good idea to allow assigning the tick interval

I think i'll do it if I have time.

... as well as how many lines it does every time it activates. Sometimes it might make sense to have it activate every tick, but only do 2 lines each time, meaning it takes 4 ticks to go through 8 lines. That would require memory of last or next line to execute and keeping this memory between ticks. This includes savegames and network.

I think this wouldn't work, since all this code about saving state may consume more time than profit. I think distributing different combinators to different ticks will give much more boost.

What happens to output on ticks where it doesn't do anything? I assume it keeps the output,...

yep. It's saved. Not by me, it's done because output is implemented as 4 constant combinators, the mod just changes their values.

...which makes me wonder: wouldn't it be a good idea to not clear output when calculations start? That way it will be a memory module by the fact that it can write to output and then next time it adds to the existing number. It could be interesting, but at the same time it needs a clear and/or overwrite command for that to work well.

Memory cell... Interesting idea, but I don't like this way of implementation.
There is no problem to save any values inside mod's data. I only need an idea how to do in in gui.

I'll think of how can this be done and I'll appreciate any ideas.

[Nightinggale]

I think distributing different combinators to different ticks will give much more boost.

So basically you are saying it should trigger on "global tick % X == Y" where you can set both X and Y. This could be useful not just for distributing CPU load, but also control of timing regarding when signals are being moved. For instance you have multiple combinators with the same X, but if the first outputs on Y=0, then the next should read on Y=1 and so on. If they all read on Y=0, then the latency will quickly add up.

Another thing would be if you work together with something from another mod, which triggers every Xth tick. If you want to read the output, then you trigger this combinator on Y=1 while you use the same X because mods tend to hardcode Y=0.

There is just one problem though. What if you want to only update one output each tick? Seems like you would need 4 combinators and hardly use them. Maybe it would be an idea to make multiple combinators with different number of inputs and outputs. It doesn't seem like a lot of work to me if you can figure out to make them all call the same code.

yep. It's saved. Not by me, it's done because output is implemented as 4 constant combinators, the mod just changes their values.

Doesn't that mean they have a limited amount of slots? I just bug reported crafting combinators for having just 20 slots as well as a way to try to make it output 21 signals, which crashes the game. Vanilla combinators (like decider combinator) appears to manage an unlimited amount of signals just fine.

This means what needs to be considered here is if there is a limit, if it can be avoided and what to do when the limit is exceeded. Just letting the game crash is not a valid answer

Maybe some sort of "splitter" would be needed, meaning first 20 on one wire, next 20 on another. I'm not sure 40 signals will ever be needed, but time will tell.

I'll appreciate any ideas.

Don't worry. I will speak my mind.

One thing, which comes to my mind is having a line, which ends execution. If/when each line can be controlled by wire signals/conditions, starting the code with "end if r1 == 0" and triggering each tick will turn the combinator into something, which triggers on input conditions rather than counting ticks. If it copies input to memory, it can compare input to memory and stop if they are identical, meaning it triggers on input changes.

Another idea would be to have a line command to assign tick interval. I can think of one usage, where it starts by assigning 2 and then as the last command it assigns 1000. The second last line would then be a end if loop not done, meaning it can run a loop every 1000 ticks.

Perhaps it could use some fixed name variables, like tick and it will provide the global tick count. Gaining internal access to "tick % variable" result could be beneficial when syncing multiple entities.

Another idea would be to allow removal and insertion of lines. It seems annoying to having to move 8 lines one down because you need another line at the top. This is even more important if it allows unlimited amount of lines.



I'm currently working on a setup to fully automate assemblers using crafting combinators and it should produce everything I need while taking into account that it won't assign production where I lack input. It's currently around 80ish combinators and 12 switches (the switch mod). It seems to work, but it's switching production too often and hence becomes inefficient. Now I have the plan to create the same setup using this mod and then I will hopefully be able to solve the remaining issues and hopefully be able to not have problems using blueprints. Looks like I have to wait until this mod matures a bit, but once it's ready for me to start trying this project, I will likely be able to provide way more feedback, be it feature requests, bug reports or just test results.

[thelordodin]

Maybe it would be an idea to make multiple combinators with different number of inputs and outputs. It doesn't seem like a lot of work to me if you can figure out to make them all call the same code.

Yes, 1 input 1 output and 2 input 2 output versions is what i'm going to make.

Doesn't that mean they have a limited amount of slots?

Yes it does. It's hard limit of factorio. Factorio have bad architecture and there is nothing modders can do with it. This is one of such problems. Another big problem of architecture is that to make this mod i had to use 10 entities. I.e. the game have to handle 10 entities when you put ComplexCombinator. This are 5 lamps (4 inputs + main entity) and 5 constant combinators (4 outputs + blueprint storage).
This value is constant, but it can be set on game loading. I've set it to 500 signals, I don't think you'll come to this limit.

Extra signals may just be truncated/ignored, or it can emit some signal (red color) or it can give a message.

One thing, which comes to my mind is having a line, which ends execution. If/when each line can be controlled by wire signals/conditions, starting the code with "end if r1 == 0" and triggering each tick will turn the combinator into something, which triggers on input conditions rather than counting ticks. If it copies input to memory, it can compare input to memory and stop if they are identical, meaning it triggers on input changes.

Another idea would be to have a line command to assign tick interval. I can think of one usage, where it starts by assigning 2 and then as the last command it assigns 1000. The second last line would then be a end if loop not done, meaning it can run a loop every 1000 ticks.

Perhaps it could use some fixed name variables, like tick and it will provide the global tick count. Gaining internal access to "tick % variable" result could be beneficial when syncing multiple entities.

I think i should gather 3-5 examples of real cases where it is needed. Then I could have design this feature better.

For now I see three options: integrator - this operation will summ its on input every tick and can be reset by some signal,
a differece - this will diff signal with previous output and averenge - it takes averenge in some period of ticks.
I think all this already exists in useful combinators mod, but I don't really see why its needed

Another idea would be to allow removal and insertion of lines. It seems annoying to having to move 8 lines one down because you need another line at the top. This is even more important if it allows unlimited amount of lines.

Yes i plan this, I don't have much time though.

I'm currently working on a setup to fully automate assemblers using crafting combinators and it should produce everything I need while taking into account that it won't assign production where I lack input. It's currently around 80ish combinators and 12 switches (the switch mod). It seems to work, but it's switching production too often and hence becomes inefficient. Now I have the plan to create the same setup using this mod and then I will hopefully be able to solve the remaining issues and hopefully be able to not have problems using blueprints. Looks like I have to wait until this mod matures a bit, but once it's ready for me to start trying this project, I will likely be able to provide way more feedback, be it feature requests, bug reports or just test results.

Interesting. I wanted to build some kind of this awhile ago, but declined this idea.

Be warned though that you'd better use not many ComplexCombinators because I think they'll lag in big amounts no matter what i do: you see compiler optimized C++ and Lua through all this architecture problems are incompartible in matter of perfomance. C++ is MUCH faster.

Yes there is A LOT of work in this mod (and a lot of bugs in it for sure).

And by the way I'm thinking if I should or should not really convert the mod to be on lua. I.e. try to make some functions in Lua and give a textbox in game with that functions, so you could really make a program.
Because no matter what i do now in ComplexCombinator it's quite hard to make control structures: loop, goto, if with a bunch of statements in it.
But this gonna be just a text box and might be little harder for user... but more flexible.

What do you think about it?

[Nightinggale]

This value is constant, but it can be set on game loading. I've set it to 500 signals, I don't think you'll come to this limit.

You need to consider what to do if you have too few slots. Make sure your code can handle all inputs without crashing, nomatter how unlikely the input is because once in a while the extremely unlikely happens (that's speaking from experience). Set it to 2, make code to truncate and test it. Once it's working as intended, return to 500. Is there a sideeffect from having such a huge number? Performance? Memory? I know the game is 64 bit only by now, but still that's 2000 signal slots on the 4 output port device you have in the screenshot.

Another thing, which seems to be able to crash the game is setting out of range signal values. The API use a 32 bit signed int. Do not set values outside that range. It will happen eventually. I tried crashing the game due to that. More or less I had a decider combinator, which read it's own output (memory), but it by accident multiplied by 20 each time. Eventually it passed 2 billion. Naturally I didn't intend to put more than 2 billion iron plates in the chest, but the game still crashed. In other words to make the game stable, cap output to 32 bit. Lua internal values seem to handle 64 bit ints just fine, at least from what I'm told.

I don't have much time though.

I know that feeling. I'm not even certain I get to play the game within the next week or two.

Be warned though that you'd better use not many ComplexCombinators because I think they'll lag in big amounts no matter what i do: you see compiler optimized C++ and Lua through all this architecture problems are incompartible in matter of perfomance. C++ is MUCH faster.

I know because I usually tell people to use C++ for performance and debugging abilities. However I'm not too concerned with performance at this point. At least my computer seems to have avoided lag so far.

And by the way I'm thinking if I should or should not really convert the mod to be on lua. I.e. try to make some functions in Lua and give a textbox in game with that functions, so you could really make a program.
Because no matter what i do now in ComplexCombinator it's quite hard to make control structures: loop, goto, if with a bunch of statements in it.
But this gonna be just a text box and might be little harder for user... but more flexible.

What do you think about it?

I think there is room for this mod and Programmable Controllers, but only if they do not try to do the same thing. Programmable controllers aims to support what is likely a full programming language, complete with call stack and multithreading. The problem is that it takes skills to use it.

This mod on the other hand would likely do best if it aims to be simple to use and be usable for people who have little or no programming experience, but have figured out how to use combinators. Adding too many programming concepts will likely just end up making this an inferior version of programmable controllers. It's better to have different intended users and not to optimize both mods for the very same tasks.

Personally I think there is room for both mods, but they will have to not try to do the same. Alternatively you can try to see if you can join forces and make one good programming mod.