Cool!
I didn’t think this was possible…
1 Like
Wow… GIMKIT is kinda wonk when it comes to triggers.
This isn’t triggers lol
You can do this with counters, checkers (i think), maybe blocks, relays, literally any signal pusher.
my bad I get mixed up with the two. (I don’t know why)
1 Like
bump because important
this keeps on getting forgotten so yeah
get pinged @Shdwy not-imposta
idk what that was for but yeah
2 Likes
Alright, I need a bit of help here.
For my project, I need to perform about 23,000 calculations, or in other words, run a trigger 23,000 times. This isn’t fast, right now it takes about a minute and a half to complete. This is far too slow, and I want to speed it up.
The current approach I’m doing is to run the trigger 300 times a second, but I heard from getrithekd that you can do something with breaking the task into chunks and then having triggers run concurrently to achieve this. How do I do this? Do I just have a trigger recurse, and then wire it to another trigger to do a total of 600 triggerings a second? Or what?
This doesn’t need pictures, it’s explained perfectly
2 Likes
At least a few pictures would be nice.
And plus, editing time ran out a long time ago
Pictures are powerful is still a very relevent and useful guide.
I’m not saying it isn’t
This isn’t a guide, it’s just a theory explaining a concept simply and asking for ideas and elaboration. Anyone reading this guide is here for the concept explained in text, not pictures. The words “make a trigger, and make it broadcast on a channel, and receive on that same channel.”
Pictures are powerful, but there isn’t a big reason to put them here. If anything, the one thing this topic really needs is spaces between paragraphs, and the python code to be in a code block.
But, I digress. Does anyone know the answer to this question I asked here?
1 Like
Alright
Are you looking for only 1 trigger, or is multiple an option?
You need 2 separately recursing systems. You can start them with the same wires though.
1 Like
As many triggers as is needed, I care much more about speed than memory here.
So two triggers that both recurse separately, but are started at the same time?
I don’t think making more recursive systems is going to help as the recursion limit is set in stone (gimkit tracks the # of signals and stops all processes in that map once it reaches over 300)
You could try sending 298 signals and then send into a 1s delay trigger (rinse and repeat) to efficiently get around the recursion limit, however, it still is going to take ~79-200s (depending on how fast the servers are) to complete that task you are trying to do.
Yeah, that’s my current approach, and it’s too slow. I still need to do some testing with getrithekd’s idea though.
Yes. That makes them have different channel caps, so then you can get more than 300 calculations per second.