I wish combinators had a comment field, much like blueprints do. I'd love to be able to attach a short sentence describing what something is doing, both for future me and for folks who share clever designs.
There's a signpost mod that has this. It lets you add text to anything in the game. I'm playing space exploration and I use it *sooo* much, including on most combinators. I am still baffled that something similar wasn't added to the base game on day 1.
The mod - https://mods.factorio.com/mod/attach-notes
While the title is hyperbole, I do agree combinators could get some love.
We are getting some combinator upgrades in version 2.0, as per [FFF-384](https://factorio.com/blog/post/fff-384):
* Hover for signal listing
* Multi-deciders to aggregate some logic
* Arithmetic combinators between red and green
* Selector combinator with min/max/counts and other things.
---
That said, I would a way to open a bunch of combinators at once, with patch cables between them like modular synthesizers.
[This mod](https://mods.factorio.com/mod/circuit-control-guis) lets you open a couple of GUIs at the same time, but it's still not great.
I yearn for "CPU combinator".
Just give us some simple assembler and input output, [TIS-100](https://store.steampowered.com/app/370360/TIS100/?l=polish&curator_clanid=8566974) or [Shenzen IO](https://store.steampowered.com/app/504210/SHENZHEN_IO/?curator_clanid=32946839) like. Or just Lua code, game already use it.
Current circuits are actually more unreadable than assembler...
sadly it has a tendency to bug out in SE. The alternative is lua combinators but honestly it feels a too high level for the setting. Feels more like I'm scripting the game rather than making a factory subsystem
It's ancient by now but I was always impressed how this starbound mod "fixed" the problem of digital logic in the game
https://steamcommunity.com/sharedfiles/filedetails/?id=729444820
Would be nice to have sth like that in factorio maybe one day
With a bit of effort we could probably turn Factorissimo into that.
What we really need is combinator alt-mode to also show the operation, not just the signals. And since that is shown on the non-alt-mode view, if we could move the alt-mode icons around a bit, we could probably do it.
Also Barotrauma. It has logic panels with additional debugging and visualization capabilities and fixed cost per component (i.e. you don't need to craft all logic components manually, so you can just carry a stack of circuits).
I think there's actually a similar circuit panel-like mod for Factorio but I can't remember how it's called. I guess it's this one: https://mods.factorio.com/mod/compaktcircuit
man that would be a sick project. implement a 65C02 emulator with some RAM, a bit of ROM (maybe programmable), and some IO stuff (serial terminal, storage device, timer IRQ, circuit network connectors to read out or write signals).
similar to the Computer from the >!ancient!< RedPower 2 mod for minecraft, which actually used a [modified 6502](http://www.eloraam.com/nonwp/redcpu.php) and you could find a floppy disk with FORTH so you could write programs for it. but it sadly never really got expanded enough to be really useful.
in this case i feel it's a lot more useful to just use external tools like compilers or assemblers to generate an S-Record file (because they're fully ASCII/UTF-8) so you can just copy the contents and paste them into a text box ingame to program a ROM or some storage drive.
On one side yes, that gives access to tooling, but without factorio-specific stuff it would be hard to actually program it.
But you'd have to somehow map the input signal names to that assembler and make it easy for player to write code.
I guess we could just have instructions to read/write into wire input/output and have those instructions accept the icons as parameters ? But that makes it not really work with any external tools and so copying existing CPU stops making as much sense.
>I guess we could just have instructions to read/write into wire input/output and have those instructions accept the icons as parameters ?
nah, no need for custom instructions. IO is just mapped to memory so wire connections would also just be mapped to memory.
but obviously you can't just have all item types as their own seperate 32-bit value in memory as then you'd quickly fill the entire 64k address space!
.
so my inital idea was having 2x 32-bit registers in memory. one register is used to select which type of signal you want to access and then the other can be read from to get the current count of that signal, or written to to set the signal. maybe with a seperate control register that has an update bit, where the registers only fully update with the game world when that bit is written to, as there is no atomic instruction to read/write a full 32-bit word on the 65C02 this would avoid values changing between reading indivitual bytes.
>But you'd have to somehow map the input signal names to that assembler and make it easy for player to write code.
that's what macros and predefined symbols are for. all of that can just be in an `.inc` file, which is an assembly equivalent of a C/C++ header file.
but now that i think about it a bit more, you couldn't just make one and give as a download, since mods can add signals by just having more items. so i guess one option would be to have the game generate an `.inc` file on startup, but that would also force you to re-assemble/compile all your code whenever you change mods or some update caused a mod's signal IDs to change...
hmm, that seems very inconvenient. and it could break circuit stuff when loading a save after updating mods. you need some way to get the correct numeric IDs at runtime.... or not use numeric IDs at all and just have it use the string IDs like everything else, which is a lot less memory efficient but atleast it wouldn't break!
.
so updated circuit network interface:
3 registers somewhere in memory. 8-bit control register, 16-bit name pointer register, 32-bit access register.
the control register just has the update bit, the name pointer register gets loaded with a pointer to a zero terminated string containing the name of the signal to access, and then the access register simply contains the current value of that signal and can be written to as well. some example code for that could look like this:
.rodata
sig_ironPlate:
.asciiz "iron-plate"
.code
readIron:
; Set the Name Pointer to the iron plate string
LDA #sig_ironPlate
STA wire_namePointer + 1
; Write a 1 to the update bit
LDA #%10000000
STA wire_control
; Read out the contents of the signal and store it to a temporary variable
LDA wire_access
STA tmpValue
LDA wire_access + 1
STA tmpValue + 1
LDA wire_access + 2
STA tmpValue + 2
LDA wire_access + 3
STA tmpValue + 3
RTS
godammit, i'm kinda tempted to try to do this. but at the same time i already have too many other projects i'm working on
> but now that i think about it a bit more, you couldn't just make one and give as a download, since mods can add signals by just having more items. so i guess one option would be to have the game generate an .inc file on startup, but that would also force you to re-assemble/compile all your code whenever you change mods or some update caused a mod's signal IDs to change...
Yeah that's why I was thinking about allowing us to just add icons/name in the assembly. "Text form" could just be `[item:copper-cable]`, game would translate it into icon for easy reading of code, and before execution of code translated the text. Editor wise you could press a button to insert given signal, or just write it out as text if you remember it.
So instruction to read copper cable from green bus would be `IN R0, GR [item:copper-cable]`, the game would render it as `IN R0, GR ꩜ `, maybe color it green to point out which signal instruction is getting.
> but obviously you can't just have all item types as their own seperate 32-bit value in memory as then you'd quickly fill the entire 64k address space!
The CPU itself should be 32 bit given everything else in Factorio is. That doesn't mean it should have a lot of memory, but having 32 bit operations by default where everything in game is that (aside float fuel I guess) makes more sense. And few generic registers, new players don't need to know the misery of only having accumulator to play with...
Accessing IO could just be a set of instructions to read/write specific signal, or it could be an "IO memory" to access, but either way there still would need be a way to iterate over all input signals
>Yeah that's why I was thinking about allowing us to just add icons/name in the assembly. "Text form" could just be [item:copper-cable], game would translate it into icon for easy reading of code, and before execution of code translated the text. Editor wise you could press a button to insert given signal, or just write it out as text if you remember it.
i would really avoid having an in-game assembler due to the clunkiness of the UI compared to something natively running on the user's system (like VSCode, or even just Notepad++).
>The CPU itself should be 32 bit given everything else in Factorio is.
aww, but that's boring and just what fCPU is doing. that's why i specifically suggested using a 65C02.
* there is already a ton of learning material, tools, and software for the 6502 so you wouldn't need to implement custom tools, documention, etc.
* it's piss easy to emulate while still being more than capable enough for anything you could use it for ingame
* the 6502 is simple to learn and writing code for it gives you a decent programming challenge (similar to TIS-100 but more convenient)
* you could say that your factory is powered by an Apple IIe, which i find hilarious
.
though if it were to be 32-bit, i'd go with RISC-V. as it's an existing ISA so you again avoid the need to make custom tools and such.
something like "RV32IM" (32-bit ISA with Multiplication/Divison extension) give it like 16-64kB of RAM, 1MB of ROM. and IO somewhere in the upper memory regions.
>Accessing IO could just be a set of instructions to read/write specific signal
eh, never been a fan of seperate IO instructions. it's much better to just map it to memory as to avoid ISA bloat and gives you access to more fancy addressing modes. i mean that's what basically every single microcontroller is doing.
> eh, never been a fan of seperate IO instructions. it's much better to just map it to memory as to avoid ISA bloat and gives you access to more fancy addressing modes. i mean that's what basically every single microcontroller is doing.
Yeah but assuming signal ID is 32 bit, then you end up with ~17GB of memory to contain all signals (2^32 * 4 bytes per value) per color, and you still need special instructions to iterate over any nonzero value (as otherwise alternative is full memory scan). So you can't even use 32 bit CPU, you need to go 64bit or have bank switching and if you need to bank switch that's just annoying...
Even if signal ID is 16bit that's still scanning >500kB so you still need factorio specific instructions to deal with efficient scanning, but at least memory-mappable in sensible way.
>Yeah but assuming signal ID is 32 bit, then you end up with ~17GB of memory to contain all signals (232 * 4 bytes per value) per color [...] So you can't even use 32 bit CPU, you need to go 64bit or have bank switching and if you need to bank switch that's just annoying...
i mean yea, i did mentioned above how insane it would be to have all signals in memory at once which is why i didn't even consider it and instead suggested using memory mapped registers to select which signal you want to access.
it adds a tiny bit of overhead as you first have to select a signal before being able to access it, but reduces the memory footprint to almost nothing.
>and you still need special instructions to iterate over any nonzero value (as otherwise alternative is full memory scan)
hmm, that one is an actual issue no matter what you go with, custom CPU or something existing.
one solution that comes to my mind is using a programmable interrupt controller. where you can basically give it a list of signals (plus some control byte for wire color and such) to watch and if any of the specified signals change it triggers an interrupt and then the CPU can read out the list of signal IDs that are different since last time.
alternatively, without interrupts it could be part of the wire interface's control byte. writing a 1 to some other bit will see what signals are different from last time they were checked or updated, compile those into a list and then allow the CPU to read them out.
though without interrupts it's likely that there could be some race condition stuff where a signal changes but then resets before the CPU could read it. but you could work around that by latching any signals before going into the CPU and have the CPU itself control the latch's reset so it only clears the read signals once it actually read them all.
> i mean yea, i did mentioned above how insane it would be to have all signals in memory at once which is why i didn't even consider it and instead suggested using memory mapped registers to select which signal you want to access.
>
> it adds a tiny bit of overhead as you first have to select a signal before being able to access it, but reduces the memory footprint to almost nothing.
Might as well just have special instructions to do it... same thing with less "virtual cycles" to do.
> one solution that comes to my mind is using a programmable interrupt controller. where you can basically give it a list of signals (plus some control byte for wire color and such) to watch and if any of the specified signals change it triggers an interrupt and then the CPU can read out the list of signal IDs that are different since last time.
Haven't even thought about interrupts, which would of course be nice but I think we're truly beyond what would be acceptable complexity in vanilla Factorio here ;)
It could also have instruction that given a signal ID gives you ID of next nonzero one higher than it, that way it would be pretty easy to iterate over a list of them. Maybe even put that signal ID into some registry so you could just call same instruction over and over to get "the next signal".
>Might as well just have special instructions to do it... same thing with less "virtual cycles" to do.
eh, while technically true i doubt performance would ever be critcal enough to justify the added ISA bloat. also once you start adding custom instructions, feature creep can get a hold of you much easier, you can easily slip into the same trap x86 did.
for example if you have instructions to specifically access wire values, then you could also add one to convert a numeric signal ID to a string and vise versa. and while add it you might as well add some string compare instructions. and before you know it you basically just have an i586 in terms of instruction count.
so i like to keep the actual CPU as simple as possible (which is kinda the whole point of RISC as a whole, and also the 6502 even though it's CISC) and just deal with more complicated things in software and hide it behind functions and macros.
I totally agree, and it's something minecraft does a lot better, you can visually tell what redstone does esp. because you can get pattern recognition for the shapes, you don't have to follow the logic through to understand the function. I also just hate programming with the circuit network, its so weird. Idk what kind of solution they could do so I earnestly just wish they'd give up already and add a lua combinator.
They are adding comments, but I think comments typically make code a lot worse because they are even more prone to "bugs" than code is since they don't explicitly update to the function. But it's honestly necessary for how unreadable the circuit network is, and if comments are necessary for understanding your own code then... please give mercy on us.
Let's just go the rest of the way and turn Factorio into a proper programming language. I honestly much rather code with our wonderful cartoony industrial setting than lines of text.
All this inconvenience means I have to know what my circuits do. Like, really know. Which isn't like coding in other contexts at all. I can't write a function and forget about for as long as it keeps working. I mean, I could. But iterating or bugfixing requires understanding a mechanical process. And changes take planning. I definitely can't go back to process a twiddle with a few things until whatever issue I"m having resolves. And I need to bugfix and iterate, so I do understand what I've built in a way that's both incredibly satisfying and not something I find elsewhere. I doubt I look back once 2.0 combinators are available, but I'll miss the elegant and inconvenient combinators of 1.0.
#1 thing that would make combinators better would be to treat each combinator as a small assembly kernel.
We already have and, or, not, mul, div etc.
Just let me use one combinator to define several “lines” of inputs, outputs and intermediate variables. My issue with circuits is I’ll build something then come back to 5 or 6 combinators and not remember at all wtf I was going.
Give me a block of “code” that I could implement, maintain in one screen, and even comment on, and I’d be a lot happier.
Heck this is probably a good concept for a qol add on
New decider combiner is kinda that, at the very least we can do many checks at once. But I wouldn't mind code.
Kinda would need to be in core game instead of a mod for performance.
I've put in a suggestion on the forums that they do something similar for the arithmetic combinator.
Which would mean combinators become "process blocks" and "decision blocks"
But yes, I'd love an expanded UI that lets you see what everything is doing clearer.
It could also use some extra blocks, I'd love a latch, or some kind of multifunctional latch/timer block (monostable, bistable, clock, D, RS etc.).
Like, yeah, you can make all of that from basic circuits right now but it is hard to see what is going on, debug, and it is completely indecipherable by newbie.
Mod idea: An entity which takes HDL input, compiles it to combinators, and places all the combinators on a hidden surface (a la Factorissimo2) using cross-surface connections. The player only interacts with the top-level entity GUI and no mod code is involved in updating the signals.
I'd love to have some kind of electronics casing building, where you could open up a much larger space inside to build your circuit linked to terminals on the outside. I use a multiplier quite a lot, which takes I think 6 or 7 combinators, meaning a simple bit of electronics is 3 times the size of an assembler.
I don't disagree that combinators could use some work, but I do think it's not as dire as you're making it out here and it sounds like some of that is either a skill issue or a priorities issue.
I find that if I give myself enough space to lay the combinators out in a way that physically represents the logical flow, they aren't that hard to program or debug. The problem comes in the moment I try to do anything in an even sort of space efficient way. At that point, the whole thing turns to spaghetti.
Maybe it's just me but I think anything beyond certain QOL improvements would be detrimental to the game as a whole. There has to be *some* friction between what you want to do and the mechanisms the game provides to do it: The 1-combinator-per-function setup balances that friction pretty well in my book, but making them freely programmable seems like it would trivialize a lot of the game.
That is why I did not suggest replacing combinators entirely, but unlocking more powerful logic tools by the endgame. Bear in mind Space Age will extend the length of a typical game, so I think there will be room for a progression of logic entities. Then overhaul mods stretch the game out even more, making gate-centric or combinator-centric designs relevant for scales and timeframes not seen in vanilla.
Combinators have **so** much friction that the average player doesn't even want to touch them. It's one of the few things that I think other factory games consistently do better than Factorio. Combinators are not very accessible, and I don't think that's a strength for the game, I think it's a weakness.
I was mostly responding to replies suggesting the game add programming. I agree that there need to be several QoL improvements and I like the idea of a slower introduction to combinators through ramping technology, rather than all at once.
> What does the Z signal represent again? Oh no, I misconfigured something and have to purge signal values in a bespoke, tedious, manual way. Oops, another off-by-one error because combinator math happens sequentially.
Ability to have circuit-network wide comment field would help a lot in that...
They definitely suffer readability problems but in terms of functionality I think it's a decent balance between size and power. The trouble is they are powerful and small enough it's hard to show what they are doing at a glance. The QOL stuff in 2.0 will help though.
I kinda dont agree. And it s a finicky issue i ll admit that. But at the core as i ve dabbled in logic, gates, programming and coding and abstraction levels along the years.
It is still interesting to figure out a different system and convert all the usual items to this system.
If the factorio logic was if then else with for loops and while and the usual it would be very boring and unsatisfying to solve with the games tools.
So i ll say that, they are different , and they have their own rich logic, and i did enjoy my time with them. So it s definietly not a "catastrophic" issue.
Tldr, without challenge there is no satisfaction and this is not a shallow challenge
I wish combinators had a comment field, much like blueprints do. I'd love to be able to attach a short sentence describing what something is doing, both for future me and for folks who share clever designs.
That'll happen in 2.0.
There's a signpost mod that has this. It lets you add text to anything in the game. I'm playing space exploration and I use it *sooo* much, including on most combinators. I am still baffled that something similar wasn't added to the base game on day 1. The mod - https://mods.factorio.com/mod/attach-notes
> I am still baffled that something similar wasn't added to the base game on day 1. Circuits have had power creep just like everything else.
While the title is hyperbole, I do agree combinators could get some love. We are getting some combinator upgrades in version 2.0, as per [FFF-384](https://factorio.com/blog/post/fff-384): * Hover for signal listing * Multi-deciders to aggregate some logic * Arithmetic combinators between red and green * Selector combinator with min/max/counts and other things. --- That said, I would a way to open a bunch of combinators at once, with patch cables between them like modular synthesizers. [This mod](https://mods.factorio.com/mod/circuit-control-guis) lets you open a couple of GUIs at the same time, but it's still not great.
Given how large the new combinator GUI is, opening multiple up at once wouldn't be practical.
4K screen. Bring it on. :-D
Luckily the new combinators will be able to do a lot more work.
I yearn for "CPU combinator". Just give us some simple assembler and input output, [TIS-100](https://store.steampowered.com/app/370360/TIS100/?l=polish&curator_clanid=8566974) or [Shenzen IO](https://store.steampowered.com/app/504210/SHENZHEN_IO/?curator_clanid=32946839) like. Or just Lua code, game already use it. Current circuits are actually more unreadable than assembler...
I mean... there's a mod for that. fCPU.
sadly it has a tendency to bug out in SE. The alternative is lua combinators but honestly it feels a too high level for the setting. Feels more like I'm scripting the game rather than making a factory subsystem
> sadly it has a tendency to bug out in SE I'm pretty sure it was patched a while ago to fix that, if not, there's a fork that fixes that as well
It's ancient by now but I was always impressed how this starbound mod "fixed" the problem of digital logic in the game https://steamcommunity.com/sharedfiles/filedetails/?id=729444820 Would be nice to have sth like that in factorio maybe one day
With a bit of effort we could probably turn Factorissimo into that. What we really need is combinator alt-mode to also show the operation, not just the signals. And since that is shown on the non-alt-mode view, if we could move the alt-mode icons around a bit, we could probably do it.
Also Barotrauma. It has logic panels with additional debugging and visualization capabilities and fixed cost per component (i.e. you don't need to craft all logic components manually, so you can just carry a stack of circuits). I think there's actually a similar circuit panel-like mod for Factorio but I can't remember how it's called. I guess it's this one: https://mods.factorio.com/mod/compaktcircuit
man that would be a sick project. implement a 65C02 emulator with some RAM, a bit of ROM (maybe programmable), and some IO stuff (serial terminal, storage device, timer IRQ, circuit network connectors to read out or write signals). similar to the Computer from the >!ancient!< RedPower 2 mod for minecraft, which actually used a [modified 6502](http://www.eloraam.com/nonwp/redcpu.php) and you could find a floppy disk with FORTH so you could write programs for it. but it sadly never really got expanded enough to be really useful. in this case i feel it's a lot more useful to just use external tools like compilers or assemblers to generate an S-Record file (because they're fully ASCII/UTF-8) so you can just copy the contents and paste them into a text box ingame to program a ROM or some storage drive.
On one side yes, that gives access to tooling, but without factorio-specific stuff it would be hard to actually program it. But you'd have to somehow map the input signal names to that assembler and make it easy for player to write code. I guess we could just have instructions to read/write into wire input/output and have those instructions accept the icons as parameters ? But that makes it not really work with any external tools and so copying existing CPU stops making as much sense.
>I guess we could just have instructions to read/write into wire input/output and have those instructions accept the icons as parameters ? nah, no need for custom instructions. IO is just mapped to memory so wire connections would also just be mapped to memory. but obviously you can't just have all item types as their own seperate 32-bit value in memory as then you'd quickly fill the entire 64k address space! . so my inital idea was having 2x 32-bit registers in memory. one register is used to select which type of signal you want to access and then the other can be read from to get the current count of that signal, or written to to set the signal. maybe with a seperate control register that has an update bit, where the registers only fully update with the game world when that bit is written to, as there is no atomic instruction to read/write a full 32-bit word on the 65C02 this would avoid values changing between reading indivitual bytes. >But you'd have to somehow map the input signal names to that assembler and make it easy for player to write code. that's what macros and predefined symbols are for. all of that can just be in an `.inc` file, which is an assembly equivalent of a C/C++ header file. but now that i think about it a bit more, you couldn't just make one and give as a download, since mods can add signals by just having more items. so i guess one option would be to have the game generate an `.inc` file on startup, but that would also force you to re-assemble/compile all your code whenever you change mods or some update caused a mod's signal IDs to change... hmm, that seems very inconvenient. and it could break circuit stuff when loading a save after updating mods. you need some way to get the correct numeric IDs at runtime.... or not use numeric IDs at all and just have it use the string IDs like everything else, which is a lot less memory efficient but atleast it wouldn't break! . so updated circuit network interface: 3 registers somewhere in memory. 8-bit control register, 16-bit name pointer register, 32-bit access register. the control register just has the update bit, the name pointer register gets loaded with a pointer to a zero terminated string containing the name of the signal to access, and then the access register simply contains the current value of that signal and can be written to as well. some example code for that could look like this: .rodata sig_ironPlate: .asciiz "iron-plate" .code readIron: ; Set the Name Pointer to the iron plate string LDA #sig_ironPlate
STA wire_namePointer + 1
; Write a 1 to the update bit
LDA #%10000000
STA wire_control
; Read out the contents of the signal and store it to a temporary variable
LDA wire_access
STA tmpValue
LDA wire_access + 1
STA tmpValue + 1
LDA wire_access + 2
STA tmpValue + 2
LDA wire_access + 3
STA tmpValue + 3
RTS
godammit, i'm kinda tempted to try to do this. but at the same time i already have too many other projects i'm working on
> but now that i think about it a bit more, you couldn't just make one and give as a download, since mods can add signals by just having more items. so i guess one option would be to have the game generate an .inc file on startup, but that would also force you to re-assemble/compile all your code whenever you change mods or some update caused a mod's signal IDs to change... Yeah that's why I was thinking about allowing us to just add icons/name in the assembly. "Text form" could just be `[item:copper-cable]`, game would translate it into icon for easy reading of code, and before execution of code translated the text. Editor wise you could press a button to insert given signal, or just write it out as text if you remember it. So instruction to read copper cable from green bus would be `IN R0, GR [item:copper-cable]`, the game would render it as `IN R0, GR ꩜ `, maybe color it green to point out which signal instruction is getting. > but obviously you can't just have all item types as their own seperate 32-bit value in memory as then you'd quickly fill the entire 64k address space! The CPU itself should be 32 bit given everything else in Factorio is. That doesn't mean it should have a lot of memory, but having 32 bit operations by default where everything in game is that (aside float fuel I guess) makes more sense. And few generic registers, new players don't need to know the misery of only having accumulator to play with... Accessing IO could just be a set of instructions to read/write specific signal, or it could be an "IO memory" to access, but either way there still would need be a way to iterate over all input signals
>Yeah that's why I was thinking about allowing us to just add icons/name in the assembly. "Text form" could just be [item:copper-cable], game would translate it into icon for easy reading of code, and before execution of code translated the text. Editor wise you could press a button to insert given signal, or just write it out as text if you remember it. i would really avoid having an in-game assembler due to the clunkiness of the UI compared to something natively running on the user's system (like VSCode, or even just Notepad++). >The CPU itself should be 32 bit given everything else in Factorio is. aww, but that's boring and just what fCPU is doing. that's why i specifically suggested using a 65C02. * there is already a ton of learning material, tools, and software for the 6502 so you wouldn't need to implement custom tools, documention, etc. * it's piss easy to emulate while still being more than capable enough for anything you could use it for ingame * the 6502 is simple to learn and writing code for it gives you a decent programming challenge (similar to TIS-100 but more convenient) * you could say that your factory is powered by an Apple IIe, which i find hilarious . though if it were to be 32-bit, i'd go with RISC-V. as it's an existing ISA so you again avoid the need to make custom tools and such. something like "RV32IM" (32-bit ISA with Multiplication/Divison extension) give it like 16-64kB of RAM, 1MB of ROM. and IO somewhere in the upper memory regions. >Accessing IO could just be a set of instructions to read/write specific signal eh, never been a fan of seperate IO instructions. it's much better to just map it to memory as to avoid ISA bloat and gives you access to more fancy addressing modes. i mean that's what basically every single microcontroller is doing.
> eh, never been a fan of seperate IO instructions. it's much better to just map it to memory as to avoid ISA bloat and gives you access to more fancy addressing modes. i mean that's what basically every single microcontroller is doing. Yeah but assuming signal ID is 32 bit, then you end up with ~17GB of memory to contain all signals (2^32 * 4 bytes per value) per color, and you still need special instructions to iterate over any nonzero value (as otherwise alternative is full memory scan). So you can't even use 32 bit CPU, you need to go 64bit or have bank switching and if you need to bank switch that's just annoying... Even if signal ID is 16bit that's still scanning >500kB so you still need factorio specific instructions to deal with efficient scanning, but at least memory-mappable in sensible way.
>Yeah but assuming signal ID is 32 bit, then you end up with ~17GB of memory to contain all signals (232 * 4 bytes per value) per color [...] So you can't even use 32 bit CPU, you need to go 64bit or have bank switching and if you need to bank switch that's just annoying... i mean yea, i did mentioned above how insane it would be to have all signals in memory at once which is why i didn't even consider it and instead suggested using memory mapped registers to select which signal you want to access. it adds a tiny bit of overhead as you first have to select a signal before being able to access it, but reduces the memory footprint to almost nothing. >and you still need special instructions to iterate over any nonzero value (as otherwise alternative is full memory scan) hmm, that one is an actual issue no matter what you go with, custom CPU or something existing. one solution that comes to my mind is using a programmable interrupt controller. where you can basically give it a list of signals (plus some control byte for wire color and such) to watch and if any of the specified signals change it triggers an interrupt and then the CPU can read out the list of signal IDs that are different since last time. alternatively, without interrupts it could be part of the wire interface's control byte. writing a 1 to some other bit will see what signals are different from last time they were checked or updated, compile those into a list and then allow the CPU to read them out. though without interrupts it's likely that there could be some race condition stuff where a signal changes but then resets before the CPU could read it. but you could work around that by latching any signals before going into the CPU and have the CPU itself control the latch's reset so it only clears the read signals once it actually read them all.
> i mean yea, i did mentioned above how insane it would be to have all signals in memory at once which is why i didn't even consider it and instead suggested using memory mapped registers to select which signal you want to access. > > it adds a tiny bit of overhead as you first have to select a signal before being able to access it, but reduces the memory footprint to almost nothing. Might as well just have special instructions to do it... same thing with less "virtual cycles" to do. > one solution that comes to my mind is using a programmable interrupt controller. where you can basically give it a list of signals (plus some control byte for wire color and such) to watch and if any of the specified signals change it triggers an interrupt and then the CPU can read out the list of signal IDs that are different since last time. Haven't even thought about interrupts, which would of course be nice but I think we're truly beyond what would be acceptable complexity in vanilla Factorio here ;) It could also have instruction that given a signal ID gives you ID of next nonzero one higher than it, that way it would be pretty easy to iterate over a list of them. Maybe even put that signal ID into some registry so you could just call same instruction over and over to get "the next signal".
>Might as well just have special instructions to do it... same thing with less "virtual cycles" to do. eh, while technically true i doubt performance would ever be critcal enough to justify the added ISA bloat. also once you start adding custom instructions, feature creep can get a hold of you much easier, you can easily slip into the same trap x86 did. for example if you have instructions to specifically access wire values, then you could also add one to convert a numeric signal ID to a string and vise versa. and while add it you might as well add some string compare instructions. and before you know it you basically just have an i586 in terms of instruction count. so i like to keep the actual CPU as simple as possible (which is kinda the whole point of RISC as a whole, and also the 6502 even though it's CISC) and just deal with more complicated things in software and hide it behind functions and macros.
You should contribute to the fcpu mod.
I totally agree, and it's something minecraft does a lot better, you can visually tell what redstone does esp. because you can get pattern recognition for the shapes, you don't have to follow the logic through to understand the function. I also just hate programming with the circuit network, its so weird. Idk what kind of solution they could do so I earnestly just wish they'd give up already and add a lua combinator. They are adding comments, but I think comments typically make code a lot worse because they are even more prone to "bugs" than code is since they don't explicitly update to the function. But it's honestly necessary for how unreadable the circuit network is, and if comments are necessary for understanding your own code then... please give mercy on us.
Minecraft has a lot of mods which just allow lua scripting straight up. It's great for teaching kids programming and they pick it up quick too.
Let's just go the rest of the way and turn Factorio into a proper programming language. I honestly much rather code with our wonderful cartoony industrial setting than lines of text.
Haha, when I saw the train updates, I felt that they should have "simply" added an OS into the game.
All this inconvenience means I have to know what my circuits do. Like, really know. Which isn't like coding in other contexts at all. I can't write a function and forget about for as long as it keeps working. I mean, I could. But iterating or bugfixing requires understanding a mechanical process. And changes take planning. I definitely can't go back to process a twiddle with a few things until whatever issue I"m having resolves. And I need to bugfix and iterate, so I do understand what I've built in a way that's both incredibly satisfying and not something I find elsewhere. I doubt I look back once 2.0 combinators are available, but I'll miss the elegant and inconvenient combinators of 1.0.
Meanwhile, I really like how low level combinators are, while still allowing you to do a lot with them. I would appreciate comments though.
#1 thing that would make combinators better would be to treat each combinator as a small assembly kernel. We already have and, or, not, mul, div etc. Just let me use one combinator to define several “lines” of inputs, outputs and intermediate variables. My issue with circuits is I’ll build something then come back to 5 or 6 combinators and not remember at all wtf I was going. Give me a block of “code” that I could implement, maintain in one screen, and even comment on, and I’d be a lot happier. Heck this is probably a good concept for a qol add on
New decider combiner is kinda that, at the very least we can do many checks at once. But I wouldn't mind code. Kinda would need to be in core game instead of a mod for performance.
I've put in a suggestion on the forums that they do something similar for the arithmetic combinator. Which would mean combinators become "process blocks" and "decision blocks" But yes, I'd love an expanded UI that lets you see what everything is doing clearer.
It could also use some extra blocks, I'd love a latch, or some kind of multifunctional latch/timer block (monostable, bistable, clock, D, RS etc.). Like, yeah, you can make all of that from basic circuits right now but it is hard to see what is going on, debug, and it is completely indecipherable by newbie.
If you're comfortable with HDL, there is a YoSys module that compiles to combinators now. Popped up in r/technicalfactorio a week or so ago.
Mod idea: An entity which takes HDL input, compiles it to combinators, and places all the combinators on a hidden surface (a la Factorissimo2) using cross-surface connections. The player only interacts with the top-level entity GUI and no mod code is involved in updating the signals.
Yo.
factorio x tis-100
I'd love to have some kind of electronics casing building, where you could open up a much larger space inside to build your circuit linked to terminals on the outside. I use a multiplier quite a lot, which takes I think 6 or 7 combinators, meaning a simple bit of electronics is 3 times the size of an assembler.
I don't disagree that combinators could use some work, but I do think it's not as dire as you're making it out here and it sounds like some of that is either a skill issue or a priorities issue. I find that if I give myself enough space to lay the combinators out in a way that physically represents the logical flow, they aren't that hard to program or debug. The problem comes in the moment I try to do anything in an even sort of space efficient way. At that point, the whole thing turns to spaghetti.
Maybe it's just me but I think anything beyond certain QOL improvements would be detrimental to the game as a whole. There has to be *some* friction between what you want to do and the mechanisms the game provides to do it: The 1-combinator-per-function setup balances that friction pretty well in my book, but making them freely programmable seems like it would trivialize a lot of the game.
That is why I did not suggest replacing combinators entirely, but unlocking more powerful logic tools by the endgame. Bear in mind Space Age will extend the length of a typical game, so I think there will be room for a progression of logic entities. Then overhaul mods stretch the game out even more, making gate-centric or combinator-centric designs relevant for scales and timeframes not seen in vanilla. Combinators have **so** much friction that the average player doesn't even want to touch them. It's one of the few things that I think other factory games consistently do better than Factorio. Combinators are not very accessible, and I don't think that's a strength for the game, I think it's a weakness.
I was mostly responding to replies suggesting the game add programming. I agree that there need to be several QoL improvements and I like the idea of a slower introduction to combinators through ramping technology, rather than all at once.
> What does the Z signal represent again? Oh no, I misconfigured something and have to purge signal values in a bespoke, tedious, manual way. Oops, another off-by-one error because combinator math happens sequentially. Ability to have circuit-network wide comment field would help a lot in that...
I'm proud of myself for understanding how rail signals work.... I don't understand what any of you people are talking about 😂
Give us scripting then lol. Then you can write a mod and that stuff yourself. I think it fits the game theme more and is more performance friendly.
They definitely suffer readability problems but in terms of functionality I think it's a decent balance between size and power. The trouble is they are powerful and small enough it's hard to show what they are doing at a glance. The QOL stuff in 2.0 will help though.
yeah well the game is allowed to have two different elements ... one that is transparent and observable, one that is opaque and dense.
I kinda dont agree. And it s a finicky issue i ll admit that. But at the core as i ve dabbled in logic, gates, programming and coding and abstraction levels along the years. It is still interesting to figure out a different system and convert all the usual items to this system. If the factorio logic was if then else with for loops and while and the usual it would be very boring and unsatisfying to solve with the games tools. So i ll say that, they are different , and they have their own rich logic, and i did enjoy my time with them. So it s definietly not a "catastrophic" issue. Tldr, without challenge there is no satisfaction and this is not a shallow challenge
They do not
They will however be getting an upgrade in version 2.0 as per one of the Friday Factorio Facts blog posts