12:30 PM
Bipolar Protocol
The Bipolar Protocol pushes Bill to try extreme opposites when stalling towards 100% rescued. Escalation Ladder. Try different things. Push the other protocols to try harder and harder per stall. The closer Bill gets to 100%, the more Bipolar Bill becomes. Experiment. Focus on what works. Hop around between any and all of the rounds, levels, worlds, phases, modes, Scan, Trim, Scrape, Crawl, flags, protocols, settings, tactics, -R reverse, and more. If something works, try it again. Especially after 85$ rescued because that is closer to 100% rescued. Escalate Bill sometimes through anything and everything. Try different combinations as Bill stalls more and more. Become more and more Bipolar as Bill stalls more and more. For example, Bill could try -a 100M and then -a 0 because those are two opposite settings. Bill can go back and forth between different various high and low settings. Bill might want to sometimes leave the Scan Mode and try Trim and other things to see if that might help. It is normally better to try to only Scan until 99% rescued. However, sometimes, it might be good to try to Trim every once in a while and especially after like 85% rescued or after stalling trying everything else. Bill needs to try harder and harder trying different things within Scan Mode and also sometimes within other modes too like Trim, Scrape, Crawl, Chaos, etc. After 85% rescued, if after ten consecutive stalls, if Bill can rescue more bytes at a faster speed via any mode outside of Scan, like maybe Trim, then Bill should try that for a pass or for as long as it seems Bill can do better in Post-Scan Modes. Make sure Bill can try more variety for his tool box of flag settings from 0 to even above 100% of what is possible regarding all the flags and combination of settings in Scan or any mode as Bill continues to stall consecutively as Bill gets closer towards 100% rescued or as Bill continues to remain under 2M speed. Bill should not escalate even at 99% rescued if Bill remains at above 2M speed. Escalate especially after 85% and especially if averaging below 2M speed in the last ten minutes or ten consecutive stalls.

02:12 PM
The Oatmeal Protocol was one of many protocols. I wrote many dozens protocols for years. Some protocols may or may not overlap with other protocols. Some protocols may or may not combine or be discontinued. I talked to Gemini about thousands of these Bill scripts for years. Gemini cannot remember all the thousands of conversations. Gemini has amnesia. That makes Gemini unable to help me. I do not know if Oatmeal can still work or not work or how Oatmeal might work best with Bill with all the many protocols.

05:20 PM
Before, I made levels named Sonic. But I discontinued the Sonic levels. Technically, Sonic levels can stay but protocols can override them if need be. There are 5 tiers in Bill: rounds, levels, worlds, phases, modes. Sonic was created to be the first three or more levels of world 0. Technically, all the levels could be named Sonic or none of them need the name. The idea was Sonic levels were supposed to focus on trying to rescue the bytes 100% in record times. For example, perhaps the first level could rescue 80% and level 2 the remaining 20%. But sometimes, it is not that easy to do that. I like my five tier system. But I also like protocols having the power to override tier defaults. I also renamed the MPH Protocol the Sonic Protocol. It might be confusing that I had both levels and a protocol both named Sonic. They're both similar and different at the same time. To be clear, the Sonic Protocol is the -a flag speed protocol that attempts to push Bill to max speeds like -a 100M for skim reading over scratches or -a 0 for slowing down. Sonic was designed to attempt to override any tier at any time for any reason according to what Bill needs at any time. It is critical that Sonic can use any -a flag from -a 0 to -a 100M in an attempt to regulate speed for any and all rounds of any and all tiers as needed. Sonic must be able to react between each round. It is critical that Sonic is aware of what works and does not work. Sometimes the -a flags might work a lot or not at all depending on many factors.

