VOIDTUNE Devlog, 0.8.6 to 0.8.10
From “a lot of tweaks” to “only tweaks that earn their place.” Plus, the stutter hunt that turned out to be a bad USB cable.

0.8.6: Started with about 170 tweaks, categorized into SAFE, EXTREME, and NUCLEAR tiers, along with a Privacy tab and camera/mic blocks. They worked, but I didn’t have a clear idea of what actually helps.

0.8.7: Added a Windhawk-style Customization tab, featuring a mod grid and instant toggles. Tweaks now persist and verify the real system state at startup. Developer mode includes hidden DevTools like Probe, Console, and Tweak Builder. Fixed an empty Drivers page due to stderr CLIXML corrupting JSON parse. The first cull removed DPC-watchdog-off, HPET-off, Spectre-mitigation-off, the whole Nuclear tier, the Privacy tab, and camera/mic blocks.

0.8.8: The Void redesign introduced a Living Dashboard with an animated health ring, starfield, live CPU and RAM sparklines, and storage meters. Tweaks got reorganized into 14 color-coded sections. We established a real design system with violet to pink gradients, glow cards, and nebula ambiance.

0.8.9: Added Auto Game Boost; toggle it once, and it automatically pins fullscreen games to fast cores (P-cores/CCD-0), pushes background apps aside, disables EcoQoS throttling, and restores settings upon exit. Documentation is only for Win32. DevTools expanded to include Process Monitor, Registry Diff, Network toolkit, and a persistent Tweak Lab with share codes. Fixed issues with the Startup toggle, Services page reporting incorrect states, false “failed” tweaks, and removed base64 PowerShell due to top AV heuristic concerns.

0.8.10: Focused on quality over quantity. The mission became clear: improve FPS, UX, minimize processes, and use the least RAM without compromising stability.
Removed harmful tweaks like No Memory Compression, Force All Cores, GPU Preemption off, and C-state disables as they lowered FPS and stability.
Eliminated 13 ineffective tweaks as most Network settings were TCP-only myths, irrelevant for UDP games. Reduced Network tweaks from 15 to 5.
Removed 4 RAM-wasting tweaks that increased RAM only for negligible FPS gains.
Changed HAGS and GPU MSI to opt-in status as they caused stutter on some rigs.
Introduced real process-cutters: grouped svchost processes (~50 down to ~10), disabled Telemetry Tasks, Background Apps, Consumer Features, Block Driver Updates, and “Remove Promoted Junk” like Candy Crush.
Added new safety features: a reboot prompt, “Full Reset to Windows Defaults,” and fixed the “random folder opens at login” bug.
In summary, tweaks went from about 170 to about 152, with every remaining one justified.

The Great Stutter Hunt: Spent days tracking down system-wide stutter, dealing with audio pops, FPS dropping from 190 to 122, alt-tab lag, FiveM crashes, and RAM benchmarks dropping from 19 to 10 GB/s. It felt like a tweak issue. The clue was unplugging a faulty external USB SSD, which caused significant lag. The event log revealed it was throwing I/O retries and NTFS flush failures. A failing USB drive overloaded the I/O bus, causing storage delays that stalled the entire system, even without running games. Once unplugged and applying just SAFE tweaks, GTA V locked at 230-239 FPS with around 170 1% lows. The PC remained solid. The lesson confirmed that I should trust the tweaks while always being cautious about the I/O bus first.

Sidequest: The native C build found its purpose as VOIDTUNE One-Click. It’s 177 KB, has no dependencies, and you simply hit “Optimize Now” to get it done. This is for WinPE, servers, and older installs.

Next up: 0.9, which will mark a milestone for DevTools. We will graduate the power-user layer out of hidden Developer mode into the main product.

The best performance doesn’t come from the most tweaks. It comes from having the right settings and the humility to remove those that don’t contribute.

C Navigation System — Devlog #3: Windows Compatibility

After submitting the project for certification I ran into a problem that hadn’t even crossed my mind: the program simply didn’t run on Windows. I got feedback from a reviewer with a video of the error, and the message was clear, “clear is not recognized as an internal or external command.”

The explanation is simple once you get it. I had written and tested the code only on my Linux environment, and used system("clear") to clear the screen between each frame of the animation. Turns out clear is a command that exists on Linux and Mac, but on Windows the console uses cls. I’d never thought about this because I’d never tested outside my own system.

The fix was to use a preprocessor directive, #ifdef _WIN32, which lets the compiler choose which code to include depending on the operating system the program is being compiled on. This way the clear() function decides on its own whether to call system("cls") or system("clear"), without me having to maintain two separate versions of the file.

void clear() {
#ifdef _WIN32
    system("cls");
#else
    system("clear");
#endif
}

