So what can this tech do?
This sounds so silly, but when you think about it, it’s actually genius. Thanks for pointing this out, and that would make a pretty good quote!
2 Likes
I responded on Discord but I’m gonna respond here too because everyone should see this.
The channel cap, if there even is such a thing, is not being triggered by this.
The ‘per-tick’ limit is unknown, and its unknown if ticks even play a role in this, if they’re real at all. I always chalked up the delay in some recursive systems as lag, but they may be something worth looking into. Gimkit can be super laggy sometimes, however, so that’s something we gotta figure out.
As for the second image, the thing that we all need to take note of is that the combined outputs reach 350, not 300. This means there is some secondary limit to multi-output recursion. It’s super weird, but the blocking all wire and channel transmissions thing is almost certainly incorrect, and relatively easy to test.
Basically, bh, the WIRE CAP seems to be 350 signals per second, and the RECURSION LIMIT is 300. When firing it from 2 different outputs, you don’t hit the recursion limit before you hit the wire cap, so the wire cap is topped instead.
OOH THIS IS GOOD
That means next we need to test multi output channel recursion, which is a whole new ball of yarn. (or whatever the saying is)
5 Likes
When I was doing some testing, I also remembered this guide, that uses 1 trigger:
This could be another method, if the first one doesn’t work in your situation, right? Right?
Genius!!!
2 Likes
I mean… kinda…
It’s not really the same, but sure.
1 Like
ALRIGHT.
It’s confirmed, the channel cap is real. Here’s the way it works:
CHANNEL CAP:
Each channel has a maximum of 300 signals that can be sent per second. This is independent of any other channels.
WIRE CAP:
Total wires in the game are tracked per second, and only 300 can be sent.
Unfortunately, channel cutting isn’t very effective, since you need to send 300 signals on that channel to get anything to stop, which kinda defeats the point of cutting the channel in the first place.
@Shdwy Why would anyone want to cut a channel in the first place? Wire cutting would be good to deactivate wire repeaters and IIMs or other undeactivatable devices, but channel cutting though?
wait you can deactivate an iim with this?
Yea I think so. If you check out pi’s guide on it.
i meant cutting wires to deactivate it but pi’s guide won’t work because iims only have activate iim and clear item from inventory
You could probably use wire cutting to deactivate it. Or just activate a second one. Channel cutting is too inefficient.
That’s not how IIMs work lol
They’re an independent thing, they don’t need wires to function.
You wouldn’t really ever need to cut a channel, necessarily. I’m sure there’s some use case, but I can’t think of it.
But the channel cap itself is good to know. This means that the recursion limit may not be a recursion limit at all!
So now how do we use this to break Gimkit? 
@getrithekd please put the concept tag back on the topic
The wire and channel limits are conceptual things; they’re ideas.
Well… Fine. It just doesn’t sit well with me…
1 Like
Bump, this is something the rookies, average, and the elders can use if the map is complex and needs a signal ending to progress through the game, or needs it to add effects for certain rooms, or other functions
Feels like a year has gone by since I been on the forums, no pun intended.
3 Likes
Agreed. The only problem with it is that it cuts ALL wires for the next second, so if you have any background wire loops or anything running when you use this, your game is not gonna have a fun time.
Channel cutters are a bit simpler because you can use a throttle limit to keep from registering cuts as just a lot of signals.
Still, this is crazy useful (every once in a while lol)
1 Like
that is why I am not the complex device guy in my lost rooms map or any of my maps for that matter, also I don’t use channels at all
Channels are super useful though!
That phrase tends to summon a lot of annoyed gims…