5m 5h 5G 500k 5M Jack Five Protocol
5m 5h 5G 500k Jack Protocol is the heartbeat of Bill. We will nickname this protocol as the Jack Five Protocol or Jack for short. Jack pushes Bill. Jack is the clock. Jack is the calendar. Jack is the heartbeat. Jack is the map. In Jack's name are five numbers representing two high numbers and three low numbers. The first set of numbers are 5m and 5h. Jack tries to copy each 5 GB disc in under 5 minutes (5m). But Jack knows it might extend to 5 hours (5h) and beyond to even 5000h. Jack pushes for 5 GB/s or at least 20 MB/s. But Jack also knows Bill may be lucky to get above 500 KB/s (500k). Rescuing 5 GB in 5 hours would be 277.78 KB/s. But let's just say 500 KB/s because faster is always better. Jack wants Bill to always go above 5 MB/s (5M). As long as Bill is rescuing at 5 MB/s or higher each second, that is perfect. The disc drive is rated at 16 MB/s max. The current disc has been in at around 85% for hours. So it is a question of what might be best for this particular disc. Scan can work for many discs. But eventually, it might be hard. I think for this current disc and any disc, it is critical that Bill tries several passes before getting stuck on Trim and anything that might be Post-Scan Modes. For example, the purposes of the protocols and the four phases was to try several tactics through entire passes using different methods from faster methods to gradually slower methods per pass.

Jack Protocol
To expand upon the 5m 5h 5G 500k 5M Jack Five Protocol which may be similar to other protocols I've written these past four months or so, like the Jordan Protocol, the Coach Phil Jackson Protocol, possibly the Oatmeal Protocol, a bit of the Goldilocks Protocol, and more. Another number that can be added the Jack Protocol can be 85 and especially as it relates to when a disc is at least 85% rescued. A key attribute to Jack must be escalation, especially if after 85% rescued. I've talked about the value of protocols overriding default tier rounds when need be. There are many tier overriding protocols like Sonic, Mario, Tetris (clusters -c), Timeout, Direct, and more. These protocols are searching for Goldilocks. But to expand upon all of this, it is critical that Jack becomes gradually more reactive as Jack gets closer to 100% rescued and especially after like 80% or 85% rescued. The Stall Protocol must become less patient and especially after 85% if below -a 5M in speed. After 85% rescued, Jack should push Bill to rotate through all combinations of tactics per stall. Jack must rotate through tiers and protocols searching for Goldilocks and especially after like 85% rescued or gradually more and more as Bill gets closer and closer to 100% rescued. After trying everything via several passes, Bill must give up on Scan and move on to Trim, Scrape, Chaos, Crawl. Jack pressures Bill to try everything within the Scan Mode at a faster pace after 85% rescued. Jack must become more Bipolar via the Bipolar Protocol to really try everything and especially after 95% rescued. Try -d and then turn off -d and back on and then off. Jack should turn things on and off. Jack should turn the volume up and down for all the flags and settings. Turn -R on and off. Turn -O on and off. Try all the flags and numbers and especially after 85% if speeds are under -a 5M.

Error
If a L-EC Medium Error ends a round, can Bill then run dmesg -w and/or commands and/or do things to see is it L-EC Medium Errors and/or what is, like what is happening, can Bill then use the info to respond accordingly?

Pass Protocol
I want you to talk about different ways to do it. We talked about protocols and tiers. But right now, we are focusing on passes. Within tiers is Phases and each phase might be like a pass. So, there might be differences and similarities between passes and phases. There might also be similarities and differences between protocols and passes. I talked about passes many times when making Bill for months. So many different protocols. And some protocols may relate to passes. But talk specifically about passes. There are many questions, desires, concerns. One question would be about how often to do full passes or how full and how often. I prefer the first ten passes be the fastest ever. But eventually at least, it might be better to do not just a fast pass but a pass that might include Trim and Scrape. Perhaps even return for another pass even after Trim and Scrape. The tier system and even the protocols were attempting to be pass focus already. I prefer a gradual system that started with the fastest pass that might rescue all the bytes in under 5 minutes if it is a perfect DVD or CD. First pass at 5 minutes at best. Pass 2 at ten minutes at best. 3 pass, 20 minutes. 4th pass at an hour. 5th pass at 2 hours. 6th pass, 3 hours. 7th pass, 4 hours. 8th pass, 5 hours. Like each pass can get a little slower and longer. That could be the general idea.

