Hi there everyone.
Remember this? Yeah, well, I did it again. Except waaaay better this time. As far as I can tell, there is a global channel cap. It seems weird, but my best guess is 694, based on this screenshot that managed to cut a disconnected system:
See, in the comments, I wrote that you could cut channels via the same mechanism. However, a key flaw (as far as I can tell) was that this only worked in same-channel cutters.
Basically, channel A could only be cut by channel A.
This is no longer true.
I’ve found a way to cut channel B with ONLY channels A, C, and D.
The setup is essentially the same: one trigger leads to two different ones, as in the screenshot. (The top one triggers the bottom two to endpointless outputs)
For Extra Details
Total Finds
Here’s everything we know so far:
The Recursion Limit
This is a limit that occurs on both channels and wires in a closed system. Basically, channel/wire A cannot run more than 300 times in one second. This is certain.
The Global Wire Cap
In your entire game, only 350 wire signals can be processed in a single second. The time is estimated and probably correct, but there’s a small chance it’s something else, like thirty ticks. I know of a way to test this, and will do it later.
The Global Channel Cap
This is the new discovery here, and as far as I can tell, it’s 694. I strongly urge you to go try and experiment for yourself, as this is a completely new find. You could literally find groundbreaking information, and as we can tell, it’s not that hard!
The delay is unknown, and more on that in the speculation section.
Speculation
So one interesting thing is that in the system I showed you, the first trigger got 300 signals, but the next two got 197. In total, of course, that’s 694 signals. The thing I’m confused about is why the bottom two had the same amount. Here are the channel configs for each:
(format is trigger location, signal to trigger, signal sending out)
top: jump, jump
middle: jump, e1
bottom: e1, e11
This is pretty weird, but could give some insights into the way Gimkit processes ticks.
If you have any thoughts do tell.
Another weird thing. I had a set of 4 triggers running at the top above the system shown to test if the system was truly able to cut channels globally.
They were all completely disconnected systems from anything else in the map. One was running at 0.1s delay, one at 0.5, one at 0.3, and one at 0.2. When all of them were active (confirmed via counters), I ran the system. A seemingly random collection of them turned off. With more trial and error, I was eventually able to get them all turned off.
Now, if you aren’t familiar with trigger mechanisms, they’re actually incapable of being stopped during their delay period. If you have a trigger with a 10 second delay, and you disable and re-enable it multiple times during that period, it won’t stop. However, as soon as it’s disabled ON either reception or broadcast of a signal, it actually disables. This works the same way; if the global channel cap cooldown time is too short and runs while the trigger is still in its delay period, then the thing will have NO EFFECT. I tried this a number of times, and I know the time is less than (but near) 0.1 seconds, because with the 0.1 second delay system, the cutter disabled it most of the time.
To Do
- Test whether the caps are tick or time based
- Find another way of proving global channel cap
- ???
If there’s anything else you can think of, any questions that you have, ask and I’ll put them here!
Sorry for the ping, technical people, just wanna make sure you see this.
@Blueboat @getrithekd @Anonymous @wingwave @Apoll02
Yes, I know some of you guys aren’t technical in the sense that I’m talking about, but you’re some of the few people who put effort into understanding this stuff, so it’s worth a shot.
