XOR memory is often used in binary counters due to its sleek effectiveness. Despite this, my original circuit I encountered this issue with was a relatively overly-complex counter, which you can find here: https://steamcommunity.com/sharedfiles/filedetails/?id=2705433423 Many creations use this kind of memory over NOR-gate T-Latches when a toggle solution with only one input is beneficial. And while the alternative NOR-gate or NAND-gate toggle flip-flops meet this requirement as well, XOR-gate memory is simpler. In fact, with blueprint editing, a XOR-gate memory cell can be reduced to a single self-connected logic gate (this is not the same as glitch welding, as it actually produces a single logic gate creation, rather than three gates in the same space as one). I prepared a test memory unit to confirm the issue and rule out other factors. The instructions are as follows:

1. Create a 3 block XOR gate memory module. It consists of three XOR gates connected in a loop pattern (Block A is connected to B, B to C, and C to A)
   
2. Connect one of these XOR gates to an AND or OR gate as an output
   
3. Connect an AND gate to each XOR block as an input
   
4. Either create a one-tick pulse generator now, or after step 5, and hook it up to the input AND gate in step 3 (in essence, create it inside or outside the circuit block. Either will reproduce the issue)
   
5. Connect the circuit block from the mod and scan the circuit
   
6. Connect the singular input and singular output to the circuit block, wire the one-tick pulse generator if necessary, and then send a signal into the circuit block through the input.

A completed circuit with an external one-tick pulse generator (as in, it is not included) can be found here for reference: https://steamcommunity.com/sharedfiles/filedetails/?id=2705444853


The simple module above should toggle the output pin every time the input pin receives a one-tick pulse (the single tick is important because of the nature of XOR-gate memory. It is loop device, and the XOR gates will shut off due to two inputs being high if the pulse is too long. This results in a repeating on-off state for as long as the pulse continues). The counter should count up one binary value every time (using the grayscale-colored outputs) a one-tick pulse is sent on the input (red pin)


No output is given on either circuit whatsoever. They are completely unresponsive

Originally posted by Prime:

XOR-gate memory does not function

XOR memory is often used in binary counters due to its sleek effectiveness. Despite this...

Thanks for the thorough description!

I've experimented a bit and it seems as if the one-tick pulse generator within the scanned circuit is the culprit. Skipping step 4 yields a working circuit for me.
I tested the T-Latch and the counter which worked fine on my side (without using a one-tick pulse generator in the scanned circuit) 🤔.

Could you do me a favour and test the CC mod with this circuit? It should be exactly the same as yours, except that it lacks the one-tick pulse generator.
https://steamcommunity.com/sharedfiles/filedetails/?id=2706115741

Originally posted by Sheggy:

Originally posted by Prime:

XOR-gate memory does not function

XOR memory is often used in binary counters due to its sleek effectiveness. Despite this...

Thanks for the thorough description!

I've experimented a bit and it seems as if the one-tick pulse generator within the scanned circuit is the culprit. Skipping step 4 yields a working circuit for me.
I tested the T-Latch and the counter which worked fine on my side (without using a one-tick pulse generator in the scanned circuit) 🤔.

Could you do me a favour and test the CC mod with this circuit? It should be exactly the same as yours, except that it lacks the one-tick pulse generator.
https://steamcommunity.com/sharedfiles/filedetails/?id=2706115741

I have just confirmed that it works. It seems the one tick pulse generator was indeed the culprit for both the counter and the single cell. I must've misremembered and thought I tested it with an external one-tick generator (or I wired it improperly). My mistake, sorry for the trouble. At least I know XOR memory works just fine! Consider it resolved.

Originally posted by Prime:

Originally posted by Sheggy:

Thanks for the thorough description!

I've experimented a bit and it seems as if the one-tick pulse generator ...

I have just confirmed that it works. It seems the one tick pulse generator was indeed the culprit for both the counter and the single cell. I must've misremembered and thought I tested it with an external one-tick generator (or I wired it improperly). My mistake, sorry for the trouble. At least I know XOR memory works just fine! Consider it resolved.

No worries! Glad I was able to help you out :)

some large builds cannot be scanned. I made circuit that turns two 8bit signals parallel channels, then adds them together and turns the result back into an 8bit long signal. When trying to scan it, it simply does nothing. It does not make use of your blocks internally, so its not a recursive scanning issue.

is there a way that you can provide us with the creation in question?

hi, yes, but i also just realized that it has a timer on it. Further testing showed that the timer is the culprit.

And it had a 1-tick generator...

I was just working on an upgrade to my 3D Printer using the instantaneous gates as ran into the problem that once I started using the large amounts for my 512 bit memory (8x8x8) the game started tanking. (I had about 1400 Instant gates and 1400 non-instant gates on the same thing and it was lagging more then the previous version that had 4000 non-instant gates. Also something to note is that the when the game started tanking it wasn't using all of my computers resources of any variety, as in I still had more CPU, GPU, and RAM that wasn't being used)