The Pass vs. Protocol vs. Tier Relationship
Protocols (The "Brain"): This is the high-level logic (like your "Oatmeal Protocol"). It decides when the hardware is too hot and triggers a cooling cycle or a reset.
Tiers (The "Gearbox"): These are the specific ddrescue flag combinations (Sonic, Run, Crawl). They dictate how the laser behaves at any given moment.
Passes (The "Map"): This is the physical progress. One pass equals one attempt to visit every "?" (untried) sector on the map

Pass Protocol
Give me block codes. First pass should attempt max speeds, jumping, settings, flags, options, like a Mario Speed-Run through all the levels. Bill must try to speed race from the start of the map to the end without slowing down. Bill must be adaptable enough to find ways to speed up with Sonic and jump farther with Mario when needed. Bill must use Tetris to gobble up as many -c 1 to 131K clusters like a Pac-Man as is possible. Bill must use a Goldilocks balance for Timeouts and any and all flags really. But after that first 5-minute (or longer) speed run (via at least one round or multiple rounds), each additional pass must be extremely reactive before and during each and every pass. In order to determine when to Trim say for example, Bill must check the map, Dmesg, and whatever else Bill can. There must be math formulas for determining when it is statistically better to Trim, Scrape, etc. Tho, some of it might be debatable. But the theory is if there only a small number of bytes left, and if Trim was faster at rescuing them then Scan was, then Trim would then therefore be the better choice in that hypothetical situation. Bill must try to get the easiest bytes in the first byte. Second pass, try to get little bit more. Perhaps the second pass could be identical to the first pass. If the first pass rescues 1 GB, then the second pass better rescue at least 500 MB or something. Otherwise, that second pass was a waste of time. Perhaps the first pass should be retired. But then again, I don't know if repeating the first pass a second time would do a lot. I don't know what the statistics say about that. But whatever Bill ends up doing, Bill can do if it works. If not, then Bill should move on and try something else. Give me block codes. All flags, speeds, numbers, settings, variables, options, must be dynamic, not just -O, -d, -R, etc. For the most part, Bill should be speed oriented in that Bill attempts the fastest first pass. Bill reacts as needed with dynamic flags. As long as Bill is running at -a 5M or higher, Bill probably shouldn't do much. But Bill needs to be ready to try things when things are not working. But Bill should at the same time understand he needs to complete the first full pass without making too many decisions and reactions, assuming Bill can complete a first pass in under 5 minutes or under an hour, I mean as fast as possible. With each pass, Bill should become more and more reactive. Eventually, if Bill already did like a thousand full passes, Bill should be really reactive per round at that point. But early on, Bill not need to always respond and react per round during like a first pass. But using math formulas, Bill can determine if he needs to change the flags and settings for the next flag assuming things are not working. Study the data. Make sure flags are totally dynamic so Bill can decide what to do and when to do it and especially as Bill gets closer and closer to 100% gradually, make sure complex math is always used to make nuance subtle choices step by step with an emphasis on riding winning waves during the first 85% if it is an easy perfect clean DVD or CD that is easy to copy and/or it may slow down and that is when Bill needs to get smart quick as things start to slow down below -a 5M. One of the flags is --cpass=1 which could be dynamic as needed to be --cpass=1,2 or --cpass=3 and whatever the options are, maybe delete --cpass=1 whenever Bill should not use it. Remember to use -R but only when needed. Use -r only when it might really work. Make sure Bill can really turn on and off and up and down all flags as needed based on whatever Bill needs the most at any given time.

