I recently got addicted to making counter-efficiency more… efficient, and I stumbled upon a problem with the limits of the counter addressed many times in help topics. The problem is that when running a trigger loop which almost all counter-efficiency mechanics feature, the maximum number a counter can run at once with channels is 300 and the maximum with wires is 187. The solution requires the trigger running the loop to add a slight delay, but the delay only goes so low and it adds up for larger mechanisms. This topic is to possibly research into ways to cut down on the delay, but also keep low memory, so counter-efficiency problems don’t take too long to run or test and don’t take up too much memory.
5 Likes
What’s the LOWEST the trigger delay CAN go?
HOW DID YOU CRASH THE GAME 
By typing:
0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 into the delay.
1 Like
The lowest it can go is technically to the binary storage limit of gimkit, but going that low doesn’t actually affect the trigger delay itself in game.
1 Like
Ohhhhhhhhhh, so there is a limit. Maybe we need to take… coding software into account. Maybe Gimkit runs on a 6-bit system?
Oh yikes that sucks…
I think someone once posted that you could just perform concurrent tasks and divide the entire operation into smaller chunks in order to finish it faster.
Example:
You have multiple triggers that repeat simultaneously, and they should be recursive. They will compute something in block code, or something else, and the result will be combined/concatenated using a center trigger that receives inputs and returns one output.
That works, but it isn’t very efficient memory-wise. I’m going to update the topic to include the memory part.
3 Likes