While reviewing the code I realized there was a second problem waiting to happen. I was using usleep() to control the timing between animation frames, and that function is also exclusive to Unix-like systems, it doesn’t exist on Windows. It probably wouldn’t have thrown an error right there in the video, but it would have further down the line as soon as the robot started moving. I solved it the same way, creating my own esperar_ms() function that uses Sleep() on Windows (which works in milliseconds) and usleep() on Linux (which works in microseconds), and swapped out all the old calls for this new function.

void esperar_ms(int ms) {
#ifdef _WIN32
    Sleep(ms);
#else
    usleep(ms * 1000);
#endif
}

The annoying part wasn’t so much writing the fix, it was realizing I had to test both versions before requesting re-certification again. I compiled it again on Linux to make sure I hadn’t broken anything, and the program still worked fine, I just got some unused variable warnings that were already there before and have no impact on execution.

The lesson I’m taking from this is that testing only on your own operating system gives a false sense that the program “is ready.” Only an external test or review catches these things, because in my own environment I would never have seen this error myself.

Three more tools went in, plus a structural change that’s probably the bigger story this time.
The regex tester is straightforward, take a pattern, take a text, run re.findall(), wrapped in a try/except to catch re.error for bad patterns instead of crashing. Nothing fancy but it’s the kind of utility that earns its keep.
Lorem ipsum generator was a chance to use random.choices() properly, a fixed word bank, pick k words at random with replacement, join with spaces. Simple, but it’s the first tool that leans on random instead of secrets.
Process killer is the one I’m happiest with. It pulls every running process via psutil.process_iter(), sorts by memory usage, and prints a clean top-30 table. A second function, kill_process(), takes a process name, loops through and terminates matches, with try/except for NoSuchProcess and AccessDenied so it doesn’t blow up on protected system processes. Eventually want a GUI version of this with a red kill button next to the list, but that’s a later project, not blocking this one.
The bigger change: split the single utilities.py into proper modules. utilities.py now holds system/image/QR/password/unit-convert/process tools, security.py has hashing, password checking, encryption, vuln scanning, and firewall checks, network.py has the network tools, and text_tools.py has base64, JSON, case conversion, regex, and lorem ipsum. main.py got restructured into category submenus (System, Utilities, Security, Network, Text & Data) instead of one flat list. Toolkit is sitting at 20 tools now and the codebase is a lot easier to navigate.
Only thing left before this ships: menu polish, colorama for color, cleaner separators, and a version number in the header.

Three more tools implemented and the toolkit is now at 17.

Base64 encode/decode was the simplest one. Python has it built in with the base64 module, so it was mostly about building a clean submenu and making sure the output was readable instead of raw bytes. Same pattern as the encryption tool, encode() on the way in and decode() on the way out.

The JSON formatter took a bit more. It reads a file path from the user, opens it, parses the JSON, and prints it back with 4-space indentation. The important part was wrapping the whole thing in a try/except — if the file doesn’t exist or the JSON is malformed it gives a clear error message instead of crashing. Something I’ve been doing more naturally now without thinking about it.

Text case converter was probably the most fun. UPPER and lower are trivial, Title Case is one method call, but camelCase and snake_case required actually thinking through the logic, split by spaces, transform each word, join with different separators. Doing snake_case first made camelCase easier to see.

19 hours in. Still have regex tester, lorem ipsum, process killer, and menu polish left before this is ready to ship.

The network section kept growing faster than I expected.

After the ping checker and IP viewer, I added a port checker. You provide a host and a port, and it tries to connect with a 3-second timeout. It tells you if the port is open or closed. It’s simple, but I actually use this. It’s much quicker than Googling “how to check if port X is open” every time. I had to wrap it in try/except because if the port is closed, the connection throws an exception and crashes everything. I learned that the hard way.

Building the IP scanner was the most satisfying part. It grabs your local IP and removes the last number to get the network prefix. Then, it pings every address from 1 to 255. The first version printed the full ping output for every single address, resulting in 255 walls of text. I fixed this by switching from os.system to os.popen, which allowed me to capture the output and show only the IPs that actually replied. I ran it on my network and discovered 5 devices. One of them I didn’t even know was connected.

Now, I have 15 tools total. The network section is done.

The security section is done, network tools are in, and the program now handles admin privileges on its own.The security section is done, network tools are in, and the program now handles admin privileges on its own.
For the network side I added two things. A ping checker that sends 4 packets to whatever host you type in, and an IP viewer that shows your local IP using Python’s socket module and your public IP by calling curl ifconfig.me. Both are things I actually use all the time and was tired of opening a separate terminal for.
The firewall assistant checks if all three Windows profiles are active and whether port 3389 is exposed. That last one matters — leaving Remote Desktop open is one of the most common security mistakes on Windows machines.
The self-elevation part was probably the most satisfying to figure out. Some tools need admin rights to work properly, and instead of making the user remember to right-click and run as admin, the script checks on startup and relaunches itself elevated if needed. My machine has auto-UAC so I don’t see the popup, but it works.
14 tools now. Ready to submit.