Climb Protocol
The Climb Protocol pushes Bill up one Climb-Level at a time. By default, Bill must begin on a base Climb-Level which is probably going to be "-c 128 -a 1M -T 20s -r0 --cpass=1 --no-trim --no-scrape -K 250MiB" assuming the flags have the highest probability of rescuing the most bytes the fastest. Max speed according to the MPH Protocol was -a 100M but Bill should probably never do 100M or only if Bill climbs there. But by default, Bill should probably start at -a 1M. Maybe in level 5, Bill can try to climb to -a 2M. But by default, Bill must not start at -a 100M. Bill must not begin with the "GEAR_CLUST_MEGA=131072" (THE VOLUME GEARBOX, The Cluster Protocol, line 132) which is -c 131072 as it is likely Bill cannot currently go above -c 2K. So, -c 131K is a crazy number. But just like with the MPH Protocol, Bill could try to climb step by step to higher cluster sizes but only one setting at a time. But that should be in higher worlds. The first world should probably not do that. Make sure Bill can start in a default base level or continue where Bill was. But currently, Bill is stuck in a -c 131K -a 100M level which is too high. Normally, Bill should continue in whatever levels Bill might be in and complete passes across multiple sessions but the -c 131K level is too high. Also, must only climb if Bill doubles his speed for five consecutive minutes. For example, if Bill tries to climb from -a 1M to -a 2M in a world 2 climbing level, then -a 2M must produce double the speed that -a 1M did before Bill can try -a 3M. Bill can gradually climb step by step. But -a 2M will probably not be better, so Bill could just go back to -a 1M. Dangerous because scratches and slow spots might slow Bill down sometimes. Bill needs to have base settings that have the highest probability of rescuing all the bytes the fastest, that was the purpose of the three Sonic levels.

Direct?
The Direct Protocol should turn on -d --idirect every other round if speeds are under -a 1M for ten consecutive minutes. If -d produces faster speeds (at least double the speed at 2X for ten consecutive minutes), stay with -d. Direct Protocol should be independent for any level, world, phase, mode, etc. Generally if under 1M, Bill might to turn -d on and off per round but then stick with whichever is faster. If -d is faster, keep it.

12:36 PM
TIME: 2026-04-24 - Friday - 12:32:20 PM PDT
SESSION TIMER: 0 days 8 hrs 21 min
PHASE: SONIC 1: GHOST SKIM | WORLD: 0/4 | LEVEL: 1/9 | ROUND: 8
RESCUED: 4009199616 bytes (85.76%)
REMAINING: 635.03 MiB (665876480 bytes) | CLUSTER SIZE: 128
UNTRIED: 262144 bytes | NON-TRIM: 634.74 MiB
NON-SCRAP: 0.00 MiB | BAD-SEC: 0.04 MiB
STALLS: 3 | RATE: 1M
FLAGS: ddrescue -b 2048 -c 128 -a 1M --cpass=1 --no-trim --no-scrape -K 250MiB -T 20s -r0
CURRENT POSITION: Searching...

GNU ddrescue 1.27
About to copy 4675 MBytes from '/dev/sr0' [UNKNOWN] (4_565_504Ki) to '/home/a/dvd/dvd.iso' (4_564_228Ki)
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 sectors Initial skip size: 128000 sectors
Sector size: 2048 Bytes
Min read rate: 1000 kB/s
Timeout: 20s
Direct in: no Direct out: no Sparse: no Truncate: no
Trim: no Scrape: no Max retry passes: 0

Press Ctrl-C to interrupt
Initial status (read from mapfile)
current position: 4674 MB, current sector: 2282496
last block size: 262144 B
rescued: 4009 MB, tried: 665614 kB, bad-sector: 38912 B, bad areas: 19

Current status
ipos: 4674 MB, non-trimmed: 665837 kB, current rate: 0 B/s
opos: 4674 MB, non-scraped: 0 B, average rate: 0 B/s
non-tried: 0 B, bad-sector: 38912 B, error rate: 0 B/s
rescued: 4009 MB, bad areas: 19, run time: 14s
pct rescued: 85.75%, read errors: 1, remaining time: n/a
slow reads: 0, time since last successful read: n/a
Copying non-tried blocks... Pass 1 (forwards)
Finished

[PASS COMPLETE] Sonic Level 1 finished. Advancing...
[REFRESH] Clearing caches and resetting I/O...

