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)
bump because important
this keeps on getting forgotten so yeah
get pinged @Shdwy not-imposta
idk what that was for but yeah
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
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?
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.
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.
Ok, so starting out: avoid wires.
You shouldnāt touch em if you want max processing, at least not in the beginning. I would suggest just splitting up the tasks into 2 or 3 completely disconnected lines. Iām not sure how youāre storing the data, but you want to avoid as many signals as possible, so having properties linked to counters or something and then using counters as your computation devices might be the move.
@Blackhole927 I saw you were online, does this answer your question?
Thatās really not important. All you need to worry about is this:
Each channel has a cap of 300 signals per second. However, you can have two channels running at this cap at the same time, and no problems occur. There is a global channel cap, but Iām not sure what it is.
Thatās notā¦
wow.
a) this post was 175 days old at the time of posting. Youāre a bit late.
b) this isnāt conventional guide; itās introducing a technical concept, not teaching someone how to make a hot dog stand with prop art.
c) thereās not really many pictures that could be used here. Iām not showing you a random picture of a trigger, this is a broad technical concept. Itās like asking you to show me a picture of what imagination is, or a picture of how flappy bird works. Just doesnāt really fit.