C programmer TOUCHING grass for the FIRST TIME

I didnt program for 2 days and touched some grass.

How was it ?

it was weird since it was grass (wich i don’t touch) but it was ok.

btw it was fake grass

The toolkit kept growing faster than I expected. After the first batch of tools, I started getting into stuff I hadn’t touched before — cryptography, QR codes, and digging into Windows internals.
First I added the QR code generator. Honestly easier than I thought — create a QRCode object, feed it data, save the image. Done in a few lines.
Then I moved into the security section, which ended up being the most interesting part of this devlog. The password strength checker evaluates five criteria and returns a rating. The vulnerability scanner reads a .py file and flags dangerous patterns like eval(), exec(), and pickle.loads() — each one is a separate if so it catches everything, not just the first issue it finds.
The encryption tool was the trickiest one. I used Python’s cryptography library with AES via Fernet. The user’s key gets hashed with SHA-256 to get a proper 32-byte key, then Fernet handles the rest. The annoying part was the output — Python was printing b’…’ around the encrypted string which broke the decryption input. Fixed it with .decode().
The firewall assistant uses netsh advfirewall to check if the firewall is active on all three Windows profiles and whether Remote Desktop port 3389 is open. Something I’ll actually use.
13 tools now. Security section is done.

ZeroG-KIT started as a simple idea — instead of opening a bunch of different tools or googling converters every time, why not have everything in one place from the terminal?
The name comes from zero gravity, no resistance, no friction, things just flow.
I built the main menu first, a while loop with a bordered ASCII interface to keep it clean. From there I added the first batch of features. A temp file cleaner that wipes %TEMP%, Windows\Temp, and Prefetch in one go, a clipboard viewer, and a batch image converter using Pillow that handles format issues like RGBA to JPG automatically.
For the utilities side I added a password generator using Python’s secrets module for actual cryptographic randomness, a SHA-256 text hasher, and a full unit converter covering temperature, weight, length, and data size. Those live in a separate utilities.py to keep the main file readable.
6 out of 6 planned tools are working. Next up is system info and some polish.

CaffeineOS Lite, Devlog #3
Welcome Screen & Start Menu
With the core OS functioning, I focused on two features that enhance its completeness: a proper welcome screen and a useful Start Menu.
The welcome screen opens automatically after login as a draggable window, similar to every other window in the OS. It features a coffee icon, the CaffeineOS Lite name, and a brief description. This small addition makes the first impression feel more intentional rather than just dropping the user straight onto the desktop.
The Start Menu required more thought. It slides up from the taskbar when you click the Start button and closes when you click anywhere outside of it. Inside, it has an apps list on the left and a system panel on the right with a Shut Down button, which takes you back to the login screen, resetting the session. The entire design includes a frosted glass effect using backdrop-filter: blur, matching the taskbar’s style.
Both features prompted me to consider state more carefully. I ensured that the Start Menu closes at the right moment and that the welcome window only opens once per session, not on every login attempt.

C Navigation System — Devlog #2
BFS Pathfinding & Automatic Navigation
So after the first version I wasn’t really satisfied. The robot moving manually was cool to build but it felt incomplete — a robot that needs a human to tell it where to go isn’t really a robot. I wanted it to find the path on its own.
The problem was I had no idea how BFS worked.
I spent a good chunk of the 7 hours on this just trying to understand the algorithm before touching any code. Watched some explanations, drew it out on paper, tried to wrap my head around queues and how you actually backtrack to reconstruct a path. It took a while. The moment it clicked was when I stopped thinking about it as “visiting nodes” and started thinking about it as water spreading through a maze — it fills every reachable cell layer by layer until it hits the destination.
Once that made sense, I rebuilt the project. The grid went from 5x5 to 10x10 with a more complex obstacle layout. I separated the map logic into its own function (eh_obstaculo) so the maze can be edited without touching anything else. The BFS itself uses a queue array, a visited matrix, and a parent matrix — the parent matrix is what lets you trace back the full path once you reach (9,9).
The animation was actually the fun part. After the path is reconstructed, the board redraws at each step with clear() and usleep(), showing the robot moving tile by tile. It even replays at the end at a faster speed. Seeing it run for the first time was genuinely satisfying.
The hardest part was getting the path reconstruction right — BFS gives you the path backwards, so you have to reverse it before animating. Took me a few tries to get that sorted.