12:59 PM
Timeout Protocol
The Timeout Protocol forces Bill to react per round. Gemini said the base timeout should be -T 18s as 18 seconds is a good starting point. I do not know if Gemini is right or wrong. But it is good to have a default starting point. If things are bad one round, the next round should probably be one second less. If things are good, perhaps increase the timeout by 1 second. Sometimes, Bill should reset to the base which you said should be -T 18s and that might be true. Also, you said that the -d --idirect related direct I/O flags to bypass kernels and stuff might then therefore allow the Timeout to extend. By default, increase Timeout if -d flags. Decrease if without -d. You might want to include a minimum and maximum for Timeout values, numbers. It is critical to check everything to see if the cops are freezing up the disc drive or other problems. Each round, The Timeout Protocol must react based on all the data from everywhere. Timeout should always go up or down per round based on any and all info collected from anywhere and everywhere. Look at maps, logs, Dmesg, etc. Collect the info and react. Timeout must have the best formulas for calculating what to do if things are good or bad. Generally, if good, extend Timeout. If bad, minimize Timeout.But if too long, that might be a problem sometimes for many reasons. If too short, that might be a problem for many reasons. Many variables to consider too like the -d flag and other flags and settings too.

Mario Protocol
The Mario Protocol must run all -K Jumping Flag decisions for Bill for any and all rounds, levels, worlds, phases, modes, etc. Most or all of the jumping should probably be done via the -K flag and not other flags or methods (like I usually do not like the -i flags for example). Mario must be independent of all rounds, etc. Mario must react between each round. By default, Mario should mostly only react per pass. In other words, being too reactive is problematic because Bill may run into scratches and slow spots randomly during a pass through all the remaining non-rescued bytes. Minimum jump must be 0 bytes meaning jumping should sometimes be disabled. Max jump could be 1 TB or a crazy number reserved for rare situations when Bill might be very stuck (but only as a last resort when all other options fail for dozens of rounds consecutively or something crazy where Bill tried everything else and everything else failed). Similar to the Timeout Protocol and other protocols, Mario must always search for the Goldilocks Settings. The default base jump should be big enough to jump over large scratches. Perhaps the faster the -a speeds, the larger the jumping possible. One challenge is as Bill gets too close to 100% rescued, it might be a problem if there are only a few bytes left to rescue, assuming it might be harder to jump over a smaller amount of the remaining bytes. There is also the "Initial skip size" which may or may not relate to the Mario Protocol. Mario must know when to jump and when not to jump. Mario must jump not too far or too little. Mario must make sure Bill can always complete full passes. Mario must make sure Bill does not get stuck on scratches, bad areas, bad sectors, slow reads, during the first like 80% rescued say for example. Mario must react between each round to all of the flags, conditions, results, consequences. Mario must be aware of the Dmesg, the map, the logs, the data, to best know what to do and when to do it. Mario should only do a 100 GiB Hail Mary as a last resort after stalling for like 20 consecutive rounds or something crazy but only after gradually escalating step by step to finally escalate to that. Also, Mario should generally decrease per pass but increase per fall. A pass is to read (run, probe) through all remaining non-rescued bytes. A fall can be scratches, slow reads, bad sectors, bad areas. The default should be that Mario jumps big enough to make sure Bill can go as fast as possible for the first pass. The jump needs to be big enough. After a pass, remaining bytes can be re-marked as untried and Mario could then jump a little smaller while Bill tries different things during a second pass. But sometimes, Mario wants increase jump size each round if need be. But generally, Mario wants to decrease jump size as Bill tries to rescue more bytes per full pass through all remaining bytes. Mario must make sure Bill can run around the entire disc trying to read all the bytes as fast as possible. My version accepts two jump sizes formatted like this: -K 10Gi,100Gi.

