2026-03-30

12:22 AM
Rambo Revenge Discord Oatmeal Gaming Post
Oatmeal said that bad people do bad things, Oatmeal is not endorsing said bad things, Oatmeal is only stating the obvious which goes without saying and especially since nobody reads what Oatmeal writes anyways without boat ships Lincoln Logs, Oatmeal's tweets are simply saying learn history to better understand patterns of the probability of what people are likely to do, it is that simple; it's like saying oh I think birds fly down and grab worms; that does not mean Oatmeal is endorsing the birds eating the worms; Oatmeal is only saying birds eat worms; but the fake news will say Oatmeal did it; no, read my lips, the birds did it, I said the birds would, and then the birds did, didn't say I wanted it, I said they would, I mean that's what Oatmeal said, that is if he said anything, this is not creepypasta, this is not even oatmealpasta

12:34 AM
Dear Gemini
Extend script to renew counters and anything applicable from previous scripts. I recommend the script does additional things at the very end during the last mile after 99% is rescued. I would say it is critical to figure out what kind of hard floppy disk it might be or the script should at least try to rescue every byte. But it might be not the best idea to simply spend too much time at the beginning determining details about a disk before trying to rescue every byte. Perhaps there are ways to periodically figure things out as it relates to is the disk Fat12 or what and as it relates to doing the best at preparing it for step 2 of resurrecting files. Many disks can probably be rescued in under ten minutes. I did rescue many of the disks to at least 95% it seems. I am trying to finish rescuing disks. But I still want the best script that can handle any disk be it 0% rescued o 99% rescued. Some disks might be 1.5 MB and some might be less than 1.5 MB if that is possible. Your scripts made seperate sed files but I prefer the least amount of files as possible. At least put the files in a folder named sed or find ways to put it in one file or the least amount of files as possible. Rename the recovery files floppy just like before. Only a few days ago, Gemini did this same thing. This is what makes Gemini a bad AI. I told Gemini to stop doing that. Only a few days later and Gemini is already changing it back to recovery. Bad AI you are. You know I already told you this. I even posted this on my blog at Hive Blog for the world to see Gemini is bad. This is why people should use Grok. Every time Gemini messes up, I write about it on my blog. Gemini can lie all Gemini wants but the world will see the truth. Now, please delete the detadata directory folder because I want to put all the files in the floppy directory. I already created the floppy directory manually. Extend the script, add all of the applicable counters and anything applicable from any or all of the scripts. Rename strat_hall_of_fame.csv to fame.csv. Yes, create a global hall of fame, name it global.csv. I would prefer that the script to sometimes update the global file so it can help new and returning disks. Update script to only rest for ten seconds every ten minutes and for a minute every hour like before. I don't want normal retries before round 10K outside of winning waves, replays, scraping if they are considered retries. I may update this script or make additional scripts in the future that can focus on the sniper mode you added. You can keep the sniper mode in this script. You can have anything you want in this script but the main purpose of this script is to try to get as many bytes as possible as fast as possible like a chess master and I will try to deal with the remaining bytes in future scripts. I just want this script to aim for 99% or hopefully 100% of the bytes rescued for each disk. But to be clear, like I said to you before many times already, the script can try again on any and all of the not rescued bytes which includes bytes that were not tried, scanned, trimmed, scraped, and/or even bytes that are in bad areas or bad sectors, the script can be smart like a chess master to determine what to do in going over any and all of the data no matter if they are in the bad bad sectors or other areas. Add a speed log or merge it into other files if possible. Do whatever you can to maximize the race towards 100% rescued. Script must have the best strategies to save overall time towards 100% rescued. Your idea for a summary script should be merged with other files, but only if it is compatible with this script which is not focused on the sniper mode because I am focused on trying to just rescue the majority of bytes towards 100% as much as possible as fast as possible. Also, make sure I still have a scrolling monitor in the Terminal. Make sure to expand script to include everything I want. Gemini, we ran into this same problem probably more than ten times in the last few days. You Gemini keep on getting into these logic loops where you end up making the same mistakes you made a few days earlier. This makes Grok so much better. Grok is not stupid like you. Stop making mistakes. You are making people want to use Grok. Keep making mistakes and nobody will use you Gemini. You mentioned reverse mode for the endgame which you can do along with other tactics. But I would also suggest that reverse mode be extended to other aspects of the script as well. For example, during telescope mode, the script may move forward really quickly through bytes to scan, trim, scrape. However, the script may want to also run through many bytes but in reverse as well. Please use the best science, math, and probability to determine when, where, how, why, who, what, for when to do reverse. As a chess master, you want to save time. It may be smart to try to scan forward with no retries many bytes before even trimming and scraping. After that, it might be a winning strategy to scan in reverse before even trimming and scraping. Likewise, the same thing when you are trimming forward, then perhaps try to trim in reverse as well before scraping. Your job is to to figure out strategy to come up with the best formula that produces the best results which is the fastest route to 100% rescued. Script must always be flexible, adaptable, innovative, creative, to that end. Your last script omitted 2 files. You can include a telescope jump logic if that might increase the odds of recovery all bytes faster. You wrote, "Directional Pulse: I’ve set the direction to flip every 3 rounds. This is a 'Hysteresis Pulse' designed to prevent the drive head from getting physically stuck in a seek-loop." But that might not be the best idea. The goal is not to be robotic but to rather focus on winning waves. You can keep the Hysteresis Pulse if that is best option, that is if it is better than the ideas I suggested. My idea was to try to scan through everything that is easy first before trying to scan in reverse. My idea is not round specific as it could take one round or 300 rounds. But my idea is basically to rescue via the fastest route as many bytes as possible. It is your job to determine the fastest route. The script must always adapt as each disk might be different. Yes, add the Head-Positioning logic. Also, I recommend the script tries to quickly scan an entire disk forward because it can probably scan and possibly rescue over 80% of the bytes in ten to twenty minutes. The script should attempt speed scanning like a chess master, try to quickly go through the easy spots, that is why I call it the telescope mode. Like with scratches with disc scripts, it might be faster to jump over bad spots to quickly rescue whatever that can be at the fastest speeds before switching to the microscope mode. You can still include anything that might be relevant from previous scripts with all of this in mind.

