Recursion 101: A Foothold into Technical Gimkit

What is recursion? Well, in general computer science, recursion is a function calling itself. If we have function f(), inside of that function it will call f(). In Python, it would look like this:
def recurse():
(indent) recurse()
But that’s Python, not Gimkit. In Gimkit, our version of recursion is much more loosely defined. Any device that triggers itself, or – more specifically – any system that triggers itself, is considered recursive. If I have trigger A send out on channel ‘b’, but it also triggers when receiving on channel ‘b,’ then that is a recursive trigger. Or having a checker that checks on signal ‘a’, but then if it fails or passes the check will check on channel ‘a’, leads to a recursive checker. You can also do this with multiple devices. Lets say trigger E sends on ‘b’ and receives on ‘c’, then if trigger O sends on ‘c’ and receives on ‘b’, then they are recursive.

This is where things start to get tricky. If a system has a timed delay, it is continuous recursion. If it has no written delay (e.g. the ‘how long does this trigger take to trigger’ field is empty), then it is instantaneous recursion!

Now, generally, continuous doesn’t cause anything weird. I say generally because I recently discovered a new quantum mechanic! However, the main qmechs are focused on instantaneous recursion and its offshoots.

One of the interesting things that fall under the recursion bucket, so to speak, is concurrent recursion. Let’s say you have trigger A from our previous example. We’ll give it a delay of .1 seconds. We also hook up an item granter to this, one that triggers on a signal from channel ‘b’.
If we step on the trigger once, we receive ten items a second. But interestingly enough, if we step on this trigger again, we will start to receive twenty. Then thirty, then forty. It keeps going. There IS a cap, but I don’t remember where it is. I think 5 total concurrent loops can run at once or something.

Anyways, there are a bunch of different things within the concept of Gimkit recursion. It’s pretty cool, and if you’re interested in learning about technical Gimkit and the bug hunting process, this is where to start. Thanks for reading, and have a good one!

shdwy out.



Oh yeah! Thanks for this @Shdwy!!!

wow! you guys can read my 300 word essay in seconds! impressive! i wish i could do that! good job! almost as good as the hay wagon! (nothing is as good as the hay wagon!)


Sorry I don’t really understand what quantum mechanics are, but great guide! Could someone explain it to me please.

1 Like

Sure! Basically, quantum mechanics were originally anything to do with sub-tick behavior of the game, e.g. AUO (the order Gimkit resolves devices). However, it’s kinda moved into a new category of really any small technical details that are the fundamental rules of Gimkit, or things that cannot be explained with other phenomena, and can only be cleared up by analyzing the code.


One of my earlier experiments in recursion was making three wire repeaters trigger themself indefinitely and it broke the counter that were tracking the loop count. The counter immediately went to 189 when I started the game and just broke forever because of how fast the devices would’ve recursed (exponential increase, like xx level). The game just stopped the recursion too.


Yep, sounds about right. 300 is usually the limit that Gimkit has before it stops the loop, but I think 189 is the benchmark for 3 device recursive systems. I’m surprised it worked with wire repeaters though, I though those resolved instantly.


Uh what? I still don’t understand. How does AUO work by the way?

1 Like

I tried it multiple times, sometimes just as a fun experiment. The number always changes, once I got 81, once I got something like 144, it’s pretty random.


Thats… not supposed to happen but ok lol
Depends on how you do it I guess

and @raeB What don’t you understand?

The simplest way of explaining AUO is, as blackhole says, ‘the order gimkit does things.’ A good way of thinking about it for those with coding experience is that there is a list of devices that need to be resolved every tick. Whenever a device is edited/created (a new instance of the device is created), the device is appended, or added to the end of a list. Then, Gimkit resolves the devices starting from the beginning of the list, meaning the ones edited most recently get resolved later.


Think about this:

Nothing happens at the “exact same time”. There will be seconds, miliseconds, nanoseconds, yoctoseconds, picoseconds, however many second-delays on these things. Nothing happens at “the same time” in gimkit too.

So in which order would gimkit do things? Trigger the actions of two wire running at the “same time” in a random order?

It’s an interesting thought. The answer? When the wires were made.

This may or may not have been confirmed, but there may be “lists” of wires from devices. And each time a new wire gets added, it’s appended to the end of the list. So essentially, wires run in the order they are created.

For channels, and channels/wires, stuff gets messy. For blocks, they run in the order they’re placed in (this is one of the most basic concepts of block coding, blocks should definitely not run in the order they’re placed in), so AWO, ABO, and ACO are solved. I guess AMO and ADO are just the “confusing” things about the field of AUO in the field of Quantum Mechanics.

Thank you for coming to my ted-talk.


Yep, sounds 'bout right. I d m’ed Josh about the whole update thing with appending lists, and he confirmed it.
AUO is, I feel like, the most useful quantum mechanic.

quick typo lol: blocks run in the order they’re placed in, they should definitely not run in the order they’re placed in

It has to be [spoiler]”inserttext”[/spoiler]


I think that this should be a guide, not in devices.

alright then

I kinda like sticking with the devices trend for all the technical Gimkit stuff, cus it really is device-based, and while it is a guide, it also brings a certain uniqueness to it. That uniqueness feels warranted since it really is a whole new branch of Gimkit stuff.

Ok. But… This has the getrithekd feel of uneasyness to it…

What’s wrong with the device tag though?

Nice! Wow Shdwy, it looks like you really are going to break Gimkit Creative down to the very minimum! Keep up the great work!


I know this wasn’t to explain recursion, but I finally understand it lol. I believe 8 is the max concurrent recursion as it is the limit in the repeater device.