Tetris Protocol
The Tetris Protocol is the Cluster Protocol. Tetris must determine the cluster sizes for Bill each round. Tetris must be independent. Tetris must work for any and all rounds, levels, worlds, phases, modes, etc. The minimum cluster size is -c 1. In the past, I've said the max could be like -c 131K. However, that will probably rarely work. It might never work in most cases. You should keep 131K. But the default base for clusters should probably be the max that can work for my disc drive. Gemini has given me many different numbers for base and max for clusters like 2K, 4K, 8K, 16K. We can keep them for crazy situations but it seems anything above 2K may not work all the time or that is still open to debate. Tetris should react between each round. If Bill is accelerating, Tetris could increase cluster size. If not, Tetris might want to decrease. But Tetris should generally not react too much for the first 80% rescued or Tetris should only react if speeds drop below -a 2M for ten consecutive rounds. Sometimes, Gemini suggests that the max should be -c 64. Other times, Gemini suggests like 128 or 256 or sometimes higher. For the first five passes or first two hours, clusters should generally be starting at max. When I say max, I mean normal max like -c 64 to as high as 2K or 16K. Probably between 64 to like 512. But it is hard to say. If higher cluster sizes can maintain anything above -a 2M for consecutive minutes without stopping, then Tetris should generally hold. Tetris should be smart enough to know what to do and when to do it. Please do not automatically downgrade to -c 1 too quickly. Tetris should probably stay at -c 512, 256, 128, or 64, or whatever the larger sizes might be, for like the first five full passes and then gradually go down one size per full pass. I don't know if there are complex formulas that can determine the Goldilocks Settings for cluster sizes and other flags too. Too big and too small can be problems sometimes. Reacting too quickly or too slowly can be problematic too.

Mario Protocol
Mario must be aware. The closer to 100% Mario gets, the more reactive Mario can be when speeds are dropping below -a 2M. The closer to 100%, the faster Bill should react in general via all protocols. That includes even the Timeout Protocol, the Direct Protocol, the Tetris Protocol, and more. Each protocol need to evolve as Bill gets closer and closer to 100%. Each protocol must be independent to search for Goldilocks per round. Must get more and more aggressive as soon as speeds continue to drop for ten consecutive rounds after 80% rescued.

Sonic Protocol
The Sonic Protocol is the MPH Protocol. Sonic must be independent. Sonic must run Bill's -a speed flags. Sonic must start at a base speed that has the highest probability of rescuing discs from 0% to 100% rescued in under 5 minutes. All protocols and systems in Bill must be designed for max speed. But each CD and DVD might be different which is why finding Goldilocks Settings is hard. Sonic should become more reactive as Sonic gets closer and closer to 100% rescued. Between each round, Sonic must react. Each protocol should react. We've talked about crazy speeds like -a 100M which can still be in Bill as a crazy Hail Mary backup plan if Bill continues to stall for ten rounds in a row. My disc drive is rated at 16 MB/s. We've talked about many different speeds up to 30M or beyond. Anything above 10M is good. 20M is perfect. Anything above 2M is acceptable. I don't know how 0% rescued discs might react to different speeds which makes it hard to determine what to do. In general, I would want a super fast first pass using crazy fast settings to create a skim reading affect to better map out bad areas. But Sonic must be more and more aware as Sonic gets closer and closer to 100%. Sonic must work on all the rounds, levels, etc. Sonic must go faster or slower depending on variables.

Goldilocks Protocol
The main goal of the Goldilocks Protocols is Speed-Run. They have Nintendo Mario Speed-Run competitions online where people compete finding the fastest ways to beat the Mario video games. Bill is playing his own Speed-Run competition rap battle of history. Bill must try to beat the game in under five minutes via all the protocols and systems. That first round must be the last round, whether the disc is 0% or 99% rescued already. That first round must have the highest probability to rescue all the bytes. Bill must coordinate with Mario, Sonic, Tetris, Timeout, Jordan, Goldilocks, Housekeeping, and more. It is critical that Bill remains universal to work with any DVD or CD, both new and old discs alike. If Bill doesn't rescue all the bytes in the first round, then protocols must react in an attempt to rescue all the bytes in the second round or the third round or so on and so forth. But Bill should generally be less reactive as long as speeds are above an average of -a 2M. Each round can extend for hours. But please minimize on excessive stalling when possible. The closer to 100%, the more reactive Bill should be. Try to avoid Post-Scan Modes for as long as possible if possible when possible until maybe 99% if need be. But at the same time, it is all about whatever routes might be the fastest towards 100% rescued. Bill must play poker and chess in beating this game for each unique disc. But it is also a game of probability where you start with the settings that have the highest probability of doing the most damage (rescuing the most bytes).