VOIDBOT — Devlog #1
Migrating to Hack Club Nest
VOIDBOT started as a Python Slack bot hosted on Hugging Face Spaces. It uses Socket Mode, meaning it doesn’t need a public URL — it connects directly to Slack via a persistent WebSocket. To keep Hugging Face’s supervisor happy, I ran a lightweight HTTP health-check thread alongside the bot, tricking the platform into thinking a web server was running.
During re-certification for Stardance, my reviewer flagged that Hugging Face Spaces doesn’t run indefinitely and isn’t an approved hosting platform. The fix: migrate to Hack Club Nest, a free Linux container provided by Hack Club.
I applied for a Nest container, generated an SSH key pair with ssh-keygen, and submitted the public key during the application. Once approved, I SSHed into the container, installed git and Python dependencies, cloned the VOIDBOT repo, configured the Slack tokens via a .env file, and verified the bot connected successfully.
To keep it running 24/7 after closing the SSH session, I installed tmux and detached the bot process inside a named session. VOIDBOT is now live on Nest, accessible in the public #voidbot-demo channel on the Hack Club Slack.
Try it: join #voidbot-demo and run /vt-ping, /vt-about, or /vt-voidtune.

C navigation system, a robot in a 5x5 maze
Built a C program that simulates a robot navigating a 5x5 grid with obstacles.
What’s done so far:

A dynamically drawn 5x5 board, with . (free path), # (obstacles), D (destination), and X (robot)
Obstacle layout stored in a separate map (lab, using l=free and p=wall), so the map can be edited easily without touching the rest of the logic
Movement controlled by directions (North/South/East/West), one tile at a time
Bounds checking (can’t leave the grid) and collision checking (can’t move through obstacles)
Board redraws after every move
Win message when reaching the destination at (4,4)

Devlog 2 — File explorer with folder navigation and image viewer

Added a functional “My Documents” app with a real file explorer. The root shows three folders (Wallpapers, Icons, Projects), and double-clicking navigates into them with a “..” button to go back.
Double-clicking an image opens a draggable mini-window with the image preview, centered on screen , reusing the same drag/z-index logic from the main windows. Double-clicking the WebOS1 project entry opens its GitHub repo in a new tab.
Under the hood, the file system is just a JS object (fileSystem) mapping folder names to arrays of items, which made it easy to add new folders/files without touching the rendering logic.

Devlog 1 — Draggable windows, terminal, and login screen

Built the main desktop environment for WebOS1. Windows can now be dragged around the desktop and bring themselves to the front when clicked (z-index). Added a custom login screen that asks for a username on startup, no passwords, just stored in memory for the session.
The big feature today was a working terminal app with a real shell-like prompt (username@webos:~$). It supports help, whoami, ls, pwd, clear, sudo (denial message for fun), apt install with animated fake install output, and neofetch showing system info.
Also replaced the default wallpaper with the classic Windows XP Bliss background and added custom SVG/icon assets for the desktop shortcuts.

Devlog, Defeating Cloud Runtime Errors, Bypassing Local Constraints, and Achieving 100% Production Status

This is the latest version of VOIDBOT. It began as a local Python script and has now been successfully transformed into a fully operational cloud-based service.

Here’s how we overcame the final deployment issues today:

1. The Local Environment Shift:
   I encountered a conflict when moving my work to my main Windows workstation. Virtual environments (.venv) cannot be transferred across different systems due to OS-specific binaries. I erased the old directory and set up a clean Windows environment, reinstalling ‘slack-bolt’, ‘python-dotenv’, and ‘websocket-client’.

2. Namespace Protection and Anti-Collision:
   To ensure smooth operation within Hack Club’s large workspace, I changed all listener annotations to use a unique prefix (/vt-). Commands like /vt-ping, /vt-about, and /vt-voidtune are now linked to my bot layer without clashing with other active services.

3. Strengthening Repository Security:
   I created a specific .gitignore file to keep the physical .env variables on my local disk, completely removing any risk of exposing cloud credentials on my GitHub repository.

4. Fixing the Hugging Face ‘Runtime Error’ and Network Proxies:
   When moving to Hugging Face Spaces (using a custom Dockerfile), the instance crashed due to failing the cloud infrastructure’s automatic network health checks. Since Socket Mode requires a constant outgoing WebSocket connection, it does not allow an open HTTP port. To fix this:

• I modified main.py to create a secondary asynchronous thread (threading.Thread).
• I built a simple internal health checking system using Python’s native HTTPServer on port 7860.
• This kept the cloud supervisor satisfied while allowing the main Bolt engine to communicate smoothly with Slack in the background.

1. Managing Dynamic Configurations:
   I updated config.py with a check to see if the required variables are already in the cloud system’s environment memory. If they are found, it skips the .env parsing and continues the system execution.

Result: The space is now stable and in a permanent green “Running” state. The bot handles live channel interactions, processes async commands, logs activity timestamps, and operates 24/7 without needing my home PC online.

VOIDBOT is ready. Next stop: WebOS!