Swarm Miner Qurry Unexplained "too Long Without Yielding"

Hello

I am having problems with debugging of my own program : Swarm Miner
Few people reported "too long without yielding" in many points of program but i am unable to duplicate and correctly solve those reports.

Here are lines people reported as "causes"

• parallel :22: turtle:22:
• parallel :22: swarminer:85:
• parallel:22:swarminer:251: (you can see there my trying ugly fix)
• bios:208:

So if someone could help me understand what is causing this error and how can i get rid of it i would be gratefull..

Also i need to ask if using parallel has some kind of effect of yielding that could be related to this (I am running 2/3 functions using it constantly.)

Here is pastebin for
Swarminer="2h1RmbAR",

also noted that program is started using Top Level Coroutine Overwrite that removes rednet coroutine and wipes out rednet API (this halves amount of event that turtles need to handle)
Swarmstart="aFgPSyGe",

Rest of files for refference:
Floppy Disk(startup)="LXLBZK25",
scanner="4wgEDymE",

Also to note here i am unable to replicate it myself - all i get is reports from 2 other players.
Its driving me crazy…

When a computer/turtle starts running code, ComputerCraft starts a ten second timer. If that code doesn't yield before that timer ends then ComputerCraft crashes that computer. After each yield, processing continues with a new time limit.

The reason why is that running your code chews up valuable server processing power, and so it shouldn't be able to monopolise it. In fact, best I can make out, only ONE CC device can run code at a time: In my tests, I found that putting one system into an infinite loop prevented me from accessing my other computers until the ten seconds passed and that computer crashed.

Whether or not it takes more then ten seconds for your code to execute has a lot to do with the power of the Minecraft server it's running on, and how often you allow your code to yield. Pulling events or sleeping triggers a yield, and may commands (eg turtle movements or getting text input from the user) have to pull events to work anyway.

Line 85 in swarminer likely crashes when the data you're trying to write as one line gets too large. Other disk-related activity running on the server may slow this down further.

Extended loops like this one at 693 are a waste of time (especially if the specified distance is large!) and likely the cause of the error at swarminer line 251:

while getFuelLevel() < 500+distance*2 and turtle.getItemCount(settings.slot.todrop)>0 do turtle.refuel(1) end

Instead, calculate the amount of fuel needed and chew it up in one go:

turtle.refuel( (500+distance*2-getFuelLevel()) / *HoweverMuchYourChosenFuelTypeProvides* )

(Not sure what this'll do if the amount of fuel to consume drops to negative (eg the turtle already has all the fuel it needs); it'll hopefully just return false but if it errors out you might need to implement a proper check for that).

Thank you for clearing all that information up. I known about how to yeld - I was unable to find information how "too Long Without Yielding" gets detected and called - This info clears a lot for me.

I realized that yielding is needed (cause of many sleep() calls) in my code and i tried to keep it yielding but it seems i failed.

I didn't know that server power could influence how fast this timer gets called. That would explain why i was unable to replicate this errors. Most of my testing servers where on stronger side of the fence.
Will need to work on my code to remove those bad loops then.Could add some yields without making system unusable.

As for your suggestions:

For line 85 i am saving 4 files at random intervals but none of them gets bigger over time - they all stay same size as rest.
Can't really do a thing about that cause all 4 files are needed for restart recovery.
Could get rid of saving position cause i am not using self position recovery system anyways. Tx for this idea.

For refueling recalculation i didn't think about doing it that way, will need to test that but thanks for idea.
Probably could get "howevermuchyourchosenfueltypeprovides" by refueling once and getting fuel level… anyways that should make it better.