Default v Reactive Protocol
Bill must first run default routes which might include fixed settings, rounds, levels, worlds, phases, modes, flags, speeds, clusters, timeouts, numbers, jumps, variables, options, etc. Eventually, Bill must become more and more reactive as time goes by. Each round perhaps or after like ten stalls or as Bill gets above 80% to 100% rescued. Bill must be engaging the Goldilocks Protocol but Bill must not react too quickly too early in the game. That is why Bill must have the best opening gambit in this speed-run chess poker game. Bill must have strong opening rounds that might rescue all the bytes in minutes or rounds. If not, then Bill can gradually become more and more reactive over time, per time, and as Bill moves closer to 100% rescued. As long as Bill is above -a 2M, Bill should be less reactive. Bill must wait long enough before stepping in too early. Reacting too early can be counterproductive.

Tiers: Rounds, Levels, Worlds, Phases, Modes.
Protocols must be Tier-Independent: each Protocol must run independent of the tiers: protocols include the following five main protocols: Mario -K, Sonic -a, Tetris -c, Timeout -T, Direct -d --idirect. Make sure at lease these five protocols are totally independent of tiers. In some ways, the protocols make the tiers more like empty boxes. Perhaps the tiers can guide and influence to protocols a little. But the protocols must be AI-Smart to have top opening gambit moves at first and then gradually transition towards chess moves per round. I want all the protocols to be as reactive as the Direct Protocol is. Protocols should generally reset to default values sometimes or as needed. But some or all of the Direct -d--idirect logic can be applied to protocols like Mario, Sonic, Tetris, Timeout, Goldilocks, Bill Jordan, and more. Maybe not totally the same as the -d protocol but I guess it depends. Default settings for flags should be designed for Speed-Runs where it might rescue all the bytes at the fastest speeds. But gradually like with the -d protocol, other protocols should sometimes toggle up and down looking for Goldilocks when speeds are under -a 2M. Tetris Default must be the highest most dependable proven cluster size which currently is -c 512. Perhaps it can do up to 16K. I even suggested 131K. Like with other protocols, try a higher tier setting but then revert to lower settings if the volume increase doesn't increase. All protocols should do this. Reset sometimes to the highest proven settings. When needed, toggle the flag settings up and down as needed looking for Goldilocks. Tetris is a tough one for example, watch out for ghost bytes stuck inside RAM, cache, kernels, cookies, CPU, GPU, hard drives, USB, buses, or wherever. If 8K or higher really can work on a perfect DVD to rescue potentially 4.7 GB of all the bytes in like 5 minutes record speeds, then 8K or higher could be the opening gambit move for Tetris for as long as it is above -a 2M on average during the last like ten minutes or something. In general, 2M should be the general rule for any and all of the protocols for the last like ten minutes. Protocols can have extended tool boxes with low to high settings. For example, Tetris can up to -c 131K. Sonic can have up to -a 100K. Mario up to -K 100 GiB. But Bill should only attempt to climb to these theoretical highs in rare situations but one step at a time. But it has to be proven that an extremely high setting is really rescuing bytes before trying even higher settings. But it could be ghosts or something. Must be incremental. Once it fails, start going back down again. Goldilocks could be -a 0 or -a 100M, you never know where Goldilocks is hiding but please gradual incremental one step at a time focusing mostly on what is the most effective, efficient, potent, productive.

2M Protocol
Bill must gradually become more aggressive trying different flag settings. The closer to 100% rescued Bill gets, the more impatient. Timeouts probably should be longer than 20 seconds sometimes. Protocols should become more aggressive each round as Bill gets closer to 100% rescued. The 2M Protocol demands Bill rides winning waves. When Bill is rescuing above -a 2M, Bill should lock it in. Bill must milk it. Bill must ride the wave. But Bill must work harder each stall. Each time Bill is below 2M, Bill must push all the protocols to try different things. If something is working, focus on that for as long and as often and as much as possible. When you stall, experiment. But you might be over a scratch or bad spot.

Twitter Tweets
11:42 AM

The Southern Poverty Law Center are bad people, Trump war in Iran is bad but Trump is right about this.

12:04 PM
Schools teach kids Unalive Prevention but's actually just teaching them how to do it which results in kids unaliving themselves.

12:34 PM
My phone number is 360-490-0542.