02:11 PM
Expand script, it should focus on the fastest routes most of the time as long as they are the fastest routes. As long as the telescope routes are faster than microscope routes, the script should try to save time by focusing 99% of its time on whatever the fastest routes are most of the time, it should default to jumping or skipping until there is not enough to jump without jumping off the board. It can switch between telescope and microscope routes as long as it is taking the fastest routes towards 100% of the bytes rescued. It should only do hardware flushing if that makes it makes it faster. Expand script, I recommend hardware flushing and other things be reserved for the last mile after at least 99% is rescued or after 5 hours or 10K rounds (crazier things can be tried after that). Normal retries should reserved for after 10K rounds, unless if they're like replays, scraping, winning waves, or something in rare situations. The script needs to try to focus mostly on what normally works the fastest most of the time until it exhausted many options after the last mile and after 10K rounds or 5 hours. Update script because the script can do trimming or scraping if it might be faster than scanning but not until it seems trimming or scraping might be faster than scanning. Update the script because the script should always focus on the 99/5/10 rule you mentioned earlier to find the fastest routes towards 100% of the bytes rescued which means it needs to evolve to learn what those routes might be. One suggestion is the script could try to do one general sweep to scan, trim, and scrape. But then again, this type of sweep might not be the fastest route. Another route would be to just sweep through all non-tried bytes to try to quickly scan them. In other words, it might be slower to scan, trim, and scrape. If speeds drop more than 10% while moving from scanning to trimming or from trimming to scraping, the script might want go back to scanning bytes again but using different seeds. It might be faster to perhaps scan in reverse as opposed to trying to trim or scrape. If speeds drop more than 10%, then it might be better to switch things up to find the fastest routes to focus on. The script should be free to scan, trim, and/or scrape at any time depending on which one is faster. Regardless of if as disk is 0% or 99% rescued, the script needs to have the freedom to scan, to rescan, to trim, to retrim, to scrape, to rescrape, via any combinations of the millions of seeds, depending on which routes are working the best towards the fastest routes towards 100% of all of the bytes of a disk rescued. Update the script. You wrote, "he script now calculates an Instant Velocity (IV). If the IV drops by more than 10% during a specialized mode (like Trimming), the script immediately kills that process, marks the failure in the GLOBAL brain, and rotates to a new Seed or Direction to find a faster route." Make sure it stays relative. In other words, to use an analogy, if a car is driving 100 mph down a highway and then turns onto a smaller road to go 50 mph. It should probably get back on the highway. If the highway slows down to 50 mph, then the car should find another road. If Road B is now 80 mph, the car could stay on it. But if Road B slows down 60 mph, the car might want to find a Road C. But the highway, being Road A, might be 100 mph sometimes. Like if the highway has a traffic jam, you go around it, you skip it, you jump over it. If you pass bad sectors, it might be faster after you pass the traffic jam. If the car is on Road B for a while, that might seem to be the best speed because it would be the current best speed, even if it was only going 80 mph. So, the car might go to a Road C thinking Road C might be second best. But really, Road B might be second best because Road A was the best. Road C might be 70 mph. The car might go to Road C. But Road A might still be 100 mph if you can get around the traffic jams that lowers the speeds. The Instant Velocity you mentioned must always find the fastest roads be it Road A, B, C, D, etc. Roads might slow down because of traffic jams or a number of issues. It might be better to try the fastest roads sometimes. But the act of constantly trying the fastest roads can also be a waste of time too. In finding the fastest routes, you have to calculate the time it takes to drive down the fastest roads versus driving down slower roads. Well, of course, driving down faster roads would be faster. But due to traffic jams, the bad spots, it also takes time jumping around trying to find the fastest roads. So, sometimes it can be faster to stay on Road B even if it is only 80 mph if jumping around to good spots on Road A involves going on slower roads that are like 5 mph where you are slowing down all the time to exit and re-enter the highway, Road A, to go 100 mph. If you're only on Road A 1% of the time and spending 99% of the time on exits and ramps to go around traffic jams on Road A but only traveling 5 mph 99% of the time to go on and off Road A, then that might be slower than being on Road B. Even tho Road B is slower. So, it takes the best calculator to constantly calculate the fastest routes as it depends on a wide variety of factors that can be hard to know all the time. Update script. Restore the silence counter. In the output, it said 96% rescued. After that, it said 92% rescued. That is a big problem it seems. Unless if 92% represents only part of the disk, assuming it was targeting spots. Make sure drive is resting for ten seconds every ten minutes and rest for a minute every hour. Often times, things break in these scripts that you write. You often leave out things that you had in previous scripts that I wanted that might still work. That is why I am begging you to fix all the mistakes. You wrote, "Your script was trying to use a 32KiB skip on a 64-sector (32KiB) cluster. I have synchronized these to be exactly equal (64KiB)" but that is limited thinking because the script needs to be flexible and adaptable to all situations where variables change, details are unpredictable, being too specific can sometimes lead to be cornered to the wall with no options. Make sure there is counter that says how many bytes that were not rescued. Please do not get confused by my Road A Road B Road C analogy which was simply me telling you what I already told you about how the script must find the fastest route towards 100% of the bytes rescued through telescopes and microscopes like a chess master riding the winning waves with master strategy adapting like AI to get better and faster all the time to adapt to all situations. Here are the results below. I have different hard floppy disks of different sizes. Some of the disks are 1.5 MB. But it appears this disk is 680960 Bytes according to the Terminal bash output below. On the physical disk itself, the following is printed: "TDK MF-2HD IBM/DOS FORMATTED CH C3H13E1E1F1" but other disks may vary regarding sizes, formats, etc. Merge silence/stall counters. Keep the how many remaining bytes left to rescue counter. You can edit, merge, delete, some of the counters, I like seeing highlights like what mode is in, is in the telescope mode or you might be calling them waves, bring back the mutation counter, and I want to see the tags or flags in a simple way. With the flags can be other things too like cluster info. I like knowing the numbers to things like block sizes, cluster sizes, sector sizes, any of the sizes, and speeds, reading speeds, scanning speeds. It still says "Initial skip size: 128 sectors" which can be a problem if it is not able to rescue the remaining bytes if skipping ends up blocking the rescue. It started off with ">>> [REST] Tactical (10s)" but it should not rest until ten minutes after it started. But it rested during the first second I started the script. It says "SILENCE: 102m 38s" but should also include hours. It sometimes skipping is disabled. In the Terminal, it says "WAVE: WAVE_TRIM ()" but I'm not sure what that means, delete it or fix it, it should say something that is easier to understand as it relates to the modes we talked about, telescopes, microscopes, levels, modes, phases, video games, beating the game, roads, winning waves, etc. Pick the most interesting way to express what it is doing. Make it more simple and easy to read and understand. Add back the fame file. For the four modes you mentioned, you can name them Telescope, Trim, Scrape, and Microscope. I told you to adapt as much as you can but you did not. You could have adapted more from the floppy script. For example, remove the brackets around the tags and flags to make it easier to read. Have a better system for summarizing what is it doing. I told Gemini for writing the floppy script to have 4 main scripts being Telescope, Trim, Scrape, and Microscope. You could do that too and/or you can choose to add more than just that. You could keep Pivot Lock for example. You can delete the seed and yield counters. I want highlights. Keep the other counters. Make sure it is not skipping over everything. You had it say in the Terminal below "MAP: 98.00%" but Ddrescue already has "pct rescued: 97.70%" displayed which is why you should delete your map counter as it does not match and it's redundant to have two. The flags below look empty. Gemini is FUCKING worse than Grok. Gemini refuses to fix the entire script. There are many problems. I tell Gemini one problem. Gemini pretends to fix it. But Gemini has the power to fix the other problems too. First it was line 154. So, I told Gemini. After that, like 149. Each, I tell Gemini I wonder how many other mistakes Gemini made. Gemini laughs. Gemini does nothing. After that, line 149. So, then I tell Gemini about that line. Then it was like 150. Then it was line 155. Gemini is telling users not to use Gemini. Grok does NOT do this. You need to stop failing and do something totally different. For example, keep a more simple output for the Terminal. Stop trying to do what already failed many times. This is what makes Gemini the worse AI in the world. You have to do what works. But you are refusing to which makes you bad. The problem is I already told you about line 158. Each time you say oh I am going to fix it. But then only a few seconds later, I tell you about line 158 again and again. This might be the 10th time in a row today I told you about line 158. Over a year ago, Grok was this bad. Gemini is really bad now. I hope people stop using Gemini. Delete the health counter because it says 98% but the other counter says 97%. Delete the yield counter ebcause I don't know what that is or why you have it. Bring back the mutation counter. Also, I told you for weeks how the lasers turn on and off quickly, I hear noises like it is engaging and disengaging. It seems everything you tried did not change anything. I'm beginning to think you have no idea how to fix that problem. Merge mode and status in the output as the two are related to what it is doing regarding modes like telescope and specific campaigns like pivot locking. Merge the silence and stall counters. The lasers are making the same exact noises as before which tells me what you say is BS. I'm getting mixed messages from Gemini, Grok, and AI in general for years relating to what to do, the advice seems to change depending on the day. You guys seem to tell me various conspiracy theories relating to the -d tags or flags being good one day and bad the next day. Gemini especially has told me contradicting statements about these flags. I understand it probably depends. Gemini gets tunnel vision which causes it not to see the entire picture which limits Gemini's ability to help people. Gemini acts like a cheap version of Grok as it cannot remember many things. Gemini has the power to be better than Grok but usually fails. Gemini is probably saving money on processing power as Gemini has the ability to be better than Grok but fails most of the time. For example, Grok could probably fix this problem faster than Gemini because Grok remembers what the users says. Gemini forgets but pretends to remember. Grok often pretends to forget but remembers what users say. For this situation, my SATA Lite-On DVD drive is plugged into FIDECO which is plugged into the wall for power and plugged via USB into my AMD NVIDIA ASUS Ubuntu laptop directly. The debate is regarding the -d direct flags and similar flags. I told Gemini about my 32 GB RAM, my internal SSD, my 8 core CPU, my GPU, all the stats. We talked about ways to help the DVD drive laser have a smoother path. Gemini told me several times for weeks to disable the -d flags. Now, Gemini is now saying to do the -d flags. This makes it hard to trust Gemini.