Reproduction Steps

1. Create 4x4 Plate of Instant Gates
2. Copy on lift and weld 4 together to get a larger square
3. Copy new square
4. Repeat Steps 2 and 3
5. At some point it starts lagging

Now you may be thinking that this will just lag anyways and yes, but now try again with unmodded gates and repeat until you have the same number of unmodded gates as you had modded gates (after deleting the old gates of course). If your computer acts the same way as mine the same number of unmodded gates shouldn't lag.

Is this something that you can fix? If not that is understandable but it would be nice to be able to create large creations like this with only the normal amount of lag.

Also something to note, I was just sitting in a world with practically nothing loaded with the mod active while writing this and I noticed that my GPU is at maximum usage. Not sure if this is the mod's fault or just scrap mechanic.

I'll have a look into it!

Another thing I've noticed. I was working on something that needed 256 (cause that's a nice number) outputs. After getting 255 of the connections done I was going to connect the circuit block to the last output when it said "Max connections reached". Is this something that you could fix?

Thanks in advance for any progress on this front.

Originally posted by scrapninja:

Another thing I've noticed. I was working on something that needed 256 (cause that's a nice number) outputs. After getting 255 of the connections done I was going to connect the circuit block to the last output when it said "Max connections reached". Is this something that you could fix?

Thanks in advance for any progress on this front.

That's a game limit we can't change unfortunately. Regarding the lagging, I'll get back to you when I've gathered more info on what might cause it. This could take few days, since I'm quite busy right now 😅

Thanks for getting back! Glad you are looking into it. When I finally got the circuit done and stress tested and scanned it the lag went away (After only having the circuit block instead of the whole thing built out). So something about the circuit block with a scanned circuit is a lot less laggy then the same circuit built in the world.

As for the built in limit of 255. What about making another block that copys all outputs of the input circuit block. Idk if that would work but it would look like: Inputs -> Circuit block -> Several "output extenders" -> Already existing output blocks of varying colors
Idk if that is feasible but it would be great if it was.

Whether or not you can do anything regarding the output limit it is nice to know that you are working on what you think you can work on.

I understand that people are sometimes busy with what is needed and I wish you luck on whatever is holding you up.

Wholesomeness be with you!

Some kind of redesign of the current user interface is actually warranted. We now can create custom tools and have some kind of "support" for drop downs (at least somewhat better GUI options than before lol). I'll think about how such a grouping of outputs could be best implemented.

If you have some kind of idea that could improve how users interface with the mod, I'd gladly read about it!

Originally posted by scrapninja:

I understand that people are sometimes busy with what is needed and I wish you luck on whatever is holding you up.

Wholesomeness be with you!

Appreciate the nice words!
It's mainly university courses that I'm busy with. I'm trying to organise my time so I can get to doing other things, but I'm bad at it 😂

After looking into the code and doing some tests, I couldn't find much that I could've changed.

I ran tests with ~16k instant logic gates my framerate dropped to around 30. I selectively changed what code was being run and - against my expectation - experienced a greater frame drop with an almost empty script 🤣

At least this shows that Scrap Mechanic suffers from poor performance in general and lacks the necessary optimisation. I suspect this behaviour manifests when a sufficient amount of calls to the part's `update` callback method are invoked adding significant computational overhead.
This could explain why the compressed circuit outperforms fully fledged instant gate circuits, since it's only a single call to simulate the whole circuit. It's likely the vanilla implementation of logic gates is also somewhat optimised which explains the performance discrepancy to scripted parts.

To conclude: I can't do much to optimise for higher frame rates. The most I've got out were around +5 FPS with a small change, but this might be insignificant considering different PC specifications for the general player base.

The biggest improvement to the UI that I can think of is the ability to choose which Pin you want in an output block by either entering a number manually or choosing from all the pins of that color in a circuit. It would also be nice to be able to manually change a gate's pin number either in the UI or with a tool.

I also can't seem to see the pin number of any instant gates, only un-modded gates.

I've also noted that the unmodded gate connection bubble (the little blue circle) is smaller than all the other connection bubbles (including the instant gates), so if you could make that connection bubble smaller then that would be a QOL improvement.

Sometimes when I have a logic system that has some unmodded memory bits (XOR LOOP) interspersed with instant gates (Which happens with my working binary counter design) that when I load the world I will often find that seemingly only one or two of the XOR's in the loop got a pulse (Which makes any XOR memory bit turn into a clock). If I had to guess this is because instant gates load a few ticks of logic before the world/creation has finished loading. I don't think I've seen this happen with instant gates though so good job on that front.

This mod has passed The Modpack on my list of favorite Scrap Mechanic mods so good job and keep up the good work!

As always have a great time and stay wholesome!