|
20748
|
PrayDB by @lupc65779 | Stardance
|
lupc65779
|
1
|
2.78
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T11:58:44Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Say hello to PrayDB, the only database engine powered entirely by gambling and faith. What started as a joke by openclaw has turned into a fully functioning project that I plan on actually maintaining. ! Note: The site demo is just a preview of how it works. To actually use it check out the GH repo.", "repo": "https://github.com/Lupc9102/PrayDB", "demo": "https://www.lupc.xyz/praydb-demo"}]...
|
[{"post_id": 11310, "ts": "202 [{"post_id": 11310, "ts": "2026-06-18T14:37:29Z", "hours": 0.7797, "text": "Basic showcase/walk-through script now on GH"}, {"post_id": 11233, "ts": "2026-06-18T11:50:03Z", "hours": 1.4272, "text": "Wrote README.md and published the client-side demo on https://www.lupc.xyz/praydb-demo"}, {"post_id": 10609, "ts": "2026-06-17T13:32:32Z", "hours": 0.9361, "text": "Little introduction to this project: PrayDB is a dumb idea that an OpenClaw agent jokingly gave to me on a Saturday afternoon. Who the fuck isn’t bored of MySQL, Mongo, and others? We need a CHANGE. As we can all see, the world is leaning towards using AI in pretty much everything… now why wouldn’t you want an LLM handling your super-duper-important database with super-duper-important user data? (I know this is dumb.) Therefore, I present to you PrayDB: the only DB that introduces gambling to data storage."}]...
|
Title: PrayDB by @lupc65779 | Stardance
Devlogs:
Title: PrayDB by @lupc65779 | Stardance
Devlogs:
Little introduction to this project: PrayDB is a dumb idea that an OpenClaw agent jokingly gave to me on a Saturday afternoon. Who the fuck isn’t bored of MySQL, Mongo, and others? We need a CHANGE. As we can all see, the world is leaning towards using AI in pretty much everything… now why wouldn’t you want an LLM handling your super-duper-important database with super-duper-important user data? (I know this is dumb.) Therefore, I present to you PrayDB: the only DB that introduces gambling to data storage.
Wrote README.md and published the client-side demo on https://www.lupc.xyz/praydb-demo
Basic showcase/walk-through script now on GH
Ships:
Say hello to PrayDB, the only database engine powered entirely by gambling and faith. What started as a joke by openclaw has turned into a fully functioning project that I plan on actually maintaining. ! Note: The site demo is just a preview of how it works. To actually use it check out the GH repo....
|
1793252912.3185027
|
1793339312.3185027
|
|
20752
|
MarkPreStarX by @toivoa070 | Stardance
|
toivoa070
|
1
|
3.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-24T06:43:36Z", "hours": 3.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "The Real-Time Markdown Previewer is a web application that allows users to write Markdown and instantly view the rendered HTML output in a live preview pane and everything was confusing and I know how it works and all but I still need to update this project furthur and want some recommendations.", "repo": "https://github.com/Nottoishenshu/MarkPreStarX", "demo": "https://nottoishenshu.github.io/MarkPreStarX/"}]...
|
[{"post_id": 13154, "ts": "202 [{"post_id": 13154, "ts": "2026-06-21T15:02:12Z", "hours": 0.6214, "text": "Styling the Application with CSS; After building the core functionality, I created the CSS stylesheet to improve the user experience and visual appearance of the application. The stylesheet is responsible for the overall layout, typography, spacing, colors, and responsiveness of the Markdown Previewer. I used CSS to create a clean split-screen interface between the editor and preview pane, making it easy for users to write and view Markdown simultaneously. Additional styling was added for buttons, code blocks, blockquotes, lists, and other rendered Markdown elements to ensure the preview closely resembles how Markdown is typically displayed on modern platforms. The stylesheet also helps maintain consistency throughout the application while keeping the interface simple, readable, and user-friendly. Once the functionality was working, I focused on styling the application to make it more visually appealing and easier to use. Using CSS, I designed the layout, styled the editor and preview sections, and improved the appearance of rendered Markdown elements such as headings, lists, code blocks, and blockquotes. This step helped transform the project from a functional prototype into a more polished application that provides a better user experience."}, {"post_id": 12540, "ts": "2026-06-20T14:14:51Z", "hours": 1.3925, "text": "app.js Overview The file serves as the main controller for the Markdown Previewer application. It manages user interactions, updates the live preview, handles toolbar actions, saves data to Local Storage, synchronizes scrolling, exports content, and applies syntax highlighting. This file connects the user interface with the Markdown parser, ensuring that changes made in the editor are instantly reflected in the preview panel. What I Added: Live Markdown rendering with real-time updates, Debounced rendering to improve performance while typing Scroll synchronization between editor and preview panels Local, Storage support for automatic save and restore Toolbar buttons for common Markdown formatting Copy HTML functionality using the Clipboard API Markdown file download functionality Clear editor and storage reset feature, Basic syntax highlighting for code blocks, Error handling for rendering and storage operations, Application initialization and startup logic. What I Learned: While building app.js, I gained practical experience with modern JavaScript and browser APIs. I learned how to manipulate the DOM, listen for user events, and update page content dynamically. I also explored Local Storage for data persistence, the Clipboard API for copying content, and the Blob API for generating downloadable files. Additionally, I learned performance optimization techniques such as debouncing, implemented scroll synchronization, worked with regular expressions for syntax highlighting, and improved application reliability through error handling and modular JavaScript design. Key Concepts Practiced DOM Manipulation, Event HandlingES6 Modules, Arrow Functions, Local Storage API, Clipboard APIBlob APIError Handling (try/catch)Debouncing, Regular Expressions, Syntax Highlighting, Scroll Synchronization, Dynamic Rendering, Modular JavaScript Architecture User Interface."}, {"post_id": 11255, "ts": "2026-06-18T12:31:15Z", "hours": 0.5042, "text": "Building this Markdown Previewer was a fun and challenging experience. At the beginning, I thought the project would simply involve converting Markdown text into HTML and displaying it on the screen. However, as I started working on the parser and rendering logic, I realized there were many details to consider, from handling different Markdown formats to making sure the output was safe and properly rendered. Throughout the project, I faced several challenges that helped me grow as a developer. Debugging became a major part of the process because even small mistakes in regular expressions or syntax could break the entire parser. I also learned that the order of processing Markdown elements matters, since links, images, bold text, and code blocks can sometimes overlap. Challenges I Faced Understanding and writing regular expressions for different Markdown patterns. Debugging syntax errors and unexpected parser behavior. Handling multiple Markdown elements without conflicts. Learning how to safely render user-generated content. Implementing local storage so user content persists after refreshing the page. Synchronizing the editor and preview pane scrolling. Testing different edge cases to ensure the parser worked correctly. What I Learned, Through this project, I gained a much deeper understanding of frontend development and how text-processing applications work. Some of the key things I learned include; How Markdown is converted into HTML. Using Regular Expressions (Regex) to identify and process text patterns. DOM manipulation with JavaScript. Working with browser APIs such as Local Storage and Clipboard. Creating reusable and organized code using modules. Basic web security concepts such as input sanitization and XSS prevention. Debugging techniques and using browser developer tools effectively. The importance of testing and handling edge cases. Reflection One of the biggest takeaways from this project was realizing that software development is often about problem-solving rather than simply writing code. Many features required multiple attempts before they worked correctly, and each bug taught me something new. While there were moments of frustration, solving those problems was also the most rewarding part of the experience. Overall, this project is helping me improve my JavaScript skills, gain confidence in building applications from scratch, and better understand how real-world web applications process and display user input."}, {"post_id": 10562, "ts": "2026-06-17T11:12:18Z", "hours": 0.4519, "text": "For a long time, I kept wondering what kind of project I could build that would genuinely improve my coding skills. One day, while working in VS Code, I started paying attention to how convenient it is to write code and instantly see the results. I noticed how different colors highlighted functions and syntax, and how useful live feedback can be while coding. That got me thinking about Markdown and how developers often need to write documentation, notes, and README files. Normally, you have to switch between editing and previewing to see how your Markdown looks. After exploring a few ideas online, I decided to build my own Markdown Previewer from scratch. The application will feature: A split-pane layout with an Editor Pane and a Preview Pane Support for Markdown headings Bold and italic text formatting Links and images Code blocks for displaying code snippets Live preview updates as the user types. The semantic structure of the project is intentionally simple and consists mainly of a element for the toolbar and a element containing the editor and preview sections .For styling, I used fonts from /* https://fonts.googleapis.com*/ and referenced design inspiration from Pinterest and made it Stardance themed. Throughout this project, I have learned more about how Markdown works behind the scenes, including :Parsing block-level elements using regular expressions (Regex)Understanding Markdown syntax rules Structuring applications with semantic HTML Building responsive split-pane layouts Creating real-time content updates with JavaScript. This project has been a great learning experience because it combines HTML, CSS, and JavaScript while introducing me to text parsing and dynamic content rendering. More importantly, it has helped me understand how tools that developers use every day are built and how they work behind the scenes."}]...
|
Title: MarkPreStarX by @toivoa070 | Stardance
Dev Title: MarkPreStarX by @toivoa070 | Stardance
Devlogs:
For a long time, I kept wondering what kind of project I could build that would genuinely improve my coding skills. One day, while working in VS Code, I started paying attention to how convenient it is to write code and instantly see the results. I noticed how different colors highlighted functions and syntax, and how useful live feedback can be while coding. That got me thinking about Markdown and how developers often need to write documentation, notes, and README files. Normally, you have to switch between editing and previewing to see how your Markdown looks. After exploring a few ideas online, I decided to build my own Markdown Previewer from scratch. The application will feature: A split-pane layout with an Editor Pane and a Preview Pane Support for Markdown headings Bold and italic text formatting Links and images Code blocks for displaying code snippets Live preview updates as the user types. The semantic structure of the project is intentionally simple and consists mainly of a element for the toolbar and a element containing the editor and preview sections .For styling, I used fonts from /* https://fonts.googleapis.com*/ and referenced design inspiration from Pinterest and made it Stardance themed. Throughout this project, I have learned more about how Markdown works behind the scenes, including :Parsing block-level elements using regular expressions (Regex)Understanding Markdown syntax rules Structuring applications with semantic HTML Building responsive split-pane layouts Creating real-time content updates with JavaScript. This project has been a great learning experience because it combines HTML, CSS, and JavaScript while introducing me to text parsing and dynamic content rendering. More importantly, it has helped me understand how tools that developers use every day are built and how they work behind the scenes.
Building this Markdown Previewer was a fun and challenging experience. At the beginning, I thought the project would simply involve converting Markdown text into HTML and displaying it on the screen. However, as I started working on the parser and rendering logic, I realized there were many details to consider, from handling different Markdown formats to making sure the output was safe and properly rendered. Throughout the project, I faced several challenges that helped me grow as a developer. Debugging became a major part of the process because even small mistakes in regular expressions or syntax could break the entire parser. I also learned that the order of processing Markdown elements matters, since links, images, bold text, and code blocks can sometimes overlap. Challenges I Faced Understanding and writing regular expressions for different Markdown patterns. Debugging syntax errors and unexpected parser behavior. Handling multiple Markdown elements without conflicts. Learning how to safely render user-generated content. Implementing local storage so user content persists after refreshing the page. Synchronizing the editor and preview pane scrolling. Testing different edge cases to ensure the parser worked correctly. What I Learned, Through this project, I gained a much deeper understanding of frontend development and how text-processing applications work. Some of the key things I learned include; How Markdown is converted into HTML. Using Regular Expressions (Regex) to identify and process text patterns. DOM manipulation with JavaScript. Working with browser APIs such as Local Storage and Clipboard. Creating reusable and organized code using modules. Basic web security concepts such as input sanitization and XSS prevention. Debugging techniques and using browser developer tools effectively. The importance of testing and handling edge cases. Reflection One of the biggest takeaways from this project was realizing that software development is often about problem-solving rather than simply writing code. Many features required multiple attempts before they worked correctly, and each bug taught me something new. While there were moments of frustration, solving those problems was also the most rewarding part of the experience. Overall, this project is helping me improve my JavaScript skills, gain confidence in building applications from scratch, and better understand how real-world web applications process and display user input.
app.js Overview The file serves as the main controller for the Markdown Previewer application. It manages user interactions, updates the live preview, handles toolbar actions, saves data to Local Storage, synchronizes scrolling, exports content, and applies syntax highlighting. This file connects the user interface with the Markdown parser, ensuring that changes made in the editor are instantly reflected in the preview panel. What I Added: Live Markdown rendering with real-time updates, Debounced rendering to improve performance while typing Scroll synchronization between editor and preview panels Local, Storage support for automatic save and restore Toolbar buttons for common Markdown formatting Copy HTML functionality using the Clipboard API Markdown file download functionality Clear editor and storage reset feature, Basic syntax highlighting for code blocks, Error handling for rendering and storage operations, Application initialization and startup logic. What I Learned: While building app.js, I gained practical experience with modern JavaScript and browser APIs. I learned how to manipulate the DOM, listen for user events, and update page content dynamically. I also explored Local Storage for data persistence, the Clipboard API for copying content, and the Blob API for generating downloadable files. Additionally, I learned performance optimization techniques such as debouncing, implemented scroll synchronization, worked with regular expressions for syntax highlighting, and improved application reliability through error handling and modular JavaScript design. Key Concepts Practiced DOM Manipulation, Event HandlingES6 Modules, Arrow Functions, Local Storage API, Clipboard APIBlob APIError Handling (try/catch)Debouncing, Regular Expressions, Syntax Highlighting, Scroll Synchronization, Dynamic Rendering, Modular JavaScript Architecture User Interface.
Styling the Application with CSS; After building the core functionality, I created the CSS stylesheet to improve the user experience and visual appearance of the application. The stylesheet is responsible for the overall layout, typography, spacing, colors, and responsiveness of the Markdown Previewer. I used CSS to create a clean split-screen interface between the editor and preview pane, making it easy for users to write and view Markdown simultaneously. Additional styling was added for buttons, code blocks, blockquotes, lists, and other rendered Markdown elements to ensure the preview closely resembles how Markdown is typically displayed on modern platforms. The stylesheet also helps maintain consistency throughout the application while keeping the interface simple, readable, and user-friendly. Once the functionality was working, I focused on styling the application to make it more visually appealing and easier to use. Using CSS, I designed the layout, styled the editor and preview sections, and improved the appearance of rendered Markdown elements such as headings, lists, code blocks, and blockquotes. This step helped transform the project from a functional prototype into a more polished application that provides a better user experience.
Ships:
The Real-Time Markdown Previewer is a web application that allows users to write Markdown and instantly view the rendered HTML output in a live preview pane and everything was confusing and I know how it works and all but I still need to update this project furthur and want some recommendations....
|
1793285489.3068826
|
1793371889.3068826
|
|
20759
|
ez-SDR by @lupc65779 | Stardance
|
lupc65779
|
1
|
163.0
|
0
|
[{"ship_num": 1, "ts": "2026-1 [{"ship_num": 1, "ts": "2026-10-17T15:44:56Z", "hours": 163.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built ez-SDR , an open source software defined radio application written entirely in Rust (one of the relatively few fully Rust-based SDR desktop applications). ez-SDR has three main tabs: Radio: A general-purpose radio receiver with AM, FM, SSB, CW, and other modulation modes, real-time spectrum and waterfall displays, and stereo FM with RDS support. ADS-B: An aircraft tracking system with an interactive map showing aircraft positions, altitudes, speeds, headings, and flight trails. It includes native decoders for both 1090 MHz ADS-B, used worldwide, and the freedom frequency (978 MHz) Meteor Decoding: A satellite image decoder capable of decoding imagery transmitted by the Russian Meteor-M2-3 and M2-4 weather satellites. It supports both live reception and decoding previously recorded radio signals (saved as CS8 or CF32 files), with image previews and PNG exports. (A moment of silence for the deprecated NOAA satellites) Another major feature is the architecture itself. I beheaded it. (The project.) The actual GUI is separated from the radio processing backend allowing it to run as a headless daemon. It exposes HTTP and WebSocket API’s, making it possible to interact with the backend without using the GUI. Getting everything working was… interesting. Building the decoding pipelines, integrating them into a responsive desktop interface (making it snappy and fast took several tens of hours), debugging signal processing issues, and literally running through cornfields with an antenna in my hand were some of the biggest challenges I ran into. The project went through several major redesigns, from the initial Rust implementation to separating the backend from the UI, briefly experimenting with Electron, and eventually returning to the native Rust interface. After over 160 hours of logged work , I’m excited to finally ship ez-SDR! The source code and Linux builds are available on GitHub, with a Windows build planned for the near future.", "repo": "https://github.com/Lupc9102/ez-sdr", "demo": "https://drive.google.com/file/d/1CAk3eGq8M2QFzbwPgKeuX1w_fwFsIhUG/view?usp=sharing"}]...
|
[{"post_id": 80362, "ts": "202 [{"post_id": 80362, "ts": "2026-10-17T12:36:53Z", "hours": 10.9075, "text": "Major reliability and release readiness improvements for EZ-SDR -stronger ADS-B/UAT decoding -safer settings, cleaner daemon and browser lifecycles -better audio and integrations - finally stable data paths -packaging fixes -removal of immense amounts of bloat PS heres an image of LRPT decoding in action"}, {"post_id": 78367, "ts": "2026-10-10T16:02:57Z", "hours": 10.4897, "text": "Getting ready to ship it so here I am trying to patch some final bugs in the Meteor Satellite Lrpt decoding pipeline"}, {"post_id": 77103, "ts": "2026-10-05T17:15:36Z", "hours": 15.5006, "text": "Going for a final round of fixes on the ads-b pipeline before marking it as finished 6.1 sol xhigh audited it and its not looking too good (holy f 11k words)"}, {"post_id": 74071, "ts": "2026-09-26T16:52:51Z", "hours": 8.1261, "text": "Rust UI is back, also ported a couple of features from sdr++, The screenshot contains an actual signal (unlike the mockups in past devblogs), more precisely a local music radio station received through ez-sdr with a rtl sdr v4 dongle"}, {"post_id": 72598, "ts": "2026-09-23T09:47:02Z", "hours": 13.9953, "text": "a TON of bug hunting and im going back to the old rust ui because it turns out the electron app wasnt my brightest idea"}, {"post_id": 57242, "ts": "2026-08-29T10:50:29Z", "hours": 9.9469, "text": "Couldnt patch the ads-b map view inside the rust gui app so i took a U turn with the porject and went all in for an Electron App as the gui for the ez-sdr daemon. mockup waterfall"}, {"post_id": 44519, "ts": "2026-08-10T10:22:10Z", "hours": 8.3333, "text": "Not much to be written, just some painful and slow progress with decoding meteor imagery."}, {"post_id": 28507, "ts": "2026-07-14T20:02:26Z", "hours": 6.0031, "text": "Should I even be happy? I finally tested ez-sdr’s satellite decoding with a real recording I took yesterday on an Meteor M2-4 88* pass, and it’s… not great, especially compared to SatDump’s decode. (Ez-sdr is the first image, SatDump is the second image.) What troubles me the most is that I literally stole SatDump’s homework equation by equation and rewrote it in Rust, and it still looks like shite lol. Its for sure progress and im happy with that lol"}, {"post_id": 27542, "ts": "2026-07-13T06:10:40Z", "hours": 9.3789, "text": "Considering that the last two LRPT satellites that still transmit are Meteor m2-3 and Meteor m2-4 i did efforts to make decoding them as fast as possible , especially cf32, cs16 and cs8 decoding. Now i didnt really get to test the upgrades.. because i didnt get to FINISH the upgrades but i DID finish the web ui remote from the last devlog. (I am posting this devlog WITHOUT a finished feature because im getting close to the 10 hour cap) Also ive went outside, touched grass and snatched a good cs32 from meteor m2-4 so i actually have what to test the decoding on."}, {"post_id": 25907, "ts": "2026-07-10T12:18:29Z", "hours": 10.7172, "text": "I cut its head off. Fully decoupled Ez-sdr from Ez-gui (the Rust UI), effectively turning Ez-sdr into a headless project. This allows Ez-sdr to be coupled to multiple channels: The original Rust UI WebUI (Almost done, in development) Discord (in development) This decoupling also exposes an API, allowing you to integrate and use Ez-sdr functionalities on the go within your own applications and projects."}, {"post_id": 25177, "ts": "2026-07-09T07:11:47Z", "hours": 28.3117, "text": "Yet another from-scratch redesign because lately most of the app started feeling bloated and hard to use for beginners (which defeats the entire purpose of ez -sdr, which is meant to be easy . Therefore i moved most of the unnecessary stuff in advanced and other tabs. Also patched a lot of bugs."}, {"post_id": 20817, "ts": "2026-07-02T15:02:41Z", "hours": 25.5669, "text": "Full UI redesign + a ton of new features: The ADSB tab now includes a map, plane labels, and a 3D view mode. Added a Discord gateway that sends notifications and images of detected planes, satellite passes, and more. Overhauled the AI Assistant tab. Added a reasoning effort dropdown to the AI assistant. Granted the AI the ability to perform web searches. Added well-documented checklists and tutorials for beginners setting up their SDR kits, including an antenna angle and length calculator, recommended environments, cabling tips, and driver recommendations. Added UI presets: users can select their experience level on the first boot, and the app automatically customizes the interface accordingly (beginners rely more on the AI assistant and auto-tuning, while experts manage everything manually with optional AI assistance). Added premade themes and in depth ui customization."}, {"post_id": 17812, "ts": "2026-06-28T19:00:19Z", "hours": 5.7533, "text": "I know how hard is it to get started with software defined radios. I went through the hassle of being a complete beginner and having to deal with sketchy blogs and UIs of apps older than most of us participating in this hackaton, and so I tried to build an all-in-one SDR app with most of the cool things you can get from the average RTL-SDR kit: plane tracking, listening to ATC and some other cool frequencies, satellite signal capturing, decoding and tracking, and many more in one unified app interface. I originally intended to do ALL this in Python, but it was way too slow and crashed during DSP, so I had to rewrite it fully in Rust. Problem is that I don’t really know Rust (and basically anything lower level than Python) so props on kimi k2.6 who handled the whole rewrite flawlessly. There’s still many things to improve on this, and, more importantly.. a ton of testing and trial and error"}]...
|
Title: ez-SDR by @lupc65779 | Stardance
Devlogs:
Title: ez-SDR by @lupc65779 | Stardance
Devlogs:
I know how hard is it to get started with software defined radios. I went through the hassle of being a complete beginner and having to deal with sketchy blogs and UIs of apps older than most of us participating in this hackaton, and so I tried to build an all-in-one SDR app with most of the cool things you can get from the average RTL-SDR kit: plane tracking, listening to ATC and some other cool frequencies, satellite signal capturing, decoding and tracking, and many more in one unified app interface. I originally intended to do ALL this in Python, but it was way too slow and crashed during DSP, so I had to rewrite it fully in Rust. Problem is that I don’t really know Rust (and basically anything lower level than Python) so props on kimi k2.6 who handled the whole rewrite flawlessly. There’s still many things to improve on this, and, more importantly.. a ton of testing and trial and error
Full UI redesign + a ton of new features: The ADSB tab now includes a map, plane labels, and a 3D view mode. Added a Discord gateway that sends notifications and images of detected planes, satellite passes, and more. Overhauled the AI Assistant tab. Added a reasoning effort dropdown to the AI assistant. Granted the AI the ability to perform web searches. Added well-documented checklists and tutorials for beginners setting up their SDR kits, including an antenna angle and length calculator, recommended environments, cabling tips, and driver recommendations. Added UI presets: users can select their experience level on the first boot, and the app automatically customizes the interface accordingly (beginners rely more on the AI assistant and auto-tuning, while experts manage everything manually with optional AI assistance). Added premade themes and in depth ui customization.
Yet another from-scratch redesign because lately most of the app started feeling bloated and hard to use for beginners (which defeats the entire purpose of ez -sdr, which is meant to be easy . Therefore i moved most of the unnecessary stuff in advanced and other tabs. Also patched a lot of bugs.
I cut its head off. Fully decoupled Ez-sdr from Ez-gui (the Rust UI), effectively turning Ez-sdr into a headless project. This allows Ez-sdr to be coupled to multiple channels: The original Rust UI WebUI (Almost done, in development) Discord (in development) This decoupling also exposes an API, allowing you to integrate and use Ez-sdr functionalities on the go within your own applications and projects.
Considering that the last two LRPT satellites that still transmit are Meteor m2-3 and Meteor m2-4 i did efforts to make decoding them as fast as possible , especially cf32, cs16 and cs8 decoding. Now i didnt really get to test the upgrades.. because i didnt get to FINISH the upgrades but i DID finish the web ui remote from the last devlog. (I am posting this devlog WITHOUT a finished feature because im getting close to the 10 hour cap) Also ive went outside, touched grass and snatched a good cs32 from meteor m2-4 so i actually have what to test the decoding on.
Should I even be happy? I finally tested ez-sdr’s satellite decoding with a real recording I took yesterday on an Meteor M2-4 88* pass, and it’s… not great, especially compared to SatDump’s decode. (Ez-sdr is the first image, SatDump is the second image.) What troubles me the most is that I literally stole SatDump’s homework equation by equation and rewrote it in Rust, and it still looks like shite lol. Its for sure progress and im happy with that lol
Not much to be written, just some painful and slow progress with decoding meteor imagery.
Couldnt patch the ads-b map view inside the rust gui app so i took a U turn with the porject and went all in for an Electron App as the gui for the ez-sdr daemon. mockup waterfall
a TON of bug hunting and im going back to the old rust ui because it turns out the electron app wasnt my brightest idea
Rust UI is back, also ported a couple of features from sdr++, The screenshot contains an actual signal (unlike the mockups in past devblogs), more precisely a local music radio station received through ez-sdr with a rtl sdr v4 dongle
Going for a final round of fixes on the ads-b pipeline before marking it as finished 6.1 sol xhigh audited it and its not looking too good (holy f 11k words)
Getting ready to ship it so here I am trying to patch some final bugs in the Meteor Satellite Lrpt decoding pipeline
Major reliability and release readiness improvements for EZ-SDR -stronger ADS-B/UAT decoding -safer settings, cleaner daemon and browser lifecycles -better audio and integrations - finally stable data paths -packaging fixes -removal of immense amounts of bloat PS heres an image of LRPT decoding in action
Ships:
I built ez-SDR , an open source software defined radio application written entirely in Rust (one of the relatively few fully Rust-based SDR desktop applications). ez-SDR has three main tabs: Radio: A general-purpose radio receiver with AM, FM, SSB, CW, and other modulation modes, real-time spectrum and waterfall displays, and stereo FM with RDS support. ADS-B: An aircraft tracking system with an interactive map showing aircraft positions, altitudes, speeds, headings, and flight trails. It includes native decoders for both 1090 MHz ADS-B, used worldwide, and the freedom frequency (978 MHz) Meteor Decoding: A satellite image decoder capable of decoding imagery transmitted by the Russian Meteor-M2-3 and M2-4 weather satellites. It supports both live reception and decoding previously recorded radio signals (saved as CS8 or CF32 files), with image previews and PNG exports. (A moment of silence for the deprecated NOAA satellites) Another major feature is the architecture itself. I beheaded it. (The project.) The actual GUI is separated from the radio processing backend allowing it to run as a headless daemon. It exposes HTTP and WebSocket API’s, making it possible to interact with the backend without using the GUI. Getting everything working was… interesting. Building the decoding pipelines, integrating them into a responsive desktop interface (making it snappy and fast took several tens of hours), debugging signal processing issues, and literally running through cornfields with an antenna in my hand were some of the biggest challenges I ran into. The project went through several major redesigns, from the initial Rust implementation to separating the backend from the UI, briefly experimenting with Electron, and eventually returning to the native Rust interface. After over 160 hours of logged work , I’m excited to finally ship ez-SDR! The source code and Linux builds are available on GitHub, with a Windows build planned for the near future....
|
1793198865.8374343
|
1793285265.8374343
|
|
20769
|
Openclip by @Aionix | Stardance
|
Aionix
|
1
|
28.01
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-21T18:54:23Z", "hours": 25.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I created and open-sourced “OpenClip” - a complete local-first AI video clipping engine that runs entirely on your machine. No subscriptions. No watermarks. No cloud uploads. Just paste a YouTube URL and get AI-generated short clips ready for TikTok, Reels, and Shorts. It automatically turns long YouTube videos into ready-to-post short clips using AI (Whisper for transcription, MediaPipe for face tracking, LLMs for captioning). Tech: Next.js + FastAPI + yt-dlp + FFmpeg Fully open-source under MIT license with detailed README, setup scripts and active development. GitHub: https://github.com/aionixOS/OpenclipV-", "repo": "https://github.com/aionixOS/OpenclipV-", "demo": "https://openclip-v.vercel.app/"}]...
|
[{"post_id": 14235, "ts": "202 [{"post_id": 14235, "ts": "2026-06-23T07:49:35Z", "hours": 3.0119, "text": "Recent Updates Browser-Side API Keys: Your LLM API keys are now stored securely in your browser’s localStorage. They never touch the backend database, making this safe to host publicly. YouTube Bot Bypass: Added pytubefix as an automated fallback to bypass YouTube’s aggressive “Sign in to prove you’re not a bot” datacenter blocks (PO Token support enabled). Vercel Compatibility: The real-time progress tracker now seamlessly falls back to fast HTTP Polling if Vercel’s Edge network blocks the WebSocket connection."}, {"post_id": 13204, "ts": "2026-06-21T17:02:22Z", "hours": 24.7883, "text": "I created and open-sourced “OpenClip” - a complete local-first AI video clipping engine. It automatically turns long YouTube videos into ready-to-post short clips using AI (Whisper for transcription, MediaPipe for face tracking, LLMs for captioning). Tech: Next.js + FastAPI + yt-dlp + FFmpeg Fully open-source under MIT license with detailed README, setup scripts and active development. GitHub: https://github.com/aionixOS/OpenclipV-"}]...
|
Title: Openclip by @Aionix | Stardance
Devlogs:
I Title: Openclip by @Aionix | Stardance
Devlogs:
I created and open-sourced “OpenClip” - a complete local-first AI video clipping engine. It automatically turns long YouTube videos into ready-to-post short clips using AI (Whisper for transcription, MediaPipe for face tracking, LLMs for captioning). Tech: Next.js + FastAPI + yt-dlp + FFmpeg Fully open-source under MIT license with detailed README, setup scripts and active development. GitHub: https://github.com/aionixOS/OpenclipV-
Recent Updates Browser-Side API Keys: Your LLM API keys are now stored securely in your browser’s localStorage. They never touch the backend database, making this safe to host publicly. YouTube Bot Bypass: Added pytubefix as an automated fallback to bypass YouTube’s aggressive “Sign in to prove you’re not a bot” datacenter blocks (PO Token support enabled). Vercel Compatibility: The real-time progress tracker now seamlessly falls back to fast HTTP Polling if Vercel’s Edge network blocks the WebSocket connection.
Ships:
I created and open-sourced “OpenClip” - a complete local-first AI video clipping engine that runs entirely on your machine. No subscriptions. No watermarks. No cloud uploads. Just paste a YouTube URL and get AI-generated short clips ready for TikTok, Reels, and Shorts. It automatically turns long YouTube videos into ready-to-post short clips using AI (Whisper for transcription, MediaPipe for face tracking, LLMs for captioning). Tech: Next.js + FastAPI + yt-dlp + FFmpeg Fully open-source under MIT license with detailed README, setup scripts and active development. GitHub: https://github.com/aionixOS/OpenclipV-...
|
1793285782.2871122
|
1793372182.2871122
|
|
20775
|
PitWall Pro by @Amcoo | Stardance
|
Amcoo
|
1
|
2.0
|
9
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-16T23:13:18Z", "hours": 2.0, "multiplier": 4.24, "payout": 9, "blessing": "neutral", "text": "What did you make? I built Pitwall Pro, an advanced, real-time Formula 1 telemetry and race strategy visualization dashboard. It’s designed to bring the complex, data-heavy environment of an F1 pitwall directly to your browser. It features a fully interactive 3D track visualization, live telemetry parsing (speed, gear, RPM, delta), head-to-head driver comparisons, and dynamic tire strategy simulators. What was challenging? Handling heavy streams of telemetry data while keeping the UI buttery smooth was a massive challenge. When rendering the 3D scene concurrently with dozens of live-updating Recharts components, the DOM initially struggled. I had to heavily optimize the application using requestAnimationFrame for a custom 60fps playback loop, aggressively memoize React components to prevent wasteful re-renders, and lazy-load the Three.js canvas. Syncing the 3D car positions perfectly with the 2D telemetry timeline took hours of complex math and state management. What are you proud of? I am incredibly proud of the UI/UX architecture. Achieving that “glassmorphism” dark-mode aesthetic while maintaining readability for dense datasets isn’t easy. The integration of keyboard shortcuts (Space to play, arrows to scrub, 1-4 for speed) makes the app feel like a native professional tool, not just a standard web page. Watching the 3D scene react instantly to the scrubbed telemetry timeline still feels magical every time I do it. What should people know so they can test your project? Hit Space to start the live telemetry playback! Use your keyboard to navigate like an engineer: 1-4 changes playback speed, L toggles lap times, and the Arrow keys let you scrub through the race data. Make sure to zoom into the telemetry charts to see the exact braking points, and click on the “Advanced Panels” to experiment with different tire strategy simulations. It’s fully responsive, but best experienced on a desktop monitor!", "repo": "https://github.com/Amertos/PitwallPro", "demo": "https://amertos.github.io/PitwallPro/"}]...
|
[{"post_id": 29814, "ts": "202 [{"post_id": 29814, "ts": "2026-07-16T23:11:14Z", "hours": 0.9286, "text": "Dev Log: Pitwall Pro - Final Release## Final Project Polish & Publication Readiness- 3D Scene Integration : Successfully integrated the heavy F13DScene using React’s lazy and Suspense for optimized initial load times. Added a sleek SceneLoader fallback.- Playback & Performance Optimization : Refined the requestAnimationFrame based playback loop to ensure a buttery smooth 60fps experience when scrubbing through telemetry data. Memoized derived data to prevent unnecessary re-renders in the extensive component tree.- Comprehensive Feature Set Complete : All advanced panels are now fully functional, including the Tire Strategy Visualizer, Driver Head-to-Head, Race Timeline, and Session Comparison.- Keyboard Navigation Enhancements : Hardened the keyboard shortcut system to prevent interference with input fields while maintaining quick access to core functions like play/pause, seek, playback speed, and UI toggles.- UI/UX Refinements : Finalized the glass-panel aesthetics, responsive grid layouts, and the “live telemetry” indicator bar.- Data Generation : Finalized the Python scripts for generating realistic mock telemetry for robust demonstrations.The project is now structurally sound, visually impressive, and ready for public release on GitHub."}, {"post_id": 24604, "ts": "2026-07-08T10:02:30Z", "hours": 0.8531, "text": "🚀 Major Update — PitWall Pro just got a massive upgrade! A lot has changed since the last update. Over the past few days, PitWall Pro has evolved from a simple telemetry concept into a much more complete Formula 1 analysis experience. The dashboard has received a complete visual overhaul, bringing a cleaner, more modern, and more immersive interface inspired by real Formula 1 engineering systems. 🏎️ New improvements: ✨ Completely redesigned UI with a more professional racing aesthetic 📊 Improved telemetry visualization and data presentation 🗺️ Enhanced track map experience ⚡ Smoother interactions and better overall performance 🎯 More detailed race analysis capabilities 📱 Improved layout and responsiveness across different screen sizes 🔥 Added many new components and visual improvements throughout the application The goal of PitWall Pro has always been to bring the feeling of a real F1 pit wall into an interactive dashboard — turning complex racing data into insights that are easy to understand and analyze. This update is a huge step forward, but there is still a lot more coming. 🏁 More telemetry, more strategy tools, and more racing intelligence are on the way. Welcome to the new era of PitWall Pro. 🚥"}, {"post_id": 19459, "ts": "2026-06-30T19:46:24Z", "hours": 0.2794, "text": "PitWall Pro is an interactive, data-driven F1 telemetry and strategy dashboard designed to replicate the analytical power of a real Formula 1 pit wall. Built for racing enthusiasts and data analysts alike, the application transforms complex, high-frequency time-series racing data into clean, actionable visual insights."}]...
|
Title: PitWall Pro by @Amcoo | Stardance
Devlogs: Title: PitWall Pro by @Amcoo | Stardance
Devlogs:
PitWall Pro is an interactive, data-driven F1 telemetry and strategy dashboard designed to replicate the analytical power of a real Formula 1 pit wall. Built for racing enthusiasts and data analysts alike, the application transforms complex, high-frequency time-series racing data into clean, actionable visual insights.
🚀 Major Update — PitWall Pro just got a massive upgrade! A lot has changed since the last update. Over the past few days, PitWall Pro has evolved from a simple telemetry concept into a much more complete Formula 1 analysis experience. The dashboard has received a complete visual overhaul, bringing a cleaner, more modern, and more immersive interface inspired by real Formula 1 engineering systems. 🏎️ New improvements: ✨ Completely redesigned UI with a more professional racing aesthetic 📊 Improved telemetry visualization and data presentation 🗺️ Enhanced track map experience ⚡ Smoother interactions and better overall performance 🎯 More detailed race analysis capabilities 📱 Improved layout and responsiveness across different screen sizes 🔥 Added many new components and visual improvements throughout the application The goal of PitWall Pro has always been to bring the feeling of a real F1 pit wall into an interactive dashboard — turning complex racing data into insights that are easy to understand and analyze. This update is a huge step forward, but there is still a lot more coming. 🏁 More telemetry, more strategy tools, and more racing intelligence are on the way. Welcome to the new era of PitWall Pro. 🚥
Dev Log: Pitwall Pro - Final Release## Final Project Polish & Publication Readiness- 3D Scene Integration : Successfully integrated the heavy F13DScene using React’s lazy and Suspense for optimized initial load times. Added a sleek SceneLoader fallback.- Playback & Performance Optimization : Refined the requestAnimationFrame based playback loop to ensure a buttery smooth 60fps experience when scrubbing through telemetry data. Memoized derived data to prevent unnecessary re-renders in the extensive component tree.- Comprehensive Feature Set Complete : All advanced panels are now fully functional, including the Tire Strategy Visualizer, Driver Head-to-Head, Race Timeline, and Session Comparison.- Keyboard Navigation Enhancements : Hardened the keyboard shortcut system to prevent interference with input fields while maintaining quick access to core functions like play/pause, seek, playback speed, and UI toggles.- UI/UX Refinements : Finalized the glass-panel aesthetics, responsive grid layouts, and the “live telemetry” indicator bar.- Data Generation : Finalized the Python scripts for generating realistic mock telemetry for robust demonstrations.The project is now structurally sound, visually impressive, and ready for public release on GitHub.
Ships:
What did you make? I built Pitwall Pro, an advanced, real-time Formula 1 telemetry and race strategy visualization dashboard. It’s designed to bring the complex, data-heavy environment of an F1 pitwall directly to your browser. It features a fully interactive 3D track visualization, live telemetry parsing (speed, gear, RPM, delta), head-to-head driver comparisons, and dynamic tire strategy simulators. What was challenging? Handling heavy streams of telemetry data while keeping the UI buttery smooth was a massive challenge. When rendering the 3D scene concurrently with dozens of live-updating Recharts components, the DOM initially struggled. I had to heavily optimize the application using requestAnimationFrame for a custom 60fps playback loop, aggressively memoize React components to prevent wasteful re-renders, and lazy-load the Three.js canvas. Syncing the 3D car positions perfectly with the 2D telemetry timeline took hours of complex math and state management. What are you proud of? I am incredibly proud of the UI/UX architecture. Achieving that “glassmorphism” dark-mode aesthetic while maintaining readability for dense datasets isn’t easy. The integration of keyboard shortcuts (Space to play, arrows to scrub, 1-4 for speed) makes the app feel like a native professional tool, not just a standard web page. Watching the 3D scene react instantly to the scrubbed telemetry timeline still feels magical every time I do it. What should people know so they can test your project? Hit Space to start the live telemetry playback! Use your keyboard to navigate like an engineer: 1-4 changes playback speed, L toggles lap times, and the Arrow keys let you scrub through the race data. Make sure to zoom into the telemetry charts to see the exact braking points, and click on the “Advanced Panels” to experiment with different tire strategy simulations. It’s fully responsive, but best experienced on a desktop monitor!...
|
1793134401.23044
|
1793220801.23044
|
|
20791
|
spark-tudu by @emb3rcia | Stardance
|
emb3rcia
|
1
|
10.73
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T15:38:01Z", "hours": 9.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made TUI app that organizes all your TODOs, FIXMEs etc into one place! Whole app is made in python with textual as TUI framework and rich for colored text. I also uploaded it to PyPI which was my first time doing that and made binary files for it for both windows and linux. I made it for Frictionless and my 3 major QoL improvements are: Organization of markers into one central place across whole project Easy export of these both in easy to read .md file and easy to scrape .json file that allows automation to be made in multi people projects like notifications for deadlines Open-in-editor feature which allows you to quickly open the file at selected marker in editor of your choice so you dont need to dig through file explorer to find this specific file", "repo": "https://github.com/emb3rcia/spark-tudu", "demo": "https://pypi.org/project/spark-tudu/"}]...
|
[{"post_id": 14419, "ts": "202 [{"post_id": 14419, "ts": "2026-06-23T15:23:51Z", "hours": 0.9356, "text": "Added option to run program with -h/–help argument that explains how to run this command and use syntax. Also added option to specify path in which it will be scanned. Also added option to add/change existing file extensions scanned in config"}, {"post_id": 13757, "ts": "2026-06-22T15:28:04Z", "hours": 0.3761, "text": "Added information about scanned file extensions and how to use comments (must be in new line)"}, {"post_id": 12360, "ts": "2026-06-20T05:08:50Z", "hours": 0.4172, "text": "Fixed f-string parsing on python 3.11, now it won’t crash when installing/running on this version. Nothing else, i packaged it again to pip, built binary for linux and when i get home i will add exe for windows and submit it for recert on stardance website. It was error that wasnt showing on my side as i am using python 3.12 which uses PEP 701 for parser that allows use of the same type of quotes (either “” or ‘’) in {} section of program if i understand correctly."}, {"post_id": 11339, "ts": "2026-06-18T15:28:59Z", "hours": 0.5892, "text": "I uploaded package to PyPI and built binaries for linux and windows and added them to github release."}, {"post_id": 11231, "ts": "2026-06-18T11:49:06Z", "hours": 0.6517, "text": "I added popups shown while exporting results and made better deadline handling!"}, {"post_id": 11212, "ts": "2026-06-18T11:01:27Z", "hours": 1.9464, "text": "Added export and filtering options. Export is currently supported to .md and .json files. Filter is used for markers shown in the left bottom corner. I used ai for troubleshooting. Now i am going to add better deadline handling and add check if there is marker for open in editor option so it dont crash"}, {"post_id": 10623, "ts": "2026-06-17T14:01:28Z", "hours": 1.4431, "text": "Added opening in editor, config file with editor command and behavior, used AI for troubleshooting. I also added priorities to the syntax and updated README.md Biggest issue was how to make running editor work on MacOS, Linux and Windows. ChatGPT suggested the solution i used but i tested it only on linux. Feel free to test it on windows or mac os and give me information about it working on slack or discord (discord: emb3rcia, slack id: U095RD2NX8F slack username: emb3rcia)"}, {"post_id": 10586, "ts": "2026-06-17T12:16:03Z", "hours": 4.1128, "text": "I made MVP of app, added more markers and made marker type text colored! It was fairly easy, even though I never used Textual before, as their docs are very good. Now i will work on adding priorities to syntax and next opening file with specific line selected in editor of your choice."}]...
|
Title: spark-tudu by @emb3rcia | Stardance
Devlog Title: spark-tudu by @emb3rcia | Stardance
Devlogs:
I made MVP of app, added more markers and made marker type text colored! It was fairly easy, even though I never used Textual before, as their docs are very good. Now i will work on adding priorities to syntax and next opening file with specific line selected in editor of your choice.
Added opening in editor, config file with editor command and behavior, used AI for troubleshooting. I also added priorities to the syntax and updated README.md Biggest issue was how to make running editor work on MacOS, Linux and Windows. ChatGPT suggested the solution i used but i tested it only on linux. Feel free to test it on windows or mac os and give me information about it working on slack or discord (discord: emb3rcia, slack id: U095RD2NX8F slack username: emb3rcia)
Added export and filtering options. Export is currently supported to .md and .json files. Filter is used for markers shown in the left bottom corner. I used ai for troubleshooting. Now i am going to add better deadline handling and add check if there is marker for open in editor option so it dont crash
I added popups shown while exporting results and made better deadline handling!
I uploaded package to PyPI and built binaries for linux and windows and added them to github release.
Fixed f-string parsing on python 3.11, now it won’t crash when installing/running on this version. Nothing else, i packaged it again to pip, built binary for linux and when i get home i will add exe for windows and submit it for recert on stardance website. It was error that wasnt showing on my side as i am using python 3.12 which uses PEP 701 for parser that allows use of the same type of quotes (either “” or ‘’) in {} section of program if i understand correctly.
Added information about scanned file extensions and how to use comments (must be in new line)
Added option to run program with -h/–help argument that explains how to run this command and use syntax. Also added option to specify path in which it will be scanned. Also added option to add/change existing file extensions scanned in config
Ships:
I made TUI app that organizes all your TODOs, FIXMEs etc into one place! Whole app is made in python with textual as TUI framework and rich for colored text. I also uploaded it to PyPI which was my first time doing that and made binary files for it for both windows and linux. I made it for Frictionless and my 3 major QoL improvements are: Organization of markers into one central place across whole project Easy export of these both in easy to read .md file and easy to scrape .json file that allows automation to be made in multi people projects like notifications for deadlines Open-in-editor feature which allows you to quickly open the file at selected marker in editor of your choice so you dont need to dig through file explorer to find this specific file...
|
1793224057.3277566
|
1793310457.3277566
|
|
20801
|
SHADOW JUMP by @samriddhjoneja | Stardance
|
samriddhjoneja
|
1
|
5.0
|
41
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-28T18:37:00Z", "hours": 5.0, "multiplier": 8.2, "payout": 41, "blessing": "neutral", "text": "An adaptation of brackeys platformer tutorial, pls note that only assets are imported while the gameplay is very different. this is NOT an imitation or direct copy of the game . (u can teleport and stuff and u have to clear 3 levels with all coins). WASD to move and E to teleport or phase within blocks", "repo": "https://github.com/sj6258/SHADOW-JUMP", "demo": "https://sj6258.itch.io/shadow-jump"}]...
|
[{"post_id": 17776, "ts": "202 [{"post_id": 17776, "ts": "2026-06-28T18:27:10Z", "hours": 1.3681, "text": "edited the main screen. added a settings button which can control music volume and toggle fullscreen, added a back button by pressing esc to quit the game. changed the main menu UI design a bit"}, {"post_id": 12431, "ts": "2026-06-20T09:08:31Z", "hours": 0.9758, "text": "added nature and greenery to the scene . made the button and changed home screen design. imported portal to change the button in the level to get back to the home screen. modded the difficulty of the levels . completed overall level 3 and home screen design"}, {"post_id": 12000, "ts": "2026-06-19T16:06:21Z", "hours": 1.7467, "text": "completed labels and coins. changed the mechanics a bit added enemies fixed a bug where enemy would stay in place at the corner. added the score keeper at the end of the level"}, {"post_id": 10587, "ts": "2026-06-17T12:22:55Z", "hours": 0.8781, "text": "started level 3.made the base level tested it to modify the overall difficulty. fixed some older bugs where score from another level would appear."}]...
|
Title: SHADOW JUMP by @samriddhjoneja | Stardance
Title: SHADOW JUMP by @samriddhjoneja | Stardance
Devlogs:
started level 3.made the base level tested it to modify the overall difficulty. fixed some older bugs where score from another level would appear.
completed labels and coins. changed the mechanics a bit added enemies fixed a bug where enemy would stay in place at the corner. added the score keeper at the end of the level
added nature and greenery to the scene . made the button and changed home screen design. imported portal to change the button in the level to get back to the home screen. modded the difficulty of the levels . completed overall level 3 and home screen design
edited the main screen. added a settings button which can control music volume and toggle fullscreen, added a back button by pressing esc to quit the game. changed the main menu UI design a bit
Ships:
An adaptation of brackeys platformer tutorial, pls note that only assets are imported while the gameplay is very different. this is NOT an imitation or direct copy of the game . (u can teleport and stuff and u have to clear 3 levels with all coins). WASD to move and E to teleport or phase within blocks...
|
1793289350.1580057
|
1793375750.1580057
|
|
20863
|
reFlow by @Aki | Stardance
|
Aki
|
1
|
5.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-26T11:45:46Z", "hours": 5.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Honestly a fun project to start with, was QUITE confusing (why math) at the beginning but turned quite fun at the end. Ngl, the hardest part was actually setting up directories and making stuff point at other stuff in the correct way rather than making the actual code (yes im dumb okay) and that took MOST of my time and wasn’t even logged (21h GONE) cuz i forgot to download the desktop application and the only time logged was in the AI debug sesh and inspos and rules in Chrome…. sadness.", "repo": "https://github.com/extension1/reFlow", "demo": "https://reflow-337435966196.asia-southeast1.run.app/"}]...
|
[{"post_id": 12254, "ts": "202 [{"post_id": 12254, "ts": "2026-06-20T00:42:01Z", "hours": 1.8578, "text": "reFlow Devlog 4 — pain & suffering++ long one, buckle up. also never posted devlog 3, so some of that’s folded in here. hour 13 (retroactive): hardware hijacking wanted the tunnel to interrogate your PC. hooked into the WebGL debug renderer extension for real GPU model strings (had to regex out ANGLE’s prefix junk), navigator.hardwareConcurrency for core count, performance.memory for live JS heap, and the Battery API for charge state. built a perf tracker timing the physics loop per frame — if it blows the 16ms budget, System Stress flips to CRITICAL with specific diagnoses like “Low Core Alert” instead of just “it’s lagging.” hour 17: the great physics divorce the entire physics engine was crammed inside Three.js’s render loop in WindTunnel.tsx. worked at 10k particles, died at 30k+ — browser froze, laptop got loud. ripped every physics function into a standalone physics.ts — pure math, zero Three.js imports, just numbers in and out. took two hours of replacing Vector3.set() calls with raw tuples and hand-rolled rotation matrices. hour 18: web workers enter the chat moved the whole particle loop off the main thread into a Web Worker via Vite’s one-line worker syntax. main thread sends position/velocity/color arrays, worker crunches 40k particles, sends them back. UI never freezes. used Transferable objects so arrays move by ownership transfer instead of getting copied every frame. added a main-thread fallback if workers fail to load. hour 19: the wake was lying to me old turbulence was just Math.sin() — predictable, periodic, fake. replaced with hash-based pseudo-random noise for organic chaos, added von Kármán vortex shedding behind bluff bodies (alternating vortex pairs, like lampposts oscillating in wind), and a no-slip boundary layer so particles slow down near surfaces instead of just bouncing. hour 20: the car was ugly and the flat plate was a brick car was a 2D extruded polygon that looked like a cheese wedge. rebuilt with bezier/quadratic curves for a real windshield, roofline, and spoiler lip, plus wheel arch cutouts. flat plate was basically a cutting board (BoxGeometry(0.3, 5.8, 5.8)) — thinned to 0.08 with beveled edges so it actually reads as a plate. hour 21: torus goes brrr torus was hardcoded. added live sliders for major radius (1.5–6.0) and minor radius (0.3–2.5) that rebuild the geometry AND feed the physics engine in real time. thin ring = ethereal vortex shedding, chonky donut = half-blocked tunnel. added an R/r ratio readout because it sounds smart. hour 22: the sidebar was eating my screen between left controls, right diagnostics, a bottom chart/AI panel, and a header full of badges, the 3D canvas shrank to a postage stamp. added collapsible panels — chevron toggles collapse the sidebars to thin strips and the canvas reclaims ~80% of the screen. sometimes the best feature is removing stuff. hour 23: the absolute madman feature (GLB loader) end of devlog 3 I said “maybe a glTF loader, we’ll see.” we saw. you can now upload any .glb/.gltf, and the app auto-scales/centers it, then voxelizes it — shoots rays through a 48×48×48 grid, counts intersections, and marks solid vs. air. physics engine uses that voxel grid for collisions. not physically perfect, but you can drop in a Stanford bunny and watch particles flow around its ears. file count went from 2 source files to 5. physics.ts alone is 731 lines of math. wrote more linear algebra this week than my whole school career. up next: markdown rendering for AI reports, and fixing the README’s leftover “YOUR_USERNAME” placeholders before anyone notices."}, {"post_id": 11360, "ts": "2026-06-18T16:00:42Z", "hours": 0.81, "text": "reFlow Devlog #2 - moar suffering!!!! round two. we are back. the wind tunnel is no longer just a 3d playground; it’s a quantum control deck. here is how i spent the last few hours losing sleep over perspective cameras, slice projection math, and custom state toggle controls. hour 7: the flatland incursion (toggling 2d slice mode) why turn a 3d tunnel back to 2d? because aerodynamics is all about cross-sections. how to constrain a 3d particle swarm to 2d without a total refactor: when “is2D” is true, we hijack the particle spawner. instead of spreading particles across x-axis depth, we force positions[idx] = (Math.random() - 0.5) * 0.1, wrapping the flow into a super thin sheet at x = 0. we also restricted the smoke line emitters to a vertical slice. the result looks like a clean laser-cut sheet of wind passing through the wing. (not really, but it’s the thought that counts) hour 8: camera capture and control hijacking particles are in 2d, but the camera still rotates in 3d. rotating it breaks the illusion (just a flat sheet of dots). solution: camera hijacking. when 2d mode triggers, we fly the camera to (38, 0, 0) looking down the x-axis at the wing. we disable OrbitControls rotation (controls.enableRotate = false) and force camera.up.set(0, 1, 0). debugging this was a nightmare—OrbitControls flips the camera if target/up vectors aren’t updated first. now, swapping dimensions is smooth. hour 9: freezing time (the pause engine) sometimes wind moves too fast to see gradients. we need a freeze-frame. added “isPaused” state. first try: skip the animate loop. but that froze the rendering, stopping camera rotation. second try: keep the rendering loop active, but bypass particle position updates. now you can pause, orbit in 3d, and inspect smoke streams and vectors suspended in amber. sci-fi vibes. hour 10: tuning the storm (particle customizability) default 6,000 particles is cool, but my GPU was barely breaking a sweat. expanded particle count up to 20,000 (step 1000) and added a size slider (0.1 to 1.5). adjusting particle size from tiny dust specks to fat plasma spheres is satisfying. setting count to 20,000 makes the wind tunnel look like a dense gas nebula. the cpu is sweating, but performance is smooth thanks to typed buffer array updates. hour 11: cyberpunk telemetry deck (hud overhaul) with new toggleable states (2d/3d and pause/play), the dashboard needed a facelift. built a cyber-cyan “Switch 2D” button with custom ambient glow shadows (shadow-[0_0_15px_rgba(125,249,255,0.15)]) and a yellow pause button changing to play icon. added a footer telemetry status pill showing “2D Slice | [Active Object]” vs “3D Space | [Active Object]”. makes the app feel like a high-budget engineering interface. hour 12: collision math strikes back (local normals) particles clipped through spherical and box obstacles due to lazy velocity mirroring. introduced a robust getNormalLocal(type, x, y, z) helper. when a particle collides with a sphere, we calculate the exact radial normal: (x/r, y/r, z/r). for box geometry, the helper evaluates which face was breached (min === dx logic) and returns an axis normal. now particles bounce and slide off physical bodies with realistic deflection vectors. no more ghosting. next up: actually making the visuals work (someone send help)"}, {"post_id": 10728, "ts": "2026-06-17T16:39:49Z", "hours": 2.4094, "text": "reFlow Devlog 1 - building a 3d wind tunnel without losing my mind (?) enjoy my suffering. hour 1: the “it’s not that hard” phase decided on: react, three.js, and tailwind css. getting three.js to render took half an hour because i forgot lights. stared at a pitch black void wondering why my life is like this. finally got a grey cube spinning. les go spinny coob hour 2: wikipedia math is scary goal: make an airfoil (wing shape). searched “naca airfoil math formula” and got hit with an abomination of an equation: yt = 5 * t * (0.2969 * sqrt(x) - 0.1260 * x - 0.3516 * x^2 + 0.2843 * x^3 - 0.1015 * x^4). wouldn’t have signed up if i knew math was involved. translated it into a javascript loop generating a THREE.Shape. my eyes watered staring at parentheses. messed up the loop direction 3 times and made twisted metal instead of a wing. had to scale it up cuz default was microscopic. after 4 tries, it looks like a wing. LETS GOOO hour 3: the wind has to blow made a particle system with 6,000 points. spawn at front, move back, respawn. easy, but particles must bend around the wing. wrote a collision loop. first draft: particles got stuck, formed a massive blue blob. second draft: calculated slope. particles flew off at 90-degree angles. coded a simplified double-flow vector calc. not real CFD (my laptop would explode running Navier-Stokes), but it looks real. hour 4: adding cool dashboards app needed to look like a telemetry deck. added: sidebar with sliders for viscosity, inlet speed, angle of attack. custom html5 canvas real-time graph. draws lift (cyan) and drag (orange) lines. legit math at home guys. pressure heatmap. flat vertical plane in center. slow air hitting nose = high pressure (RED). fast air over top = low pressure (NEON GREEN). tilting the wing shifts the red spot. ASMR for the eyes wooooo hour 5: stall warning and ai pilot added stall physics! over 15deg tilt, lift cuts by 70% and drag multiplies. added a flashing CRITICAL STALL WARNING banner. integrated Gemini API for aero reports then realized this comp requires no auth, so api keys are prolly an issue. wrote a local backup expert system. no API key = runs generateLocalReport() with rule-based templates. 100% plug-and-play. hour 6: single-file challenge wanted app super portable. one .html file. vite/tailwind output to .js and .css. wrote bundle.js to inline them which ended up giving “ReferenceError: require is not defined in ES module scope.” bruh. renamed it to bundle.cjs and that worked yay btw throwing html into google AI studio gets a free hosted site?? the more you know i guess lots of math still broken lol. coolest project i’ve built though. going to sleep for a week."}]...
|
Title: reFlow by @Aki | Stardance
Devlogs:
reFlow Title: reFlow by @Aki | Stardance
Devlogs:
reFlow Devlog 1 - building a 3d wind tunnel without losing my mind (?) enjoy my suffering. hour 1: the “it’s not that hard” phase decided on: react, three.js, and tailwind css. getting three.js to render took half an hour because i forgot lights. stared at a pitch black void wondering why my life is like this. finally got a grey cube spinning. les go spinny coob hour 2: wikipedia math is scary goal: make an airfoil (wing shape). searched “naca airfoil math formula” and got hit with an abomination of an equation: yt = 5 * t * (0.2969 * sqrt(x) - 0.1260 * x - 0.3516 * x^2 + 0.2843 * x^3 - 0.1015 * x^4). wouldn’t have signed up if i knew math was involved. translated it into a javascript loop generating a THREE.Shape. my eyes watered staring at parentheses. messed up the loop direction 3 times and made twisted metal instead of a wing. had to scale it up cuz default was microscopic. after 4 tries, it looks like a wing. LETS GOOO hour 3: the wind has to blow made a particle system with 6,000 points. spawn at front, move back, respawn. easy, but particles must bend around the wing. wrote a collision loop. first draft: particles got stuck, formed a massive blue blob. second draft: calculated slope. particles flew off at 90-degree angles. coded a simplified double-flow vector calc. not real CFD (my laptop would explode running Navier-Stokes), but it looks real. hour 4: adding cool dashboards app needed to look like a telemetry deck. added: sidebar with sliders for viscosity, inlet speed, angle of attack. custom html5 canvas real-time graph. draws lift (cyan) and drag (orange) lines. legit math at home guys. pressure heatmap. flat vertical plane in center. slow air hitting nose = high pressure (RED). fast air over top = low pressure (NEON GREEN). tilting the wing shifts the red spot. ASMR for the eyes wooooo hour 5: stall warning and ai pilot added stall physics! over 15deg tilt, lift cuts by 70% and drag multiplies. added a flashing CRITICAL STALL WARNING banner. integrated Gemini API for aero reports then realized this comp requires no auth, so api keys are prolly an issue. wrote a local backup expert system. no API key = runs generateLocalReport() with rule-based templates. 100% plug-and-play. hour 6: single-file challenge wanted app super portable. one .html file. vite/tailwind output to .js and .css. wrote bundle.js to inline them which ended up giving “ReferenceError: require is not defined in ES module scope.” bruh. renamed it to bundle.cjs and that worked yay btw throwing html into google AI studio gets a free hosted site?? the more you know i guess lots of math still broken lol. coolest project i’ve built though. going to sleep for a week.
reFlow Devlog #2 - moar suffering!!!! round two. we are back. the wind tunnel is no longer just a 3d playground; it’s a quantum control deck. here is how i spent the last few hours losing sleep over perspective cameras, slice projection math, and custom state toggle controls. hour 7: the flatland incursion (toggling 2d slice mode) why turn a 3d tunnel back to 2d? because aerodynamics is all about cross-sections. how to constrain a 3d particle swarm to 2d without a total refactor: when “is2D” is true, we hijack the particle spawner. instead of spreading particles across x-axis depth, we force positions[idx] = (Math.random() - 0.5) * 0.1, wrapping the flow into a super thin sheet at x = 0. we also restricted the smoke line emitters to a vertical slice. the result looks like a clean laser-cut sheet of wind passing through the wing. (not really, but it’s the thought that counts) hour 8: camera capture and control hijacking particles are in 2d, but the camera still rotates in 3d. rotating it breaks the illusion (just a flat sheet of dots). solution: camera hijacking. when 2d mode triggers, we fly the camera to (38, 0, 0) looking down the x-axis at the wing. we disable OrbitControls rotation (controls.enableRotate = false) and force camera.up.set(0, 1, 0). debugging this was a nightmare—OrbitControls flips the camera if target/up vectors aren’t updated first. now, swapping dimensions is smooth. hour 9: freezing time (the pause engine) sometimes wind moves too fast to see gradients. we need a freeze-frame. added “isPaused” state. first try: skip the animate loop. but that froze the rendering, stopping camera rotation. second try: keep the rendering loop active, but bypass particle position updates. now you can pause, orbit in 3d, and inspect smoke streams and vectors suspended in amber. sci-fi vibes. hour 10: tuning the storm (particle customizability) default 6,000 particles is cool, but my GPU was barely breaking a sweat. expanded particle count up to 20,000 (step 1000) and added a size slider (0.1 to 1.5). adjusting particle size from tiny dust specks to fat plasma spheres is satisfying. setting count to 20,000 makes the wind tunnel look like a dense gas nebula. the cpu is sweating, but performance is smooth thanks to typed buffer array updates. hour 11: cyberpunk telemetry deck (hud overhaul) with new toggleable states (2d/3d and pause/play), the dashboard needed a facelift. built a cyber-cyan “Switch 2D” button with custom ambient glow shadows (shadow-[0_0_15px_rgba(125,249,255,0.15)]) and a yellow pause button changing to play icon. added a footer telemetry status pill showing “2D Slice | [Active Object]” vs “3D Space | [Active Object]”. makes the app feel like a high-budget engineering interface. hour 12: collision math strikes back (local normals) particles clipped through spherical and box obstacles due to lazy velocity mirroring. introduced a robust getNormalLocal(type, x, y, z) helper. when a particle collides with a sphere, we calculate the exact radial normal: (x/r, y/r, z/r). for box geometry, the helper evaluates which face was breached (min === dx logic) and returns an axis normal. now particles bounce and slide off physical bodies with realistic deflection vectors. no more ghosting. next up: actually making the visuals work (someone send help)
reFlow Devlog 4 — pain & suffering++ long one, buckle up. also never posted devlog 3, so some of that’s folded in here. hour 13 (retroactive): hardware hijacking wanted the tunnel to interrogate your PC. hooked into the WebGL debug renderer extension for real GPU model strings (had to regex out ANGLE’s prefix junk), navigator.hardwareConcurrency for core count, performance.memory for live JS heap, and the Battery API for charge state. built a perf tracker timing the physics loop per frame — if it blows the 16ms budget, System Stress flips to CRITICAL with specific diagnoses like “Low Core Alert” instead of just “it’s lagging.” hour 17: the great physics divorce the entire physics engine was crammed inside Three.js’s render loop in WindTunnel.tsx. worked at 10k particles, died at 30k+ — browser froze, laptop got loud. ripped every physics function into a standalone physics.ts — pure math, zero Three.js imports, just numbers in and out. took two hours of replacing Vector3.set() calls with raw tuples and hand-rolled rotation matrices. hour 18: web workers enter the chat moved the whole particle loop off the main thread into a Web Worker via Vite’s one-line worker syntax. main thread sends position/velocity/color arrays, worker crunches 40k particles, sends them back. UI never freezes. used Transferable objects so arrays move by ownership transfer instead of getting copied every frame. added a main-thread fallback if workers fail to load. hour 19: the wake was lying to me old turbulence was just Math.sin() — predictable, periodic, fake. replaced with hash-based pseudo-random noise for organic chaos, added von Kármán vortex shedding behind bluff bodies (alternating vortex pairs, like lampposts oscillating in wind), and a no-slip boundary layer so particles slow down near surfaces instead of just bouncing. hour 20: the car was ugly and the flat plate was a brick car was a 2D extruded polygon that looked like a cheese wedge. rebuilt with bezier/quadratic curves for a real windshield, roofline, and spoiler lip, plus wheel arch cutouts. flat plate was basically a cutting board (BoxGeometry(0.3, 5.8, 5.8)) — thinned to 0.08 with beveled edges so it actually reads as a plate. hour 21: torus goes brrr torus was hardcoded. added live sliders for major radius (1.5–6.0) and minor radius (0.3–2.5) that rebuild the geometry AND feed the physics engine in real time. thin ring = ethereal vortex shedding, chonky donut = half-blocked tunnel. added an R/r ratio readout because it sounds smart. hour 22: the sidebar was eating my screen between left controls, right diagnostics, a bottom chart/AI panel, and a header full of badges, the 3D canvas shrank to a postage stamp. added collapsible panels — chevron toggles collapse the sidebars to thin strips and the canvas reclaims ~80% of the screen. sometimes the best feature is removing stuff. hour 23: the absolute madman feature (GLB loader) end of devlog 3 I said “maybe a glTF loader, we’ll see.” we saw. you can now upload any .glb/.gltf, and the app auto-scales/centers it, then voxelizes it — shoots rays through a 48×48×48 grid, counts intersections, and marks solid vs. air. physics engine uses that voxel grid for collisions. not physically perfect, but you can drop in a Stanford bunny and watch particles flow around its ears. file count went from 2 source files to 5. physics.ts alone is 731 lines of math. wrote more linear algebra this week than my whole school career. up next: markdown rendering for AI reports, and fixing the README’s leftover “YOUR_USERNAME” placeholders before anyone notices.
Ships:
Honestly a fun project to start with, was QUITE confusing (why math) at the beginning but turned quite fun at the end. Ngl, the hardest part was actually setting up directories and making stuff point at other stuff in the correct way rather than making the actual code (yes im dumb okay) and that took MOST of my time and wasn’t even logged (21h GONE) cuz i forgot to download the desktop application and the only time logged was in the AI debug sesh and inspos and rules in Chrome…. sadness....
|
1793260430.990943
|
1793346830.990943
|
|
20864
|
Revision Cards by @lando498 | Stardance
|
lando498
|
1
|
3.0
|
3
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-17T16:03:09Z", "hours": 3.0, "multiplier": 1.66, "payout": 3, "blessing": "neutral", "text": "I made a revision/ flashcards website where the user inputs up to 15 questions and answers that show on the card and the user answers in the text box below", "repo": "https://github.com/Lando498/Flashcards-app", "demo": "https://caffeinated.qzz.io/Flashcards-app/flashcards.html"}]...
|
[{"post_id": 10707, "ts": "202 [{"post_id": 10707, "ts": "2026-06-17T15:57:49Z", "hours": 0.2803, "text": "added numbers to each text field for clarity"}, {"post_id": 10683, "ts": "2026-06-17T15:25:36Z", "hours": 0.4464, "text": "bigger confetti and centred ui for different screen sizes"}, {"post_id": 10647, "ts": "2026-06-17T14:42:37Z", "hours": 0.3931, "text": "pretty major ui update (space!)"}, {"post_id": 10631, "ts": "2026-06-17T14:16:45Z", "hours": 2.1758, "text": "question and answers ui hidden"}]...
|
Title: Revision Cards by @lando498 | Stardance
De Title: Revision Cards by @lando498 | Stardance
Devlogs:
question and answers ui hidden
pretty major ui update (space!)
bigger confetti and centred ui for different screen sizes
added numbers to each text field for clarity
Ships:
I made a revision/ flashcards website where the user inputs up to 15 questions and answers that show on the card and the user answers in the text box below...
|
1793289332.553097
|
1793375732.553097
|
|
20873
|
My very own WebOS by @sirius | Stardance
|
sirius
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-11T06:04:15Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built SiriusOS, a space-themed WebOS with multiple interactive windows and five apps: About, Terminal, Stargazer, Notes, and Calculator. The hardest part was coordinating window dragging, focus, and z-index behavior. I am especially proud of the interactive Stargazer and the polished no-password welcome flow. Open the demo, press ENTER, then launch several desktop apps to test the window controls.", "repo": "https://github.com/SiriusW823/sirius-webos", "demo": "https://siriusw823.github.io/sirius-webos/"}]...
|
[{"post_id": 26413, "ts": "202 [{"post_id": 26413, "ts": "2026-07-11T06:00:48Z", "hours": 0.3806, "text": "Final QA and release check I completed a final browser QA pass on SiriusOS before shipping. Confirmed the welcome screen opens without a password Opened About, Terminal, Stargazer, Notes, and Calculator Verified multiple windows can stay open together Verified close, minimize, and maximize controls are present Confirmed the public GitHub Pages deployment loads correctly Checked the browser console and found no errors or warnings The custom space-themed interface and interactive Stargazer make this more than a copy of the guide. The project is now ready for mission review. Demo: https://siriusw823.github.io/sirius-webos/ Source: https://github.com/SiriusW823/sirius-webos"}, {"post_id": 16952, "ts": "2026-06-27T14:58:34Z", "hours": 1.2714, "text": "Added a README and polished the SiriusOS codebase today! What’s new: Wrote a full README.md for the GitHub repo — covers all features, tech stack, and how to run it locally Pushed to GitHub, repo now has a proper landing page with badges and a live demo link Cleaned up the window manager code — extracted drag logic into a reusable makeDraggable() helper Fixed a z-index bug where minimized windows could still intercept mouse events Improved the Stargazer app: constellation lines now render in a softer color so individual stars are easier to see The draggable window system is holding up really well — no flicker, smooth focus management. Next step is adding a File Manager app and a settings panel for theming!"}, {"post_id": 11302, "ts": "2026-06-18T14:22:32Z", "hours": 0.5403, "text": "今天開始建造 SiriusOS — 一個跑在瀏覽器裡的太空主題 WebOS！ 整個系統塞在單一 HTML 檔案裡，包含： 動態星空背景 + 登入畫面 視窗管理器（可拖曳、最小化、關閉） 5 個內建 App：About、Terminal、Stargazer 星座儀、Notes、Calculator Pomodoro 計時器 Terminal 支援指令歷史（↑↓ 鍵） 最大挑戰是做出真正可拖曳的視窗系統，要同時處理 z-index 焦點管理跟滑鼠事件。最後用原生 JS 的 mousedown/mousemove 解決了，不需要任何外部套件。 現在已經 deploy 到 GitHub Pages，明天繼續加更多功能！"}]...
|
Title: My very own WebOS by @sirius | Stardance
D Title: My very own WebOS by @sirius | Stardance
Devlogs:
今天開始建造 SiriusOS — 一個跑在瀏覽器裡的太空主題 WebOS！ 整個系統塞在單一 HTML 檔案裡，包含： 動態星空背景 + 登入畫面 視窗管理器（可拖曳、最小化、關閉） 5 個內建 App：About、Terminal、Stargazer 星座儀、Notes、Calculator Pomodoro 計時器 Terminal 支援指令歷史（↑↓ 鍵） 最大挑戰是做出真正可拖曳的視窗系統，要同時處理 z-index 焦點管理跟滑鼠事件。最後用原生 JS 的 mousedown/mousemove 解決了，不需要任何外部套件。 現在已經 deploy 到 GitHub Pages，明天繼續加更多功能！
Added a README and polished the SiriusOS codebase today! What’s new: Wrote a full README.md for the GitHub repo — covers all features, tech stack, and how to run it locally Pushed to GitHub, repo now has a proper landing page with badges and a live demo link Cleaned up the window manager code — extracted drag logic into a reusable makeDraggable() helper Fixed a z-index bug where minimized windows could still intercept mouse events Improved the Stargazer app: constellation lines now render in a softer color so individual stars are easier to see The draggable window system is holding up really well — no flicker, smooth focus management. Next step is adding a File Manager app and a settings panel for theming!
Final QA and release check I completed a final browser QA pass on SiriusOS before shipping. Confirmed the welcome screen opens without a password Opened About, Terminal, Stargazer, Notes, and Calculator Verified multiple windows can stay open together Verified close, minimize, and maximize controls are present Confirmed the public GitHub Pages deployment loads correctly Checked the browser console and found no errors or warnings The custom space-themed interface and interactive Stargazer make this more than a copy of the guide. The project is now ready for mission review. Demo: https://siriusw823.github.io/sirius-webos/ Source: https://github.com/SiriusW823/sirius-webos
Ships:
I built SiriusOS, a space-themed WebOS with multiple interactive windows and five apps: About, Terminal, Stargazer, Notes, and Calculator. The hardest part was coordinating window dragging, focus, and z-index behavior. I am especially proud of the interactive Stargazer and the polished no-password welcome flow. Open the demo, press ENTER, then launch several desktop apps to test the window controls....
|
1793267623.0115407
|
1793354023.0115407
|
|
20890
|
P99 by @takumi1612 | Stardance
|
takumi1612
|
1
|
3.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-30T17:35:30Z", "hours": 3.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "A Program to encode file A into lossless media files like png and wav to hide the file B whilst keeping the media file looking unsuspicous.", "repo": "https://github.com/MrHunor/P99", "demo": "https://github.com/MrHunor/P99/releases/latest"}]...
|
[{"post_id": 58283, "ts": "202 [{"post_id": 58283, "ts": "2026-08-30T17:28:40Z", "hours": 2.0303, "text": "Finished audio functionality and implemented filesze checking"}, {"post_id": 16888, "ts": "2026-06-27T12:37:20Z", "hours": 1.4464, "text": "Partly finished including .wav functionality (files for now)"}]...
|
Title: P99 by @takumi1612 | Stardance
Devlogs:
Pa Title: P99 by @takumi1612 | Stardance
Devlogs:
Partly finished including .wav functionality (files for now)
Finished audio functionality and implemented filesze checking
Ships:
A Program to encode file A into lossless media files like png and wav to hide the file B whilst keeping the media file looking unsuspicous....
|
1793245832.871479
|
1793332232.871479
|
|
20896
|
Mr.BentOver by @Adarsh | Stardance
|
Adarsh
|
1
|
6.0
|
33
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-21T06:06:05Z", "hours": 6.0, "multiplier": 5.17, "payout": 33, "blessing": "neutral", "text": "This is my fun project so i build this project for fun and this is a bentover this reads our discord conversation and its judges in a GIF and we can call him by $Bentover . The hardest part building was a import override and also deployement", "repo": "https://github.com/stairmoss/Mr.BentOver", "demo": "https://discord.com/oauth2/authorize?client_id=1550551463011287100&permissions=274878114816&integration_type=0&scope=bot"}]...
|
[{"post_id": 70614, "ts": "202 [{"post_id": 70614, "ts": "2026-09-19T13:42:01Z", "hours": 0.4358, "text": "added requirements.txt and Readme file"}, {"post_id": 70566, "ts": "2026-09-19T11:32:20Z", "hours": 1.6689, "text": "integrated discord to the project and made all the things working . in the way there were many bugs and error and i solved with using AI gemini guidance"}, {"post_id": 70176, "ts": "2026-09-18T16:54:28Z", "hours": 1.7661, "text": "so i finished the terminal version of bentover and now i have to connect to the discord bot and also i got a huge error and i got confused and it took so much time to solve it was .. [ ImportError: cannot import name ‘get_gif’ from partially initialized module ‘Gif_search’ (most likely due to a circular import) ]"}, {"post_id": 69972, "ts": "2026-09-18T04:36:42Z", "hours": 2.5331, "text": "made the the AI to decide the search phrase of the conversation but its on terminal and not interated with the dicord"}]...
|
Title: Mr.BentOver by @Adarsh | Stardance
Devlogs Title: Mr.BentOver by @Adarsh | Stardance
Devlogs:
made the the AI to decide the search phrase of the conversation but its on terminal and not interated with the dicord
so i finished the terminal version of bentover and now i have to connect to the discord bot and also i got a huge error and i got confused and it took so much time to solve it was .. [ ImportError: cannot import name ‘get_gif’ from partially initialized module ‘Gif_search’ (most likely due to a circular import) ]
integrated discord to the project and made all the things working . in the way there were many bugs and error and i solved with using AI gemini guidance
added requirements.txt and Readme file
Ships:
This is my fun project so i build this project for fun and this is a bentover this reads our discord conversation and its judges in a GIF and we can call him by $Bentover . The hardest part building was a import override and also deployement...
|
1793148713.914223
|
1793235113.914223
|
|
20900
|
Frictionless by @Basit | Stardance
|
Basit
|
1
|
27.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-24T19:39:23Z", "hours": 27.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a jarvis AI system, my only challenges was hardware due to the fact i was useing a 4gb ram chromebook, it can do various of stuff it was made in python useing linux.", "repo": "https://github.com/grubasit1/J.A.R.V.I.S", "demo": "https://grubasit1.github.io/Jarvis/?t=4"}]...
|
[{"post_id": 34244, "ts": "202 [{"post_id": 34244, "ts": "2026-07-24T19:37:03Z", "hours": 24.0003, "text": "I did some extra refining it took a long time but i made jarvis before i found stardance so i lost a lot of hours."}, {"post_id": 13683, "ts": "2026-06-22T13:11:33Z", "hours": 3.0303, "text": "Building an AI chatbot widget for my freelance portfolio. Embeddable on any site, powered by Gemini 2.0 Flash — conversation memory, typing animations, and responsive design. Single-file, no frameworks. Part of my J.A.R.V.I.S project (7,200+ lines across 25 files, 53+ hours of development — most untracked before I set up Hackatime)."}]...
|
Title: Frictionless by @Basit | Stardance
Devlogs Title: Frictionless by @Basit | Stardance
Devlogs:
Building an AI chatbot widget for my freelance portfolio. Embeddable on any site, powered by Gemini 2.0 Flash — conversation memory, typing animations, and responsive design. Single-file, no frameworks. Part of my J.A.R.V.I.S project (7,200+ lines across 25 files, 53+ hours of development — most untracked before I set up Hackatime).
I did some extra refining it took a long time but i made jarvis before i found stardance so i lost a lot of hours.
Ships:
I made a jarvis AI system, my only challenges was hardware due to the fact i was useing a 4gb ram chromebook, it can do various of stuff it was made in python useing linux....
|
1793285287.4533167
|
1793371687.4533167
|
|
20957
|
About Me Website by @Crizer | Stardance
|
Crizer
|
1
|
22.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-23T19:26:43Z", "hours": 22.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I have made a about me website just to get some practice on html, css, and js to show off what I enjoy and my hobbies.", "repo": "https://github.com/JohnleeVy/mywebsite", "demo": "https://crizer.dingusblingus.cc/"}]...
|
[{"post_id": 33654, "ts": "202 [{"post_id": 33654, "ts": "2026-07-23T19:00:12Z", "hours": 11.1275, "text": "This is such a late dev log but I have been mostly finishing up website and everything I wanted to add to the site it self. So I have finished all the sub section of my site where which are my interest. the reason i haven’t posted in such a long time was I forgot about this and I was mostly enthralled working on my website and nothing else and while having that insane passion I learned some javascript and used them for the retro media part of the website to play the music in the background and have it loop as well and with the music page with it having api access for both my lastfm account and my local music server hosted on the same machine to play what im listening and the stats of what im listening to. This has been very fun experience to learn all this stuff"}, {"post_id": 19595, "ts": "2026-06-30T23:03:14Z", "hours": 10.5694, "text": "I spent a lot of time learning how html and css works and setup certain parts of my website. I have finished my front page but I want to add more and there are other parts of my website that goes more in depth into what I am into currently working on my music section of interest and understanding css with animated backgrounds"}]...
|
Title: About Me Website by @Crizer | Stardance
De Title: About Me Website by @Crizer | Stardance
Devlogs:
I spent a lot of time learning how html and css works and setup certain parts of my website. I have finished my front page but I want to add more and there are other parts of my website that goes more in depth into what I am into currently working on my music section of interest and understanding css with animated backgrounds
This is such a late dev log but I have been mostly finishing up website and everything I wanted to add to the site it self. So I have finished all the sub section of my site where which are my interest. the reason i haven’t posted in such a long time was I forgot about this and I was mostly enthralled working on my website and nothing else and while having that insane passion I learned some javascript and used them for the retro media part of the website to play the music in the background and have it loop as well and with the music page with it having api access for both my lastfm account and my local music server hosted on the same machine to play what im listening and the stats of what im listening to. This has been very fun experience to learn all this stuff
Ships:
I have made a about me website just to get some practice on html, css, and js to show off what I enjoy and my hobbies....
|
1793130735.0324388
|
1793217135.0324388
|
|
20987
|
Pancake FRC Turret by @strixt | Stardance
|
strixt
|
1
|
46.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-17T23:35:12Z", "hours": 46.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I cadded an FRC Turret designed around the 2026 game REBUILT. This project started off as a personal project, just a cad but after I finished I convinced my team to let me build it but I shipped it now because the parts will come after stardance :(. Everything you need to know about this turret is in the google doc below: https://docs.google.com/document/d/19otRmG-d0zHCSDyZ5glDNmW7cP3afZkpb5Q3BmI4kPE/edit?tab=t.0 (P.S. to the mod reading this is it possible i can get my hours back? I didnt know that you had to devlog every 10 hours)", "repo": "https://github.com/strixt1/FRC-Pancake-Style-Turret-", "demo": ""}]...
|
[{"post_id": 49492, "ts": "202 [{"post_id": 49492, "ts": "2026-08-18T11:07:52Z", "hours": 40.1572, "text": "Its been a long time huh. I basically finished the whole thing, however to catch yall up to speed I have created the ultimate devlog. PLS look at this google doc if you can. I made a whole essentially an ESSAY trying to make a recap with at most info as needed but its too long to post so here is the google doc with it in https://docs.google.com/document/d/19otRmG-d0zHCSDyZ5glDNmW7cP3afZkpb5Q3BmI4kPE/edit?tab=t.0 4"}, {"post_id": 27641, "ts": "2026-07-13T12:19:20Z", "hours": 5.3853, "text": "The Turret Sketch of everything is complete. Turret Gearing: The turret gearing is geared to 1:56.25, powered by one kraken x44. The turret is supported by 4 box tubes (2 1x1 and 2 2x1) Shooter Geometry: Using very similar to team 4414. 3 inch flywheel/ stealth wheel with a 1 inch sushi roller on the other side powered 1:1 by 2 kraken x60s. 1 inch compression between the roller and the flywheel. Bottom bearing is an 8 inch bearing for dye rotor. Wiring: Wiring a turret can be difficult, since no slip ring means no free rotation. That’s why I have this e-chain. This allows the turret to spin a 360 full rotation before spinning back. the e-chain is constantly tensioned with an 8 lb spring to help it reset its position when the turret needs it"}]...
|
Title: Pancake FRC Turret by @strixt | Stardance
Title: Pancake FRC Turret by @strixt | Stardance
Devlogs:
The Turret Sketch of everything is complete. Turret Gearing: The turret gearing is geared to 1:56.25, powered by one kraken x44. The turret is supported by 4 box tubes (2 1x1 and 2 2x1) Shooter Geometry: Using very similar to team 4414. 3 inch flywheel/ stealth wheel with a 1 inch sushi roller on the other side powered 1:1 by 2 kraken x60s. 1 inch compression between the roller and the flywheel. Bottom bearing is an 8 inch bearing for dye rotor. Wiring: Wiring a turret can be difficult, since no slip ring means no free rotation. That’s why I have this e-chain. This allows the turret to spin a 360 full rotation before spinning back. the e-chain is constantly tensioned with an 8 lb spring to help it reset its position when the turret needs it
Its been a long time huh. I basically finished the whole thing, however to catch yall up to speed I have created the ultimate devlog. PLS look at this google doc if you can. I made a whole essentially an ESSAY trying to make a recap with at most info as needed but its too long to post so here is the google doc with it in https://docs.google.com/document/d/19otRmG-d0zHCSDyZ5glDNmW7cP3afZkpb5Q3BmI4kPE/edit?tab=t.0 4
Ships:
I cadded an FRC Turret designed around the 2026 game REBUILT. This project started off as a personal project, just a cad but after I finished I convinced my team to let me build it but I shipped it now because the parts will come after stardance :(. Everything you need to know about this turret is in the google doc below: https://docs.google.com/document/d/19otRmG-d0zHCSDyZ5glDNmW7cP3afZkpb5Q3BmI4kPE/edit?tab=t.0 (P.S. to the mod reading this is it possible i can get my hours back? I didnt know that you had to devlog every 10 hours)...
|
1793152209.7051518
|
1793238609.7051518
|
|
21003
|
Iss tracker by @huncikoma | Stardance
|
huncikoma
|
1
|
21.0
|
245
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-10T16:56:38Z", "hours": 21.0, "multiplier": 11.84, "payout": 245, "blessing": "neutral", "text": "I make a real-time ISS tracker with a 3D globe. It shows the station’s live position, altitude, speed and whether it’s sunlit — plus it predicts when the ISS will be visible with the naked eye from your location in the next 6 days. It also shows who’s currently aboard. All the orbital math (SGP4) runs locally with satellite.js, the 3D globe is globe.gl. What was challenging?-Pretty much everything — this is my first web project ever. I’m a Python guy, so I had to learn the whole thing from the ground up: HTML, CSS, JavaScript, all of it. None of this existed in my toolbox before this project. The hardest part by far was the pass prediction: look angles, ECI to ECF conversion, checking if the ISS is sunlit while your sky is dark. Actual orbital mechanics. I used AI as a tutor along the way, but I made sure I understood every part instead of just pasting code. I am proud of that the pass prediction actually works — three conditions lining up (ISS above 10°, sun 6° below your horizon, station still in sunlight) and it tells you exactly when to look up. Also the “mission control” design, built from scratch with CSS variables. And honestly: that as a Python-only dev I had to learn an entirely new stack for this, and it actually came together. From barely knowing what a div is to this, in a few weeks. To test it: Just run start.bat (it starts a small Python webserver and opens the app) — or open the demo URL. Click “Use my location” or type coordinates manually, and the visible passes table fills in. Try the Follow/Rotate camera modes and the Day/Night texture toggle too. Details in the README.", "repo": "https://github.com/huncikoma-code/Iss-tracker", "demo": "https://huncikoma-code.github.io/Iss-tracker/"}]...
|
[{"post_id": 26009, "ts": "202 [{"post_id": 26009, "ts": "2026-07-10T16:00:47Z", "hours": 4.5603, "text": "Devlog #10 — Crew, startup & it’s doneLast pieces today.Crew section first. Pulls from the Open Notify API — who’s on the ISS right now. Had to route it through a CORS proxy because the API is http-only and browsers block that from an https page. Filters for ISS crew specifically, falls back to everyone in space if the filter comes up empty. If the API dies, shows a graceful “unavailable” message instead of breaking.Then the startup section — the part that boots everything. Load saved observer location, fetch TLE, fetch crew, then the intervals: tick() every second, orbit path refresh every minute, fresh TLE every 2 hours, crew every 6 hours. Everything on its own schedule.Finally made it actually easy to run. Wrote a small Python server file that spins up a local webserver — this is where my Python comfort zone finally got to shine in this project. Plus a start.bat that launches the server and opens the app in the browser in one double-click. And a README so anyone can figure out how to run it.That’s it. The tracker is done. Live position, 3D globe, pass predictions, crew list, one-click startup. Started this barely knowing what a div was."}, {"post_id": 25798, "ts": "2026-07-10T08:19:42Z", "hours": 2.5208, "text": "Devlog #9 — Pass predictionThe part I was most scared of. Also the coolest.computePasses() steps through the next 6 days in 30-second jumps, calculates the ISS position at each step, and converts it to look angles from your location. Elevation above 10° = pass starts. Drops below = pass ends.The visibility check is the fun part. You can only see the ISS with your own eyes if three things line up: it’s above 10°, the sun is 6°+ below your horizon , but the ISS up there is still catching sunlight. Basically a sunlit object against a dark sky. That’s what you’re actually seeing.Also finished the geolocation button, the reverse geocoding for your city name, and the pass table — time, duration, max elevation, compass direction. Visible passes get an orange dot.Deepest I’ve been in over my head this whole project. But piece by piece, it makes sense now."}, {"post_id": 25208, "ts": "2026-07-09T09:57:40Z", "hours": 3.0786, "text": "Devlog #8 — TLE age, observer location & localStorageShort but important session.First, finished off the tick() function. Added TLE age display — shows how old the orbital data is. Under an hour it shows minutes, over an hour it shows decimal hours. Small detail but useful, stale TLE data means inaccurate position.Then observer location. This took a bit of thinking. The app needs to know where you are to predict ISS passes — so setObserver() takes lat/lng, validates it (no infinite values, lat within ±90, lng within ±180), converts to radians for the math, and stores it.The localStorage part was new territory for me. Never used it before. Basically the browser remembers your location between sessions — so next time you open the app it loads your saved coordinates automatically via loadObserver(). One line to save, one line to load, JSON in between. Actually really simple once I understood it.The observer marker gets placed on the globe too — same system as the ISS marker but sits almost on the surface (altFrac: 0.005).Input fields update to show the saved coordinates. The location display shows hemisphere format — 47.50° N, 19.04° E style — then “loading…” underneath while it reverse geocodes the place name.Coordinates, radians, localStorage, marker placement — a lot of small things that all had to connect correctly. Felt good when it clicked."}, {"post_id": 24115, "ts": "2026-07-07T14:07:26Z", "hours": 3.0858, "text": "Devlog #7 — Camera, live updates & the tick loopThis session was the one where it started actually feeling alive.Camera controls first. Three modes — follow, rotate, free. “Follow” mode smoothly pans the globe to the ISS position every 2.4 seconds with a 900ms animation. Feels really clean, like the camera is actually tracking something. “Rotate” just spins the globe on its own. “Free” is hands-off, user controls everything. Also wired up the day/night texture toggle — one click switches between the blue marble and the night lights texture.Found a bug: setStatus() is missing a space — “led” + cls produces “ledlive” instead of “led live”. The LED will never change color because the class name is wrong. One character fix.Then the tick() function. This is the heartbeat of the whole app. Runs on an interval, calls stateAt(now), updates the marker position, updates all the telemetry readouts — lat, lng, altitude, speed, orbital period, illumination. Everything live."}, {"post_id": 21368, "ts": "2026-07-03T08:20:22Z", "hours": 0.9267, "text": "Devlog #6 — Markers, orbit track & resizeShort session today but got a few important things done.Set the globe’s starting view — looking down at lat: 20, lng: 0 from altitude 2.4. Basically a nice “overview of Earth” angle when the page loads. Auto-rotate speed set to 0.45, slow and smooth. Small detail but it makes the whole thing feel alive even before any data loads.Then the markers. Two functions — makeIssEl() and makeObsEl() — each just creates a div with the right CSS class and inner HTML. The ISS gets the orange ring, the observer gets a “You” label. Simple.Found two HTML typos in there while writing this. makeIssEl() has </div missing the closing >. makeObsEl() is missing the opening < on the dot div — ‘div class=“dot”>’ instead of ‘’. Both will silently break the markers in the browser. Need to fix those.The orbit track was interesting. It loops from -25 minutes to +70 minutes around now, samples a position every 1.5 minutes, builds a path array. So you see where the ISS came from and where it’s going. Past 25 minutes, future 70. Felt like a very “Python” approach — just loop, collect, feed into the renderer.Also wired up resize handling. Globe redraws to fill its container whenever the window size changes. One listener, one function."}, {"post_id": 16304, "ts": "2026-06-26T15:08:45Z", "hours": 1.685, "text": "Devlog #5 — The JavaScript begins. It’s a lot.Okay. JavaScript. Here we go.Started wiring up the actual logic today. First thing: fetching the TLE data — basically the orbital parameters that tell satellite.js where the ISS is. Hitting the wheretheiss.at API, parsing the two lines, feeding them into satellite.twoline2satrec(). If it fails, the LED goes red. If it works, green. Simple.Then stateAt() — takes a date, runs the SGP4 propagation, converts ECI coordinates to geodetic (lat/lng/altitude). That’s the core of the whole tracker. One function, does a lot.Also wrote sun position math from scratch. Like actual astronomy math — Julian dates, ecliptic longitude, Earth’s axial tilt. Did not expect to be doing orbital mechanics today. The issSunlit() function checks if the ISS is in Earth’s shadow using a dot product. Python brain kicked in here, vector math felt familiar at least.Then the globe. globe.gl is actually pretty nice to work with. Night texture, bump map, atmosphere, star background. Hooked up the HTML markers for the ISS and observer position.Found a few bugs while writing this. Typo in a texture URL — hree-globe instead of three-globe, and earh-blue-marble instead of earth-blue-marble. Also a missing closing parenthesis somewhere in the globe chain that’s going to cause a syntax error. Classic late night coding stuff.JavaScript is definitely harder than HTML and CSS. But the Python background helps more than I expected — the logic side of it feels familiar, just different syntax.I changed my mind about the design and I changed to blue."}, {"post_id": 15006, "ts": "2026-06-24T11:55:00Z", "hours": 1.1847, "text": "Devlog #4 — Location, passes, crew & wrapping up the HTMLFinished the HTML structure today. Three more sections in the sidebar.Observer location first. Two inputs — lat/lon manually, or a “Use my location” button that’ll hit the browser geolocation API. Placeholder values are Budapest coordinates (47.4979, 19.0402) — yeah, I’m Hungarian, felt right, but I live in Romania because of the Trianon.Then the visible passes section. Right now just shows an empty state: “Set an observer location to predict naked-eye visible passes.” There’s a checkbox for showing all passes, not just visible ones. The actual pass prediction math is going to be the hardest part I think. satellite.js can do it but I haven’t figured out that part yet.Crew section is there too. Pulls from Open Notify API — basically just a list of who’s up there right now. Placeholder shows “Loading…” for now.Also noticed a bug writing this: three of the globe control buttons (Rotate, Orbit, Day) all have id=“c-follow”. Duplicate IDs. JavaScript is going to have a bad time with that. Need to fix before I wire anything up.Footer has the data sources listed — wheretheiss.at for live position, satellite.js for the SGP4 math, Open Notify for crew. Felt important to credit them properly.HTML’s basically done. Next session is the scary part — the JavaScript.Honestly, as a beginner with HTML and CSS, I think I actually get it now. I’m not just copy-pasting; I truly understand why things go where they do. Grid, flexbox, CSS variables, pseudo-elements—these were concepts that looked like alien syntax a week ago. AI helped a lot with that. It didn’t do the work for me, but it explained what each part actually does while we built it. I didn’t expect to learn this much so quickly, and I’m very happy for this."}, {"post_id": 14370, "ts": "2026-06-23T14:06:50Z", "hours": 1.1667, "text": "Devlog #3 — Globe markers & the telemetry panelGot the globe section wired up today. The ISS marker is a small orange ring with a dot in the middle — like a crosshair. Took a while to get the centering right with translate(-50%, -50%), kept jumping to weird positions on the globe. CSS ::after pseudo-element for the inner dot. Didn’t know that trick before, actually pretty clean.Also built out the telemetry panel. Latitude, longitude, altitude, orbital speed, orbital period, illumination — all sitting in those readout rows from last session. Right now they just show - as placeholders. Next step is hooking them up to live data so they actually update.One thing I noticed: the status LED up in the header is set to warn (orange) by default — because while the app is still loading TLE data, it shouldn’t show green. Small UX detail but it matters. Green means live, orange means loading, red means something broke.Also added the observer marker for the user’s location on the globe. Different color from the ISS marker — white tag instead of orange — so it’s clear which is which at a glance.Starting to look like an actual mission control dashboard. Not bad for someone who barely knew what CSS grid was two weeks ago."}, {"post_id": 13088, "ts": "2026-06-21T12:50:05Z", "hours": 1.6939, "text": "Devlog #2. Building the sidebar consoleI spent this session working on the sidebar panel. The layout is like a “mission control”. A console on the left and a globe on the right. I used CSS grid to achieve this. The console has a fixed width of 392px and the rest of the space goes to the globe.I built the console piece by piece. First I added a header with a status light. It’s green when live orange when theres a warning and red when theres an error. It’s basic. It gets the job done.Then I added rows to show data. I styled them like telemetry data with a key-value pair format. I used a number format called tabular-nums. This keeps the digits lined up properly when they update.I also added some toggle buttons, location input fields and a table to predict when the ISS will be visible from a location. I tried to use a monospace font for the data and a regular sans font, for the labels. This makes it feel like an instrument panel and less like a website.While writing this I found a typo bug. I had written –line-2 in my root variables. Used var(–line2) in a couple of places. It took me a while to notice why some borders weren’t showing up. It was a mistake.Next I need to hook up ISS position data. I want to wire the readout rows to show numbers instead of placeholders."}, {"post_id": 11934, "ts": "2026-06-19T13:58:09Z", "hours": 0.7636, "text": "I started my ISS Orbital Tracker project. The goal is to create a 3D globe that shows the ISS in real-time as it orbits the planet. For the orbital calculations, I’m using satellite.js, which handles the SGP4 math. For the 3D globe, I’m using globe.gl with WebGL working in the background.Honestly, HTML and frontend work aren’t my strong points. I feel most comfortable with Python. However, “learn web development” has been on my summer to-do list for a long time. Stardance seemed like the perfect opportunity to finally jump in.I began with some help from AI, and I won’t pretend otherwise. However, I’m not just copying and pasting what it produces. I review every line and ask, “Why does this work like that?” I’m making all the decisions myself regarding structure and design. The AI acts more like a tutor beside me than someone doing my work. I want to control this project, not just watch it develop.So far, I’ve set up the basics. The HTML structure is complete. The scripts for satellite.js and globe.gl are loaded and connected. I’ve also created a full color system using CSS variables like –bg and –accent. I’m aiming for that dark “mission control” vibe, similar to the energy in a NASA control room, but within a browser tab.Next, I need to pull the ISS’s live position and display it on the globe. That’s the exciting part"}]...
|
Title: Iss tracker by @huncikoma | Stardance
Devl Title: Iss tracker by @huncikoma | Stardance
Devlogs:
I started my ISS Orbital Tracker project. The goal is to create a 3D globe that shows the ISS in real-time as it orbits the planet. For the orbital calculations, I’m using satellite.js, which handles the SGP4 math. For the 3D globe, I’m using globe.gl with WebGL working in the background.Honestly, HTML and frontend work aren’t my strong points. I feel most comfortable with Python. However, “learn web development” has been on my summer to-do list for a long time. Stardance seemed like the perfect opportunity to finally jump in.I began with some help from AI, and I won’t pretend otherwise. However, I’m not just copying and pasting what it produces. I review every line and ask, “Why does this work like that?” I’m making all the decisions myself regarding structure and design. The AI acts more like a tutor beside me than someone doing my work. I want to control this project, not just watch it develop.So far, I’ve set up the basics. The HTML structure is complete. The scripts for satellite.js and globe.gl are loaded and connected. I’ve also created a full color system using CSS variables like –bg and –accent. I’m aiming for that dark “mission control” vibe, similar to the energy in a NASA control room, but within a browser tab.Next, I need to pull the ISS’s live position and display it on the globe. That’s the exciting part
Devlog #2. Building the sidebar consoleI spent this session working on the sidebar panel. The layout is like a “mission control”. A console on the left and a globe on the right. I used CSS grid to achieve this. The console has a fixed width of 392px and the rest of the space goes to the globe.I built the console piece by piece. First I added a header with a status light. It’s green when live orange when theres a warning and red when theres an error. It’s basic. It gets the job done.Then I added rows to show data. I styled them like telemetry data with a key-value pair format. I used a number format called tabular-nums. This keeps the digits lined up properly when they update.I also added some toggle buttons, location input fields and a table to predict when the ISS will be visible from a location. I tried to use a monospace font for the data and a regular sans font, for the labels. This makes it feel like an instrument panel and less like a website.While writing this I found a typo bug. I had written –line-2 in my root variables. Used var(–line2) in a couple of places. It took me a while to notice why some borders weren’t showing up. It was a mistake.Next I need to hook up ISS position data. I want to wire the readout rows to show numbers instead of placeholders.
Devlog #3 — Globe markers & the telemetry panelGot the globe section wired up today. The ISS marker is a small orange ring with a dot in the middle — like a crosshair. Took a while to get the centering right with translate(-50%, -50%), kept jumping to weird positions on the globe. CSS ::after pseudo-element for the inner dot. Didn’t know that trick before, actually pretty clean.Also built out the telemetry panel. Latitude, longitude, altitude, orbital speed, orbital period, illumination — all sitting in those readout rows from last session. Right now they just show - as placeholders. Next step is hooking them up to live data so they actually update.One thing I noticed: the status LED up in the header is set to warn (orange) by default — because while the app is still loading TLE data, it shouldn’t show green. Small UX detail but it matters. Green means live, orange means loading, red means something broke.Also added the observer marker for the user’s location on the globe. Different color from the ISS marker — white tag instead of orange — so it’s clear which is which at a glance.Starting to look like an actual mission control dashboard. Not bad for someone who barely knew what CSS grid was two weeks ago.
Devlog #4 — Location, passes, crew & wrapping up the HTMLFinished the HTML structure today. Three more sections in the sidebar.Observer location first. Two inputs — lat/lon manually, or a “Use my location” button that’ll hit the browser geolocation API. Placeholder values are Budapest coordinates (47.4979, 19.0402) — yeah, I’m Hungarian, felt right, but I live in Romania because of the Trianon.Then the visible passes section. Right now just shows an empty state: “Set an observer location to predict naked-eye visible passes.” There’s a checkbox for showing all passes, not just visible ones. The actual pass prediction math is going to be the hardest part I think. satellite.js can do it but I haven’t figured out that part yet.Crew section is there too. Pulls from Open Notify API — basically just a list of who’s up there right now. Placeholder shows “Loading…” for now.Also noticed a bug writing this: three of the globe control buttons (Rotate, Orbit, Day) all have id=“c-follow”. Duplicate IDs. JavaScript is going to have a bad time with that. Need to fix before I wire anything up.Footer has the data sources listed — wheretheiss.at for live position, satellite.js for the SGP4 math, Open Notify for crew. Felt important to credit them properly.HTML’s basically done. Next session is the scary part — the JavaScript.Honestly, as a beginner with HTML and CSS, I think I actually get it now. I’m not just copy-pasting; I truly understand why things go where they do. Grid, flexbox, CSS variables, pseudo-elements—these were concepts that looked like alien syntax a week ago. AI helped a lot with that. It didn’t do the work for me, but it explained what each part actually does while we built it. I didn’t expect to learn this much so quickly, and I’m very happy for this.
Devlog #5 — The JavaScript begins. It’s a lot.Okay. JavaScript. Here we go.Started wiring up the actual logic today. First thing: fetching the TLE data — basically the orbital parameters that tell satellite.js where the ISS is. Hitting the wheretheiss.at API, parsing the two lines, feeding them into satellite.twoline2satrec(). If it fails, the LED goes red. If it works, green. Simple.Then stateAt() — takes a date, runs the SGP4 propagation, converts ECI coordinates to geodetic (lat/lng/altitude). That’s the core of the whole tracker. One function, does a lot.Also wrote sun position math from scratch. Like actual astronomy math — Julian dates, ecliptic longitude, Earth’s axial tilt. Did not expect to be doing orbital mechanics today. The issSunlit() function checks if the ISS is in Earth’s shadow using a dot product. Python brain kicked in here, vector math felt familiar at least.Then the globe. globe.gl is actually pretty nice to work with. Night texture, bump map, atmosphere, star background. Hooked up the HTML markers for the ISS and observer position.Found a few bugs while writing this. Typo in a texture URL — hree-globe instead of three-globe, and earh-blue-marble instead of earth-blue-marble. Also a missing closing parenthesis somewhere in the globe chain that’s going to cause a syntax error. Classic late night coding stuff.JavaScript is definitely harder than HTML and CSS. But the Python background helps more than I expected — the logic side of it feels familiar, just different syntax.I changed my mind about the design and I changed to blue.
Devlog #6 — Markers, orbit track & resizeShort session today but got a few important things done.Set the globe’s starting view — looking down at lat: 20, lng: 0 from altitude 2.4. Basically a nice “overview of Earth” angle when the page loads. Auto-rotate speed set to 0.45, slow and smooth. Small detail but it makes the whole thing feel alive even before any data loads.Then the markers. Two functions — makeIssEl() and makeObsEl() — each just creates a div with the right CSS class and inner HTML. The ISS gets the orange ring, the observer gets a “You” label. Simple.Found two HTML typos in there while writing this. makeIssEl() has </div missing the closing >. makeObsEl() is missing the opening < on the dot div — ‘div class=“dot”>’ instead of ‘’. Both will silently break the markers in the browser. Need to fix those.The orbit track was interesting. It loops from -25 minutes to +70 minutes around now, samples a position every 1.5 minutes, builds a path array. So you see where the ISS came from and where it’s going. Past 25 minutes, future 70. Felt like a very “Python” approach — just loop, collect, feed into the renderer.Also wired up resize handling. Globe redraws to fill its container whenever the window size changes. One listener, one function.
Devlog #7 — Camera, live updates & the tick loopThis session was the one where it started actually feeling alive.Camera controls first. Three modes — follow, rotate, free. “Follow” mode smoothly pans the globe to the ISS position every 2.4 seconds with a 900ms animation. Feels really clean, like the camera is actually tracking something. “Rotate” just spins the globe on its own. “Free” is hands-off, user controls everything. Also wired up the day/night texture toggle — one click switches between the blue marble and the night lights texture.Found a bug: setStatus() is missing a space — “led” + cls produces “ledlive” instead of “led live”. The LED will never change color because the class name is wrong. One character fix.Then the tick() function. This is the heartbeat of the whole app. Runs on an interval, calls stateAt(now), updates the marker position, updates all the telemetry readouts — lat, lng, altitude, speed, orbital period, illumination. Everything live.
Devlog #8 — TLE age, observer location & localStorageShort but important session.First, finished off the tick() function. Added TLE age display — shows how old the orbital data is. Under an hour it shows minutes, over an hour it shows decimal hours. Small detail but useful, stale TLE data means inaccurate position.Then observer location. This took a bit of thinking. The app needs to know where you are to predict ISS passes — so setObserver() takes lat/lng, validates it (no infinite values, lat within ±90, lng within ±180), converts to radians for the math, and stores it.The localStorage part was new territory for me. Never used it before. Basically the browser remembers your location between sessions — so next time you open the app it loads your saved coordinates automatically via loadObserver(). One line to save, one line to load, JSON in between. Actually really simple once I understood it.The observer marker gets placed on the globe too — same system as the ISS marker but sits almost on the surface (altFrac: 0.005).Input fields update to show the saved coordinates. The location display shows hemisphere format — 47.50° N, 19.04° E style — then “loading…” underneath while it reverse geocodes the place name.Coordinates, radians, localStorage, marker placement — a lot of small things that all had to connect correctly. Felt good when it clicked.
Devlog #9 — Pass predictionThe part I was most scared of. Also the coolest.computePasses() steps through the next 6 days in 30-second jumps, calculates the ISS position at each step, and converts it to look angles from your location. Elevation above 10° = pass starts. Drops below = pass ends.The visibility check is the fun part. You can only see the ISS with your own eyes if three things line up: it’s above 10°, the sun is 6°+ below your horizon , but the ISS up there is still catching sunlight. Basically a sunlit object against a dark sky. That’s what you’re actually seeing.Also finished the geolocation button, the reverse geocoding for your city name, and the pass table — time, duration, max elevation, compass direction. Visible passes get an orange dot.Deepest I’ve been in over my head this whole project. But piece by piece, it makes sense now.
Devlog #10 — Crew, startup & it’s doneLast pieces today.Crew section first. Pulls from the Open Notify API — who’s on the ISS right now. Had to route it through a CORS proxy because the API is http-only and browsers block that from an https page. Filters for ISS crew specifically, falls back to everyone in space if the filter comes up empty. If the API dies, shows a graceful “unavailable” message instead of breaking.Then the startup section — the part that boots everything. Load saved observer location, fetch TLE, fetch crew, then the intervals: tick() every second, orbit path refresh every minute, fresh TLE every 2 hours, crew every 6 hours. Everything on its own schedule.Finally made it actually easy to run. Wrote a small Python server file that spins up a local webserver — this is where my Python comfort zone finally got to shine in this project. Plus a start.bat that launches the server and opens the app in the browser in one double-click. And a README so anyone can figure out how to run it.That’s it. The tracker is done. Live position, 3D globe, pass predictions, crew list, one-click startup. Started this barely knowing what a div was.
Ships:
I make a real-time ISS tracker with a 3D globe. It shows the station’s live position, altitude, speed and whether it’s sunlit — plus it predicts when the ISS will be visible with the naked eye from your location in the next 6 days. It also shows who’s currently aboard. All the orbital math (SGP4) runs locally with satellite.js, the 3D globe is globe.gl. What was challenging?-Pretty much everything — this is my first web project ever. I’m a Python guy, so I had to learn the whole thing from the ground up: HTML, CSS, JavaScript, all of it. None of this existed in my toolbox before this project. The hardest part by far was the pass prediction: look angles, ECI to ECF conversion, checking if the ISS is sunlit while your sky is dark. Actual orbital mechanics. I used AI as a tutor along the way, but I made sure I understood every part instead of just pasting code. I am proud of that the pass prediction actually works — three conditions lining up (ISS above 10°, sun 6° below your horizon, station still in sunlight) and it tells you exactly when to look up. Also the “mission control” design, built from scratch with CSS variables. And honestly: that as a Python-only dev I had to learn an entirely new stack for this, and it actually came together. From barely knowing what a div is to this, in a few weeks. To test it: Just run start.bat (it starts a small Python webserver and opens the app) — or open the demo URL. Click “Use my location” or type coordinates manually, and the visible passes table fills in. Try the Follow/Rotate camera modes and the Day/Night texture toggle too. Details in the README....
|
1792878675.2463546
|
1793742675.2463546
|
|
21032
|
Precision Tweezer Grinder by @DRWUKAS | Stardance
|
DRWUKAS
|
1
|
6.0
|
31
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-20T19:05:55Z", "hours": 6.0, "multiplier": 5.0, "payout": 31, "blessing": "neutral", "text": "I made a precision tweezers grinder to sharpen my tweezers. The thing I found most difficult was solderingf the miniscule micro usb port, I am very happy with how it turned out and I hope others feel the same.", "repo": "https://github.com/DRWUKAS/Precision-Tweezer-Grinder", "demo": ""}]...
|
[{"post_id": 12702, "ts": "202 [{"post_id": 12702, "ts": "2026-06-20T18:57:13Z", "hours": 2.395, "text": "Soldering and Finishing In this session, I worked on soldering the components together. While it should have been a simple process, a tricky component turned it into a two-hour task, but everything now works as intended. Micro USB Challenges: Struggled with the Micro USB port because it was a bare USB port rather than a proper 5V breakout board. Soldering Difficulties: Faced issues soldering wires directly to the tiny pins without bridging them or having the connections fall off. Cable Solution: Resolved the issue by cutting a standard USB cable and soldering those wires directly into the circuit instead. Current Status: The solution works perfectly as intended, even though the internal wiring is not quite as sleek as originally planned. Future Improvements: Plan to replace this current setup with a proper breakout board in a future iteration to make the design cleaner."}, {"post_id": 12026, "ts": "2026-06-19T16:43:57Z", "hours": 0.4319, "text": "Final CAD Adjustments and First Assembly In this session, I worked on the final CAD adjustments for the project design and successfully assembled the newly printed parts. Everything fits much better now and looks amazing. CAD Modifications: Changed the hole sizes and reworked the micro USB bracket to prevent it from sliding inside its case. Printing and Fit: Printed the three parts with the new dimensions and verified that everything fits much better than the previous version. Case Assembly: Tapped the main case for M3 screws, placed all the components inside, and screwed the entire assembly together. Next Steps: The last remaining task is to solder everything together, test if it works, and submit all CAD files and journal logs."}, {"post_id": 11906, "ts": "2026-06-19T12:21:06Z", "hours": 1.2936, "text": "First Print and Full CAD Mostly Done In this session, I finished the main design in CAD and printed the three parts. The two main body pieces fit together nicely but will need a few minor adjustments. Time Tracking: Spent 2 hours total on this session, including 1 hour and 15 minutes on CAD and 45 minutes assembling and tinkering. Base Plate Tweaks: Need to raise the height of the pole on the base plate so it pushes up against the motor properly. Hole Alignment: Need to move the holes inward slightly because they are too close to the wall to print properly with a 0.4 mm nozzle. Chassis Strength: Need to remove the small micro USB port area from the main body and place that pad on the bottom half instead to make it stronger and easier to print. Motor Clearance: Need to make the recessed area larger because the motor does not fit yet."}, {"post_id": 11283, "ts": "2026-06-18T13:35:18Z", "hours": 2.1031, "text": "Day 1 CAD Today I started the CAD for this project. I recorded a time-lapse while making it. Component Modeling: First, I created the motor, switch, and micro USB models to determine their sizes and better visualize the design. Main Chassis: I then started designing the main body and added a recessed area for the motor to fit into. This is not yet finalised. Manufacturing Setup: I then started work on the mounting points for the bottom and top halves, as the design will consist of two parts for ease of manufacturing. Fasteners & Alignment: There are 2.4 mm diameter holes, which will be tapped to M3. The holes have a recessed area that allows the bottom plate to align perfectly with the top. Switch Integration: The last thing I did was add the area where the switch will sit and be press-fitted into place. This is a simple slot with a very small clearance, allowing the switch to be securely press-fitted into the housing."}]...
|
Title: Precision Tweezer Grinder by @DRWUKAS | Sta Title: Precision Tweezer Grinder by @DRWUKAS | Stardance
Devlogs:
Day 1 CAD Today I started the CAD for this project. I recorded a time-lapse while making it. Component Modeling: First, I created the motor, switch, and micro USB models to determine their sizes and better visualize the design. Main Chassis: I then started designing the main body and added a recessed area for the motor to fit into. This is not yet finalised. Manufacturing Setup: I then started work on the mounting points for the bottom and top halves, as the design will consist of two parts for ease of manufacturing. Fasteners & Alignment: There are 2.4 mm diameter holes, which will be tapped to M3. The holes have a recessed area that allows the bottom plate to align perfectly with the top. Switch Integration: The last thing I did was add the area where the switch will sit and be press-fitted into place. This is a simple slot with a very small clearance, allowing the switch to be securely press-fitted into the housing.
First Print and Full CAD Mostly Done In this session, I finished the main design in CAD and printed the three parts. The two main body pieces fit together nicely but will need a few minor adjustments. Time Tracking: Spent 2 hours total on this session, including 1 hour and 15 minutes on CAD and 45 minutes assembling and tinkering. Base Plate Tweaks: Need to raise the height of the pole on the base plate so it pushes up against the motor properly. Hole Alignment: Need to move the holes inward slightly because they are too close to the wall to print properly with a 0.4 mm nozzle. Chassis Strength: Need to remove the small micro USB port area from the main body and place that pad on the bottom half instead to make it stronger and easier to print. Motor Clearance: Need to make the recessed area larger because the motor does not fit yet.
Final CAD Adjustments and First Assembly In this session, I worked on the final CAD adjustments for the project design and successfully assembled the newly printed parts. Everything fits much better now and looks amazing. CAD Modifications: Changed the hole sizes and reworked the micro USB bracket to prevent it from sliding inside its case. Printing and Fit: Printed the three parts with the new dimensions and verified that everything fits much better than the previous version. Case Assembly: Tapped the main case for M3 screws, placed all the components inside, and screwed the entire assembly together. Next Steps: The last remaining task is to solder everything together, test if it works, and submit all CAD files and journal logs.
Soldering and Finishing In this session, I worked on soldering the components together. While it should have been a simple process, a tricky component turned it into a two-hour task, but everything now works as intended. Micro USB Challenges: Struggled with the Micro USB port because it was a bare USB port rather than a proper 5V breakout board. Soldering Difficulties: Faced issues soldering wires directly to the tiny pins without bridging them or having the connections fall off. Cable Solution: Resolved the issue by cutting a standard USB cable and soldering those wires directly into the circuit instead. Current Status: The solution works perfectly as intended, even though the internal wiring is not quite as sleek as originally planned. Future Improvements: Plan to replace this current setup with a proper breakout board in a future iteration to make the design cleaner.
Ships:
I made a precision tweezers grinder to sharpen my tweezers. The thing I found most difficult was solderingf the miniscule micro usb port, I am very happy with how it turned out and I hope others feel the same....
|
1793288931.8095615
|
1793375331.8095615
|
|
21040
|
R2D2 model by @TamasLaszloffy777 | Stardance
|
TamasLaszloffy777
|
1
|
87.0
|
0
|
[{"ship_num": 1, "ts": "2026-1 [{"ship_num": 1, "ts": "2026-10-20T06:00:44Z", "hours": 87.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "This project is a fan-made R2-D2 replica. I made with my fellow, @benedekkristof16 . My part was the 3D modeling and designing, making the mechanincs, (motors with functioning gears), painting and decorating. The most chalenging part of the project wasn’t the learning; however the designing and understanding the complicated blueprints and surface modeling (especially the dome) was the toughest part. This hardware project is capable of rolling around, turning its head and bring light the to night with some LEDs. We made a cool demo video presenting R2. We hope you’ll find it enjoyable.", "repo": "https://github.com/kirikristof/R2D2-model", "demo": ""}]...
|
[{"post_id": 74081, "ts": "202 [{"post_id": 74081, "ts": "2026-09-26T17:09:01Z", "hours": 4.535, "text": "Hello, guys! R2 has been built (mostly)!!! With the help of my dear fellows ( @benedekkristof16 and @hunorkiss04 ), we spent a lot of time working on it. As expected, we faced some difficulties during the building session. The main problem was the CAD design and 3D printing: in some places the holes are too tight for the screws and there are defective pieces; however we could resolve all the problems with some unique solutions. At the end of the day, R2 is moving and he’s able to turn his head! We’ve started to fill the GitHub files and I’ll fix the 3D mistakes. (Ignore the questionable paint job)"}, {"post_id": 63123, "ts": "2026-09-06T19:07:58Z", "hours": 4.7514, "text": "Hello, guys! Hopefully, it’ll be my last devlog about 3D modelling, and next time, I’ll build R2 in real life with my dear fellows, @benedekkristof16 and @hunorkiss04 . I’ve spent hours and hours designing with varying degrees of success and from this mighty point, R2 probably has a much cooler look and far more aura than me🥀. Unfortunatelly, this replica is NOT 100% accurate and I had to model some elements by sight (R2’s holoprojector) and I horribly miscalculated a ratio: R2’s main body (the cylinder) is 220mm and it should have been 200mm. I noticed it too late. Due to the complexity of R2’s torso and the lack of time, I didn’t correct this. It’s not that visible; however I had to let go of the two center foot cylinder due to a lack of space. But it’s our R2, so We’ll keep him, no matter what 😉."}, {"post_id": 62093, "ts": "2026-09-05T10:41:58Z", "hours": 9.1628, "text": "Hello, guys! 3D printing has started, and I designed some important details for R2’s body: the Radar Eye, Shoulder and Battery box. Currently, I’m making the Leg Booster. I still have to model the Ankle Cylinders and a few remaining details for R2’s dome."}, {"post_id": 54599, "ts": "2026-08-25T16:59:32Z", "hours": 9.1508, "text": "Hello guys! I’ve finally finished (almost) R2’s modeling, and I’ve successfully done the hardest part of the project: the decorative panels and holes on the dome. I used plane splitting and surface projection tricks to get perfect panel lines all around the dome to avoid distortion on the spherical surface. All that’s left now is modeling an internal mount for a small IR sensor, and the dome is ready for printing. I’ll design the rest of the decorative elements, such as R2’s eyes and shoulder rings."}, {"post_id": 51125, "ts": "2026-08-20T16:58:22Z", "hours": 9.1283, "text": "Hello, guys! The progress has been huge, and here is a quick list of what I’ve done recently: -I’ve modeled a custom lazy susan bearing for R2’s head that runs on 6mm BBs -The motor mount fot the 28BYJ-48 stepper motor is basically ready and it’s attachable to R2’s torso. -I also made the head-turning system with a huge internal gear. I still need to do some tuning; however it’s time for R2 to come alive. The 3D printing will probably take a couple of hours (or days). Stay tuned!"}, {"post_id": 46403, "ts": "2026-08-13T16:10:33Z", "hours": 7.8453, "text": "Hello, guys! I’m back with a huge update! Recently, I’ve been working on finalizing R2’s legs and shoulder attachment, and it’s looking far better than expected! It’s finally starting to look truly recognizable. It wasn’t a smooth process, though I ran into quite a few problems with component positioning and broken external links between files. Fixing lost references took a lot of patience and effort and figuring out the correct 18° body tilt and getting the shoulder alignment right was time-consuming. Basically it’s done; however, I still haven’t figured out how to make the center wheel. I hope I’ll find the right way. Maybe I’ll have to use LEGO wheel…"}, {"post_id": 42716, "ts": "2026-08-07T15:57:47Z", "hours": 1.3003, "text": "I’m here again and I’ve just tried to finish the main leg. It’s still missing a few decorative elements. Next I will make the shoulder attachment and after that, it’s time for R2’s head!"}, {"post_id": 42639, "ts": "2026-08-07T13:48:13Z", "hours": 3.6844, "text": "This time, I tackled the main ankle block, and it’s done, and also wrapped up the design for the decorative side panels on the center foot assembly. To keep maintenance easy and avoid visible screw holes, I separated the decorative panels and designed small pockets for 5x2mm neodymium magnets that perfectly fit into the hole."}, {"post_id": 31951, "ts": "2026-07-20T19:28:39Z", "hours": 9.1475, "text": "It’s been over a week since the last update; however, don’t let the silence fool you! 😉 In the latest grinding, I worked almost entirely on the most critical piece: the main foot. Anyone who has ever designed a functioning mechanical foot knows exactly the pain and agony, that turning a solid block into a precise assembly is a total survival trip (maybe it’s just skill issue🥀), but I’m so proud that I’ve made it so far! The perfect wheel connection is ready, and the JGA25-370’s motor mount has found its home. Even those printer-killing, razor-sharp internal overhangs got tamed with clean chamfers and fillets. R2 will be proud of our team!"}, {"post_id": 24229, "ts": "2026-07-07T17:30:31Z", "hours": 8.1139, "text": "Hello, guys! It has been long since my last devlog, so let me break it down for y’all: -I’ve been working on the main cylinder for 8 hours (not straight) and I can finally say: It’s basicly done! -I modeled the cylinder with the body frame, and it became brutally strong (I hope it won’t brake in my hands). -I also made the internal shoulder mounts for the legs. They are perfectly integrated into the inner frame, making sure that this won’t fall apart! -To finish off this massive update, I spent quite some time sketching out all the crucial decorative panels, using a reference canvas. I’m as keen as mustard to finish and see something come to life!"}, {"post_id": 20708, "ts": "2026-07-02T11:36:09Z", "hours": 1.2308, "text": "Hello, guys! What I’ve achieved this past week is not as impressive as I’ve hoped: It’s been a packed week of modeling and geometry solving. I have successfully brought together several crucial assemblies into the main project: 1. Raspberry Pi Pico Frame 2. R2-D2 Center Foot: Completed the primary structural foot base 3. Center Ankle and Shroud Connection: After battling some complex 3D curved geometry, the ankle block is ready! Next steps: The next phase will be refining the joints and I will start the main cylinder!"}, {"post_id": 20248, "ts": "2026-07-01T19:54:12Z", "hours": 3.2669, "text": "I spent today working on the main ankle. The biggest hurdle was the curved outer plate. The blueprint is a bit confusing. Trying to accurately wrap and cut this 2D pattern onto the 3D curved ankle part in Fusion 360 turned out to be a real geometry headache. The main ankle structure is about 90% complete. As soon as I figure it out how to do this properly, this section will be ready (hopefully by tomorrow)."}, {"post_id": 19324, "ts": "2026-06-30T16:33:49Z", "hours": 2.0169, "text": "Another success! Today, I made sure that R2 won’t lose his leg during his first test drive: I finished the internal pass-through screw system. On one side, the screw head sits inside a deeper hole so it stays hidden under the panel. On the other side, I cut a perfect 6-sided hexagon shape. A real metal nut will sit inside this pocket, so when I tighten the screw, it will hold the leg perfectly, without breaking the plastic (at least, I hope 😜). I’ve started the ankle, making it 9,6 mm wide because the slot is 9.89 mm. This leaves a tiny gap both sides. I also imported the blueprint image to Fusion, scaled to the right size. Finally the project is coming together!"}, {"post_id": 18615, "ts": "2026-06-29T20:17:38Z", "hours": 1.8669, "text": "Today, I finally managed to model the most sweat-inducing parts of the R2-D2 foot, and after a few near-rage-quit moments, I made some step forward. The biggest headache was definitely wrestling that weird decorative trim on the side of the foot. After that, I had to start with the ankle attachment. Since this joint carries our little friend’s (R2’s) weight, it had to be built like a tank. I modeled a standard M6 socket screw. I hope it’ll be solid as rock! Next mission: figuring out how to hide this outer screw hole to keep things completely accurate, and I’ll model the center ankle!"}, {"post_id": 17685, "ts": "2026-06-28T16:14:15Z", "hours": 1.0333, "text": "Progress was slow AGAIN, that stubborn “Half Moon” side arc was completely annoying and refused to cooperate within the time limit. I didn’t let the session go to waste. Instead, I successfully cut out the main socket/connection point for the future leg. One step at a time!"}, {"post_id": 17082, "ts": "2026-06-27T18:51:34Z", "hours": 2.0167, "text": "Progress was way better today! I finally managed to tame the geometry of R2-D2’s center foot after some intense mathematical gymnastics, which was provided by the blueprints. The main body is basically done. There are still decorative panels which are waiting for modeling. The next step is to flip this thing over and design a customized frame for a caster wheel. R2 will be happy, rolling around the house!"}, {"post_id": 16353, "ts": "2026-06-26T16:37:41Z", "hours": 0.6, "text": "Progress was slow today (again), but I started working on a completely new component: the center foot. Though, it was hard, with limited time, I really enjoyed the process. I hope, I will be more efficient."}, {"post_id": 15756, "ts": "2026-06-25T17:05:47Z", "hours": 1.2506, "text": "Progress was a bit slower today and the electronics layout was refined. I modeled the breadboard holder because I forgot to add it yesterday. Since the Pico plugs straight into the breadboard anyway,a separate Pico case isn’t needed anymore and I removed it. I started sketching the panels and windows directly onto the main cylinder using the blueprint dimensions. I hope that the progress will accelerate!"}, {"post_id": 15130, "ts": "2026-06-24T16:15:32Z", "hours": 1.7006, "text": "The R2-D2 project had officially begun! After 5 hours of learning and I finally started the session. Since we are using a Raspberry Pi Pico W as the main controller (recently, my fellow, @benedekkristof16 has just started learning coding and he will do the software part of the project), I created a custom 3D ‘dummy’ model to match its exact physical dimensions. Using this dummy, I designed a protectiv case for the board. Finally, I started the main body of the robot by creating the core cylinder. Next, I will work on the internal parts with @hunorkiss04 !"}, {"post_id": 14442, "ts": "2026-06-23T15:55:01Z", "hours": 1.8008, "text": "My final training session is complete! In today’s practice I modeled a custom ‘Stardance’ object and a detailed polygon screw. Now, I feel experienced enough with Fusion 360’s tools to finish practicing. Next time, my newly joined teammate @hunorkiss04 and I are diving straight into building and modelling R2-D2! Stay tuned, it will be incredible!"}, {"post_id": 13610, "ts": "2026-06-22T09:50:00Z", "hours": 0.9167, "text": "Hopefully leveled up my Fusion 360 skills! Today I designed more complex shapes with more details and curves. Still no robot parts yet, but R2-D2 will be astonishing . Trust the process!"}, {"post_id": 13296, "ts": "2026-06-21T19:34:07Z", "hours": 1.7289, "text": "Spent another 1h 43m practicing the basics. I worked on a bottle and a LEGO brick to master the tools and navigation. It might not look like a robot yet, but I’m learning the rules before I start building the actual model. R2-D2 will be born soon!"}, {"post_id": 12608, "ts": "2026-06-20T16:29:39Z", "hours": 0.9333, "text": "Spent 56 minutes fighting the recording software and figuring out how Fusion 360 works as a rookie. The software looks like an aircraft control panel. Progress is moving at the speed of a snail right now, but tomorrow I’m coming back with more experience!"}]...
|
Title: R2D2 model by @TamasLaszloffy777 | Stardanc Title: R2D2 model by @TamasLaszloffy777 | Stardance
Devlogs:
Spent 56 minutes fighting the recording software and figuring out how Fusion 360 works as a rookie. The software looks like an aircraft control panel. Progress is moving at the speed of a snail right now, but tomorrow I’m coming back with more experience!
Spent another 1h 43m practicing the basics. I worked on a bottle and a LEGO brick to master the tools and navigation. It might not look like a robot yet, but I’m learning the rules before I start building the actual model. R2-D2 will be born soon!
Hopefully leveled up my Fusion 360 skills! Today I designed more complex shapes with more details and curves. Still no robot parts yet, but R2-D2 will be astonishing . Trust the process!
My final training session is complete! In today’s practice I modeled a custom ‘Stardance’ object and a detailed polygon screw. Now, I feel experienced enough with Fusion 360’s tools to finish practicing. Next time, my newly joined teammate @hunorkiss04 and I are diving straight into building and modelling R2-D2! Stay tuned, it will be incredible!
The R2-D2 project had officially begun! After 5 hours of learning and I finally started the session. Since we are using a Raspberry Pi Pico W as the main controller (recently, my fellow, @benedekkristof16 has just started learning coding and he will do the software part of the project), I created a custom 3D ‘dummy’ model to match its exact physical dimensions. Using this dummy, I designed a protectiv case for the board. Finally, I started the main body of the robot by creating the core cylinder. Next, I will work on the internal parts with @hunorkiss04 !
Progress was a bit slower today and the electronics layout was refined. I modeled the breadboard holder because I forgot to add it yesterday. Since the Pico plugs straight into the breadboard anyway,a separate Pico case isn’t needed anymore and I removed it. I started sketching the panels and windows directly onto the main cylinder using the blueprint dimensions. I hope that the progress will accelerate!
Progress was slow today (again), but I started working on a completely new component: the center foot. Though, it was hard, with limited time, I really enjoyed the process. I hope, I will be more efficient.
Progress was way better today! I finally managed to tame the geometry of R2-D2’s center foot after some intense mathematical gymnastics, which was provided by the blueprints. The main body is basically done. There are still decorative panels which are waiting for modeling. The next step is to flip this thing over and design a customized frame for a caster wheel. R2 will be happy, rolling around the house!
Progress was slow AGAIN, that stubborn “Half Moon” side arc was completely annoying and refused to cooperate within the time limit. I didn’t let the session go to waste. Instead, I successfully cut out the main socket/connection point for the future leg. One step at a time!
Today, I finally managed to model the most sweat-inducing parts of the R2-D2 foot, and after a few near-rage-quit moments, I made some step forward. The biggest headache was definitely wrestling that weird decorative trim on the side of the foot. After that, I had to start with the ankle attachment. Since this joint carries our little friend’s (R2’s) weight, it had to be built like a tank. I modeled a standard M6 socket screw. I hope it’ll be solid as rock! Next mission: figuring out how to hide this outer screw hole to keep things completely accurate, and I’ll model the center ankle!
Another success! Today, I made sure that R2 won’t lose his leg during his first test drive: I finished the internal pass-through screw system. On one side, the screw head sits inside a deeper hole so it stays hidden under the panel. On the other side, I cut a perfect 6-sided hexagon shape. A real metal nut will sit inside this pocket, so when I tighten the screw, it will hold the leg perfectly, without breaking the plastic (at least, I hope 😜). I’ve started the ankle, making it 9,6 mm wide because the slot is 9.89 mm. This leaves a tiny gap both sides. I also imported the blueprint image to Fusion, scaled to the right size. Finally the project is coming together!
I spent today working on the main ankle. The biggest hurdle was the curved outer plate. The blueprint is a bit confusing. Trying to accurately wrap and cut this 2D pattern onto the 3D curved ankle part in Fusion 360 turned out to be a real geometry headache. The main ankle structure is about 90% complete. As soon as I figure it out how to do this properly, this section will be ready (hopefully by tomorrow).
Hello, guys! What I’ve achieved this past week is not as impressive as I’ve hoped: It’s been a packed week of modeling and geometry solving. I have successfully brought together several crucial assemblies into the main project: 1. Raspberry Pi Pico Frame 2. R2-D2 Center Foot: Completed the primary structural foot base 3. Center Ankle and Shroud Connection: After battling some complex 3D curved geometry, the ankle block is ready! Next steps: The next phase will be refining the joints and I will start the main cylinder!
Hello, guys! It has been long since my last devlog, so let me break it down for y’all: -I’ve been working on the main cylinder for 8 hours (not straight) and I can finally say: It’s basicly done! -I modeled the cylinder with the body frame, and it became brutally strong (I hope it won’t brake in my hands). -I also made the internal shoulder mounts for the legs. They are perfectly integrated into the inner frame, making sure that this won’t fall apart! -To finish off this massive update, I spent quite some time sketching out all the crucial decorative panels, using a reference canvas. I’m as keen as mustard to finish and see something come to life!
It’s been over a week since the last update; however, don’t let the silence fool you! 😉 In the latest grinding, I worked almost entirely on the most critical piece: the main foot. Anyone who has ever designed a functioning mechanical foot knows exactly the pain and agony, that turning a solid block into a precise assembly is a total survival trip (maybe it’s just skill issue🥀), but I’m so proud that I’ve made it so far! The perfect wheel connection is ready, and the JGA25-370’s motor mount has found its home. Even those printer-killing, razor-sharp internal overhangs got tamed with clean chamfers and fillets. R2 will be proud of our team!
This time, I tackled the main ankle block, and it’s done, and also wrapped up the design for the decorative side panels on the center foot assembly. To keep maintenance easy and avoid visible screw holes, I separated the decorative panels and designed small pockets for 5x2mm neodymium magnets that perfectly fit into the hole.
I’m here again and I’ve just tried to finish the main leg. It’s still missing a few decorative elements. Next I will make the shoulder attachment and after that, it’s time for R2’s head!
Hello, guys! I’m back with a huge update! Recently, I’ve been working on finalizing R2’s legs and shoulder attachment, and it’s looking far better than expected! It’s finally starting to look truly recognizable. It wasn’t a smooth process, though I ran into quite a few problems with component positioning and broken external links between files. Fixing lost references took a lot of patience and effort and figuring out the correct 18° body tilt and getting the shoulder alignment right was time-consuming. Basically it’s done; however, I still haven’t figured out how to make the center wheel. I hope I’ll find the right way. Maybe I’ll have to use LEGO wheel…
Hello, guys! The progress has been huge, and here is a quick list of what I’ve done recently: -I’ve modeled a custom lazy susan bearing for R2’s head that runs on 6mm BBs -The motor mount fot the 28BYJ-48 stepper motor is basically ready and it’s attachable to R2’s torso. -I also made the head-turning system with a huge internal gear. I still need to do some tuning; however it’s time for R2 to come alive. The 3D printing will probably take a couple of hours (or days). Stay tuned!
Hello guys! I’ve finally finished (almost) R2’s modeling, and I’ve successfully done the hardest part of the project: the decorative panels and holes on the dome. I used plane splitting and surface projection tricks to get perfect panel lines all around the dome to avoid distortion on the spherical surface. All that’s left now is modeling an internal mount for a small IR sensor, and the dome is ready for printing. I’ll design the rest of the decorative elements, such as R2’s eyes and shoulder rings.
Hello, guys! 3D printing has started, and I designed some important details for R2’s body: the Radar Eye, Shoulder and Battery box. Currently, I’m making the Leg Booster. I still have to model the Ankle Cylinders and a few remaining details for R2’s dome.
Hello, guys! Hopefully, it’ll be my last devlog about 3D modelling, and next time, I’ll build R2 in real life with my dear fellows, @benedekkristof16 and @hunorkiss04 . I’ve spent hours and hours designing with varying degrees of success and from this mighty point, R2 probably has a much cooler look and far more aura than me🥀. Unfortunatelly, this replica is NOT 100% accurate and I had to model some elements by sight (R2’s holoprojector) and I horribly miscalculated a ratio: R2’s main body (the cylinder) is 220mm and it should have been 200mm. I noticed it too late. Due to the complexity of R2’s torso and the lack of time, I didn’t correct this. It’s not that visible; however I had to let go of the two center foot cylinder due to a lack of space. But it’s our R2, so We’ll keep him, no matter what 😉.
Hello, guys! R2 has been built (mostly)!!! With the help of my dear fellows ( @benedekkristof16 and @hunorkiss04 ), we spent a lot of time working on it. As expected, we faced some difficulties during the building session. The main problem was the CAD design and 3D printing: in some places the holes are too tight for the screws and there are defective pieces; however we could resolve all the problems with some unique solutions. At the end of the day, R2 is moving and he’s able to turn his head! We’ve started to fill the GitHub files and I’ll fix the 3D mistakes. (Ignore the questionable paint job)
Ships:
This project is a fan-made R2-D2 replica. I made with my fellow, @benedekkristof16 . My part was the 3D modeling and designing, making the mechanincs, (motors with functioning gears), painting and decorating. The most chalenging part of the project wasn’t the learning; however the designing and understanding the complicated blueprints and surface modeling (especially the dome) was the toughest part. This hardware project is capable of rolling around, turning its head and bring light the to night with some LEDs. We made a cool demo video presenting R2. We hope you’ll find it enjoyable....
|
1793199030.4254026
|
1793285430.4254026
|
|
21041
|
R2D2 model by @benedekkristof16 | Stardance
|
benedekkristof16
|
1
|
37.0
|
0
|
[{"ship_num": 1, "ts": "2026-1 [{"ship_num": 1, "ts": "2026-10-20T06:00:47Z", "hours": 37.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made this project with @TamasLaszloffy777 . My part was the electronics and coding. THe biggest hurdle was, that I’ve had to learn everything from scratch. I only knew basic python, and something about circuits, but only what I’ve learnt in school. This project is a fan-made R2-D2 replica, which is capable of rolling, turning it’s head, and has some LEDs. The project includes a demo link, where you can see it work in real life. Make sure you watch it, and We hope You’ll enjoy it!", "repo": "https://github.com/kirikristof/R2D2-model", "demo": ""}]...
|
[{"post_id": 74072, "ts": "202 [{"post_id": 74072, "ts": "2026-09-26T16:54:18Z", "hours": 2.8039, "text": "Hey! I think this will be my last, and my longest devlog! I need to clarify things, and address things, but first– I tell what I did. So I wired up the motor driver (an anquintance of mine helped to solder up the wires which will take the high current to the motors), wired up the LED’s, and put everything in the 3D printed chassis done, and assembled by @TamasLaszloffy777 , with the help of our friends (and my mom :) ). I soldered the wires to the motors, and glued the LED’s in the head. Now comes a list of things, that didn’t work: I copyed the HTML code my friend wrote into my code, but unfortunately I couldn’t get it working. I’ve spent countless hours debugging with Gemini, but as the project got more complex, it gave me more stupid answers. When I tested it with just the stepper motor, it worked, but with everything connected, it didnt. So out of desperation I’ve had to go back the old method I used at testing, which is that everything works with an USB cable. I’ve spent circa 30 minutes changing the code, and commenting out everything that has to do something with the wireless thing. Of course Hackatime didn’t register nothing out of this half an hour. This was the main thing why I used Lookout and Lapse for coding before the Ban. But after all, thank God it works now with USB (after some debugging with Gemini of course). This means that the LEDs also lost their purpose as wifi status indicators, so now the project has 2 spare LEDs inside. (I won’t put those in the wiring diagram, since they are not used, but its too much work to take them out. I saved two of them by repurposing them to “head turning indicators”, but left two out, because it would just make it harder for me to take the head off, to access everything inside. Also I plan to fix the wireless part in the future, but not in Stardance). The next thing I noticed, is the homing sequence is pretty useless. Fortunately the wires never twist dangerously, contrary to my previous assumptions, and R2 would have to rotate its head 360 degrees multiple times in a row for it to become dangerous for the wires. I was quite upset that I did the homing sequence, and bought the sensor for nothing, but keeping it would add unnecessary complexity. And unnecessary complexity is NEVER good in a project.(I wont put the sensor into the BOM list, nor into the wiring diagram)"}, {"post_id": 63719, "ts": "2026-09-07T17:33:29Z", "hours": 3.8669, "text": "So this time, I’ve had to update the entire code. So, as I’ve told you guys in my previous devlog, I’ve tried to make R2 wireless with UDP, but it did not work for some reason. Because of this, we decided to try another method. We will host a web server on the Pico! My friend, who knows this stuff, will write a basic HTML code, with buttons, to control R2. For this, I’ve had to go down a little rabbit hole with youtube, google and gemini, to learn how actually this stuff works. After, and along with researching, I’ve had to change a little the structure of my code, and implement new features. I also added LEDs this time! I think the coolest feature is, that R2 will tell us with Morse his IP address, using his LEDs (because he will have different ones based on which wifi network he is currently connected to, and he will have no other way to tell it us). We’ve also made some crucial changes. At first we’ve wanted R2D2 to have sounds, but we will have to omit this one for now, because our lack of time. Also, rather than random flashing, each LED will have it’s own purpose, and they all going to be used for communication."}, {"post_id": 60383, "ts": "2026-09-02T17:55:10Z", "hours": 2.66, "text": "So this time, I’ve tried to test the wireless part. I started by downloading a UDP app on my mom’s phone, and rotating the stepper motor with that, but nothing happened. After this I’ve rewritten the code so it does nothing with the motor, but prints the text in the UDP pockets, but still nothing. I’ve downloaded Packet Sender to my laptop, but still nothing. The UDP packets did never reach the Pico. I’ve tried everything the Debug Master Gemini said for more than two hours, but nothing… I think I will ask my friend who is familiar with making websites to write me a lightweight HTML page with buttons, then somehow make it connect to the motor logic. I reallyyy hope that will work."}, {"post_id": 59453, "ts": "2026-09-01T09:57:28Z", "hours": 0.6469, "text": "Today I tested the battery voltage measuring feature, I last time made! I put in the batteries, wired it up, copied this specific part of the code in Thonny, told it to print the voltage, aaaannd when I checked with the multimeter, it was waaay off, lol. I was baffled, because the voltage my Pico measured was MORE than a full volt below the actual voltage. I immediately started researching, (by asking Gemini… of course…. I start to feel guilty for all the trees and water I waste), and it said to me that it is likely due to resistors are not perfect, this is why they have a TOLERANCE band, and I should start a different approach. It suggested that I should calculate a factor, by dividing the voltage of the batteries measured with a multimeter, by the raw ADC value my Pico reads, then multiply with that with the raw ADC value. After fixing this, it gave me roughly the exact value my multimeter had shown. P.S. If I could learn for once, that I HAVE to use period at decimal numbers, instead of comma, I would spend way less time searching for bugs that don’t exist…"}, {"post_id": 57166, "ts": "2026-08-29T08:36:24Z", "hours": 3.7306, "text": "This time, I made the main power lines of R2D2! I started by soldering 3 wires (three positive, and three ground) to the battery holder, which will be the cozy home of two 18650 Li-Ion batteries. I connected a 5 volt buck converter to one of the lines, which will power the Pico, and a voltage divider to the next one, to help the Pico measure the batteries’ voltage, and give me a warning (eventually using R2’s LEDs) of low voltage. There is not connected anything yet to the third line, because the motor driver will be powered using this, but that soldering would be really hard with my setup, and I don’t know if I could safely do it. So I think I will ask an adult acquintance of mine, who works with electronics, to do that one for me."}, {"post_id": 47045, "ts": "2026-08-14T17:22:35Z", "hours": 5.0992, "text": "This time, I’ve finally made the wireless part! I started by, as you probably guessed it already, by brainstorming with Gemini! I asked it to give me tutorials on youtube, on how to make my robot wirelessly controllable, since I have a Pico W, as well as explain it himself. At first, I’ve went down a little rabbit hole, because I wanted to build a simple website, with buttons, to control R2D2. I quickly realized after peeking into college-level tutorials, that it far exceeds my capabilities at the moment, so I asked my good ol’ friend, Gemini, to give me a bit of a simpler solution. After some deep discussions, and watching a nice old man on youtube explaining it, I decided on non-blocking UDP socket polling, with the help of an external app. This will work by downloading an app to my phone (or anyone’s phone, who wants to control R2), agreeing on an ip address, and port number, then typing the letters, which represents the w, a, s, d, etc. keys. It may not look pretty, but it’s just as effective, and MUCH simpler."}, {"post_id": 44633, "ts": "2026-08-10T15:05:18Z", "hours": 1.3833, "text": "Today, I added the sensor for the homing sequence of R2’s head! This way, at startup, the head will start to turn, until it hits the infrared sensor, then go back to the middle. This way it is ensured, that no matter what position was the head at startup, it won’t go beyond the safe limits"}, {"post_id": 42777, "ts": "2026-08-07T17:36:43Z", "hours": 2.1439, "text": "So this time, I finally wired everything for the stepper motor-powered head together! I copyed the part which controls specifically this from my entire code sitting VSCode, just to try this out. I had an old battery holder saved from a toy, to make an external power source, and wired everything together. I checked the wiring with Gemini, to make sure I don’t light anything on fire. After this, well, it did not work… I spent brainstorming, “debugging”, and checking everything twice, until I realized the “bug” which prevented the motor spin, was the very common “missing battery” error. So I put it in, and after some fine tuning on the code, it worked really nice"}, {"post_id": 42644, "ts": "2026-08-07T14:07:55Z", "hours": 0.9744, "text": "This time I coded the homing sequence, which will help R2 center it’s head using the stepper motor. There will be an infrared sensor in the head, and at startup, R2 will turn its head slowly left, until the sensor detects it, and after this, the code will set the step count to 0. After this the head will automatically turn to look forward, while counting the steps. This is necessary to ensure that the head will move only in the safe limits, no matter in which position it was at startup. I took the help of Gemini at debugging."}, {"post_id": 36923, "ts": "2026-07-29T10:12:02Z", "hours": 4.9153, "text": "This time, I collected multiple days’ work for this devlog. I started by brainstorming with Gemini (by now I must be their top user, lol) about what motor would be best for turning R2’s head. We’re planning LEDs in the head, so I had to make sure it cannot rotate all the way around, because this would break the wires. I came to the conclusion, that a custom 3D printed gear mechanism would be best, with a 28BYJ-48 stepper motor, and a ULN2003 board, and rotation limits in the software. I watched videos on Youtube, and also asked Gemini to explain to me how to write a code to control the stepper motor. The code is not yet complete, I’ll have to add a “homing mechanism”, which would help the head find it’s position at startup."}, {"post_id": 30087, "ts": "2026-07-17T12:00:42Z", "hours": 1.6503, "text": "Today I wrote the prototype of the code, which will control the motion of R2D2. The original version will control it wirelessly, along with the sounds and ligths, but this controls only the motors yet, via a microUSB cable. I wrote it in VSCode, and I will only copy it to Thonny (which i’ll be using for the Pico) when it is fully completed. I took the help of Gemini, to explain me how to control it (the robot, eventually) using my keyboard, and with the final debugging. I also watched Electro Nerds Academy’s youtube video in the process, which explains how to control the TB6612FNG motor driver with Arduino, and C++, I did this to make sure I understand the process. I still have a lot to learn, but slowly and surely, R2 will roll!"}, {"post_id": 29420, "ts": "2026-07-16T11:13:48Z", "hours": 1.3206, "text": "Today, I got the Pico!!! Immediatelly I started to load up micropython on it, and download Thonny. It was a bit tricky, because my antivirus program wouldn’t let me download it, but I disabled it temporarily, and it worked just fine. And I quickly reviewed the first few pages of my PDF book, to make sure I know my Pico physically, not just the Wokwi version. After that I wanted to try it out with the onboard LED, but it didn’t worked, so I asked Gemini. I found out that my Pico, is actually Pico W, and the onboard led is a little different. After that it worked beautifully. Then I wanted to light up an external LED, and guess what, it also didn’t work! I started troubleshooting with Gemini on my side, and I found out, that my breadboard’s ground rail is probably damaged. After rewiring to bypass it, it lighted up!"}, {"post_id": 24693, "ts": "2026-07-08T13:32:16Z", "hours": 0.8378, "text": "A problem occurred during the delivery if the Pico, so it got retured to the sender. We had to order it again, so until it arrives, I thought I could learn actually how to control the DC motors with it, with the help of a TB6612FNG motor driver which we will be using. I asked Gemini to explain it to me, without providing exact codes, to ensure I actually understand the code, and not just copy-pasteing. It gave me a great youtube tutorial too, from Electro Nerds Academy, which used Arduino (and therefore C++), but it helped me understand the core principles of the wiring, and the code EDIT: This was BEFORE I was aware of the rule which states that we should not log too much continuous time spent watching youtube. This was only the learning phase, and I tried making it as active as possible, by building my own version on the way. If it is against the rules, please just ignore the time logged in this post. I don’t know if it is possible, but I’m pretty freaked out my entire summer work gets flushed down the toilet😭😭"}, {"post_id": 21522, "ts": "2026-07-03T15:13:57Z", "hours": 1.2167, "text": "So today, while I was STILL waiting for the Pico, I built a reaction time based game, and a burglar alarm in Wokwi, with the help of the PDF book I’ve mentioned before. By this, I’ve learnt how to use the urandom library in Micropython, which I think will be really useful with R2D2 ‘s flashing lights, and sounds, and with the burglar alarm I’ve learnt how to connect, and use a sensor with the Pico. Putting sensors in R2D2 is a secondary, and a long-term goal, but it would be really nice. I hope that after this, I’ve learnt the basics of Micropython, so I think I’ll start focusing on our actual project, R2D2. (I don’t know when will the Pico arrive, so this is a major limiting factor) IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT"}, {"post_id": 19433, "ts": "2026-06-30T19:12:12Z", "hours": 1.4111, "text": "So, today I’m still waiting for the Pico, so I’m still using Wokwi, and the PDF book, to learn, and practice. Today I’ve made a traffic light, which is working by continuously alternating red, yellow and green lights. It worked just fine, until I added a feature, so when a “pedestrian” pushes a button, a buzzer makes 10 beeps, and the light switches to red for the “cars”. This seemed to be too much for Wokwi, and it kind of crashed, so I relied on the PDF book, to verify the code, and the wiring. IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT"}, {"post_id": 18293, "ts": "2026-06-29T12:06:59Z", "hours": 1.1833, "text": "Today, I was still practicing Micropython, and connecting circuits in Wokwi’s Raspberry Pi Pico simulator, with the help of the “Get Started with MicroPython on Raspberry Pi Pico” book. I’m still waiting for the delivery, so I can’t do it physically yet, but I think it’s still a great way to learn, and it even lacks the risk of frying anything. I succesfully made an LED blink, and connected a four-legged push button to the Pico. The final “project” of this session was building a circuit, so when you push the button, the LED lights up. I had a little problem with this, so I took the help of Gemini, and we figured out, that I accidentally connected the button to the Pico’s 3V3 EN pin, instead of the 3V3 pin, and I had a missing colon in the code. After fixing, it worked beautifully IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT"}, {"post_id": 15807, "ts": "2026-06-25T18:04:51Z", "hours": 1.1422, "text": "Today, I started to learn micropython for the Raspberry pi Pico WH, which I will use for my team’s R2D2 model. I do not have one yet, im currently waiting for the delivery :) , but I used Wokwi’s Raspberry pi Pico simulator, and the PDF micropython tutorial book, which I found on the original Raspberry Pi website. (well, not exactly there, because it showed me error 404, but I found it on Internet Archives, it’s title is “Get Started with MicroPython on Raspberry Pi Pico”). With the help of these, I learned how to import libraries in micropython, and how to turn on the Pico’s onboard LED. I even programmed it to stay on for a certain amount of seconds. I also used VS Code to try out some basic python loops. IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT"}]...
|
Title: R2D2 model by @benedekkristof16 | Stardance Title: R2D2 model by @benedekkristof16 | Stardance
Devlogs:
Today, I started to learn micropython for the Raspberry pi Pico WH, which I will use for my team’s R2D2 model. I do not have one yet, im currently waiting for the delivery :) , but I used Wokwi’s Raspberry pi Pico simulator, and the PDF micropython tutorial book, which I found on the original Raspberry Pi website. (well, not exactly there, because it showed me error 404, but I found it on Internet Archives, it’s title is “Get Started with MicroPython on Raspberry Pi Pico”). With the help of these, I learned how to import libraries in micropython, and how to turn on the Pico’s onboard LED. I even programmed it to stay on for a certain amount of seconds. I also used VS Code to try out some basic python loops. IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT
Today, I was still practicing Micropython, and connecting circuits in Wokwi’s Raspberry Pi Pico simulator, with the help of the “Get Started with MicroPython on Raspberry Pi Pico” book. I’m still waiting for the delivery, so I can’t do it physically yet, but I think it’s still a great way to learn, and it even lacks the risk of frying anything. I succesfully made an LED blink, and connected a four-legged push button to the Pico. The final “project” of this session was building a circuit, so when you push the button, the LED lights up. I had a little problem with this, so I took the help of Gemini, and we figured out, that I accidentally connected the button to the Pico’s 3V3 EN pin, instead of the 3V3 pin, and I had a missing colon in the code. After fixing, it worked beautifully IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT
So, today I’m still waiting for the Pico, so I’m still using Wokwi, and the PDF book, to learn, and practice. Today I’ve made a traffic light, which is working by continuously alternating red, yellow and green lights. It worked just fine, until I added a feature, so when a “pedestrian” pushes a button, a buzzer makes 10 beeps, and the light switches to red for the “cars”. This seemed to be too much for Wokwi, and it kind of crashed, so I relied on the PDF book, to verify the code, and the wiring. IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT
So today, while I was STILL waiting for the Pico, I built a reaction time based game, and a burglar alarm in Wokwi, with the help of the PDF book I’ve mentioned before. By this, I’ve learnt how to use the urandom library in Micropython, which I think will be really useful with R2D2 ‘s flashing lights, and sounds, and with the burglar alarm I’ve learnt how to connect, and use a sensor with the Pico. Putting sensors in R2D2 is a secondary, and a long-term goal, but it would be really nice. I hope that after this, I’ve learnt the basics of Micropython, so I think I’ll start focusing on our actual project, R2D2. (I don’t know when will the Pico arrive, so this is a major limiting factor) IT IS JUST LEARNING THE BASICS, NOT THE ACTUAL PROJECT
A problem occurred during the delivery if the Pico, so it got retured to the sender. We had to order it again, so until it arrives, I thought I could learn actually how to control the DC motors with it, with the help of a TB6612FNG motor driver which we will be using. I asked Gemini to explain it to me, without providing exact codes, to ensure I actually understand the code, and not just copy-pasteing. It gave me a great youtube tutorial too, from Electro Nerds Academy, which used Arduino (and therefore C++), but it helped me understand the core principles of the wiring, and the code EDIT: This was BEFORE I was aware of the rule which states that we should not log too much continuous time spent watching youtube. This was only the learning phase, and I tried making it as active as possible, by building my own version on the way. If it is against the rules, please just ignore the time logged in this post. I don’t know if it is possible, but I’m pretty freaked out my entire summer work gets flushed down the toilet😭😭
Today, I got the Pico!!! Immediatelly I started to load up micropython on it, and download Thonny. It was a bit tricky, because my antivirus program wouldn’t let me download it, but I disabled it temporarily, and it worked just fine. And I quickly reviewed the first few pages of my PDF book, to make sure I know my Pico physically, not just the Wokwi version. After that I wanted to try it out with the onboard LED, but it didn’t worked, so I asked Gemini. I found out that my Pico, is actually Pico W, and the onboard led is a little different. After that it worked beautifully. Then I wanted to light up an external LED, and guess what, it also didn’t work! I started troubleshooting with Gemini on my side, and I found out, that my breadboard’s ground rail is probably damaged. After rewiring to bypass it, it lighted up!
Today I wrote the prototype of the code, which will control the motion of R2D2. The original version will control it wirelessly, along with the sounds and ligths, but this controls only the motors yet, via a microUSB cable. I wrote it in VSCode, and I will only copy it to Thonny (which i’ll be using for the Pico) when it is fully completed. I took the help of Gemini, to explain me how to control it (the robot, eventually) using my keyboard, and with the final debugging. I also watched Electro Nerds Academy’s youtube video in the process, which explains how to control the TB6612FNG motor driver with Arduino, and C++, I did this to make sure I understand the process. I still have a lot to learn, but slowly and surely, R2 will roll!
This time, I collected multiple days’ work for this devlog. I started by brainstorming with Gemini (by now I must be their top user, lol) about what motor would be best for turning R2’s head. We’re planning LEDs in the head, so I had to make sure it cannot rotate all the way around, because this would break the wires. I came to the conclusion, that a custom 3D printed gear mechanism would be best, with a 28BYJ-48 stepper motor, and a ULN2003 board, and rotation limits in the software. I watched videos on Youtube, and also asked Gemini to explain to me how to write a code to control the stepper motor. The code is not yet complete, I’ll have to add a “homing mechanism”, which would help the head find it’s position at startup.
This time I coded the homing sequence, which will help R2 center it’s head using the stepper motor. There will be an infrared sensor in the head, and at startup, R2 will turn its head slowly left, until the sensor detects it, and after this, the code will set the step count to 0. After this the head will automatically turn to look forward, while counting the steps. This is necessary to ensure that the head will move only in the safe limits, no matter in which position it was at startup. I took the help of Gemini at debugging.
So this time, I finally wired everything for the stepper motor-powered head together! I copyed the part which controls specifically this from my entire code sitting VSCode, just to try this out. I had an old battery holder saved from a toy, to make an external power source, and wired everything together. I checked the wiring with Gemini, to make sure I don’t light anything on fire. After this, well, it did not work… I spent brainstorming, “debugging”, and checking everything twice, until I realized the “bug” which prevented the motor spin, was the very common “missing battery” error. So I put it in, and after some fine tuning on the code, it worked really nice
Today, I added the sensor for the homing sequence of R2’s head! This way, at startup, the head will start to turn, until it hits the infrared sensor, then go back to the middle. This way it is ensured, that no matter what position was the head at startup, it won’t go beyond the safe limits
This time, I’ve finally made the wireless part! I started by, as you probably guessed it already, by brainstorming with Gemini! I asked it to give me tutorials on youtube, on how to make my robot wirelessly controllable, since I have a Pico W, as well as explain it himself. At first, I’ve went down a little rabbit hole, because I wanted to build a simple website, with buttons, to control R2D2. I quickly realized after peeking into college-level tutorials, that it far exceeds my capabilities at the moment, so I asked my good ol’ friend, Gemini, to give me a bit of a simpler solution. After some deep discussions, and watching a nice old man on youtube explaining it, I decided on non-blocking UDP socket polling, with the help of an external app. This will work by downloading an app to my phone (or anyone’s phone, who wants to control R2), agreeing on an ip address, and port number, then typing the letters, which represents the w, a, s, d, etc. keys. It may not look pretty, but it’s just as effective, and MUCH simpler.
This time, I made the main power lines of R2D2! I started by soldering 3 wires (three positive, and three ground) to the battery holder, which will be the cozy home of two 18650 Li-Ion batteries. I connected a 5 volt buck converter to one of the lines, which will power the Pico, and a voltage divider to the next one, to help the Pico measure the batteries’ voltage, and give me a warning (eventually using R2’s LEDs) of low voltage. There is not connected anything yet to the third line, because the motor driver will be powered using this, but that soldering would be really hard with my setup, and I don’t know if I could safely do it. So I think I will ask an adult acquintance of mine, who works with electronics, to do that one for me.
Today I tested the battery voltage measuring feature, I last time made! I put in the batteries, wired it up, copied this specific part of the code in Thonny, told it to print the voltage, aaaannd when I checked with the multimeter, it was waaay off, lol. I was baffled, because the voltage my Pico measured was MORE than a full volt below the actual voltage. I immediately started researching, (by asking Gemini… of course…. I start to feel guilty for all the trees and water I waste), and it said to me that it is likely due to resistors are not perfect, this is why they have a TOLERANCE band, and I should start a different approach. It suggested that I should calculate a factor, by dividing the voltage of the batteries measured with a multimeter, by the raw ADC value my Pico reads, then multiply with that with the raw ADC value. After fixing this, it gave me roughly the exact value my multimeter had shown. P.S. If I could learn for once, that I HAVE to use period at decimal numbers, instead of comma, I would spend way less time searching for bugs that don’t exist…
So this time, I’ve tried to test the wireless part. I started by downloading a UDP app on my mom’s phone, and rotating the stepper motor with that, but nothing happened. After this I’ve rewritten the code so it does nothing with the motor, but prints the text in the UDP pockets, but still nothing. I’ve downloaded Packet Sender to my laptop, but still nothing. The UDP packets did never reach the Pico. I’ve tried everything the Debug Master Gemini said for more than two hours, but nothing… I think I will ask my friend who is familiar with making websites to write me a lightweight HTML page with buttons, then somehow make it connect to the motor logic. I reallyyy hope that will work.
So this time, I’ve had to update the entire code. So, as I’ve told you guys in my previous devlog, I’ve tried to make R2 wireless with UDP, but it did not work for some reason. Because of this, we decided to try another method. We will host a web server on the Pico! My friend, who knows this stuff, will write a basic HTML code, with buttons, to control R2. For this, I’ve had to go down a little rabbit hole with youtube, google and gemini, to learn how actually this stuff works. After, and along with researching, I’ve had to change a little the structure of my code, and implement new features. I also added LEDs this time! I think the coolest feature is, that R2 will tell us with Morse his IP address, using his LEDs (because he will have different ones based on which wifi network he is currently connected to, and he will have no other way to tell it us). We’ve also made some crucial changes. At first we’ve wanted R2D2 to have sounds, but we will have to omit this one for now, because our lack of time. Also, rather than random flashing, each LED will have it’s own purpose, and they all going to be used for communication.
Hey! I think this will be my last, and my longest devlog! I need to clarify things, and address things, but first– I tell what I did. So I wired up the motor driver (an anquintance of mine helped to solder up the wires which will take the high current to the motors), wired up the LED’s, and put everything in the 3D printed chassis done, and assembled by @TamasLaszloffy777 , with the help of our friends (and my mom :) ). I soldered the wires to the motors, and glued the LED’s in the head. Now comes a list of things, that didn’t work: I copyed the HTML code my friend wrote into my code, but unfortunately I couldn’t get it working. I’ve spent countless hours debugging with Gemini, but as the project got more complex, it gave me more stupid answers. When I tested it with just the stepper motor, it worked, but with everything connected, it didnt. So out of desperation I’ve had to go back the old method I used at testing, which is that everything works with an USB cable. I’ve spent circa 30 minutes changing the code, and commenting out everything that has to do something with the wireless thing. Of course Hackatime didn’t register nothing out of this half an hour. This was the main thing why I used Lookout and Lapse for coding before the Ban. But after all, thank God it works now with USB (after some debugging with Gemini of course). This means that the LEDs also lost their purpose as wifi status indicators, so now the project has 2 spare LEDs inside. (I won’t put those in the wiring diagram, since they are not used, but its too much work to take them out. I saved two of them by repurposing them to “head turning indicators”, but left two out, because it would just make it harder for me to take the head off, to access everything inside. Also I plan to fix the wireless part in the future, but not in Stardance). The next thing I noticed, is the homing sequence is pretty useless. Fortunately the wires never twist dangerously, contrary to my previous assumptions, and R2 would have to rotate its head 360 degrees multiple times in a row for it to become dangerous for the wires. I was quite upset that I did the homing sequence, and bought the sensor for nothing, but keeping it would add unnecessary complexity. And unnecessary complexity is NEVER good in a project.(I wont put the sensor into the BOM list, nor into the wiring diagram)
Ships:
I made this project with @TamasLaszloffy777 . My part was the electronics and coding. THe biggest hurdle was, that I’ve had to learn everything from scratch. I only knew basic python, and something about circuits, but only what I’ve learnt in school. This project is a fan-made R2-D2 replica, which is capable of rolling, turning it’s head, and has some LEDs. The project includes a demo link, where you can see it work in real life. Make sure you watch it, and We hope You’ll enjoy it!...
|
1793195722.042937
|
1793282122.042937
|
|
21092
|
The HackClub cloud by @Toma_Kuchta | Stardance
|
Toma_Kuchta
|
1
|
54.0
|
0
|
[{"ship_num": 1, "ts": "2026-1 [{"ship_num": 1, "ts": "2026-10-15T07:09:26Z", "hours": 54.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "So this was my first project I have ever done in a real hackathon. I was in a team with Olivia and she had a beautiful traditional Chinese string instrument and we wanted to merge them both into one beautiful and colorful art piece. And we weren’t able to do that in the end sadly. :( lie it would have look great! ciya", "repo": "https://github.com/Tomas-Kuchta-FPV/The_Hack-Club_cloud", "demo": ""}]...
|
[{"post_id": 79722, "ts": "202 [{"post_id": 79722, "ts": "2026-10-15T06:57:50Z", "hours": 2.1853, "text": "Oh neat extra forgotten hours. It’s probably from when I was doing something and didn’t devlog it. sorry for this one. BC IDK what I was doing and don’t recal anything."}, {"post_id": 56134, "ts": "2026-07-17T00:00:00Z", "hours": 6.7, "text": "So we’ve unpaked everything from the ClayHaul and asseced the damage on the led wall. And oh boy all the pillow fill fell from it. So after more figuring out from where to get spray adhereve it turned out that it was in a repair booth, how convinient. Also like a lot of solder connections were tore up from the transport so I’ve repaired those, glued on the pillow fill and it worked great!! Oh yeah and then Gwendal figured out how to play games on the matrix with wled!!!!"}, {"post_id": 56133, "ts": "2026-07-16T00:00:00Z", "hours": 9.0, "text": "Allright so after that mess we’ve locked in hard. While my temate was repairing her project (She did that for almost the whole hackathon, which is crazy). I began soldering and gluing on the LED strips. Then remembered that it would be great to screw in the screws (With the DIY shitty screwdriver), resumed work on the LED strips. Allright and now we have around two hours left. After everything was soldered I’ve turned it on and it didn’t work. First there were problems with WLED configuration and then with one segment that was dead. Soooo after a “quick hour fix” The LED matrix was working. But we still have just a hour left to ship it. So I’ve quickly done some plywood gymnastic with spare people and put the whole contraption on chairs screwed in the legs and stood it up. Oh yeah it was working!!!!! OH no my teamate was still working on her project, so we needed to pivot. I had prepaired the repo for shipping while she sprayed adhesive on the board and glued the pillow fluff on. It was a messs. But we managed to do it in time lol. After that we had a short visit from our favorite creators, packed everything and went partying! They even had a B-day cake for me how lovely! Thank y’all! Here is a little video we’ve filmed. PS: I didn’t take a photo of the final build as I was so bussy!!!!"}, {"post_id": 56132, "ts": "2026-07-15T00:00:00Z", "hours": 10.0, "text": "So this day was spent by asking people around if we can PAINT! I thought we can atlest do some things that are not really needed but there wasn’t much though. So the whole morning was spent asking if we can paint as it was promised to happen now, but everytime I was told off. So I’ve procrastinated instead with talking to people lol. After it we all went on a picnic and we got back by around 4 pm. Allright no more staling we have layed down the OBS boards and began gluing on the led strips which we have precut yeasterday. And while gluing on the strips I went to another round of asking around for a saw, but this time dhamari helped me soooo much!!! <3 So after yesterdays pain with a small metal saw I’ve managed to borrowed a great stanley saw from a framing shop nextdoor. Nice!! Aaaaaaaaaaahhhhhh so I’ve finally managed to cut down the wood. Oh also we don’t have a scredriver so we’ve made our own scrappy one."}, {"post_id": 56131, "ts": "2026-07-14T00:00:00Z", "hours": 6.7, "text": "Mys first task was finding a teamate in which I failed horibly as I wasn’t able fo find anyone. I’m normaly social but it was different here as I was speaking a different language, and just a lot of first times (USA, Solo flight, long haul flight, hackathon, new people, different culture) … yeah it was overwhelming. And did I mention that I was on a family and frinds gathering in the middle of novehwre! So my plan was to when I land go to lowes and bring back all the stuff needed with yaha, but by the time I’ve came from the airport I wouldn’t have enough time to make it in time for the opening ceremony. So yaha came there by himself, picked up and rode it in an uber - just in time nice!!!! Also my plan was to spray paint the OSB light blue at lowes but that didn’t happen so I’ve bugged staff for the whole evening if there is a place that we can paint it, I weren’t to a more disorganized even in my whole life! It was chaos on all fronts."}, {"post_id": 56130, "ts": "2026-07-14T00:00:00Z", "hours": 1.5, "text": "So after a bit of setup I had like 18hr traveling to the venue. The leg to Frankfurt was great but the flight to San Francisco was super long and I didn’t know what to do. But in the last two hours of flight I’ve remembered that I need to finish the animations for the LED matrix. ’*sad"}, {"post_id": 14521, "ts": "2026-06-23T17:40:25Z", "hours": 2.9719, "text": "After shipping yesterday I had today started working on riping TwinkleTron out of my table, and overwriting it with the latest FW. Then I began configuring it. I have set up the LED strip channels as one can only do 800 LED’s reliably. It was split in the middle by 576 pixels. After I peeked into the matrix config set up the defined matrix size and it didn’t look right. Went to readme to spot the mistake ant it was because I’ve wrongly converted from mm to cm. OR so I thought. It was the whole calculation that was wrong. 🤦♂️ MATHS Boink I got an notification that my ship was rejected and needs changes. (No images in readme and no BOM) Back to the project, and after a few blank stares into the readme and also the CAD file I’ve managed to at least hopefully correctly calculate the needed LEDs. SO I had to redesign the power delivery section. Updated the repo for requested changes and shipped it back out. PS: I also managed to get the price down :yay"}, {"post_id": 13753, "ts": "2026-06-22T15:19:42Z", "hours": 4.2097, "text": "Allright I’m almost finished!! So first thing I did today was cleaning up the repo and pushing the yesterdays changes. Then I went on to do the drawing of the stand that will hold the LED matrix, I’ve tried to even show the LED strips in there but FreeCAD couldn’t handle it, so I sketched it up in draw.IO. with a kinda like a block diagram. Wrote about the intended SW in the readme. And then I’ve created the vision board so anybody can get the idea about the project, which is going to get shipped as a demo The whole time I was thinking about how I’ll create a render in blender for it with cloud simulation, but it didn’t work yesterday. But I got inspiration from some YT video that mocked it up with photoshop. So I hopped into affinity and started designing after a tutorial which I couldn’t follow, so I’ve found an online texture export and inported it into affinity tweaked it and it worked. But then I need some kind of backgroud for it, so I took akemi from the WLED effects website and blurred it out behind the cloud layer. Yeah it didn’t look right. And ChatGPT halucinated completly different thing. But after a bit of tweaking I managed to make it work. And after all of that I have threw everything into the shipping baskets, wrote down the price. And going to ship soon …. Good luck"}, {"post_id": 13086, "ts": "2026-06-21T12:46:37Z", "hours": 2.2622, "text": "Today I had done the schematic. It’s going to be a pretty interesting concept as the wiring is wild different to other matricies. We need almost 120m of LED strips. And they are going to draw almost 2 000W. It’s going to be an electric kettle lol. Because of that I have added two power cables to power the thing, as 220V is better for this. *laughs in geman. I have started creating the schematic in DrawIO. First was the PSU along with the two heavy duty cables I’ve mentioned earlier. Then it’s going to WAGO connectors which will be our power distribution and then it’s going to be distributed to the LED power injection points. Next I did a block diagram in it for the LED matrix, but it wasn’t really clear how to connect it up so I’ve hopped into tinkercad and did a small scale schematic with all of the right features. Next up is: Doing drawings of the the LED strip placement and / adding the 2x4 supports as well as the PSUs Ask my brother if he can try to visualize it in blender Create instructions for building at outpost or at home lol"}, {"post_id": 12752, "ts": "2026-06-20T21:01:24Z", "hours": 3.6581, "text": "So after that last pivot I’m super happy how this project is turning out. I hope that other people loves it as much as I do. But firstly I wanted to move the repo as the original is getting cluttered and it’s a mess. so new repo it it. And it’s also getting a rebrand from generic MatrixShow it’s going to be called The Hack Club cloud, symbolizing the many great ideas of Hack Clubbers. Well this one isn’t going to be about me it’s about ya’lls creativity passion and perseverance. And this sounds so epic in my head! So after a bit of philosophy. I went to look for suitable LED strips they were either super expensive or didn’t meet my criteria. And after a while I was able to find them, neat! So everything else was based around them, like the rows spacing, read more about that in my repo. https://github.com/Tomas-Kuchta-FPV/The_Hack-Club_cloud/blob/main/readme.md#constraints Alright and then I done the 3D model for the matrix. Which turned out OK, but it’s looking too much technical, but I can make drawing for it that we’ll use when building. Peace out Thomas"}, {"post_id": 11833, "ts": "2026-06-19T08:30:07Z", "hours": 1.915, "text": "So I need to pivot as it’s going to be super expensive! It’s going to be like 300 bulbs, which is feasible but it needs to be a huge budget. It would be fun thought, as I was on planning to use American electrical material. BTW I love the flat cables! So at first I’ve pivoted to making a addressable LED Christmass string light matrix. So basically drill out thousand of holes and plop them in an interval of about 15cm, but that wouldn’t have the right WOW effect. So there was another pivot to cheaper LED strips, which is doable!!! So I’ve decided to make a 4x8ft cloud wall!! It’s going to be addresable and it will be driven by my custom WLED LED controller called TwinkleTron. I still need to CAD it and spec the PSU, but it’s going to be awesome!!!!!!!"}, {"post_id": 11183, "ts": "2026-06-18T09:12:38Z", "hours": 2.9239, "text": "So I’ve defined BOM, and made a sketch of the matrix. A halve a year ago I had a light exposition in my hometown which turned out very good. So I want to use the current tested setup, which are Smart sonoff lightbulbs. So I’ve made a BOM around it. And CADed it. But when in CAD I’ve noticed that it’s like 300 smart bulbs and it’s going to be super expensive. So after finding out that this route isn’t good I’m going for a WS2811 addressable lights."}]...
|
Title: The HackClub cloud by @Toma_Kuchta | Starda Title: The HackClub cloud by @Toma_Kuchta | Stardance
Devlogs:
So I’ve defined BOM, and made a sketch of the matrix. A halve a year ago I had a light exposition in my hometown which turned out very good. So I want to use the current tested setup, which are Smart sonoff lightbulbs. So I’ve made a BOM around it. And CADed it. But when in CAD I’ve noticed that it’s like 300 smart bulbs and it’s going to be super expensive. So after finding out that this route isn’t good I’m going for a WS2811 addressable lights.
So I need to pivot as it’s going to be super expensive! It’s going to be like 300 bulbs, which is feasible but it needs to be a huge budget. It would be fun thought, as I was on planning to use American electrical material. BTW I love the flat cables! So at first I’ve pivoted to making a addressable LED Christmass string light matrix. So basically drill out thousand of holes and plop them in an interval of about 15cm, but that wouldn’t have the right WOW effect. So there was another pivot to cheaper LED strips, which is doable!!! So I’ve decided to make a 4x8ft cloud wall!! It’s going to be addresable and it will be driven by my custom WLED LED controller called TwinkleTron. I still need to CAD it and spec the PSU, but it’s going to be awesome!!!!!!!
So after that last pivot I’m super happy how this project is turning out. I hope that other people loves it as much as I do. But firstly I wanted to move the repo as the original is getting cluttered and it’s a mess. so new repo it it. And it’s also getting a rebrand from generic MatrixShow it’s going to be called The Hack Club cloud, symbolizing the many great ideas of Hack Clubbers. Well this one isn’t going to be about me it’s about ya’lls creativity passion and perseverance. And this sounds so epic in my head! So after a bit of philosophy. I went to look for suitable LED strips they were either super expensive or didn’t meet my criteria. And after a while I was able to find them, neat! So everything else was based around them, like the rows spacing, read more about that in my repo. https://github.com/Tomas-Kuchta-FPV/The_Hack-Club_cloud/blob/main/readme.md#constraints Alright and then I done the 3D model for the matrix. Which turned out OK, but it’s looking too much technical, but I can make drawing for it that we’ll use when building. Peace out Thomas
Today I had done the schematic. It’s going to be a pretty interesting concept as the wiring is wild different to other matricies. We need almost 120m of LED strips. And they are going to draw almost 2 000W. It’s going to be an electric kettle lol. Because of that I have added two power cables to power the thing, as 220V is better for this. *laughs in geman. I have started creating the schematic in DrawIO. First was the PSU along with the two heavy duty cables I’ve mentioned earlier. Then it’s going to WAGO connectors which will be our power distribution and then it’s going to be distributed to the LED power injection points. Next I did a block diagram in it for the LED matrix, but it wasn’t really clear how to connect it up so I’ve hopped into tinkercad and did a small scale schematic with all of the right features. Next up is: Doing drawings of the the LED strip placement and / adding the 2x4 supports as well as the PSUs Ask my brother if he can try to visualize it in blender Create instructions for building at outpost or at home lol
Allright I’m almost finished!! So first thing I did today was cleaning up the repo and pushing the yesterdays changes. Then I went on to do the drawing of the stand that will hold the LED matrix, I’ve tried to even show the LED strips in there but FreeCAD couldn’t handle it, so I sketched it up in draw.IO. with a kinda like a block diagram. Wrote about the intended SW in the readme. And then I’ve created the vision board so anybody can get the idea about the project, which is going to get shipped as a demo The whole time I was thinking about how I’ll create a render in blender for it with cloud simulation, but it didn’t work yesterday. But I got inspiration from some YT video that mocked it up with photoshop. So I hopped into affinity and started designing after a tutorial which I couldn’t follow, so I’ve found an online texture export and inported it into affinity tweaked it and it worked. But then I need some kind of backgroud for it, so I took akemi from the WLED effects website and blurred it out behind the cloud layer. Yeah it didn’t look right. And ChatGPT halucinated completly different thing. But after a bit of tweaking I managed to make it work. And after all of that I have threw everything into the shipping baskets, wrote down the price. And going to ship soon …. Good luck
After shipping yesterday I had today started working on riping TwinkleTron out of my table, and overwriting it with the latest FW. Then I began configuring it. I have set up the LED strip channels as one can only do 800 LED’s reliably. It was split in the middle by 576 pixels. After I peeked into the matrix config set up the defined matrix size and it didn’t look right. Went to readme to spot the mistake ant it was because I’ve wrongly converted from mm to cm. OR so I thought. It was the whole calculation that was wrong. 🤦♂️ MATHS Boink I got an notification that my ship was rejected and needs changes. (No images in readme and no BOM) Back to the project, and after a few blank stares into the readme and also the CAD file I’ve managed to at least hopefully correctly calculate the needed LEDs. SO I had to redesign the power delivery section. Updated the repo for requested changes and shipped it back out. PS: I also managed to get the price down :yay
So after a bit of setup I had like 18hr traveling to the venue. The leg to Frankfurt was great but the flight to San Francisco was super long and I didn’t know what to do. But in the last two hours of flight I’ve remembered that I need to finish the animations for the LED matrix. ’*sad
Mys first task was finding a teamate in which I failed horibly as I wasn’t able fo find anyone. I’m normaly social but it was different here as I was speaking a different language, and just a lot of first times (USA, Solo flight, long haul flight, hackathon, new people, different culture) … yeah it was overwhelming. And did I mention that I was on a family and frinds gathering in the middle of novehwre! So my plan was to when I land go to lowes and bring back all the stuff needed with yaha, but by the time I’ve came from the airport I wouldn’t have enough time to make it in time for the opening ceremony. So yaha came there by himself, picked up and rode it in an uber - just in time nice!!!! Also my plan was to spray paint the OSB light blue at lowes but that didn’t happen so I’ve bugged staff for the whole evening if there is a place that we can paint it, I weren’t to a more disorganized even in my whole life! It was chaos on all fronts.
So this day was spent by asking people around if we can PAINT! I thought we can atlest do some things that are not really needed but there wasn’t much though. So the whole morning was spent asking if we can paint as it was promised to happen now, but everytime I was told off. So I’ve procrastinated instead with talking to people lol. After it we all went on a picnic and we got back by around 4 pm. Allright no more staling we have layed down the OBS boards and began gluing on the led strips which we have precut yeasterday. And while gluing on the strips I went to another round of asking around for a saw, but this time dhamari helped me soooo much!!! <3 So after yesterdays pain with a small metal saw I’ve managed to borrowed a great stanley saw from a framing shop nextdoor. Nice!! Aaaaaaaaaaahhhhhh so I’ve finally managed to cut down the wood. Oh also we don’t have a scredriver so we’ve made our own scrappy one.
Allright so after that mess we’ve locked in hard. While my temate was repairing her project (She did that for almost the whole hackathon, which is crazy). I began soldering and gluing on the LED strips. Then remembered that it would be great to screw in the screws (With the DIY shitty screwdriver), resumed work on the LED strips. Allright and now we have around two hours left. After everything was soldered I’ve turned it on and it didn’t work. First there were problems with WLED configuration and then with one segment that was dead. Soooo after a “quick hour fix” The LED matrix was working. But we still have just a hour left to ship it. So I’ve quickly done some plywood gymnastic with spare people and put the whole contraption on chairs screwed in the legs and stood it up. Oh yeah it was working!!!!! OH no my teamate was still working on her project, so we needed to pivot. I had prepaired the repo for shipping while she sprayed adhesive on the board and glued the pillow fluff on. It was a messs. But we managed to do it in time lol. After that we had a short visit from our favorite creators, packed everything and went partying! They even had a B-day cake for me how lovely! Thank y’all! Here is a little video we’ve filmed. PS: I didn’t take a photo of the final build as I was so bussy!!!!
So we’ve unpaked everything from the ClayHaul and asseced the damage on the led wall. And oh boy all the pillow fill fell from it. So after more figuring out from where to get spray adhereve it turned out that it was in a repair booth, how convinient. Also like a lot of solder connections were tore up from the transport so I’ve repaired those, glued on the pillow fill and it worked great!! Oh yeah and then Gwendal figured out how to play games on the matrix with wled!!!!
Oh neat extra forgotten hours. It’s probably from when I was doing something and didn’t devlog it. sorry for this one. BC IDK what I was doing and don’t recal anything.
Ships:
So this was my first project I have ever done in a real hackathon. I was in a team with Olivia and she had a beautiful traditional Chinese string instrument and we wanted to merge them both into one beautiful and colorful art piece. And we weren’t able to do that in the end sadly. :( lie it would have look great! ciya...
|
1793199282.3201427
|
1793285682.3201427
|
|
21093
|
High Voltage Launch Controller by @percentchunk376 High Voltage Launch Controller by @percentchunk376 | Stardance...
|
percentchunk376
|
1
|
1.86
|
5
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-17T20:20:46Z", "hours": 1.0, "multiplier": 5.0, "payout": 5, "blessing": "neutral", "text": "I made the first wiring plan and schematic for my high voltage launch controller. It uses a key switch, flip cover switch, momentary safety button, continuity led, buzzer, and large red launch button. The hardest part was figuring out the correct wiring order. I had to make sure the launch output only works after all the safety switches are active, and the continuity LED can still safely test the igniter connection. I am proud that the schematic now has a clear safety path Each part has a cool job, and gives a really good launch. To test it , I advise following my video demo, because it shows the safety features in action, and gives a pretty good idea on how it works.", "repo": "https://github.com/percentchunk/The-Greatest-Launch-Controller-Ever", "demo": ""}]...
|
[{"post_id": 41601, "ts": "202 [{"post_id": 41601, "ts": "2026-08-05T22:02:09Z", "hours": 0.8575, "text": "Just resubmitting heres some ksp gameplay idk if im gonna get in trouble"}, {"post_id": 10857, "ts": "2026-06-17T20:08:53Z", "hours": 0.9997, "text": "For my project, I am building a high voltage model rocket launch controller designed to be safer, more intentional and way cooler then the basic ones sold for $50 dollars. The goal is to make a controller that uses multiple safety steps before ignition can happen, including a key switch, flip- cover, continuity led, warning buzzer, momentary safety button, and a large red launch button. The schematic is built around a safety path. The key switch acts as the first lockout, making nobody random can use it. The wiring was most important due to needing to prove continuity by sending a small enough current not to set off the ignitor. after that, it was a series of setting roadblocks for the current, and allowing the full power to go through on all safeties were off. In overview, most controllers send about 2 amps due to that being only what is needed to set off the ignitor. Mine sends 6 amps practically exploding the ignitor getting a better rocket launch."}]...
|
Title: High Voltage Launch Controller by @percentc Title: High Voltage Launch Controller by @percentchunk376 | Stardance
Devlogs:
For my project, I am building a high voltage model rocket launch controller designed to be safer, more intentional and way cooler then the basic ones sold for $50 dollars. The goal is to make a controller that uses multiple safety steps before ignition can happen, including a key switch, flip- cover, continuity led, warning buzzer, momentary safety button, and a large red launch button. The schematic is built around a safety path. The key switch acts as the first lockout, making nobody random can use it. The wiring was most important due to needing to prove continuity by sending a small enough current not to set off the ignitor. after that, it was a series of setting roadblocks for the current, and allowing the full power to go through on all safeties were off. In overview, most controllers send about 2 amps due to that being only what is needed to set off the ignitor. Mine sends 6 amps practically exploding the ignitor getting a better rocket launch.
Just resubmitting heres some ksp gameplay idk if im gonna get in trouble
Ships:
I made the first wiring plan and schematic for my high voltage launch controller. It uses a key switch, flip cover switch, momentary safety button, continuity led, buzzer, and large red launch button. The hardest part was figuring out the correct wiring order. I had to make sure the launch output only works after all the safety switches are active, and the continuity LED can still safely test the igniter connection. I am proud that the schematic now has a clear safety path Each part has a cool job, and gives a really good launch. To test it , I advise following my video demo, because it shows the safety features in action, and gives a pretty good idea on how it works....
|
1793278036.5618157
|
1793364436.5618157
|
|
21103
|
Ritualia by @gabriel_ferreira | Stardance
|
gabriel_ferreira
|
1
|
148.7
|
2310
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-23T23:45:29Z", "hours": 148.0, "multiplier": 18.45, "payout": 2310, "blessing": "neutral", "text": "What did i made I made an complete music play system that will help users to learn while listening to musics! I used youtube, flask, python, mysql, js and hope to make this! What else Solved a lot of painful bugs that were stopping the project from working Finished and made the music queue work Added music description labels Improved a lot the performance Made the website responsive Added a keyboard based navigation Fixed so much errors at the cover-flow that now i forgot how many Added bug checks before the play of each video on the player Created an toast component to show errors or infos Added 54 musics to choose and listen Challenges The most painful code was the player and the cover-flow, they were with a lot of hidden bugs that i had to figure out, feats that i had to make and pain to suffer! Now i figured out that i love and HATE making a website responsive! What im proud of MutationObserver: An observer that loads / hides an image based on its position at the cover-flow, this system took a while and worked very well. Error checks at player: The system can handle the error that happen and dont crash! Keyboard navigation: Everyone can use the keyboard to navigate now! Oracle VM: For the first time i used an ssh and hosted an website in my own machine (oracle, not mine)! How to test Access http://ritualia.duckdns.org/ , when you join and the page loads you will find a screen to choose an genre, select which one you want, after you will see an emotion selector, select the emotion that you wanna feel! You will see the player screen and an audio explaining the music (The audio is in portuguese), after the audio the music will play. Notice: The github and the website are in portuguese, please use your browser built-in translator or any that you want to use the software properly! Follow the installation guides at github if you want to install", "repo": "https://github.com/GF-Silva/Ritualia", "demo": "https://ritualia.hackclub.app"}]...
|
[{"post_id": 73067, "ts": "202 [{"post_id": 73067, "ts": "2026-09-24T09:47:16Z", "hours": 0.6983, "text": "Added english readme I created an english readme, api and install Guide, so it will be easier to read and more accessible for worl-wide users"}, {"post_id": 72881, "ts": "2026-09-23T22:36:56Z", "hours": 0.3906, "text": "It is time to ship! Now the system is working perfectly fine running at a vm in oracle cloud with a public domain, and a dns with duckdns at http://ritualia.duckdns.org/ Warning: It is just HTTP!"}, {"post_id": 72810, "ts": "2026-09-23T19:36:13Z", "hours": 1.3461, "text": "Configuring an ssh server! I configured an oracle cloud vm with ubuntu to host my website 24/7, that was because nest wasnt working in a while. Im running it at a local IP with http only, i will configure https today and maybe an domain, the IP is http://164.152.55.252 , notice that some browsers may block you from accessing and http website. UPDATE AFTER THE DEVLOG: I put an domain using duck dns: http://ritualia.duckdns.org Hardwork I had absolutely not a single knowledge about oracle cloud vm, so configuring it was an hell. Sometime my internet stopped working so i had to use my smartphone, this lead me to configuring an invalid ssh key and i had do configure everything from scratch, i spent 5 hours configuring everything, but that was ssh and wasnt tracked. But now everything is working fine. Thx oracle This vm is a 24/7 entire OS (Virtual Machine) that has some good free plans, without any cold start. Thx stardance Stardance now will have one more mount!!!!!! I still has roughly 40 hours of deep development to do after this ship, i will love to finish that in stardance!"}, {"post_id": 70936, "ts": "2026-09-20T02:22:48Z", "hours": 2.9706, "text": "Added install guides Now there is guides to help the user install for ubuntu, arch and windows. Notice that im a linux user and my pc is weak, so i could not test it on another operational system. Also the guide is in portuguese (all of them), please use your browser built-in translator or any of them to read if u dont understands portuguese I could test it on another linux distro, but i would have to go through all the install steps. Also i cannot try installing windows because it normally wipe out another OS installed on the same disc (i know that it just replaces the bootloader) and using a VM was not possible due to the amount of RAM and the processor that i have."}, {"post_id": 69913, "ts": "2026-09-18T01:53:38Z", "hours": 0.3256, "text": "All done, it is time to ship Every metric at lighthouse it nearly perfect, im so exited to ship it!"}, {"post_id": 69904, "ts": "2026-09-18T01:19:42Z", "hours": 4.9561, "text": "The accessibility workings is done Features Now the system has a new navigation system that allow users to navigate with just the keyboard! (The video was with just the keyboard) Why Why not? It was meant to improve the accessibility for users without mouse, or any another problem and because i was tired of having to use the mouse to debug something. How it was made Again with a lot of pain, the feature itself was easy but i had to fix some errors that went unnoticed, so it took more time. The feature detects when the user press a key and do an action based on wich key was. The accessibility was easy to get 100, but the metrics at lighthouse dont give all what the users will need, i had to think about the website usage and how would be the easiest way for the user. Results The accessibility went from nearly 69 to 100! What next Now i will work on the best practices! Update after the devlog: Nearly every metric is already maxed out lol, i will ship it very soon!"}, {"post_id": 69444, "ts": "2026-09-17T02:13:13Z", "hours": 1.6906, "text": "The performance workings is finished and bug fix Fixes Now the logo z-index is lower, that is because the logo was ‘eating’ the click in more important elements. Also i did a small change at the cover-flow, that change fix the bug of the scroll at the element sudently stoping when at a certain position. The copa script had some old references to images that were leading to bugs, i changed it. Performance I already finished it in the past devlog, i was just checking if there was anything worth improving, but everything is working fine and now is time to improve acessibility. Most of the logged time was me trying to improve more some metrics at the lighthouse, but the work was too much for anything that is already good, so i decided to stop before i started focusing too much in it."}, {"post_id": 69395, "ts": "2026-09-16T23:43:00Z", "hours": 1.505, "text": "Fixing an error at the youtubeHelper Now the youtubeHelpers checks if the youtube API is ready before sending commands. Why Sometimes the API maybe is not finished yet, that was leaving an untreated error that was braking the entire website. How was made With a lot of pain and suffer. I thought “Oh hey, that will be a 15 minutes fix” - i spent 1 HOUR FIGHTING with the iframe itself, nothing was working and at some point i started thinking that even the API of YOUTUBE wasnt working, even the most basic function that should be triggered when the youtube finished the loading wasnt beeing activated, even the console.log(“Api READY!”) wasnt working, even when it worked it wasnt working well, the variable of the player was a promise and not the result. At the end i shut down my PC, defeated, without any energy left, with just hope that in the next day (this) that would be fixed (if not i was planning to ignore and make it a feature “Easter egg, if u dont join the website for a while it will not load!”. The problem here was just the position were the iframe api was in the HTML, it was being loaded before the helper script, so the helper was not there to check if it the iframe was ready or not, the fix was just move it a little down. Architecture It was just an promise, if the function checks that the iframe isnt available it await for it to be available. The check if it was available use the onYoutubeIframeAPIReady, easy easy (except for all the suffer that i went into)."}, {"post_id": 68896, "ts": "2026-09-15T23:59:43Z", "hours": 1.1389, "text": "The loading is done and working! Fix I fixed the error that were happening when the cover had a certain amount of elements. Problems The fix itself was very easy to do, but doing it in a readable or without using 10 lines of code (i want things concise) was way harder than i expected. So i spent this entire time trying different ways to do it, each of them making everything worse. Reasoning The bug were with less than 14 elements, the script were calculating the first and last element index, it happened that these elements were behind the screen focus. Why? Because the values that the system was using were leaving these values, so i had to fix the way it was calculating things."}, {"post_id": 68865, "ts": "2026-09-15T22:15:27Z", "hours": 1.3303, "text": "The loading is done Features Now the loading at the mutationObserver is finished, it finally loads or unloads the images that should be (or not) loaded! The new observer is way faster, because it can detect the image way before it enters the screen, loading it before and having more time to do it. Also the system loads just a maximum of images (with the configs that i put it is 13), so it will not fry an cellphone. Problems The loading part was easy to do, i already done it before in the past observer (intersectionObserver), so i just had to pass the old code to the new part. But when the cover-flow element dont got atleast 13 elements the mutationObserver code breaks completely! Im still pondering how to solve it, when i do i will post about! Results The performance went from 78 to 100! The system is way faster! The user does not see a blank image anymore! Why The old method was slow even with a good internet connection, because it was loading the images just when the element was already in the screen, leaving to a perceptive delay for the user and a blank image to the user. Also i thought about creating an observer from scratch (maybe i was a little off my ideas, because that was insane), but the browser already had exactly what i wanted (the mutationObserver) Videos The new features The performance of the new feats The old features Reasoning While i was trying to sleep i thought about a system that fill the cover-flow with a maximum of images (like 10, or 13, or the code decides) at the DOM, using less memory to run. That system will free a lot of memory based on how many cards the cover-flow have. But that will have noticeable effects just with a lot of elements and probably would be hard to develop, maybe i will do in next updates. What next Im leading to the shipping, so i will improve metrics about the lighthouse, improve the readme and post it."}, {"post_id": 68449, "ts": "2026-09-15T04:25:35Z", "hours": 7.2278, "text": "Adding a mutationObserver Now, instead of an intersectionObserver, the system use a mutationObserver that monitors the angle of the cylinder itself. With that the loading of the images will be insanely better, faster and user-friendly. Now the changes in the cover-flow is observed at the cylinder angle, not at each card. There was some problems in the journey like, for some reason, unexpected cards being loaded or not, the loading script at the observer dont triggering at all (that was caused by the speed of the observer) and an insane amount of cards being triggered at the same time (i still did not figured out why, but that isnt ‘harmful’). But man, i had to be creative here and remember about some concepts like concurrent programming, buffer / queue and apply some delays (because the mutationObserver is insanely fast and can trigger every millisecond). That all was meant to decrease the speed of the mutationObserver, because it was triggering with the most small change in the cylinder, so i made it trigger just when an expected amount of movement was made. The red/yellow collor is for me to visualize the loading state, it is just for debug The code isnt finished, i still need to implement the loading part, for now i just implemented the observer and basics of the loading part"}, {"post_id": 67841, "ts": "2026-09-14T03:19:48Z", "hours": 4.2825, "text": "The observer is finished (nearly) Now the cover-flow has an observer that checks the position of the images and changes it styles based on that, so the images that the user is seeing is loaded while the others is hide. It still has some bugs and space for improvements that im still figuring out how to solve, like the image loading too late on the screen or, in slow internet connections, the image takes too long to load. Most of these bugs are because the observer (an intersectionObserver ) was designed for 2d contexts, not 3d (that were and still is an giant problem to solve). For this reason i was thinking about creating an observer from scratch in C++ that can work better in my 3d element, but the overhead would be high so im trying to solve in other ways before that. The feature was made using fetchPriority, contentVisibility and src (the system add the source just when the image is near the screen). OBS: I found about MutationObserver after this post, maybe i will use that instead of insersectionObserver. Oh man, at least if had found about this before… Aaaaaahhhhh i spent 9 hours in that, but at least a Lot of the new logic will be used. Anyway, lets cook"}, {"post_id": 67151, "ts": "2026-09-13T06:53:12Z", "hours": 5.4219, "text": "Adding an observer Now the script observe the card elements at the cover-flow component, classify their position and changes it visibility based on that. Im using an IntersectionObserver to observe every card, but it was designed to observe the position of 2d elements, so i had to figure out how to make it work well in an 3d element. The way it works is when the observe activates (it basically means that some card is in the range to load) it get the card info (like position and angle) and changes it visibility state based on that. Simple, right? No, it was a headache for the start to the top, nearly 4 hours of what i did was to fix the fact that it was meant for 2d. The observer were activating for cards that were in the back of the element, so i had to classify the card position into back or front by using its angle. But if i tried to use the card angle without anything else the script would broke (and did for 3 hours until i realized how to fix), so i had to use an second angle which is 360 - cardAngle (the 360 is the angle of an circle), so this new angle is based on the circle end while the other is based on the circle start. But the system still broke, because at some point one of these values would become negative and makes the if that classify the elements fail. The fix was using the absolute value in the if (it took 1 hour until i figured that; oh i were so happy when it worked). Why To improve the performance, so the browser will just load what is really important and not 50 images that the user cant even see. What else All that work definitely improved a lot my logic thinking and for the first time i used the truth table well. Now i just need to use the new code to change more the style of the images that are not in the screen. I did not deleted the code that i wrote in the past devlog, it was used in the new code to select how many images should be loaded in the same time. ** The first video is the result, the others is some problems that i had **"}, {"post_id": 66316, "ts": "2026-09-12T02:31:12Z", "hours": 4.5481, "text": "Improving the loading performance Now the system selects some images that needs to be shown faster than the others and making them load with priority. It was made by selecting the images that the user is seeing and defining some params like fetchPriority = \"high\" and decoding=\"sync\" , the other images have the params: decoding=\"async\"; loading=\"lazy\"; contentVisibility=\"auto\"; . With that config the LCP went from 2.4s to 0.5s . Also it loads the image in the start and dont change that config again, so the browser will be lazy while downloading these images. The problem is: only the first images are chosen as high priority, but their positions will be changed while the configs stays the same, that makes the browser lazy while loading them and makes the runtime performance became worse. To fix that i found about IntersectionObserver, that are meant to solve the problem of updating the images position fast. It was not applied yet, i found about it like 1 hour ago. What else Now the perspective of the emotionDrum is based on the elements that it have, before it was based just in the screen and would broke if something changes. I did a little change in the way that the script checks for clicks in the screen, now it has more accuracy (I changed the round system)."}, {"post_id": 64533, "ts": "2026-09-09T00:41:52Z", "hours": 7.6869, "text": "Improving the LCP (Largest content paint) performance I am improving the way that the website create and downloads the images, the main reason is to make the user see something faster. Before the system were doing 2 main things: Go trough the entire list of images, creating the elements and placing them into the page. Position them. But the position of the items were being done after the creation of the images, in another function. Now they are in the same function: it create the element, position it and add it to the page. That does not seem like much, but the code got way faster with that, probably because it dont need to go item by item in an list twice just to create an element. I tested the time to load the first element and it went from 8.63s to 6.43s , the test was made with 2200 elements (Yeah ik, it is a lot and normally it isnt that much, but i had to see how they were holding with more than 22 items). Also i fixed a bug that passed unnoticed while improving the responsiveness: At some point of images the visibility of the elements broke, that was because the perspective (what makes the 3D perspective of the component, and makes it visible with 3D effects) was based on the screen size, not the elements itself. What was the problem in that: Each element takes a size in the screen ‘makes the circle that shows the element be more and more near of our point of view’ (i cant explain it any better, search what is ‘perspective in an 3d element at HTML’ ). While it was approaching our point of view (POV), our POV were exactly at the same position (based on the screen size), so at some point the circle perspective would pass the POV and we would be unable of seeing it well. Now it is based on the elements: The 3d elements were basically a circle, i just used the diameter to change the perspective based on it. TODO: Maybe i lowered the image quality too much… I will fix it in the next updates. Also i were trying to improve the font settings to improve the performance, but that wast working so i decided to move on to this because it was more critical (took a while for me to jump to this, maybe like 2 hours trying and trying values in the font settings). i am also working in a way to load the images in parallel, with that it will take way less time (I didnt known about LCP before so i spent a while figuring out the way it works)."}, {"post_id": 63656, "ts": "2026-09-07T16:11:33Z", "hours": 2.6633, "text": "Improving the performance After finishing the improvements in the responsiveness, now i decided to improve the performance. I used lighthouse to get insights (i learned about it in an tiktok video) and figured out that the images size were too high (were an png of 1280x1280px), so i saw more about that in the page: https://developer.chrome.com/docs/performance/insights/image-delivery (an link that google lighthouse gave). With that i saw how to decrease the size while staying with quality, i reached up to the sharp-cli tool, that makes the work of resize, convert and compress the image for me. The command used was that: npx sharp-cli -i * .png -o ./output resize 320 -f avif -q 50 --effort 6 --smartDeblock --preset photo The 320 is the size that i want it to be at the end, i got that value by seeing what was the computed value (the value that is being used in the website) in an high resolution pc (not the most higher one, the high but normal pc) with the resolution of 2500x1714px . With this simple changing the image went from 2mb to 40Kb! Nearly 100% decrease, and take in mind that there is more than one img, so the change were even higher. Also i created 5 different images: 320px, 480px, 640px, 960px e 1280px. With them the browser can choose which one is better for each device. With these changes i went from 35 points of performance to 59."}, {"post_id": 63459, "ts": "2026-09-07T10:10:31Z", "hours": 0.8717, "text": "The home is now fully responsive Ah that took a while, but finally it is fully responsive. Now the description at the player UI resizes based on the screen size and active a scroll behaviour when need, also i did some minor change at the emotionDrum perspective to make it show more emotions at the same time, removed the padding in the arrows at the emotionDrum so they will have more space and fixed an error in the genre drum that was making it perspective broke. After all these devlogs i improved how i make a code responsive."}, {"post_id": 63436, "ts": "2026-09-07T08:55:04Z", "hours": 2.5378, "text": "The emotionDrum is now responsive! Now the buttons that you use to select the emotion are in the same side as the div that displays the emotion, so they dont fight for space anymore. This change is meant to fix the low size of the items in screens that are too small, in the new way we have more free space to display the emotions, there is not much to say. What else I did some minor changes in the size of some items at the player area, now they are easier to read! (I increased the size of some items)"}, {"post_id": 63379, "ts": "2026-09-07T05:17:01Z", "hours": 6.6125, "text": "Im nearly finishing the workings on the responsiveness. Now the entire player screen is responsive and do not breaks the texts anymore (except for the description area), also the buttons that show you the next screen (the ones that displays ‘player’ and ‘generos’) are responsive too, the music queue is working perfectly fine, and the area that is used to select an emotion is nearly responsive too, it just needs some adjusts in the two buttons that change the current emotion because they become too small and uses a lot of space when the screen is too small, after that this screen will be finished. It is taking a really long time, the fact of how many different screen sizes exists makes it harder to finish, but now there is times that i even cannot see if i changed the resolution in some areas, because the system looks the same. I spent quite a while testing different resolutions and combinations of size, i didnt even noticed that i where 6 hours here, but now ik more about css (things like container-type + container based sizes and more ways to set the size of an text) The video shows how it is now, if u want to see the before just checks the past devlog."}, {"post_id": 62723, "ts": "2026-09-06T06:59:19Z", "hours": 0.7094, "text": "Finished the correction of the errors at the perspective and click in the cover-flow component. Now the perspective stays the same 150vw value (that is based on the screen width) and stays normal, with everything working. Oh man, that needed a lot of logic and out of box thinking finding another ways to check where the user clicked without using an normal click event listener (for those who lost the past devlog or didnt understood, i cannot use a normal eventListener in that because the clicks is detected in another element or in nothing, even with z-index or more in css, so the solution should be done entirely on javascript logic). The first video is the new way, the second is how it was before all changes in it"}, {"post_id": 62679, "ts": "2026-09-06T05:10:34Z", "hours": 5.5194, "text": "i finished the workings on the section of the home page that i where doing before, now has a good responsiveness for pc and a decent one for mobile. Now im working on the main area of the home page, the one where the user selects the desired genre for the music (second img). It may looks completely fine, but that same element already was a headache before and is here again. The given area is the cover-flow component, before i already fixed it (or so i thought), but it was looking bad (the 3d perspective where a bit strange) and would probably broken if i added new genres. I were trying to figure out a way to listen to the clicks in the card without any problems, that seems easy at first glance, but the 3d perspective in the element make other elements eat the click from one another, make the clicks dont be listened and so many problems that i nearly decided to erase it and write from scratch. I already found a way to do it by using the mouse position, the center of the screen and the card width (the genre img) to transform it in an value that can be used to select the exact card without any dependencies on the doom selector. It basically uses just some values, put in some calcs and get the difference between the current card (genre) index and the clicked. Im nearly finishing it, but i still need to figure out some values and more."}, {"post_id": 61879, "ts": "2026-09-05T01:17:53Z", "hours": 1.1772, "text": "Im improving the responsiveness at the home page (before was the player page), but for some reason that idk the emotion selection div is having a strange behavior, i will update what it is after i fix it. Take a look: (the item in the center should be centered)"}, {"post_id": 61218, "ts": "2026-09-04T01:30:11Z", "hours": 0.725, "text": "Hi again! Like said in the past devlog, im improving the responsiveness of the website, specifically in the player part. But it had some problems and where distorting when playing an video, now it resizes based on the screen size in a way that it stays ¨normal¨. The first video is the new way, the second is the old way. It still needs a lot of improvements, but it is going!"}, {"post_id": 60619, "ts": "2026-09-03T02:22:12Z", "hours": 1.4631, "text": "Making the website responsive Hi again! Like i said in some devlog, the website dont have support for mobile, that was because it was designed to be at kiosk mode and work just in desktops. but i decided to change that. First of all: the site where using a lot of absolute values of dimensions, so it where braking even in the desktops (it wasnt responsive at all). But i spent a while changing it, it is isnt ready and has some problems, but is better than before. (The mobile is still strange, i did not started fixing it yet). Credits: https://css-tricks.com/snippets/css/fluid-typography/ - This website shows about a way to make the texts become responsive for the screen using some calcs, it is worth seeing. The first video is how it was before, the second is how it is now"}, {"post_id": 60559, "ts": "2026-09-02T23:48:07Z", "hours": 0.7944, "text": "Creating a new helper Context: There was an class called youtubeFrameControls , this class basically where designed as an structure to help using the youtube iframe API, but with the time this class where becoming basically to hold just an function (and in a very inefficient way), because the methods that it had before (like the one that runs when the iframe is loaded) had to have more and more specific logic in the codes that used it, so they where useless (because the codes that where using it where rewriting it). What i did: I picked the only function that where being used and transformed it in an helpers (that can easily be customized). This function was the one that creates the player of the musics, and the function where called createPlayer . Also i removed the old class (youtubeFrameControls) and replaced it for this helper in every place that used it. It now is way more simple than before and can me more customized."}, {"post_id": 60001, "ts": "2026-09-02T02:58:53Z", "hours": 2.1603, "text": "Refactoring the copa script I where placing some scripts in a class. These scripts are related with the player functions of the copa script, so i pick all of them and placed in the same class. I did it to follow best practices, but i confess that i still got some doubts about when to create an class and when the variable or method should be static or private (#property), i will search and learn more about because maybe i will have to refactor some parts of the code following these rules of best practices. That was all for now, see ya!"}, {"post_id": 59339, "ts": "2026-09-01T02:28:57Z", "hours": 2.4744, "text": "Adding more bug checks I added some checks in the player class at the startExplication function that checks if the src (the url for the audio) is valid or not by doing an fetch with the HEAD method and checking if the return is an valid audio before trying anything in this function. Also i solved this error in the same function: Uncaught (in promise) AbortError: The play() request was interrupted because the media was removed from the document. https://goo.gl/LdLk22 This error was because the startExplication function where trying to play the audio before it was loaded, i solved it by making it play the audio just after it was load with the event listener canplaythrough . There was another error at the playMusic function where the code where trying to play the youtube video before it was loaded, i solved it by making it wait until it was CUED (Where the video isnt playing, but is loaded and showed). (The website was not created to be in mobile and dont has a lot of support, the video where recorded in my smartphone because i had to record the audio and the audio on my pc dont work. In the Future i Will add mobile suport, but right now im finishing the bugs and etc)"}, {"post_id": 58653, "ts": "2026-08-31T04:27:35Z", "hours": 2.7947, "text": "Adding a new description feature So basically there was an place where was designed to have the description about an music, but that was empty and where only finished today What it do It is petty simple, it just show an text about the music that is currently playing, also there is an audio that plays before the music starts playing, but this audios is played just one time before the music so if someone loses it or didnt listen well there was not a second chance to listen for that audio. Now there is this place that holds the same content, but in the format of an text that can be read whenever they want while the music is being played, that was what i added. Also that text can be hidden, so it will not stay using half of the screen every time (in the screenshot it is active) What this audios do This audio / text is part of the main purpose of the website, they give some fun facts about the music that may be useful someday in some kind of quiz or essay. Also the audio is played before the music and the music plays just after the audio finishes. That is to make whoever is listening listen to the entire audio before having what he (or she) wants, so they will not listen to the music and skip the audio."}, {"post_id": 58526, "ts": "2026-08-30T23:20:27Z", "hours": 1.3911, "text": "Studing about cache So basically i where studing about cache, the main ideia was to implement it in the sistem, but then i realized something: Theres is nearly no difference between cache and a normal request in an localhost project, adding the cache would not improve anything, sometimes it maybe even slow the website, because the page would need load more code. I realized it afther a while studing about it, but anyway lets focus on another thing. Also i where studing with google for devs: https://developer.chrome.com/docs/workbox/caching-strategies-overview"}, {"post_id": 56374, "ts": "2026-08-28T03:45:15Z", "hours": 1.0169, "text": "Toast applied and tested The toast notification component is now being used at the player class, i did some tests and it is working very nice, hopefully the user will not see it very often (because that would be a problem, the user must not see it unless there is an error playing the music). But why did i make it? It is used to show more about what is going on for the user, so they will not become anxious if it something is working or not. Why not use another notification system? Each notification system has its own use cases, the others would be very painful for the user. Imagine every time a simple error (that is simple for me) like the music fail to play there was an error that interrupt the use of the app with an popup or alert, that would be painful, dont it? That is why i used an toast notification, because it is temporary (disappears after some seconds) and dont stop the use of the website. Also there is a feature that i implemented for the same reason a few devlogs ago that add a fallback in the music search, so it wont show a message at every single combination. Lets calculate how many combinations we have: there is around 50 musics in the database, 22 genres and around 40 emotions, multiplying the genres and the music 880 combinations that the user can make. Now lets see how many musics we can get: each music have around 1.2 emotions and 1.2 genres, so we get 72 combinations that lead to an music . With that in mind, we can see that from 880 combinations, just 72 of them are useful combinations, so we get a 8.18% for getting a music, and 91,12% of not getting one. Consider that each failed attempt shows an error that stop the use flow of the website, but that was before the past devlog, now it tries again and again and only afther failing everything it shows an error, at that point it must really show an error. Thats all, sorry for the long boring text and thanks everyone that read, see yall later"}, {"post_id": 56331, "ts": "2026-08-28T01:58:42Z", "hours": 3.1336, "text": "The toast notification is finished So i finished it, it is a component that u adds in the code that u wants to use. I added 2 icons, 1 for infos and another for warnings. What i used and did The element that holds it all is an dialog , the icons are svg , the text is a span and the element that shows the time left is an progress . To update the time left i used an setInterval that runs at a 10ms delay and deduce 0.01 of the dialog value, so it will be smooth to see. Also there is an if inside that destroy the element and clear the interval when the value of the dialog reaches zero or less (In the past devlog i said about not using an if, but considering how low the cost for an if in that time is i decided to use it anyway). The function that creates the toast receives some params that will let it be customized by whoever is calling it: const icons = Object . freeze ({ INFO : infoIcon (), WARNING : warningIcon () }); function createToast ({ message , time = 5 , styles , icon = icons . INFO }) // the `message` is the displayed message // the `time` is the time until close // the `styles` is custom css styles for the element, it uses the dictionary format {} // the `icon` is the svg icon What else? I will apply it in some elements and post about. See you later!"}, {"post_id": 56188, "ts": "2026-08-27T20:27:52Z", "hours": 1.5956, "text": "Creating a toast notification system So rn im creating what i said in the past devlog about a toast navigation. This isnt finished yet, im still figuring out an way to check the end of the timer, i found some ways to do it, like using an simple if inside the countdown. I didnt comment but i am using an setInterval to decrease the time and an <progress> tag to show the value but that is a bad ideia, imagine doing 1 if every 50 ms? that dont cost a lot of processing power, but i still will search for other ways to do it just to check, if yall got any hints or ideas leave a comment. Also i will improve the design, the design is petty poor."}, {"post_id": 55334, "ts": "2026-08-27T02:23:29Z", "hours": 4.2383, "text": "Fixing errors and adding bug checks Hi everyone, so i were fixing some bugs that i saw that may broke the app, i fixed all of them (for now), here they are: There was a logic bug that a class (the one that controls the youtube iframe) where doing stuff that it wasnt supposed to do (not an unexpected behavior, but a logic that should be outside of it), it was an easy fix. There was a bug at the player class that when the provided sourceId (for the youtube iframe) where wrong or unable to use it crash and stopped doing anything else (like playing another musics). I tryied solving it in various ways, one was beffore the changes that i did in my last devlog, but i failed because the class that holds the player where hard to fix, this devlog fix it. I fixed it by adding some bug checks and, when some error ocurred, it play the next music. There was also a bug at the player class and youtube-iframe-controls class, that for a couple seconds in the start of the website it would broke if u tried to play a music. It was because in the start of the program the youtube API where unable to be used. To fix it i just made it wait until the API where ready using an ASYNC function. There was also a bug that, afther the past devlog, it was doing and request at the /api/songs with params at the wrong format. Afther the past devlog the API started using the params genre_id and emotion_id , but the frontend where passing with the incorrect name (genre, emotion). Something that i implemented I upgraded the mysql query that where being used to get more infos about the music, before it where just returning infos like name, author, sourceId, etc, but now it also returns the genre and emotion from that given music. I added a bug check at the player class, now if it fails it pass to the next music. Something that i want implement I want to implement a simple toast notification system that will apear when something fails, like the playing of some music. Others The youtube docs for the iframe where very helpful for this changes, check it out: https://developers.google.com/youtube/iframe_api_reference?hl=pt-br"}, {"post_id": 54690, "ts": "2026-08-25T19:06:05Z", "hours": 3.2633, "text": "Optimizating some piece of code So there was a certain part of the code responsible for the songs queue in the main route, that piece is a core function but where running a while true loop for no reason , here is the part: async start () { while ( true ) { // { emotion, genre, author, name, sourceId } const musicData = await this . #musicQueue . get (); this . createPlayer ( musicData [ ' sourceId ' ], null ); this . #showMusicInfos ( musicData [ ' name ' ], musicData [ ' author ' ]); this . #queueList . removeChild ( this . #queueList . children [ 0 ]); await this . #startExplication ( `/storage/ ${ musicData [ ' explicationSource ' ]} ` ); this . player . playVideo (); await this . #musicFinished . when ( true ); this . #musicFinished . set ( false ); } } Basically the code were calling it at the start and running it forever, but that code where a nightmare to maintain / implement, i tried to implement a safe check here for over 2 hours, but wasnt possible. I replaced it for a more efficient approach that do a loop in a different way, here it is: when adding a music, it checks if it is already playing, if no starts to play. when start to play it checks if there is a music in the queue for it to play, if no it stops playing, if yes it get it and play. When the music that is playing ends, it call the play function (from the above topic). That is just it, no while or constant loops, no overhead, it works by basically connecting all the codes in a way that they work together to maintain (or stop) the loop (notice how i said loop, it uses a loop but isnt a while or for loop, it connects the end of one code and the start of another, like a chain . I made it in the pull request #2, check it out: here"}, {"post_id": 54151, "ts": "2026-08-24T23:51:28Z", "hours": 5.8114, "text": "Fixing some forgoten code and more So at this devlog i were fixing some bugs in a specific ui / route called ¨copa¨, this is a special route added because a teacher asked our team to create them to use at some football games in our school. But since it was a hiddend route and mostly like a easter egg it hasnt been updated in a while and wasnt working anymore. What i fixed i was following a pattern where most of the images that each route used should be in a special foulder of storage (literally called /storage), but this mode (copa) where created before it and was following the old way Also there was some errors ocurred afther i changed the entire folder structure, so the copa mode where completely broken, i fixed it too. What i added I had a class about PHP + Laravel | API | Controlers in my course, afther that class i realized that the way the API (copa) where searching for data based on ID where wrong (was doing copa?id=…), i changed it to /copa/id There is a function that show the teams to the user to select one that he wants, but the teams list where hard coded and wasnt synced with the database. I made it use the database data instead of a hardcoded value ** That where all for that mode, but i didnt spent 5 hours just on it, i made more: ** Fixing (or making) some other bugs There is a script that controls the database that where holding and infinite single connection with the database, something like this conn = mysql . connector . connect ( ** configs ) cursor = conn . cursor ( Dictionary = True ) But all the codes where using the same connection and cursor, so i decided to apply a connecton pool and make each database call get a connection and a new cursor. Also i added some functions to abstrac the connection and query part: def __get_connection ( self ): conn = self . db_pool . get_connection () conn . ping ( reconnect = True , attempts = 3 , delay = 1 ) return conn def __execute_query ( self , query : str , params : list | None = None , dictionary = True , query_type : QueryTypes = QueryTypes . ALL ): conn = self . __get_connection () try : with conn . cursor ( dictionary = dictionary ) as cursor : cursor . execute ( query , ( params ) or ()) match query_type : case QueryTypes . ALL : return cursor . fetchall () case QueryTypes . ONE : return cursor . fetchone () case QueryTypes . EXECUTE : cursor . commit () return cursor . lastrowid or cursor . rowcount case _ : raise ValueError ( f \" Tipo de consulta não suportado: { query_type } \" ) If yall want to see it check here at my repo That was also the first time that i used a Enum (on code) and branchs (on github, but i didnt used them properly) Others There was also some other changes, check the repo GF-Silva/Ritualia What next Now i will add some bug checks on a piece of code that handle the video display using an youtube iframe."}, {"post_id": 52754, "ts": "2026-08-23T03:00:03Z", "hours": 4.8206, "text": "Changing some values to be relative I spent a while (more than i expected) changing some strange values that control some settings of a component called cover-flow (this component create and control the images that are displayed in the home screen). I spent more time figuring out what where each variable and lhe logic behind than acually writing.Before it had some hardcoded values that would probably broke if anything changes, i saw it and solved. I wasnt here for it, i was fixing another bug and fixed it before it broke. I also used some basic math of circles like angle of an arc. That is all for today"}, {"post_id": 52465, "ts": "2026-08-22T16:18:22Z", "hours": 3.1097, "text": "I spent some time correcting errors and logic problems, here they are: Error Correction Music playback would freeze when the music queue ended : This problem would break the app until you restarted it, but it was very simple to solve. I had simply made it remove the first instance of music from the HTML twice, which caused it to try to remove an element that didn’t exist, thus freezing the app. Removed an unnecessary loop : In the player section, there was a loop that iterated through all the elements (emotions) in a list to toggle the state of ONLY 1 ELEMENT. With the few elements it had (there were 3), this was minimal, but adding more could be detrimental to functionality. It only did this to toggle the state of the PREVIOUS element from active to inactive. I solved this simply by making it save the index of the last element and use that to access it. It took a while to work because javascript was treating 0 (the first indice / old indice when u start) as false in the if, but afther i figured out why it was simple to solve (if oldIndice != null) Implementations / Changes I separated the API/WEB routes : Previously, the routes exposed by the backend (such as /songs) were in the same file. This wasn’t a problem before, but with the addition of new functions, it could become difficult to maintain and prone to various errors, as the routes weren’t separated (a name could be the same). Therefore, I separated them into: /api (backend API codes) and / (frontend web codes). I put the genres in the database : Previously, the genres were in the frontend, and to add a new one, I would have to update both the backend and the frontend. To solve this, I simply added a route that retrieves the current genres (from the database) and uses the data (name / location) to load them into the frontend. I added the emotions to the database : The emotions had the same problem; although both (they and the genres) were in the database, the frontend wasn’t based on that data, so I did the same thing I did with the genres. I changed the name of where the music explanations were saved : I must have mentioned in a devlog that the folder inside storage was called /explication_source, and I also mentioned that the name was incorrect (because the audio source wasn’t there, nor would it be; the audio files themselves are there), so I changed it to /explication_audios"}, {"post_id": 48602, "ts": "2026-08-17T02:01:56Z", "hours": 3.6708, "text": "Updating the README I saw a post about how to structure a README, how to make it clear and etc. Afther i realized how wrong the old README was (it was confusing, and also was months out of date). So I chose some topics that would be interesting to include in and filled in a skeleton, spending some time learning what to do and what not to do. I also didn’t fill in some fields because they aren’t ready yet (they now are stored in my memory to add later). How it was before: https://github.com/GF-Silva/RitualIa/blob/9a2a7756c777a7042eca28309924e5a408bd561f/README.md How it is now: https://github.com/GF-Silva/RitualIa/blob/2dea5f80266f06e8633af1aa3c9430065cde9231/README.md There is a huge difference. Also i did some bugs and noticed how bad my commits are"}, {"post_id": 47776, "ts": "2026-08-15T22:55:35Z", "hours": 32.5314, "text": "After a development pause, here are the various changes made. Also, I never mentioned it, but this project was made by students focused on the school environment. (This time I finally got around to writing the devlog myself): Structure Moved main.py to the root Replaced mysql-connector with the official version : The added library was a version I didn’t recognize; I added the official one instead. Cleanup Removed some Code that wasnt being used. Backend Change the return value of the SQL cursor : Previously, the cursor returned an array, but for code readability and security, I opted to change it to an array. Structured Error 404 : The backend used abort in certain parts, but it returns HTML and certain parts of the frontend expected JSON, so I formatted the abort to JSON. This caused a headache, I hadn’t tested it (again lol) and when I saw it, it was time to present the project at school and I was having this error. frontend Fixed the CoverFlow component : An error went unnoticed in the creation of the component, this made the size and spacing of the images look strange, it was fixed to a certain extent. I implemented a new playback policy : The text about it got so long that I decided to open an extra topic. Playback Policy Now it search for the requested emotion + genre that the user choose, If It fails It search Just for the genre, if It fails again it search for anything. Now it falls into a fallback: This policy change was motivated by having to find a song to show in a presentation and failing. I reflected that if it was annoying for me, it would be for the end user (students) as well. Database Added new songs : I added 50 extras and their respective genres/emotions. (Also i wrote some helpers in python to help me categorize and search for the musics in youtube and get and structured sql output, that took quite a while) Saved the songs locally : Topic local saving Local saving But why would saving the songs in the cloud be a problem? Nothing comes for free, the server we were using to host the music had a monthly access limit, which was a silent problem that, thankfully, was noticed before it happened. My mistake, I didn’t even think about the possibility of saving locally and went straight to saving in the cloud, it must have been due to haste and inattention (always plan well what you are going to do before you do it, weigh the risks and benefits). Now, how it works The audios are saved inside the /storage folder. The database still saves the location, but this time it saves the relative path (e.g., /explication_audiis/fun_audio.extension). Why save the folder path as well? Won’t the audios always be there? Yes, but at some point the path might change (e.g., explication_source/youtube/audio_legal.extension). Future plans I’m going to improve my devlogs lol, this one got huge"}, {"post_id": 12818, "ts": "2026-06-20T23:46:13Z", "hours": 5.5386, "text": "RitualIa in Evolution: Refactoring, Optimization, and New Features 🎶 Hey everyone! I’m back with a cool update on what’s been happening here at RitualIa. After that commit where we transformed some scripts into helpers, things have evolved quite a bit. We’ve been doing a heavy refactoring of the project, focusing on organization, performance, and better code architecture . What’s changed: Structure & Organization: I removed legacy folders that weren’t being used, did a mega merge bringing everything from /frontend (the folder that where holding ALL the frontend logics) to the project root (with that the frontend and backend are in the same folder), and switched from FastAPI to Flask on the backend. Why the change of FastAPI to Flask: Because my supervisor or mentor (something like this) said and said again to, because there was other guys in the project (still is, but im the main developer, the others stopped doing anything like mounths Ago, and even while they where doing something i still was the main dev), these other guys where total starters and could not hold the learning curve of FastAPI (even with the fact that was Just me that where using It, because it was at the backend and i was the only developing at back). Code Quality: We made several methods private in the PlayerControls class, making the API cleaner and more secure. We also fixed the “enclosing class errors” that appeared. These small fixes make a huge difference in code reliability. UI/UX Improvements: We created a new CoverFlow component to replace GenreCylinder on the homepage – it’s much smoother and prettier now. We added support for async onClick, grab + touch in CoverFlow, and adjusted visual positioning to keep everything aligned. Oh, and we removed that unnecessary playerText that was cluttering the interface. New Features: A really cool feature that was added was the checking for duplicate songs in the queue . Nothing worse than accidentally playing the same song twice, right? Now that doesn’t happen anymore. Maintenance & Updates: We updated the fetches to call the new routes, moved the favicon to assets (because everything has its place), and focused on the details. What’s coming next: We are in a consolidation phase, laying a solid foundation for the upcoming features. The focus now is on ensuring that each component is doing exactly what it needs to do, nothing more, nothing less. Thanks for following along!"}, {"post_id": 11702, "ts": "2026-06-19T02:03:07Z", "hours": 1.0236, "text": "I’m transforming some duplicate code into helpers so they can be more easily used in new code."}, {"post_id": 11412, "ts": "2026-06-18T17:53:37Z", "hours": 1.2881, "text": "Introducing: The ‘Ritualia’ project is a project developed by me and some colleagues with the help of the school. In it, we have done and continue to do research and assembly with the aim of impacting the daily lives of students in our school and (in the future) other schools. It is an open-source project with an article soon to be published detailing the foundations used, etc. The readme is currently outdated because I am redoing part of the current architecture, but I will update it later to include information on how to assemble and create your own version. The project is divided into hardware and software. I, along with other members, am responsible for the software (which is usable on most computers), and the hardware is relatively simple (it only depends on a display + sound + a controller with an OS + the preparations for installation)."}]...
|
Title: Ritualia by @gabriel_ferreira | Stardance
Title: Ritualia by @gabriel_ferreira | Stardance
Devlogs:
Introducing: The ‘Ritualia’ project is a project developed by me and some colleagues with the help of the school. In it, we have done and continue to do research and assembly with the aim of impacting the daily lives of students in our school and (in the future) other schools. It is an open-source project with an article soon to be published detailing the foundations used, etc. The readme is currently outdated because I am redoing part of the current architecture, but I will update it later to include information on how to assemble and create your own version. The project is divided into hardware and software. I, along with other members, am responsible for the software (which is usable on most computers), and the hardware is relatively simple (it only depends on a display + sound + a controller with an OS + the preparations for installation).
I’m transforming some duplicate code into helpers so they can be more easily used in new code.
RitualIa in Evolution: Refactoring, Optimization, and New Features 🎶 Hey everyone! I’m back with a cool update on what’s been happening here at RitualIa. After that commit where we transformed some scripts into helpers, things have evolved quite a bit. We’ve been doing a heavy refactoring of the project, focusing on organization, performance, and better code architecture . What’s changed: Structure & Organization: I removed legacy folders that weren’t being used, did a mega merge bringing everything from /frontend (the folder that where holding ALL the frontend logics) to the project root (with that the frontend and backend are in the same folder), and switched from FastAPI to Flask on the backend. Why the change of FastAPI to Flask: Because my supervisor or mentor (something like this) said and said again to, because there was other guys in the project (still is, but im the main developer, the others stopped doing anything like mounths Ago, and even while they where doing something i still was the main dev), these other guys where total starters and could not hold the learning curve of FastAPI (even with the fact that was Just me that where using It, because it was at the backend and i was the only developing at back). Code Quality: We made several methods private in the PlayerControls class, making the API cleaner and more secure. We also fixed the “enclosing class errors” that appeared. These small fixes make a huge difference in code reliability. UI/UX Improvements: We created a new CoverFlow component to replace GenreCylinder on the homepage – it’s much smoother and prettier now. We added support for async onClick, grab + touch in CoverFlow, and adjusted visual positioning to keep everything aligned. Oh, and we removed that unnecessary playerText that was cluttering the interface. New Features: A really cool feature that was added was the checking for duplicate songs in the queue . Nothing worse than accidentally playing the same song twice, right? Now that doesn’t happen anymore. Maintenance & Updates: We updated the fetches to call the new routes, moved the favicon to assets (because everything has its place), and focused on the details. What’s coming next: We are in a consolidation phase, laying a solid foundation for the upcoming features. The focus now is on ensuring that each component is doing exactly what it needs to do, nothing more, nothing less. Thanks for following along!
After a development pause, here are the various changes made. Also, I never mentioned it, but this project was made by students focused on the school environment. (This time I finally got around to writing the devlog myself): Structure Moved main.py to the root Replaced mysql-connector with the official version : The added library was a version I didn’t recognize; I added the official one instead. Cleanup Removed some Code that wasnt being used. Backend Change the return value of the SQL cursor : Previously, the cursor returned an array, but for code readability and security, I opted to change it to an array. Structured Error 404 : The backend used abort in certain parts, but it returns HTML and certain parts of the frontend expected JSON, so I formatted the abort to JSON. This caused a headache, I hadn’t tested it (again lol) and when I saw it, it was time to present the project at school and I was having this error. frontend Fixed the CoverFlow component : An error went unnoticed in the creation of the component, this made the size and spacing of the images look strange, it was fixed to a certain extent. I implemented a new playback policy : The text about it got so long that I decided to open an extra topic. Playback Policy Now it search for the requested emotion + genre that the user choose, If It fails It search Just for the genre, if It fails again it search for anything. Now it falls into a fallback: This policy change was motivated by having to find a song to show in a presentation and failing. I reflected that if it was annoying for me, it would be for the end user (students) as well. Database Added new songs : I added 50 extras and their respective genres/emotions. (Also i wrote some helpers in python to help me categorize and search for the musics in youtube and get and structured sql output, that took quite a while) Saved the songs locally : Topic local saving Local saving But why would saving the songs in the cloud be a problem? Nothing comes for free, the server we were using to host the music had a monthly access limit, which was a silent problem that, thankfully, was noticed before it happened. My mistake, I didn’t even think about the possibility of saving locally and went straight to saving in the cloud, it must have been due to haste and inattention (always plan well what you are going to do before you do it, weigh the risks and benefits). Now, how it works The audios are saved inside the /storage folder. The database still saves the location, but this time it saves the relative path (e.g., /explication_audiis/fun_audio.extension). Why save the folder path as well? Won’t the audios always be there? Yes, but at some point the path might change (e.g., explication_source/youtube/audio_legal.extension). Future plans I’m going to improve my devlogs lol, this one got huge
Updating the README I saw a post about how to structure a README, how to make it clear and etc. Afther i realized how wrong the old README was (it was confusing, and also was months out of date). So I chose some topics that would be interesting to include in and filled in a skeleton, spending some time learning what to do and what not to do. I also didn’t fill in some fields because they aren’t ready yet (they now are stored in my memory to add later). How it was before: https://github.com/GF-Silva/RitualIa/blob/9a2a7756c777a7042eca28309924e5a408bd561f/README.md How it is now: https://github.com/GF-Silva/RitualIa/blob/2dea5f80266f06e8633af1aa3c9430065cde9231/README.md There is a huge difference. Also i did some bugs and noticed how bad my commits are
I spent some time correcting errors and logic problems, here they are: Error Correction Music playback would freeze when the music queue ended : This problem would break the app until you restarted it, but it was very simple to solve. I had simply made it remove the first instance of music from the HTML twice, which caused it to try to remove an element that didn’t exist, thus freezing the app. Removed an unnecessary loop : In the player section, there was a loop that iterated through all the elements (emotions) in a list to toggle the state of ONLY 1 ELEMENT. With the few elements it had (there were 3), this was minimal, but adding more could be detrimental to functionality. It only did this to toggle the state of the PREVIOUS element from active to inactive. I solved this simply by making it save the index of the last element and use that to access it. It took a while to work because javascript was treating 0 (the first indice / old indice when u start) as false in the if, but afther i figured out why it was simple to solve (if oldIndice != null) Implementations / Changes I separated the API/WEB routes : Previously, the routes exposed by the backend (such as /songs) were in the same file. This wasn’t a problem before, but with the addition of new functions, it could become difficult to maintain and prone to various errors, as the routes weren’t separated (a name could be the same). Therefore, I separated them into: /api (backend API codes) and / (frontend web codes). I put the genres in the database : Previously, the genres were in the frontend, and to add a new one, I would have to update both the backend and the frontend. To solve this, I simply added a route that retrieves the current genres (from the database) and uses the data (name / location) to load them into the frontend. I added the emotions to the database : The emotions had the same problem; although both (they and the genres) were in the database, the frontend wasn’t based on that data, so I did the same thing I did with the genres. I changed the name of where the music explanations were saved : I must have mentioned in a devlog that the folder inside storage was called /explication_source, and I also mentioned that the name was incorrect (because the audio source wasn’t there, nor would it be; the audio files themselves are there), so I changed it to /explication_audios
Changing some values to be relative I spent a while (more than i expected) changing some strange values that control some settings of a component called cover-flow (this component create and control the images that are displayed in the home screen). I spent more time figuring out what where each variable and lhe logic behind than acually writing.Before it had some hardcoded values that would probably broke if anything changes, i saw it and solved. I wasnt here for it, i was fixing another bug and fixed it before it broke. I also used some basic math of circles like angle of an arc. That is all for today
Fixing some forgoten code and more So at this devlog i were fixing some bugs in a specific ui / route called ¨copa¨, this is a special route added because a teacher asked our team to create them to use at some football games in our school. But since it was a hiddend route and mostly like a easter egg it hasnt been updated in a while and wasnt working anymore. What i fixed i was following a pattern where most of the images that each route used should be in a special foulder of storage (literally called /storage), but this mode (copa) where created before it and was following the old way Also there was some errors ocurred afther i changed the entire folder structure, so the copa mode where completely broken, i fixed it too. What i added I had a class about PHP + Laravel | API | Controlers in my course, afther that class i realized that the way the API (copa) where searching for data based on ID where wrong (was doing copa?id=…), i changed it to /copa/id There is a function that show the teams to the user to select one that he wants, but the teams list where hard coded and wasnt synced with the database. I made it use the database data instead of a hardcoded value ** That where all for that mode, but i didnt spent 5 hours just on it, i made more: ** Fixing (or making) some other bugs There is a script that controls the database that where holding and infinite single connection with the database, something like this conn = mysql . connector . connect ( ** configs ) cursor = conn . cursor ( Dictionary = True ) But all the codes where using the same connection and cursor, so i decided to apply a connecton pool and make each database call get a connection and a new cursor. Also i added some functions to abstrac the connection and query part: def __get_connection ( self ): conn = self . db_pool . get_connection () conn . ping ( reconnect = True , attempts = 3 , delay = 1 ) return conn def __execute_query ( self , query : str , params : list | None = None , dictionary = True , query_type : QueryTypes = QueryTypes . ALL ): conn = self . __get_connection () try : with conn . cursor ( dictionary = dictionary ) as cursor : cursor . execute ( query , ( params ) or ()) match query_type : case QueryTypes . ALL : return cursor . fetchall () case QueryTypes . ONE : return cursor . fetchone () case QueryTypes . EXECUTE : cursor . commit () return cursor . lastrowid or cursor . rowcount case _ : raise ValueError ( f " Tipo de consulta não suportado: { query_type } " ) If yall want to see it check here at my repo That was also the first time that i used a Enum (on code) and branchs (on github, but i didnt used them properly) Others There was also some other changes, check the repo GF-Silva/Ritualia What next Now i will add some bug checks on a piece of code that handle the video display using an youtube iframe.
Optimizating some piece of code So there was a certain part of the code responsible for the songs queue in the main route, that piece is a core function but where running a while true loop for no reason , here is the part: async start () { while ( true ) { // { emotion, genre, author, name, sourceId } const musicData = await this . #musicQueue . get (); this . createPlayer ( musicData [ ' sourceId ' ], null ); this . #showMusicInfos ( musicData [ ' name ' ], musicData [ ' author ' ]); this . #queueList . removeChild ( this . #queueList . children [ 0 ]); await this . #startExplication ( `/storage/ ${ musicData [ ' explicationSource ' ]} ` ); this . player . playVideo (); await this . #musicFinished . when ( true ); this . #musicFinished . set ( false ); } } Basically the code were calling it at the start and running it forever, but that code where a nightmare to maintain / implement, i tried to implement a safe check here for over 2 hours, but wasnt possible. I replaced it for a more efficient approach that do a loop in a different way, here it is: when adding a music, it checks if it is already playing, if no starts to play. when start to play it checks if there is a music in the queue for it to play, if no it stops playing, if yes it get it and play. When the music that is playing ends, it call the play function (from the above topic). That is just it, no while or constant loops, no overhead, it works by basically connecting all the codes in a way that they work together to maintain (or stop) the loop (notice how i said loop, it uses a loop but isnt a while or for loop, it connects the end of one code and the start of another, like a chain . I made it in the pull request #2, check it out: here
Fixing errors and adding bug checks Hi everyone, so i were fixing some bugs that i saw that may broke the app, i fixed all of them (for now), here they are: There was a logic bug that a class (the one that controls the youtube iframe) where doing stuff that it wasnt supposed to do (not an unexpected behavior, but a logic that should be outside of it), it was an easy fix. There was a bug at the player class that when the provided sourceId (for the youtube iframe) where wrong or unable to use it crash and stopped doing anything else (like playing another musics). I tryied solving it in various ways, one was beffore the changes that i did in my last devlog, but i failed because the class that holds the player where hard to fix, this devlog fix it. I fixed it by adding some bug checks and, when some error ocurred, it play the next music. There was also a bug at the player class and youtube-iframe-controls class, that for a couple seconds in the start of the website it would broke if u tried to play a music. It was because in the start of the program the youtube API where unable to be used. To fix it i just made it wait until the API where ready using an ASYNC function. There was also a bug that, afther the past devlog, it was doing and request at the /api/songs with params at the wrong format. Afther the past devlog the API started using the params genre_id and emotion_id , but the frontend where passing with the incorrect name (genre, emotion). Something that i implemented I upgraded the mysql query that where being used to get more infos about the music, before it where just returning infos like name, author, sourceId, etc, but now it also returns the genre and emotion from that given music. I added a bug check at the player class, now if it fails it pass to the next music. Something that i want implement I want to implement a simple toast notification system that will apear when something fails, like the playing of some music. Others The youtube docs for the iframe where very helpful for this changes, check it out: https://developers.google.com/youtube/iframe_api_reference?hl=pt-br
Creating a toast notification system So rn im creating what i said in the past devlog about a toast navigation. This isnt finished yet, im still figuring out an way to check the end of the timer, i found some ways to do it, like using an simple if inside the countdown. I didnt comment but i am using an setInterval to decrease the time and an <progress> tag to show the value but that is a bad ideia, imagine doing 1 if every 50 ms? that dont cost a lot of processing power, but i still will search for other ways to do it just to check, if yall got any hints or ideas leave a comment. Also i will improve the design, the design is petty poor.
The toast notification is finished So i finished it, it is a component that u adds in the code that u wants to use. I added 2 icons, 1 for infos and another for warnings. What i used and did The element that holds it all is an dialog , the icons are svg , the text is a span and the element that shows the time left is an progress . To update the time left i used an setInterval that runs at a 10ms delay and deduce 0.01 of the dialog value, so it will be smooth to see. Also there is an if inside that destroy the element and clear the interval when the value of the dialog reaches zero or less (In the past devlog i said about not using an if, but considering how low the cost for an if in that time is i decided to use it anyway). The function that creates the toast receives some params that will let it be customized by whoever is calling it: const icons = Object . freeze ({ INFO : infoIcon (), WARNING : warningIcon () }); function createToast ({ message , time = 5 , styles , icon = icons . INFO }) // the `message` is the displayed message // the `time` is the time until close // the `styles` is custom css styles for the element, it uses the dictionary format {} // the `icon` is the svg icon What else? I will apply it in some elements and post about. See you later!
Toast applied and tested The toast notification component is now being used at the player class, i did some tests and it is working very nice, hopefully the user will not see it very often (because that would be a problem, the user must not see it unless there is an error playing the music). But why did i make it? It is used to show more about what is going on for the user, so they will not become anxious if it something is working or not. Why not use another notification system? Each notification system has its own use cases, the others would be very painful for the user. Imagine every time a simple error (that is simple for me) like the music fail to play there was an error that interrupt the use of the app with an popup or alert, that would be painful, dont it? That is why i used an toast notification, because it is temporary (disappears after some seconds) and dont stop the use of the website. Also there is a feature that i implemented for the same reason a few devlogs ago that add a fallback in the music search, so it wont show a message at every single combination. Lets calculate how many combinations we have: there is around 50 musics in the database, 22 genres and around 40 emotions, multiplying the genres and the music 880 combinations that the user can make. Now lets see how many musics we can get: each music have around 1.2 emotions and 1.2 genres, so we get 72 combinations that lead to an music . With that in mind, we can see that from 880 combinations, just 72 of them are useful combinations, so we get a 8.18% for getting a music, and 91,12% of not getting one. Consider that each failed attempt shows an error that stop the use flow of the website, but that was before the past devlog, now it tries again and again and only afther failing everything it shows an error, at that point it must really show an error. Thats all, sorry for the long boring text and thanks everyone that read, see yall later
Studing about cache So basically i where studing about cache, the main ideia was to implement it in the sistem, but then i realized something: Theres is nearly no difference between cache and a normal request in an localhost project, adding the cache would not improve anything, sometimes it maybe even slow the website, because the page would need load more code. I realized it afther a while studing about it, but anyway lets focus on another thing. Also i where studing with google for devs: https://developer.chrome.com/docs/workbox/caching-strategies-overview
Adding a new description feature So basically there was an place where was designed to have the description about an music, but that was empty and where only finished today What it do It is petty simple, it just show an text about the music that is currently playing, also there is an audio that plays before the music starts playing, but this audios is played just one time before the music so if someone loses it or didnt listen well there was not a second chance to listen for that audio. Now there is this place that holds the same content, but in the format of an text that can be read whenever they want while the music is being played, that was what i added. Also that text can be hidden, so it will not stay using half of the screen every time (in the screenshot it is active) What this audios do This audio / text is part of the main purpose of the website, they give some fun facts about the music that may be useful someday in some kind of quiz or essay. Also the audio is played before the music and the music plays just after the audio finishes. That is to make whoever is listening listen to the entire audio before having what he (or she) wants, so they will not listen to the music and skip the audio.
Adding more bug checks I added some checks in the player class at the startExplication function that checks if the src (the url for the audio) is valid or not by doing an fetch with the HEAD method and checking if the return is an valid audio before trying anything in this function. Also i solved this error in the same function: Uncaught (in promise) AbortError: The play() request was interrupted because the media was removed from the document. https://goo.gl/LdLk22 This error was because the startExplication function where trying to play the audio before it was loaded, i solved it by making it play the audio just after it was load with the event listener canplaythrough . There was another error at the playMusic function where the code where trying to play the youtube video before it was loaded, i solved it by making it wait until it was CUED (Where the video isnt playing, but is loaded and showed). (The website was not created to be in mobile and dont has a lot of support, the video where recorded in my smartphone because i had to record the audio and the audio on my pc dont work. In the Future i Will add mobile suport, but right now im finishing the bugs and etc)
Refactoring the copa script I where placing some scripts in a class. These scripts are related with the player functions of the copa script, so i pick all of them and placed in the same class. I did it to follow best practices, but i confess that i still got some doubts about when to create an class and when the variable or method should be static or private (#property), i will search and learn more about because maybe i will have to refactor some parts of the code following these rules of best practices. That was all for now, see ya!
Creating a new helper Context: There was an class called youtubeFrameControls , this class basically where designed as an structure to help using the youtube iframe API, but with the time this class where becoming basically to hold just an function (and in a very inefficient way), because the methods that it had before (like the one that runs when the iframe is loaded) had to have more and more specific logic in the codes that used it, so they where useless (because the codes that where using it where rewriting it). What i did: I picked the only function that where being used and transformed it in an helpers (that can easily be customized). This function was the one that creates the player of the musics, and the function where called createPlayer . Also i removed the old class (youtubeFrameControls) and replaced it for this helper in every place that used it. It now is way more simple than before and can me more customized.
Making the website responsive Hi again! Like i said in some devlog, the website dont have support for mobile, that was because it was designed to be at kiosk mode and work just in desktops. but i decided to change that. First of all: the site where using a lot of absolute values of dimensions, so it where braking even in the desktops (it wasnt responsive at all). But i spent a while changing it, it is isnt ready and has some problems, but is better than before. (The mobile is still strange, i did not started fixing it yet). Credits: https://css-tricks.com/snippets/css/fluid-typography/ - This website shows about a way to make the texts become responsive for the screen using some calcs, it is worth seeing. The first video is how it was before, the second is how it is now
Hi again! Like said in the past devlog, im improving the responsiveness of the website, specifically in the player part. But it had some problems and where distorting when playing an video, now it resizes based on the screen size in a way that it stays ¨normal¨. The first video is the new way, the second is the old way. It still needs a lot of improvements, but it is going!
Im improving the responsiveness at the home page (before was the player page), but for some reason that idk the emotion selection div is having a strange behavior, i will update what it is after i fix it. Take a look: (the item in the center should be centered)
i finished the workings on the section of the home page that i where doing before, now has a good responsiveness for pc and a decent one for mobile. Now im working on the main area of the home page, the one where the user selects the desired genre for the music (second img). It may looks completely fine, but that same element already was a headache before and is here again. The given area is the cover-flow component, before i already fixed it (or so i thought), but it was looking bad (the 3d perspective where a bit strange) and would probably broken if i added new genres. I were trying to figure out a way to listen to the clicks in the card without any problems, that seems easy at first glance, but the 3d perspective in the element make other elements eat the click from one another, make the clicks dont be listened and so many problems that i nearly decided to erase it and write from scratch. I already found a way to do it by using the mouse position, the center of the screen and the card width (the genre img) to transform it in an value that can be used to select the exact card without any dependencies on the doom selector. It basically uses just some values, put in some calcs and get the difference between the current card (genre) index and the clicked. Im nearly finishing it, but i still need to figure out some values and more.
Finished the correction of the errors at the perspective and click in the cover-flow component. Now the perspective stays the same 150vw value (that is based on the screen width) and stays normal, with everything working. Oh man, that needed a lot of logic and out of box thinking finding another ways to check where the user clicked without using an normal click event listener (for those who lost the past devlog or didnt understood, i cannot use a normal eventListener in that because the clicks is detected in another element or in nothing, even with z-index or more in css, so the solution should be done entirely on javascript logic). The first video is the new way, the second is how it was before all changes in it
Im nearly finishing the workings on the responsiveness. Now the entire player screen is responsive and do not breaks the texts anymore (except for the description area), also the buttons that show you the next screen (the ones that displays ‘player’ and ‘generos’) are responsive too, the music queue is working perfectly fine, and the area that is used to select an emotion is nearly responsive too, it just needs some adjusts in the two buttons that change the current emotion because they become too small and uses a lot of space when the screen is too small, after that this screen will be finished. It is taking a really long time, the fact of how many different screen sizes exists makes it harder to finish, but now there is times that i even cannot see if i changed the resolution in some areas, because the system looks the same. I spent quite a while testing different resolutions and combinations of size, i didnt even noticed that i where 6 hours here, but now ik more about css (things like container-type + container based sizes and more ways to set the size of an text) The video shows how it is now, if u want to see the before just checks the past devlog.
The emotionDrum is now responsive! Now the buttons that you use to select the emotion are in the same side as the div that displays the emotion, so they dont fight for space anymore. This change is meant to fix the low size of the items in screens that are too small, in the new way we have more free space to display the emotions, there is not much to say. What else I did some minor changes in the size of some items at the player area, now they are easier to read! (I increased the size of some items)
The home is now fully responsive Ah that took a while, but finally it is fully responsive. Now the description at the player UI resizes based on the screen size and active a scroll behaviour when need, also i did some minor change at the emotionDrum perspective to make it show more emotions at the same time, removed the padding in the arrows at the emotionDrum so they will have more space and fixed an error in the genre drum that was making it perspective broke. After all these devlogs i improved how i make a code responsive.
Improving the performance After finishing the improvements in the responsiveness, now i decided to improve the performance. I used lighthouse to get insights (i learned about it in an tiktok video) and figured out that the images size were too high (were an png of 1280x1280px), so i saw more about that in the page: https://developer.chrome.com/docs/performance/insights/image-delivery (an link that google lighthouse gave). With that i saw how to decrease the size while staying with quality, i reached up to the sharp-cli tool, that makes the work of resize, convert and compress the image for me. The command used was that: npx sharp-cli -i * .png -o ./output resize 320 -f avif -q 50 --effort 6 --smartDeblock --preset photo The 320 is the size that i want it to be at the end, i got that value by seeing what was the computed value (the value that is being used in the website) in an high resolution pc (not the most higher one, the high but normal pc) with the resolution of 2500x1714px . With this simple changing the image went from 2mb to 40Kb! Nearly 100% decrease, and take in mind that there is more than one img, so the change were even higher. Also i created 5 different images: 320px, 480px, 640px, 960px e 1280px. With them the browser can choose which one is better for each device. With these changes i went from 35 points of performance to 59.
Improving the LCP (Largest content paint) performance I am improving the way that the website create and downloads the images, the main reason is to make the user see something faster. Before the system were doing 2 main things: Go trough the entire list of images, creating the elements and placing them into the page. Position them. But the position of the items were being done after the creation of the images, in another function. Now they are in the same function: it create the element, position it and add it to the page. That does not seem like much, but the code got way faster with that, probably because it dont need to go item by item in an list twice just to create an element. I tested the time to load the first element and it went from 8.63s to 6.43s , the test was made with 2200 elements (Yeah ik, it is a lot and normally it isnt that much, but i had to see how they were holding with more than 22 items). Also i fixed a bug that passed unnoticed while improving the responsiveness: At some point of images the visibility of the elements broke, that was because the perspective (what makes the 3D perspective of the component, and makes it visible with 3D effects) was based on the screen size, not the elements itself. What was the problem in that: Each element takes a size in the screen ‘makes the circle that shows the element be more and more near of our point of view’ (i cant explain it any better, search what is ‘perspective in an 3d element at HTML’ ). While it was approaching our point of view (POV), our POV were exactly at the same position (based on the screen size), so at some point the circle perspective would pass the POV and we would be unable of seeing it well. Now it is based on the elements: The 3d elements were basically a circle, i just used the diameter to change the perspective based on it. TODO: Maybe i lowered the image quality too much… I will fix it in the next updates. Also i were trying to improve the font settings to improve the performance, but that wast working so i decided to move on to this because it was more critical (took a while for me to jump to this, maybe like 2 hours trying and trying values in the font settings). i am also working in a way to load the images in parallel, with that it will take way less time (I didnt known about LCP before so i spent a while figuring out the way it works).
Improving the loading performance Now the system selects some images that needs to be shown faster than the others and making them load with priority. It was made by selecting the images that the user is seeing and defining some params like fetchPriority = "high" and decoding="sync" , the other images have the params: decoding="async"; loading="lazy"; contentVisibility="auto"; . With that config the LCP went from 2.4s to 0.5s . Also it loads the image in the start and dont change that config again, so the browser will be lazy while downloading these images. The problem is: only the first images are chosen as high priority, but their positions will be changed while the configs stays the same, that makes the browser lazy while loading them and makes the runtime performance became worse. To fix that i found about IntersectionObserver, that are meant to solve the problem of updating the images position fast. It was not applied yet, i found about it like 1 hour ago. What else Now the perspective of the emotionDrum is based on the elements that it have, before it was based just in the screen and would broke if something changes. I did a little change in the way that the script checks for clicks in the screen, now it has more accuracy (I changed the round system).
Adding an observer Now the script observe the card elements at the cover-flow component, classify their position and changes it visibility based on that. Im using an IntersectionObserver to observe every card, but it was designed to observe the position of 2d elements, so i had to figure out how to make it work well in an 3d element. The way it works is when the observe activates (it basically means that some card is in the range to load) it get the card info (like position and angle) and changes it visibility state based on that. Simple, right? No, it was a headache for the start to the top, nearly 4 hours of what i did was to fix the fact that it was meant for 2d. The observer were activating for cards that were in the back of the element, so i had to classify the card position into back or front by using its angle. But if i tried to use the card angle without anything else the script would broke (and did for 3 hours until i realized how to fix), so i had to use an second angle which is 360 - cardAngle (the 360 is the angle of an circle), so this new angle is based on the circle end while the other is based on the circle start. But the system still broke, because at some point one of these values would become negative and makes the if that classify the elements fail. The fix was using the absolute value in the if (it took 1 hour until i figured that; oh i were so happy when it worked). Why To improve the performance, so the browser will just load what is really important and not 50 images that the user cant even see. What else All that work definitely improved a lot my logic thinking and for the first time i used the truth table well. Now i just need to use the new code to change more the style of the images that are not in the screen. I did not deleted the code that i wrote in the past devlog, it was used in the new code to select how many images should be loaded in the same time. ** The first video is the result, the others is some problems that i had **
The observer is finished (nearly) Now the cover-flow has an observer that checks the position of the images and changes it styles based on that, so the images that the user is seeing is loaded while the others is hide. It still has some bugs and space for improvements that im still figuring out how to solve, like the image loading too late on the screen or, in slow internet connections, the image takes too long to load. Most of these bugs are because the observer (an intersectionObserver ) was designed for 2d contexts, not 3d (that were and still is an giant problem to solve). For this reason i was thinking about creating an observer from scratch in C++ that can work better in my 3d element, but the overhead would be high so im trying to solve in other ways before that. The feature was made using fetchPriority, contentVisibility and src (the system add the source just when the image is near the screen). OBS: I found about MutationObserver after this post, maybe i will use that instead of insersectionObserver. Oh man, at least if had found about this before… Aaaaaahhhhh i spent 9 hours in that, but at least a Lot of the new logic will be used. Anyway, lets cook
Adding a mutationObserver Now, instead of an intersectionObserver, the system use a mutationObserver that monitors the angle of the cylinder itself. With that the loading of the images will be insanely better, faster and user-friendly. Now the changes in the cover-flow is observed at the cylinder angle, not at each card. There was some problems in the journey like, for some reason, unexpected cards being loaded or not, the loading script at the observer dont triggering at all (that was caused by the speed of the observer) and an insane amount of cards being triggered at the same time (i still did not figured out why, but that isnt ‘harmful’). But man, i had to be creative here and remember about some concepts like concurrent programming, buffer / queue and apply some delays (because the mutationObserver is insanely fast and can trigger every millisecond). That all was meant to decrease the speed of the mutationObserver, because it was triggering with the most small change in the cylinder, so i made it trigger just when an expected amount of movement was made. The red/yellow collor is for me to visualize the loading state, it is just for debug The code isnt finished, i still need to implement the loading part, for now i just implemented the observer and basics of the loading part
The loading is done Features Now the loading at the mutationObserver is finished, it finally loads or unloads the images that should be (or not) loaded! The new observer is way faster, because it can detect the image way before it enters the screen, loading it before and having more time to do it. Also the system loads just a maximum of images (with the configs that i put it is 13), so it will not fry an cellphone. Problems The loading part was easy to do, i already done it before in the past observer (intersectionObserver), so i just had to pass the old code to the new part. But when the cover-flow element dont got atleast 13 elements the mutationObserver code breaks completely! Im still pondering how to solve it, when i do i will post about! Results The performance went from 78 to 100! The system is way faster! The user does not see a blank image anymore! Why The old method was slow even with a good internet connection, because it was loading the images just when the element was already in the screen, leaving to a perceptive delay for the user and a blank image to the user. Also i thought about creating an observer from scratch (maybe i was a little off my ideas, because that was insane), but the browser already had exactly what i wanted (the mutationObserver) Videos The new features The performance of the new feats The old features Reasoning While i was trying to sleep i thought about a system that fill the cover-flow with a maximum of images (like 10, or 13, or the code decides) at the DOM, using less memory to run. That system will free a lot of memory based on how many cards the cover-flow have. But that will have noticeable effects just with a lot of elements and probably would be hard to develop, maybe i will do in next updates. What next Im leading to the shipping, so i will improve metrics about the lighthouse, improve the readme and post it.
The loading is done and working! Fix I fixed the error that were happening when the cover had a certain amount of elements. Problems The fix itself was very easy to do, but doing it in a readable or without using 10 lines of code (i want things concise) was way harder than i expected. So i spent this entire time trying different ways to do it, each of them making everything worse. Reasoning The bug were with less than 14 elements, the script were calculating the first and last element index, it happened that these elements were behind the screen focus. Why? Because the values that the system was using were leaving these values, so i had to fix the way it was calculating things.
Fixing an error at the youtubeHelper Now the youtubeHelpers checks if the youtube API is ready before sending commands. Why Sometimes the API maybe is not finished yet, that was leaving an untreated error that was braking the entire website. How was made With a lot of pain and suffer. I thought “Oh hey, that will be a 15 minutes fix” - i spent 1 HOUR FIGHTING with the iframe itself, nothing was working and at some point i started thinking that even the API of YOUTUBE wasnt working, even the most basic function that should be triggered when the youtube finished the loading wasnt beeing activated, even the console.log(“Api READY!”) wasnt working, even when it worked it wasnt working well, the variable of the player was a promise and not the result. At the end i shut down my PC, defeated, without any energy left, with just hope that in the next day (this) that would be fixed (if not i was planning to ignore and make it a feature “Easter egg, if u dont join the website for a while it will not load!”. The problem here was just the position were the iframe api was in the HTML, it was being loaded before the helper script, so the helper was not there to check if it the iframe was ready or not, the fix was just move it a little down. Architecture It was just an promise, if the function checks that the iframe isnt available it await for it to be available. The check if it was available use the onYoutubeIframeAPIReady, easy easy (except for all the suffer that i went into).
The performance workings is finished and bug fix Fixes Now the logo z-index is lower, that is because the logo was ‘eating’ the click in more important elements. Also i did a small change at the cover-flow, that change fix the bug of the scroll at the element sudently stoping when at a certain position. The copa script had some old references to images that were leading to bugs, i changed it. Performance I already finished it in the past devlog, i was just checking if there was anything worth improving, but everything is working fine and now is time to improve acessibility. Most of the logged time was me trying to improve more some metrics at the lighthouse, but the work was too much for anything that is already good, so i decided to stop before i started focusing too much in it.
The accessibility workings is done Features Now the system has a new navigation system that allow users to navigate with just the keyboard! (The video was with just the keyboard) Why Why not? It was meant to improve the accessibility for users without mouse, or any another problem and because i was tired of having to use the mouse to debug something. How it was made Again with a lot of pain, the feature itself was easy but i had to fix some errors that went unnoticed, so it took more time. The feature detects when the user press a key and do an action based on wich key was. The accessibility was easy to get 100, but the metrics at lighthouse dont give all what the users will need, i had to think about the website usage and how would be the easiest way for the user. Results The accessibility went from nearly 69 to 100! What next Now i will work on the best practices! Update after the devlog: Nearly every metric is already maxed out lol, i will ship it very soon!
All done, it is time to ship Every metric at lighthouse it nearly perfect, im so exited to ship it!
Added install guides Now there is guides to help the user install for ubuntu, arch and windows. Notice that im a linux user and my pc is weak, so i could not test it on another operational system. Also the guide is in portuguese (all of them), please use your browser built-in translator or any of them to read if u dont understands portuguese I could test it on another linux distro, but i would have to go through all the install steps. Also i cannot try installing windows because it normally wipe out another OS installed on the same disc (i know that it just replaces the bootloader) and using a VM was not possible due to the amount of RAM and the processor that i have.
Configuring an ssh server! I configured an oracle cloud vm with ubuntu to host my website 24/7, that was because nest wasnt working in a while. Im running it at a local IP with http only, i will configure https today and maybe an domain, the IP is http://164.152.55.252 , notice that some browsers may block you from accessing and http website. UPDATE AFTER THE DEVLOG: I put an domain using duck dns: http://ritualia.duckdns.org Hardwork I had absolutely not a single knowledge about oracle cloud vm, so configuring it was an hell. Sometime my internet stopped working so i had to use my smartphone, this lead me to configuring an invalid ssh key and i had do configure everything from scratch, i spent 5 hours configuring everything, but that was ssh and wasnt tracked. But now everything is working fine. Thx oracle This vm is a 24/7 entire OS (Virtual Machine) that has some good free plans, without any cold start. Thx stardance Stardance now will have one more mount!!!!!! I still has roughly 40 hours of deep development to do after this ship, i will love to finish that in stardance!
It is time to ship! Now the system is working perfectly fine running at a vm in oracle cloud with a public domain, and a dns with duckdns at http://ritualia.duckdns.org/ Warning: It is just HTTP!
Added english readme I created an english readme, api and install Guide, so it will be easier to read and more accessible for worl-wide users
Ships:
What did i made I made an complete music play system that will help users to learn while listening to musics! I used youtube, flask, python, mysql, js and hope to make this! What else Solved a lot of painful bugs that were stopping the project from working Finished and made the music queue work Added music description labels Improved a lot the performance Made the website responsive Added a keyboard based navigation Fixed so much errors at the cover-flow that now i forgot how many Added bug checks before the play of each video on the player Created an toast component to show errors or infos Added 54 musics to choose and listen Challenges The most painful code was the player and the cover-flow, they were with a lot of hidden bugs that i had to figure out, feats that i had to make and pain to suffer! Now i figured out that i love and HATE making a website responsive! What im proud of MutationObserver: An observer that loads / hides an image based on its position at the cover-flow, this system took a while and worked very well. Error checks at player: The system can handle the error that happen and dont crash! Keyboard navigation: Everyone can use the keyboard to navigate now! Oracle VM: For the first time i used an ssh and hosted an website in my own machine (oracle, not mine)! How to test Access http://ritualia.duckdns.org/ , when you join and the page loads you will find a screen to choose an genre, select which one you want, after you will see an emotion selector, select the emotion that you wanna feel! You will see the player screen and an audio explaining the music (The audio is in portuguese), after the audio the music will play. Notice: The github and the website are in portuguese, please use your browser built-in translator or any that you want to use the software properly! Follow the installation guides at github if you want to install...
|
1793152534.9427526
|
1793238934.9427526
|
|
21116
|
The Almanac by @Vedant_Daga | Stardance
|
Vedant_Daga
|
1
|
3.0
|
17
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-19T18:47:58Z", "hours": 3.0, "multiplier": 5.99, "payout": 17, "blessing": "neutral", "text": "This is the almanac bot which sends you a cool daily digest with a Word of the Day, a random fun fact, historical events, and an inspiring quote. You can get everything at once with just /almanac-today or run each one separately if you only want one thing. What was challenging: I ran into like 1000 bugs. My code kept crashing because I was declaring variables in the wrong scope so nothing could read them, and then some of the APIs kept breaking so I just cut them and rewrote those parts. Honestly made the whole thing way simpler. What I'm proud of: If one API goes down, the rest of the digest still sends instead of the whole thing crashing. Also runs 24/7 on a server so go check it out (gogogogo) How to test it: Type /almanac-today OR Try the individual commands: /almanac-wotd - word of the day /almanac-fotd - fun fact /almanac-otd - on this day in history /almanac-qotd - quote of the day", "repo": "https://github.com/DagaVedant/Almanac-Slack-Bot", "demo": "https://app.slack.com/client/E09V59WQY1E/C0BBD17T3QB"}]...
|
[{"post_id": 12089, "ts": "202 [{"post_id": 12089, "ts": "2026-06-19T18:50:49Z", "hours": 0.0, "text": "made the last few edits before shipping..may have misordered the devlog and the ship but both the ship and the devlog are here…the ship is right before this devlog"}, {"post_id": 11388, "ts": "2026-06-18T17:08:39Z", "hours": 0.0, "text": "Got everything ready to shippppp, added a readme, made a logo, took screenshots, and organized my code"}, {"post_id": 11334, "ts": "2026-06-18T15:23:58Z", "hours": 2.0, "text": "i made a Slack bot that gives you a cool daily update with a Word of the Day, a random fun fact, historical events, and an inspiring quote. i combined everything into just one command called /almanac-today. I ran into like 1000000000000000000 different bugs. First, my code kept crashing because I made some variables inside the wrong code blocks, so the rest of the bot couldn’t read them. After I fixed that, some of the APIs were breaking, so i just removed them. It made my code sooooo much simpler and now it works perfectly."}]...
|
Title: The Almanac by @Vedant_Daga | Stardance
De Title: The Almanac by @Vedant_Daga | Stardance
Devlogs:
i made a Slack bot that gives you a cool daily update with a Word of the Day, a random fun fact, historical events, and an inspiring quote. i combined everything into just one command called /almanac-today. I ran into like 1000000000000000000 different bugs. First, my code kept crashing because I made some variables inside the wrong code blocks, so the rest of the bot couldn’t read them. After I fixed that, some of the APIs were breaking, so i just removed them. It made my code sooooo much simpler and now it works perfectly.
Got everything ready to shippppp, added a readme, made a logo, took screenshots, and organized my code
made the last few edits before shipping..may have misordered the devlog and the ship but both the ship and the devlog are here…the ship is right before this devlog
Ships:
This is the almanac bot which sends you a cool daily digest with a Word of the Day, a random fun fact, historical events, and an inspiring quote. You can get everything at once with just /almanac-today or run each one separately if you only want one thing. What was challenging: I ran into like 1000 bugs. My code kept crashing because I was declaring variables in the wrong scope so nothing could read them, and then some of the APIs kept breaking so I just cut them and rewrote those parts. Honestly made the whole thing way simpler. What I'm proud of: If one API goes down, the rest of the digest still sends instead of the whole thing crashing. Also runs 24/7 on a server so go check it out (gogogogo) How to test it: Type /almanac-today OR Try the individual commands: /almanac-wotd - word of the day /almanac-fotd - fun fact /almanac-otd - on this day in history /almanac-qotd - quote of the day...
|
1792882061.2663763
|
1793746061.2663763
|
|
21159
|
C.O.S.M.O.S by @sathyndhira | Stardance
|
sathyndhira
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-19T20:20:52Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built an orbital simulation deck using CesiumJS that visualizes real-world LEO and inclined orbit paths. I mapped out a fake telemetry pipeline to create radio link budgeting based on the position of the satellites that were orbiting the Earth based on coordinates relative to a fixed ground station. I struggled with learning the basic code a lot but eventually it got easier as I went on as it turned out to be copy paste for the satellites and flight path.", "repo": "https://github.com/Sathyndhira/C.O.S.M.O.S", "demo": "https://sathyndhira.github.io/C.O.S.M.O.S/"}]...
|
[{"post_id": 12124, "ts": "202 [{"post_id": 12124, "ts": "2026-06-19T20:12:04Z", "hours": 0.3531, "text": "This is the final devlog for this project! It was a great experience getting to build this. Added: The ISS and it’s own path RF Engineering and displaying signal connection Stuggles: Nothing much today, it was mostly just copy pasting previous code."}, {"post_id": 11618, "ts": "2026-06-18T22:25:07Z", "hours": 0.6, "text": "I got pretty far today. It was mostly just a repeat of last devlog, adding another satellite using similar code but the latitude coordinates were hard to manage. Added: COSMOS-2 which is similar to COSMOS-1 but with different colors and goes North and South Control Panel on the top corner of the screen showing basic information such as activity Struggles It was hard to control the latitude of COSMOS-2’s coordinates It took a while to learn how to create a sci-fi panel style Next: Adding more information to the space panel"}, {"post_id": 11452, "ts": "2026-06-18T18:40:28Z", "hours": 0.5844, "text": "I created the first satellite (COSMOS-1) which orbits in LEO (Low Earth Orbit) with a designated path around the top of the Earth. I also set Mission Control to California! Added: Goldstone Ground Control in California Fixed a Camera Tracking Bug to make a Cinematic Entrance to Ground Control Added COMOS-1, the first satellite of many to come, which orbits in LEO (Low-Earth-Orbit) Added COMOS-1’s flight path Struggles: The flight path wouldn’t generate properly for a long time. Fixed it with an array which generates multiple points finally creating a circle. Had to use AI to fix many many typos that I couldn’t find :(. Next Steps: Second Satellite going North to South And the ISS in real time. A Clean Panel Showing important information on the side."}, {"post_id": 10888, "ts": "2026-06-17T20:54:35Z", "hours": 0.4989, "text": "This is the first step in this project. It visualizes the Earth with Cesium (which took me a long time before I started recording this to learn). I used HTML and Local Server within VS Code to create this simulation of Earth. Next, I need to add a coordinate plane for this simulation."}]...
|
Title: C.O.S.M.O.S by @sathyndhira | Stardance
De Title: C.O.S.M.O.S by @sathyndhira | Stardance
Devlogs:
This is the first step in this project. It visualizes the Earth with Cesium (which took me a long time before I started recording this to learn). I used HTML and Local Server within VS Code to create this simulation of Earth. Next, I need to add a coordinate plane for this simulation.
I created the first satellite (COSMOS-1) which orbits in LEO (Low Earth Orbit) with a designated path around the top of the Earth. I also set Mission Control to California! Added: Goldstone Ground Control in California Fixed a Camera Tracking Bug to make a Cinematic Entrance to Ground Control Added COMOS-1, the first satellite of many to come, which orbits in LEO (Low-Earth-Orbit) Added COMOS-1’s flight path Struggles: The flight path wouldn’t generate properly for a long time. Fixed it with an array which generates multiple points finally creating a circle. Had to use AI to fix many many typos that I couldn’t find :(. Next Steps: Second Satellite going North to South And the ISS in real time. A Clean Panel Showing important information on the side.
I got pretty far today. It was mostly just a repeat of last devlog, adding another satellite using similar code but the latitude coordinates were hard to manage. Added: COSMOS-2 which is similar to COSMOS-1 but with different colors and goes North and South Control Panel on the top corner of the screen showing basic information such as activity Struggles It was hard to control the latitude of COSMOS-2’s coordinates It took a while to learn how to create a sci-fi panel style Next: Adding more information to the space panel
This is the final devlog for this project! It was a great experience getting to build this. Added: The ISS and it’s own path RF Engineering and displaying signal connection Stuggles: Nothing much today, it was mostly just copy pasting previous code.
Ships:
I built an orbital simulation deck using CesiumJS that visualizes real-world LEO and inclined orbit paths. I mapped out a fake telemetry pipeline to create radio link budgeting based on the position of the satellites that were orbiting the Earth based on coordinates relative to a fixed ground station. I struggled with learning the basic code a lot but eventually it got easier as I went on as it turned out to be copy paste for the satellites and flight path....
|
1793202703.221539
|
1793289103.221539
|
|
21221
|
Noya Explorer by @_Nixo_ | Stardance
|
_Nixo_
|
1
|
33.66
|
12
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-21T21:27:48Z", "hours": 3.0, "multiplier": 4.19, "payout": 12, "blessing": "neutral", "text": "I made Noya Explorer for better organisations but it still in development", "repo": "https://github.com/Nixo0725/NoyaExplorer", "demo": "https://github.com/Nixo0725/NoyaExplorer/releases/tag/v0.1.0"}]...
|
[{"post_id": 31528, "ts": "202 [{"post_id": 31528, "ts": "2026-07-20T00:28:16Z", "hours": 10.1567, "text": "Made some really good progress on Noya Explorer over the last few days.One of the biggest changes is that the app is now fully translated in both English and French. I added a proper language system with a language switcher in the settings, and every part of the UI now uses translations instead of hardcoded text.I also started making the explorer feel more personal. There’s now a new Home page showing your most used files and recently opened files, plus a persistent Favorites system. You can pin folders straight from the explorer, manage them from the sidebar, and they’ll still be there the next time you launch the app.Search got a pretty big upgrade too. Instead of only looking at file names, it now ranks results by relevance and can even search inside text files with a small preview showing where the match was found.On the performance side I spent some time optimizing things. Long file lists are now virtualized so they stay smooth, and I started using Rayon on the Rust backend to parallelize heavier operations like directory sorting and storage analysis.I also cleaned up a good part of the codebase by splitting some large components into smaller ones, which should make future updates much easier to build.Noya Explorer is slowly starting to feel like a real daily driver instead of just a side project, and I’m really happy with the direction it’s taking.As always, I’m open to any suggestions or feedback, so if there’s a feature you’d like to see or something you think could be improved, let me know :)"}, {"post_id": 30728, "ts": "2026-07-18T15:30:28Z", "hours": 12.9247, "text": "Development Log — Noya Explorer Noya Explorer received a huge update focused on turning it into a real file explorer instead of just a file browser. First, I fixed a compilation issue caused by a duplicated tokio key in src-tauri/Cargo.toml , which was preventing Cargo from parsing the project correctly. After that, I completely redesigned the interface and theme system. The old system with multiple dark-only themes(never see the day) was replaced with a cleaner light/dark theme setup with automatic system detection, a new purple accent color, and a more technical angular design. I removed the glassmorphism style, reduced border radius, improved typography, and created a more unique identity inspired by Linux file managers like Nautilus and Dolphin while keeping Noya Explorer’s own style. The file icons were also improved with category-based colors: folders, images, videos, audio files, documents, archives, code files, and executables now have their own visual identity, making navigation easier. The settings panel was redesigned with a simple Auto / Light / Dark selector instead of the previous theme cards system. I also fixed file opening issues by replacing the Tauri opener plugin with a native Rust command using the system file opener ( xdg-open on Linux, open on macOS, and cmd start on Windows), making file launching more reliable. The biggest part of this update was transforming Noya Explorer into a real file manager. I added new Rust backend commands for creating files and folders, renaming, deleting, copying, moving entries, and retrieving detailed file information such as size, dates, permissions, and extensions. On the React side, a large part of the application was rewritten to add real explorer features: multi-selection, copy/cut/paste operations, right-click context menus, file creation dialogs, rename dialogs, delete confirmations, a detailed properties panel, a new toolbar, and many keyboard shortcuts. New shortcuts include: Ctrl+C to copy Ctrl+X to cut Ctrl+V to paste F2 to rename Delete to remove files Ctrl+A to select everything Ctrl+Shift+N to create a folder Alt + arrows for navigation I also created new reusable components like ContextMenu , Dialog , and PropertiesPanel to keep the code cleaner and easier to maintain. Finally, I adjusted the layout by moving the Analyze and Settings buttons into the sidebar footer, making the sidebar fixed, removing unnecessary elements, and improving the overall consistency of the UI. This update is a major milestone for Noya Explorer. It is no longer just a file viewer, but a real modern file manager with its own design language. The next goals are advanced features like storage analysis, duplicate detection, suspicious file detection, and smarter file organization."}, {"post_id": 29846, "ts": "2026-07-17T00:04:33Z", "hours": 7.5775, "text": "Made some solid progress on Noya Explorer today. The app was already able to list files and navigate directories but it felt bare. I added a sidebar with quick access to the home folder, Desktop, Documents, Downloads, and all the drives on my machine, it auto-loads the last visited folder on startup so you pick up where you left off. There’s also a proper breadcrumb now that lets you click any parent folder or type a path directly. Navigation works with back/forward/up buttons and keyboard shortcuts too (Alt+arrows or Backspace to go back). Then I built a storage analysis panel that recursively scans the current directory from Rust, categorizes every file by type, and shows a breakdown with total size, file count, and visual bars per category: images, videos, audio, documents, archives, code, executables. The whole thing compiles and runs as a Tauri desktop app, and it’s starting to look like a real file explorer so im happy with it"}, {"post_id": 13349, "ts": "2026-06-21T21:22:10Z", "hours": 1.6453, "text": "Made progress on Noya Explorer today. After the initial setup I wanted to get something actually working, a basic file browser that can list files from a folder on my computer. I wrote a Rust command in Tauri that reads a directory and returns the file list with names, sizes, dates and whether each entry is a folder or a file. Then I built a simple React interface that calls this command and displays the results. You can click a button to open a folder picker and the files show up in a list with icons based on file type. Clicking a folder navigates into it, and there’s a back button to go up.I also added a simple file type detection system based on extensions — images, videos, audio, documents, archives, code files, executables. Each type gets its own emoji icon for now. The file list shows name, size and modification date. Nothing fancy yet but it actually works.The UI is dark themed with a clean header and a basic toolbar. Still looks like a prototype but the core loop is there: pick a folder, browse its contents, navigate around. So i’m happy. Next I want to add search, sorting and folder size calculation."}, {"post_id": 12229, "ts": "2026-06-19T23:15:04Z", "hours": 1.4178, "text": "Started working on Noya Explorer today. The goal is to build a better local file explorer with Rust, Tauri, React and TypeScript. I want it to be more useful than a classic file explorer, with search, categories, storage analysis and later suspicious file detection. For this first session, I set up the Tauri project structure, created the basic repository, worked on the README, added the non-commercial license, and planned the first MVP features. Next, I want to make the first real interface: a simple file browser view with a sidebar, a file list, and basic navigation."}]...
|
Title: Noya Explorer by @_Nixo_ | Stardance
Devlo Title: Noya Explorer by @_Nixo_ | Stardance
Devlogs:
Started working on Noya Explorer today. The goal is to build a better local file explorer with Rust, Tauri, React and TypeScript. I want it to be more useful than a classic file explorer, with search, categories, storage analysis and later suspicious file detection. For this first session, I set up the Tauri project structure, created the basic repository, worked on the README, added the non-commercial license, and planned the first MVP features. Next, I want to make the first real interface: a simple file browser view with a sidebar, a file list, and basic navigation.
Made progress on Noya Explorer today. After the initial setup I wanted to get something actually working, a basic file browser that can list files from a folder on my computer. I wrote a Rust command in Tauri that reads a directory and returns the file list with names, sizes, dates and whether each entry is a folder or a file. Then I built a simple React interface that calls this command and displays the results. You can click a button to open a folder picker and the files show up in a list with icons based on file type. Clicking a folder navigates into it, and there’s a back button to go up.I also added a simple file type detection system based on extensions — images, videos, audio, documents, archives, code files, executables. Each type gets its own emoji icon for now. The file list shows name, size and modification date. Nothing fancy yet but it actually works.The UI is dark themed with a clean header and a basic toolbar. Still looks like a prototype but the core loop is there: pick a folder, browse its contents, navigate around. So i’m happy. Next I want to add search, sorting and folder size calculation.
Made some solid progress on Noya Explorer today. The app was already able to list files and navigate directories but it felt bare. I added a sidebar with quick access to the home folder, Desktop, Documents, Downloads, and all the drives on my machine, it auto-loads the last visited folder on startup so you pick up where you left off. There’s also a proper breadcrumb now that lets you click any parent folder or type a path directly. Navigation works with back/forward/up buttons and keyboard shortcuts too (Alt+arrows or Backspace to go back). Then I built a storage analysis panel that recursively scans the current directory from Rust, categorizes every file by type, and shows a breakdown with total size, file count, and visual bars per category: images, videos, audio, documents, archives, code, executables. The whole thing compiles and runs as a Tauri desktop app, and it’s starting to look like a real file explorer so im happy with it
Development Log — Noya Explorer Noya Explorer received a huge update focused on turning it into a real file explorer instead of just a file browser. First, I fixed a compilation issue caused by a duplicated tokio key in src-tauri/Cargo.toml , which was preventing Cargo from parsing the project correctly. After that, I completely redesigned the interface and theme system. The old system with multiple dark-only themes(never see the day) was replaced with a cleaner light/dark theme setup with automatic system detection, a new purple accent color, and a more technical angular design. I removed the glassmorphism style, reduced border radius, improved typography, and created a more unique identity inspired by Linux file managers like Nautilus and Dolphin while keeping Noya Explorer’s own style. The file icons were also improved with category-based colors: folders, images, videos, audio files, documents, archives, code files, and executables now have their own visual identity, making navigation easier. The settings panel was redesigned with a simple Auto / Light / Dark selector instead of the previous theme cards system. I also fixed file opening issues by replacing the Tauri opener plugin with a native Rust command using the system file opener ( xdg-open on Linux, open on macOS, and cmd start on Windows), making file launching more reliable. The biggest part of this update was transforming Noya Explorer into a real file manager. I added new Rust backend commands for creating files and folders, renaming, deleting, copying, moving entries, and retrieving detailed file information such as size, dates, permissions, and extensions. On the React side, a large part of the application was rewritten to add real explorer features: multi-selection, copy/cut/paste operations, right-click context menus, file creation dialogs, rename dialogs, delete confirmations, a detailed properties panel, a new toolbar, and many keyboard shortcuts. New shortcuts include: Ctrl+C to copy Ctrl+X to cut Ctrl+V to paste F2 to rename Delete to remove files Ctrl+A to select everything Ctrl+Shift+N to create a folder Alt + arrows for navigation I also created new reusable components like ContextMenu , Dialog , and PropertiesPanel to keep the code cleaner and easier to maintain. Finally, I adjusted the layout by moving the Analyze and Settings buttons into the sidebar footer, making the sidebar fixed, removing unnecessary elements, and improving the overall consistency of the UI. This update is a major milestone for Noya Explorer. It is no longer just a file viewer, but a real modern file manager with its own design language. The next goals are advanced features like storage analysis, duplicate detection, suspicious file detection, and smarter file organization.
Made some really good progress on Noya Explorer over the last few days.One of the biggest changes is that the app is now fully translated in both English and French. I added a proper language system with a language switcher in the settings, and every part of the UI now uses translations instead of hardcoded text.I also started making the explorer feel more personal. There’s now a new Home page showing your most used files and recently opened files, plus a persistent Favorites system. You can pin folders straight from the explorer, manage them from the sidebar, and they’ll still be there the next time you launch the app.Search got a pretty big upgrade too. Instead of only looking at file names, it now ranks results by relevance and can even search inside text files with a small preview showing where the match was found.On the performance side I spent some time optimizing things. Long file lists are now virtualized so they stay smooth, and I started using Rayon on the Rust backend to parallelize heavier operations like directory sorting and storage analysis.I also cleaned up a good part of the codebase by splitting some large components into smaller ones, which should make future updates much easier to build.Noya Explorer is slowly starting to feel like a real daily driver instead of just a side project, and I’m really happy with the direction it’s taking.As always, I’m open to any suggestions or feedback, so if there’s a feature you’d like to see or something you think could be improved, let me know :)
Ships:
I made Noya Explorer for better organisations but it still in development...
|
1793134323.6155403
|
1793220723.6155403
|
|
21227
|
Weather App by @Grace3 | Stardance
|
Grace3
|
1
|
2.0
|
6
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-27T11:43:48Z", "hours": 2.0, "multiplier": 2.51, "payout": 6, "blessing": "neutral", "text": "A weather lookup app: type in a city, hit Get Weather, and a card updates with the temperature, humidity, a short description, and a matching emoji — all pulled live from the OpenWeatherMap API. using HTML, CSS and JS,", "repo": "https://github.com/Temi-ay/Weather-app", "demo": "https://temi-ay.github.io/Weather-app/"}]...
|
[{"post_id": 16856, "ts": "202 [{"post_id": 16856, "ts": "2026-06-27T11:11:41Z", "hours": 1.3294, "text": "A simple weather lookup app: enter a city, hit “Get Weather,” and see the current temperature, humidity, description, and an emoji for the conditions. Built with HTML, CSS, and JavaScript, using the OpenWeatherMap API."}, {"post_id": 16347, "ts": "2026-06-26T16:25:19Z", "hours": 1.1461, "text": "I built the layout for a Weather App; the structure and design are complete"}]...
|
Title: Weather App by @Grace3 | Stardance
Devlogs Title: Weather App by @Grace3 | Stardance
Devlogs:
I built the layout for a Weather App; the structure and design are complete
A simple weather lookup app: enter a city, hit “Get Weather,” and see the current temperature, humidity, description, and an emoji for the conditions. Built with HTML, CSS, and JavaScript, using the OpenWeatherMap API.
Ships:
A weather lookup app: type in a city, hit Get Weather, and a card updates with the temperature, humidity, a short description, and a matching emoji — all pulled live from the OpenWeatherMap API. using HTML, CSS and JS,...
|
1793260194.6042159
|
1793346594.6042159
|
|
21242
|
NetherOS by @Vova_Professor | Stardance
|
Vova_Professor
|
1
|
12.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-28T22:32:32Z", "hours": 12.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Added programming language icons and HTML support in CraftCode editor Added code autosave functionality Fixed multiple old and new bugs Added hotkeys and improved editor input handling Added automatic indentation support Added HTML syntax highlighting Improved UI/UX design Added boot screen before desktop launch Added local account registration system with basic encryption (offline only) Added window resizing for application windows Improved overall system stability and performance Fixed terminal command misspellings", "repo": "https://github.com/Vova-Professor/NetherOS", "demo": "https://vova-professor.github.io/NetherOS/boot/index.html"}]...
|
[{"post_id": 17953, "ts": "202 [{"post_id": 17953, "ts": "2026-06-28T22:16:53Z", "hours": 11.8275, "text": "Hey Stardance community! Because I’m importing this project from another Hack Club platform, I already have a lot done. So, in short, here’s what I’ve made.First, I added programming language icons and HTML support to the CraftCode code editor. I also added code autosave and fixed a lot of old and new bugs. The code editor also got some hotkeys and writing improvements, such as automatic indentation and HTML syntax highlighting.I also upgraded the UI/UX. For example, I added a boot screen before the desktop launches. I added a registration form that lets users create a local account with basic encryption, although it’s not connected to the server yet, so it isn’t fully functional.Finally, I added a window resizing feature."}]...
|
Title: NetherOS by @Vova_Professor | Stardance
De Title: NetherOS by @Vova_Professor | Stardance
Devlogs:
Hey Stardance community! Because I’m importing this project from another Hack Club platform, I already have a lot done. So, in short, here’s what I’ve made.First, I added programming language icons and HTML support to the CraftCode code editor. I also added code autosave and fixed a lot of old and new bugs. The code editor also got some hotkeys and writing improvements, such as automatic indentation and HTML syntax highlighting.I also upgraded the UI/UX. For example, I added a boot screen before the desktop launches. I added a registration form that lets users create a local account with basic encryption, although it’s not connected to the server yet, so it isn’t fully functional.Finally, I added a window resizing feature.
Ships:
Added programming language icons and HTML support in CraftCode editor Added code autosave functionality Fixed multiple old and new bugs Added hotkeys and improved editor input handling Added automatic indentation support Added HTML syntax highlighting Improved UI/UX design Added boot screen before desktop launch Added local account registration system with basic encryption (offline only) Added window resizing for application windows Improved overall system stability and performance Fixed terminal command misspellings...
|
1793271261.0544267
|
1793357661.0544267
|
|
21283
|
CosmicGuessr by @ArylesMedjebar | Stardance
|
ArylesMedjebar
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T23:36:05Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a quiz to learn things about astronomie, it will grow with time because this is my first time ine computer code.", "repo": "https://github.com/Arylesmjbr/CosmoGuessr", "demo": "https://Arylesmjbr.github.io/CosmoGuessr"}]...
|
[{"post_id": 11642, "ts": "202 [{"post_id": 11642, "ts": "2026-06-18T23:28:56Z", "hours": 2.1447, "text": "I made a little quiz on astronomie (the best part coming soon)."}]...
|
Title: CosmicGuessr by @ArylesMedjebar | Stardance Title: CosmicGuessr by @ArylesMedjebar | Stardance
Devlogs:
I made a little quiz on astronomie (the best part coming soon).
Ships:
I made a quiz to learn things about astronomie, it will grow with time because this is my first time ine computer code....
|
1793289340.0951412
|
1793375740.0951412
|
|
21285
|
My very own WebOS by @MysticisOG | Stardance
|
MysticisOG
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-18T19:55:32Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a website called launch os in which there is a live clock and a window to view notes from launch control from different launch sites and also different launches that are upcoming around the world. This was really hard since I did not know how to code, so this was a challenge, but the agent helped quite a bit.", "repo": "https://github.com/MysticisOG/Launch-os", "demo": "https://mysticisog.github.io/Launch-os/"}]...
|
[{"post_id": 30846, "ts": "202 [{"post_id": 30846, "ts": "2026-07-18T19:52:03Z", "hours": 0.2833, "text": "I added draggable windows and a little blue afterburner effect for the cursor."}, {"post_id": 30738, "ts": "2026-07-18T15:52:22Z", "hours": 1.175, "text": "A website that shows upcoming rocket launches- I am pretty much done and have learned a lot. This was fun, and the AI bot helped me a bunch."}, {"post_id": 29939, "ts": "2026-07-17T03:40:34Z", "hours": 0.2803, "text": "I am working on web os for my school club but I am also learning so things are a little slow for now."}]...
|
Title: My very own WebOS by @MysticisOG | Stardanc Title: My very own WebOS by @MysticisOG | Stardance
Devlogs:
I am working on web os for my school club but I am also learning so things are a little slow for now.
A website that shows upcoming rocket launches- I am pretty much done and have learned a lot. This was fun, and the AI bot helped me a bunch.
I added draggable windows and a little blue afterburner effect for the cursor.
Ships:
I made a website called launch os in which there is a live clock and a window to view notes from launch control from different launch sites and also different launches that are upcoming around the world. This was really hard since I did not know how to code, so this was a challenge, but the agent helped quite a bit....
|
1793256675.685234
|
1793343075.685234
|
|
21303
|
MultiHeadSubleq by @ciaran | Stardance
|
ciaran
|
1
|
21.0
|
219
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-06T02:23:04Z", "hours": 21.0, "multiplier": 10.43, "payout": 219, "blessing": "neutral", "text": "Finally done! After quite a bit of issues of the infernal persuasion, its actually done! Somehow, despite this project encompassing emulating an (albeit simple) CPU, multithreading in assembly with zero protections, and writing a bunch of math routines from scratch, the hardest part was probably making things not look horrible.", "repo": "https://github.com/ciaranmcguinness/multisubleq", "demo": "https://cmcg.pyscriptapps.com/jolly-union/"}]...
|
[{"post_id": 23241, "ts": "202 [{"post_id": 23241, "ts": "2026-07-06T02:19:26Z", "hours": 0.4142, "text": "Made a few final touchups to the readme, built a CLI to run asm without having to edit python files."}, {"post_id": 23235, "ts": "2026-07-06T01:48:42Z", "hours": 0.3072, "text": "Punch up my readme in prep for shipping."}, {"post_id": 23220, "ts": "2026-07-06T01:22:24Z", "hours": 1.6681, "text": "I built a TUI version of the webapp! It’s not as pretty as I’d like, but its good enough."}, {"post_id": 23134, "ts": "2026-07-05T22:10:58Z", "hours": 7.2711, "text": "CSS IS PAIN Most of this time was fighting a losing battle against CSS. But in my darkest hour (~2:00 AM, last night), a knight in shining armor came to rescue me, Claude. The actual code part was pretty easy, mostly just hooking up methods to buttons and making my assembler work in micropython. All I have left now is writing a tutorial, so people can better figure out how this works."}, {"post_id": 12235, "ts": "2026-06-19T23:41:01Z", "hours": 8.2114, "text": "I accidentally made a pesudo-compiler. AGAIN. Also, I hate numbers now. So, I’m working on a parallel implementation of an esoteric-ish assembly language called subleq. The defining feature of which is that it only has a single instruction, Subtract and jump if Less than or EQual to zero (hence the name). At first, I thought this was going to be a simple project. Maybe 4 hours writing the implementation and 2 hours writing a frontend. Boy, was I wrong. At first it was all going to plan, I had most of it done. I just needed to write a few demo programs for multiprocessing and then I plonk it into web assembly and give it a UI. Then the worms started talking to me. They said, “you know how painful writing subleq by hand is, you should make some helper functions, like you had when you first learned about subleq.” So I made a few functions, addition, subtraction, jumping, and inverting values. But then I heard the worms voice, echoing from the distance, “Multiplication and division would be easy, and it would mean you could find primes.” Condemnation directly to number hell The worms lied to me, as they often do. It was in fact not easy. Multiplication was less painful. Its just repeated addition. BUT, i have to deal with negatives. So, the simpler of the two became spaghetti. And that was the east one! Next it was time for division. Division (and it’s twin, modulo) legitimately could have been most of this time. I’m not exactly sure how my division routine works, because it was written at midnight. But what I can tell you is that it involves magic numbers, loops, and subtracting zero from zero. Also it broke my compiler, flinging the function pointer directly into my variables, requiring multiple patch jobs to the division function and my compiler. But now! Finally! I have a working calculator! Now to parallelize…"}, {"post_id": 11008, "ts": "2026-06-18T01:06:15Z", "hours": 1.0592, "text": "Got parallel working! Now i just need to hook it up to HTML canvas and maybe make some convenience functions."}, {"post_id": 10966, "ts": "2026-06-17T23:51:58Z", "hours": 2.1264, "text": "Finally got the basics of this done! Assembler is fully working and I have my IO such that I could theoretically glue multiple heads/processors together. Emphasis on theoretically."}]...
|
Title: MultiHeadSubleq by @ciaran | Stardance
Dev Title: MultiHeadSubleq by @ciaran | Stardance
Devlogs:
Finally got the basics of this done! Assembler is fully working and I have my IO such that I could theoretically glue multiple heads/processors together. Emphasis on theoretically.
Got parallel working! Now i just need to hook it up to HTML canvas and maybe make some convenience functions.
I accidentally made a pesudo-compiler. AGAIN. Also, I hate numbers now. So, I’m working on a parallel implementation of an esoteric-ish assembly language called subleq. The defining feature of which is that it only has a single instruction, Subtract and jump if Less than or EQual to zero (hence the name). At first, I thought this was going to be a simple project. Maybe 4 hours writing the implementation and 2 hours writing a frontend. Boy, was I wrong. At first it was all going to plan, I had most of it done. I just needed to write a few demo programs for multiprocessing and then I plonk it into web assembly and give it a UI. Then the worms started talking to me. They said, “you know how painful writing subleq by hand is, you should make some helper functions, like you had when you first learned about subleq.” So I made a few functions, addition, subtraction, jumping, and inverting values. But then I heard the worms voice, echoing from the distance, “Multiplication and division would be easy, and it would mean you could find primes.” Condemnation directly to number hell The worms lied to me, as they often do. It was in fact not easy. Multiplication was less painful. Its just repeated addition. BUT, i have to deal with negatives. So, the simpler of the two became spaghetti. And that was the east one! Next it was time for division. Division (and it’s twin, modulo) legitimately could have been most of this time. I’m not exactly sure how my division routine works, because it was written at midnight. But what I can tell you is that it involves magic numbers, loops, and subtracting zero from zero. Also it broke my compiler, flinging the function pointer directly into my variables, requiring multiple patch jobs to the division function and my compiler. But now! Finally! I have a working calculator! Now to parallelize…
CSS IS PAIN Most of this time was fighting a losing battle against CSS. But in my darkest hour (~2:00 AM, last night), a knight in shining armor came to rescue me, Claude. The actual code part was pretty easy, mostly just hooking up methods to buttons and making my assembler work in micropython. All I have left now is writing a tutorial, so people can better figure out how this works.
I built a TUI version of the webapp! It’s not as pretty as I’d like, but its good enough.
Punch up my readme in prep for shipping.
Made a few final touchups to the readme, built a CLI to run asm without having to edit python files.
Ships:
Finally done! After quite a bit of issues of the infernal persuasion, its actually done! Somehow, despite this project encompassing emulating an (albeit simple) CPU, multithreading in assembly with zero protections, and writing a bunch of math routines from scratch, the hardest part was probably making things not look horrible....
|
1793267412.755737
|
1793353812.755737
|
|
21306
|
STARVEST by @JDG | Stardance
|
JDG
|
1
|
9.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-28T14:56:13Z", "hours": 9.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "What did you make? Starvest is a satellite-driven trading signal for Frozen Concentrated Orange Juice (FCOJ) futures. It pulls 20 years of NASA MODIS satellite imagery to measure the health of Florida’s orange groves every January through March, then issues a directional prediction on OJ futures before the April expiry. The dashboard shows the full backtest, NDVI trend, yield vs. price history, and the current 2026 signal (LONG). What was challenging? Cleaning and aligning six independent data sources (NASA satellite data via Google Earth Engine, USDA crop stats, ICE futures prices, NOAA weather records, and Brazil production data) across 20 years without gaps or mismatches. Florida’s orange industry has shrunk 69% since 2005 due to citrus greening disease, so the signal had to account for a structurally collapsing baseline, not just year-to-year weather noise. What are you proud of? The backtest hits 62% directional accuracy (13/21 years) using only publicly available NASA data, no proprietary feeds. The whole pipeline runs on free APIs and the dashboard works without any setup for the judge. What should people know so they can test your project? The live dashboard is deployed and requires no setup, just click the link. If you want to run it locally, clone the repo and run streamlit run dashboard/app.py. The pre-built CSV is included so no API keys are needed.", "repo": "https://github.com/justindelgiudice/Starvest", "demo": "https://huggingface.co/spaces/JustinDG/Starvest"}]...
|
[{"post_id": 17332, "ts": "202 [{"post_id": 17332, "ts": "2026-06-28T02:21:36Z", "hours": 9.3883, "text": "Started with a question: can you predict whether OJ futures will go up or down before the harvest, using only satellite data? Built a full data pipeline pulling NASA MODIS MOD13Q1 satellite imagery (250m resolution) over the Florida citrus belt every January through March via Google Earth Engine. The core signal is NDVI surprise, how much greener or browner the groves are compared to their 3-year rolling average. Brown groves = stressed trees = lower yield = price goes up.Added five more data sources on top: USDA NASS for Florida orange production and bearing acreage, ICE OJ futures prices via yfinance, NOAA GHCN-Daily for hard freeze days and rainfall, and USDA FAS for Brazil production as a global supply check.Built a Streamlit dashboard with 6 tabs: Overview, NDVI Trend, Yield vs Price, Backtest, Signal, and Glossary. The Backtest tab lets you adjust a threshold slider and see cumulative P&L, hit rate, and a 3-tier signal comparison (NDVI only, plus Brazil confirmation, plus drought confirmation).Backtested across 2005 to 2025: 62% directional accuracy (13/21 years correct). Most commodity price prediction models rely on historical price patterns or economic indicators and typically land around 52 to 54% directional accuracy on out-of-sample data. Starvest gets its edge from reading the physical world directly via satellite before the supply shock shows up in any price data. The signal is issued in March, months before the market fully prices in the harvest outcome.The 2026 forward signal is LONG. Hard freeze in January (24.1°F, 2 days) plus drought stress pushed NDVI surprise to -0.0423. Outcome resolves in September."}]...
|
Title: STARVEST by @JDG | Stardance
Devlogs:
Star Title: STARVEST by @JDG | Stardance
Devlogs:
Started with a question: can you predict whether OJ futures will go up or down before the harvest, using only satellite data? Built a full data pipeline pulling NASA MODIS MOD13Q1 satellite imagery (250m resolution) over the Florida citrus belt every January through March via Google Earth Engine. The core signal is NDVI surprise, how much greener or browner the groves are compared to their 3-year rolling average. Brown groves = stressed trees = lower yield = price goes up.Added five more data sources on top: USDA NASS for Florida orange production and bearing acreage, ICE OJ futures prices via yfinance, NOAA GHCN-Daily for hard freeze days and rainfall, and USDA FAS for Brazil production as a global supply check.Built a Streamlit dashboard with 6 tabs: Overview, NDVI Trend, Yield vs Price, Backtest, Signal, and Glossary. The Backtest tab lets you adjust a threshold slider and see cumulative P&L, hit rate, and a 3-tier signal comparison (NDVI only, plus Brazil confirmation, plus drought confirmation).Backtested across 2005 to 2025: 62% directional accuracy (13/21 years correct). Most commodity price prediction models rely on historical price patterns or economic indicators and typically land around 52 to 54% directional accuracy on out-of-sample data. Starvest gets its edge from reading the physical world directly via satellite before the supply shock shows up in any price data. The signal is issued in March, months before the market fully prices in the harvest outcome.The 2026 forward signal is LONG. Hard freeze in January (24.1°F, 2 days) plus drought stress pushed NDVI surprise to -0.0423. Outcome resolves in September.
Ships:
What did you make? Starvest is a satellite-driven trading signal for Frozen Concentrated Orange Juice (FCOJ) futures. It pulls 20 years of NASA MODIS satellite imagery to measure the health of Florida’s orange groves every January through March, then issues a directional prediction on OJ futures before the April expiry. The dashboard shows the full backtest, NDVI trend, yield vs. price history, and the current 2026 signal (LONG). What was challenging? Cleaning and aligning six independent data sources (NASA satellite data via Google Earth Engine, USDA crop stats, ICE futures prices, NOAA weather records, and Brazil production data) across 20 years without gaps or mismatches. Florida’s orange industry has shrunk 69% since 2005 due to citrus greening disease, so the signal had to account for a structurally collapsing baseline, not just year-to-year weather noise. What are you proud of? The backtest hits 62% directional accuracy (13/21 years) using only publicly available NASA data, no proprietary feeds. The whole pipeline runs on free APIs and the dashboard works without any setup for the judge. What should people know so they can test your project? The live dashboard is deployed and requires no setup, just click the link. If you want to run it locally, clone the repo and run streamlit run dashboard/app.py. The pre-built CSV is included so no API keys are needed....
|
1793141236.4233792
|
1793227636.4233792
|
|
21308
|
NihonGo! by @Manenti | Stardance
|
Manenti
|
1
|
39.64
|
654
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-11T19:25:19Z", "hours": 39.0, "multiplier": 17.16, "payout": 654, "blessing": "neutral", "text": "NihonGo! I made NihonGo! , a full-stack Japanese learning platform for English speakers. It includes structured lessons, interactive exercises, progress tracking, authentication, and a flashcard system where users can create decks, add cards, and practice vocabulary or writing systems like hiragana, katakana, and kanji. The most challenging part was connecting all the pieces together into a real deployed app: the React frontend, Express backend, PostgreSQL database, migrations, seed data, authentication, CORS, rate limits, and Render deployment. I also had to think carefully about how learners move through the app, so it feels like a study tool instead of just a collection of pages. I’m proud that NihonGo! is not only a UI mockup, but a working full-stack project with user accounts, saved progress, lessons, exercises, and flashcards. I’m also proud of improving the project structure, documentation, deployment setup, and overall polish so it feels more complete and usable. To test the project, create a new account or log in, then explore the dashboard, modules, lessons, trainer, and flashcards pages. The app may take a few seconds to respond the first time because the backend is hosted on Render’s free tier and can spin down when inactive.", "repo": "https://github.com/noname697/NihonGo", "demo": "https://nihon-go-jp.vercel.app"}]...
|
[{"post_id": 27337, "ts": "202 [{"post_id": 27337, "ts": "2026-07-12T20:30:08Z", "hours": 0.64, "text": "Devlog: Fixing the Deployment After submitting NihonGo!, I found out that Render was not an accepted deployment option for this project. I also realized that Render’s free tier can put services to sleep after periods of inactivity, which is not ideal for a project that reviewers and users need to test reliably. To fix this, I migrated the deployment away from Render: Moved the frontend deployment to Vercel Moved the backend API deployment to Vercel Switched the production database to Neon PostgreSQL Updated the frontend environment variable to point to the new Vercel backend Updated the backend CORS settings to allow the new Vercel frontend URL Fixed the backend serverless deployment configuration for Vercel Added the PostgreSQL dialect module explicitly so Sequelize works correctly in Vercel’s serverless environment Re-ran the production migrations and seeders on the new database Tested account registration and the main app flow again after the migration The main reason for this change was reliability. Since Render can make free services inactive when there is no traffic for a while, the app could appear broken or slow when someone tries to test it later. Moving the app to Vercel and Neon makes the project easier to access, test, and review. The new deployment is now working correctly, with the frontend, backend, database, authentication, and CORS all connected again."}, {"post_id": 26768, "ts": "2026-07-11T19:17:43Z", "hours": 2.5694, "text": "Since the last devlog, I focused on preparing NihonGo! for a more complete public release. I expanded the learning content with new seeders for more hiragana, katakana, N5 kanji, and beginner lessons covering particles like を , に , の , questions with か , and polite ます verbs. I also added backend tests with Jest and Supertest to validate the API health check, protected dashboard routes, and unknown route handling. On the frontend, I repolished the landing page to better present the app as a full Japanese learning platform, with clearer calls to action, feature highlights, preview stats, and a stronger visual identity. I also added a custom favicon and included a preview GIF so the project feels more complete and presentable from the first visit. Finally, I prepared the project for deployment: I configured the backend for production PostgreSQL over SSL, added the proper start/test scripts and dependencies, consolidated the documentation into a full project README, and published the live demo on Render at nihongo-udug.onrender.com . With this, NihonGo! now has content, documentation, tests, production configuration, and a working public deployment."}, {"post_id": 26265, "ts": "2026-07-10T23:16:21Z", "hours": 4.7308, "text": "Since the last devlog, I focused on making the dashboard more complete and data-driven. On the backend, I refactored the dashboard service and presenter, expanded the statistics service to return quick stats, daily goal progress, and recent activity, adjusted progress handling, added a migration for renamed character progress columns, cleaned up unused code, and updated the API docs. On the frontend, I connected the new dashboard data to polished cards for Daily Goal, Recent Activity, Recommended Lessons, and Quick Stats. I also improved module/exercise UI details, cleaned up duplicated or unused components, fixed naming and lint issues, and made small page-level adjustments across the app. I also expanded the Flashcards feature into a fuller management flow: fetching deck details, editing and deleting decks, editing and deleting cards, refreshing due cards and progress after actions, and resolving warnings around the page state. This makes flashcards feel much closer to a complete study tool rather than just a basic review screen."}, {"post_id": 25079, "ts": "2026-07-09T01:35:53Z", "hours": 5.7917, "text": "Today I expanded NihonGo with new learning flows for practice and review. On the backend, I added the dashboard recommendation feature, connecting lesson progress, quick stats, and recommendations so users can continue unfinished lessons or start the next suggested lesson. On the frontend, I improved the Dashboard with modular cards for continuing learning, daily goals, recent activity, recommendations, and quick stats. I also built the Kana/Kanji Trainer page with filters, progress tracking, random practice, answer submission, and instant feedback. I also implemented the Flashcards experience, including deck creation, card creation, due-card review, answer reveal, and progress tracking. Finally, I cleaned up page exports/routes and fixed integration bugs across auth, exercises, module details, and flashcard behavior."}, {"post_id": 23838, "ts": "2026-07-07T00:42:42Z", "hours": 3.1194, "text": "Since the last update, I shifted the backend toward a clearer screen-driven architecture by introducing dedicated screen services and presenters. This included the first lesson screen flow, with a new lesson endpoint and controller designed to return lesson content in a frontend-friendly shape. I also prepared the presentation layer to merge lesson data with user progress details, setting up cleaner contracts between API and UI. I then expanded the dashboard API with a v2 response format focused on frontend consumption. The dashboard service now aggregates the user’s latest studied lesson plus quick stats in one place, and maps them into a structured payload for cards like Continue Learning, Lessons Completed, Exercise Accuracy, Characters Mastered, and Flashcards Reviewed. This makes the home experience more actionable and reduces data assembly work on the client side. To support this, I improved backend organization by separating domain services from screen services and updating controllers to use the new structure. I also added supporting progress/statistics functions to centralize calculations and keep business logic out of route handlers. Overall, this sprint was about making the backend more scalable, consistent, and aligned with the next frontend iterations."}, {"post_id": 21876, "ts": "2026-07-04T01:29:52Z", "hours": 2.8131, "text": "Since the last update, I pushed NihonGo! into the actual learning flow instead of just the dashboard. The modules page now pulls real progress data from the backend and presents each JLPT module as a clickable card, with loading, error, and empty states to make the experience feel complete and stable. I also added dedicated module and lesson detail pages. Module pages now show overall completion and the full list of lessons, while lesson pages display the explanation content together with exercise previews, making the study journey feel much more structured. To keep everything consistent, I introduced reusable UI pieces like page headers, badges, empty states, and lesson/exercise cards."}, {"post_id": 21666, "ts": "2026-07-03T19:03:29Z", "hours": 2.4261, "text": "I moved the front-end from setup mode into a real product experience by building the first complete dashboard screen for NihonGo! . The dashboard now loads live summary data from the API , greets the user, shows their current study progress, and highlights what they should continue next. I also added proper loading and error states so the page feels stable instead of empty. To support that, I created a small set of reusable UI pieces like cards , stat blocks , and a progress bar , which made the interface much easier to structure and keep consistent. With that in place, the front-end now feels like the beginning of a full learning platform instead of just a shell around the authentication flow."}, {"post_id": 20419, "ts": "2026-07-02T00:41:54Z", "hours": 3.1839, "text": "I started turning NihonGo! into a real frontend app by setting up the main routing structure and global providers for authentication and theme control. That gave the project a proper foundation, with protected routes for the learning area and a shared app layout that keeps navigation consistent across the site. From there, I built the first visible pieces of the interface: a landing page, a styled auth layout, and a functional login screen. I also added reusable form components, API error handling, and session logic so the frontend can talk to the backend, keep users logged in, and send them to the dashboard when authentication succeeds."}, {"post_id": 18824, "ts": "2026-06-30T00:57:08Z", "hours": 1.8339, "text": "Since the last update, I worked on the backend’s security and request-handling layer. I added validation schemas with Zod across the main routes, including auth, progress, trainer, and flashcards, so the API now validates params, query strings, and request bodies more consistently. I also improved the app structure with a rate limiter, a not-found middleware, and stronger error handling for validation and database issues. On top of that, I added CORS configuration and request logging with Morgan in development. This was also my first time using both Zod and Morgan , so this update was useful for learning how to structure validation and logging in a more organized way."}, {"post_id": 18589, "ts": "2026-06-29T19:39:02Z", "hours": 2.5708, "text": "Since the last update, I added a dashboard layer that brings together the main learning data in one place. The backend now exposes a dashboard summary route that aggregates progress across lessons, exercises, trainer characters, and flashcards, along with recent activity for each area. I also kept improving the flashcards flow by fixing the due-cards logic and adding example flashcard seed data. The app now includes the new dashboard routes, so the API is starting to feel more complete and connected across all study features."}, {"post_id": 17799, "ts": "2026-06-28T18:44:40Z", "hours": 2.0806, "text": "Since the last update, I implemented a complete Flashcards module end-to-end. This included new database migrations and models for decks, cards, and card reviews, plus the associations needed to connect users, decks, and review history. I also finished the full MVC flow for flashcards: Deck management ( create , list , view , update , delete ). Card management inside decks ( create , update , delete ). Review flow with due cards and answer submission. Review progress endpoint for tracking performance over time. On the logic side, I added mastery score calculation and a spaced-review style due-date strategy based on correct and wrong attempts. I also fixed integration issues from this cycle, including model naming, async promise handling, and boolean behavior in requests."}, {"post_id": 16609, "ts": "2026-06-27T00:43:37Z", "hours": 2.2261, "text": "Since the last devlog, I added the trainer system for study characters. The backend now supports listing characters, fetching random practice sets, submitting character answers, and tracking each user’s trainer progress . I also seeded the first batch of hiragana , katakana , and a few kanji so the trainer has real content to work with. On top of that, I wired the new trainer and progress routes into the app and fixed a few implementation issues around model names, async handling, and boolean values."}, {"post_id": 15208, "ts": "2026-06-24T18:32:51Z", "hours": 1.7694, "text": "Since the last devlog, I added the first version of the progress layer for users. The new service now tracks exercise submissions, lesson progress, and module progress, so the backend can calculate completion and score instead of only serving content. I also adjusted the models and associations to support that progress data, and fixed some import/export and naming issues along the way. The app is moving from content delivery to actual study tracking, which is the main step forward in this update."}, {"post_id": 13306, "ts": "2026-06-21T19:43:49Z", "hours": 1.1961, "text": "Since the last update, I finished the first full content layer of the backend. I added a content service that can fetch modules, individual modules with their lessons, lessons with their parent module, and lesson exercises with answer options. This turned the database schema into something the API can actually serve. I also created the content controller and routes, then mounted them in the main app under /api/content . At the same time, I added an initial content seeder to populate the database with JLPT module data, lessons, exercises, and multiple-choice options so the API has real content to work with right away. After that, I fixed a few integration issues, including import/export problems and some attribute name typos, so the content queries and models line up correctly. The backend is now in a much better state: authentication is in place, content endpoints are wired, and the database can be seeded with starter learning material."}, {"post_id": 12812, "ts": "2026-06-20T23:34:58Z", "hours": 0.7633, "text": "Since the last update, I expanded the backend schema beyond authentication and started modeling the learning content structure of NihonGo. I added the core Sequelize models for course modules, lessons, exercises, and exercise options, along with the relationships between them so the content can be loaded in a structured way. The project now supports a full content hierarchy: modules contain lessons, lessons contain exercises, and exercises can contain multiple answer options. I also kept the user model in place for authentication, with roles already prepared for future access control. On the database side, I created and ran the migrations needed to make these tables available in PostgreSQL. The schema is now in a usable state for starting content seeding and API endpoints for lessons and exercises."}, {"post_id": 12764, "ts": "2026-06-20T21:30:02Z", "hours": 0.8664, "text": "Since the last update, I focused on turning the backend into a real authentication API . I created the User model and its migration, then added the auth service layer to handle registration and login logic. I also built a token utility with JWT so authenticated users can receive access tokens after signing in. On top of that, I added an auth controller, auth routes, and a global error middleware to keep the API responses consistent. The main app was updated to use the new auth routes and the error handler, and the Sequelize setup was adjusted to load the shared config correctly."}, {"post_id": 12739, "ts": "2026-06-20T20:34:15Z", "hours": 1.0964, "text": "Set up the backend project and installed the dependencies. Added the main scripts for development, start, migrations, and seeders with sequelize-CLI. Built the Express app with cors , helmet , and JSON parsing enabled. Configured the server entry point to load environment variables and start the app on the chosen port. Created environment-based database configuration for development, test, and production. Adjusted Sequelize paths so the CLI can find the config, models, migrations, and seeders correctly."}]...
|
Title: NihonGo! by @Manenti | Stardance
Devlogs:
Title: NihonGo! by @Manenti | Stardance
Devlogs:
Set up the backend project and installed the dependencies. Added the main scripts for development, start, migrations, and seeders with sequelize-CLI. Built the Express app with cors , helmet , and JSON parsing enabled. Configured the server entry point to load environment variables and start the app on the chosen port. Created environment-based database configuration for development, test, and production. Adjusted Sequelize paths so the CLI can find the config, models, migrations, and seeders correctly.
Since the last update, I focused on turning the backend into a real authentication API . I created the User model and its migration, then added the auth service layer to handle registration and login logic. I also built a token utility with JWT so authenticated users can receive access tokens after signing in. On top of that, I added an auth controller, auth routes, and a global error middleware to keep the API responses consistent. The main app was updated to use the new auth routes and the error handler, and the Sequelize setup was adjusted to load the shared config correctly.
Since the last update, I expanded the backend schema beyond authentication and started modeling the learning content structure of NihonGo. I added the core Sequelize models for course modules, lessons, exercises, and exercise options, along with the relationships between them so the content can be loaded in a structured way. The project now supports a full content hierarchy: modules contain lessons, lessons contain exercises, and exercises can contain multiple answer options. I also kept the user model in place for authentication, with roles already prepared for future access control. On the database side, I created and ran the migrations needed to make these tables available in PostgreSQL. The schema is now in a usable state for starting content seeding and API endpoints for lessons and exercises.
Since the last update, I finished the first full content layer of the backend. I added a content service that can fetch modules, individual modules with their lessons, lessons with their parent module, and lesson exercises with answer options. This turned the database schema into something the API can actually serve. I also created the content controller and routes, then mounted them in the main app under /api/content . At the same time, I added an initial content seeder to populate the database with JLPT module data, lessons, exercises, and multiple-choice options so the API has real content to work with right away. After that, I fixed a few integration issues, including import/export problems and some attribute name typos, so the content queries and models line up correctly. The backend is now in a much better state: authentication is in place, content endpoints are wired, and the database can be seeded with starter learning material.
Since the last devlog, I added the first version of the progress layer for users. The new service now tracks exercise submissions, lesson progress, and module progress, so the backend can calculate completion and score instead of only serving content. I also adjusted the models and associations to support that progress data, and fixed some import/export and naming issues along the way. The app is moving from content delivery to actual study tracking, which is the main step forward in this update.
Since the last devlog, I added the trainer system for study characters. The backend now supports listing characters, fetching random practice sets, submitting character answers, and tracking each user’s trainer progress . I also seeded the first batch of hiragana , katakana , and a few kanji so the trainer has real content to work with. On top of that, I wired the new trainer and progress routes into the app and fixed a few implementation issues around model names, async handling, and boolean values.
Since the last update, I implemented a complete Flashcards module end-to-end. This included new database migrations and models for decks, cards, and card reviews, plus the associations needed to connect users, decks, and review history. I also finished the full MVC flow for flashcards: Deck management ( create , list , view , update , delete ). Card management inside decks ( create , update , delete ). Review flow with due cards and answer submission. Review progress endpoint for tracking performance over time. On the logic side, I added mastery score calculation and a spaced-review style due-date strategy based on correct and wrong attempts. I also fixed integration issues from this cycle, including model naming, async promise handling, and boolean behavior in requests.
Since the last update, I added a dashboard layer that brings together the main learning data in one place. The backend now exposes a dashboard summary route that aggregates progress across lessons, exercises, trainer characters, and flashcards, along with recent activity for each area. I also kept improving the flashcards flow by fixing the due-cards logic and adding example flashcard seed data. The app now includes the new dashboard routes, so the API is starting to feel more complete and connected across all study features.
Since the last update, I worked on the backend’s security and request-handling layer. I added validation schemas with Zod across the main routes, including auth, progress, trainer, and flashcards, so the API now validates params, query strings, and request bodies more consistently. I also improved the app structure with a rate limiter, a not-found middleware, and stronger error handling for validation and database issues. On top of that, I added CORS configuration and request logging with Morgan in development. This was also my first time using both Zod and Morgan , so this update was useful for learning how to structure validation and logging in a more organized way.
I started turning NihonGo! into a real frontend app by setting up the main routing structure and global providers for authentication and theme control. That gave the project a proper foundation, with protected routes for the learning area and a shared app layout that keeps navigation consistent across the site. From there, I built the first visible pieces of the interface: a landing page, a styled auth layout, and a functional login screen. I also added reusable form components, API error handling, and session logic so the frontend can talk to the backend, keep users logged in, and send them to the dashboard when authentication succeeds.
I moved the front-end from setup mode into a real product experience by building the first complete dashboard screen for NihonGo! . The dashboard now loads live summary data from the API , greets the user, shows their current study progress, and highlights what they should continue next. I also added proper loading and error states so the page feels stable instead of empty. To support that, I created a small set of reusable UI pieces like cards , stat blocks , and a progress bar , which made the interface much easier to structure and keep consistent. With that in place, the front-end now feels like the beginning of a full learning platform instead of just a shell around the authentication flow.
Since the last update, I pushed NihonGo! into the actual learning flow instead of just the dashboard. The modules page now pulls real progress data from the backend and presents each JLPT module as a clickable card, with loading, error, and empty states to make the experience feel complete and stable. I also added dedicated module and lesson detail pages. Module pages now show overall completion and the full list of lessons, while lesson pages display the explanation content together with exercise previews, making the study journey feel much more structured. To keep everything consistent, I introduced reusable UI pieces like page headers, badges, empty states, and lesson/exercise cards.
Since the last update, I shifted the backend toward a clearer screen-driven architecture by introducing dedicated screen services and presenters. This included the first lesson screen flow, with a new lesson endpoint and controller designed to return lesson content in a frontend-friendly shape. I also prepared the presentation layer to merge lesson data with user progress details, setting up cleaner contracts between API and UI. I then expanded the dashboard API with a v2 response format focused on frontend consumption. The dashboard service now aggregates the user’s latest studied lesson plus quick stats in one place, and maps them into a structured payload for cards like Continue Learning, Lessons Completed, Exercise Accuracy, Characters Mastered, and Flashcards Reviewed. This makes the home experience more actionable and reduces data assembly work on the client side. To support this, I improved backend organization by separating domain services from screen services and updating controllers to use the new structure. I also added supporting progress/statistics functions to centralize calculations and keep business logic out of route handlers. Overall, this sprint was about making the backend more scalable, consistent, and aligned with the next frontend iterations.
Today I expanded NihonGo with new learning flows for practice and review. On the backend, I added the dashboard recommendation feature, connecting lesson progress, quick stats, and recommendations so users can continue unfinished lessons or start the next suggested lesson. On the frontend, I improved the Dashboard with modular cards for continuing learning, daily goals, recent activity, recommendations, and quick stats. I also built the Kana/Kanji Trainer page with filters, progress tracking, random practice, answer submission, and instant feedback. I also implemented the Flashcards experience, including deck creation, card creation, due-card review, answer reveal, and progress tracking. Finally, I cleaned up page exports/routes and fixed integration bugs across auth, exercises, module details, and flashcard behavior.
Since the last devlog, I focused on making the dashboard more complete and data-driven. On the backend, I refactored the dashboard service and presenter, expanded the statistics service to return quick stats, daily goal progress, and recent activity, adjusted progress handling, added a migration for renamed character progress columns, cleaned up unused code, and updated the API docs. On the frontend, I connected the new dashboard data to polished cards for Daily Goal, Recent Activity, Recommended Lessons, and Quick Stats. I also improved module/exercise UI details, cleaned up duplicated or unused components, fixed naming and lint issues, and made small page-level adjustments across the app. I also expanded the Flashcards feature into a fuller management flow: fetching deck details, editing and deleting decks, editing and deleting cards, refreshing due cards and progress after actions, and resolving warnings around the page state. This makes flashcards feel much closer to a complete study tool rather than just a basic review screen.
Since the last devlog, I focused on preparing NihonGo! for a more complete public release. I expanded the learning content with new seeders for more hiragana, katakana, N5 kanji, and beginner lessons covering particles like を , に , の , questions with か , and polite ます verbs. I also added backend tests with Jest and Supertest to validate the API health check, protected dashboard routes, and unknown route handling. On the frontend, I repolished the landing page to better present the app as a full Japanese learning platform, with clearer calls to action, feature highlights, preview stats, and a stronger visual identity. I also added a custom favicon and included a preview GIF so the project feels more complete and presentable from the first visit. Finally, I prepared the project for deployment: I configured the backend for production PostgreSQL over SSL, added the proper start/test scripts and dependencies, consolidated the documentation into a full project README, and published the live demo on Render at nihongo-udug.onrender.com . With this, NihonGo! now has content, documentation, tests, production configuration, and a working public deployment.
Devlog: Fixing the Deployment After submitting NihonGo!, I found out that Render was not an accepted deployment option for this project. I also realized that Render’s free tier can put services to sleep after periods of inactivity, which is not ideal for a project that reviewers and users need to test reliably. To fix this, I migrated the deployment away from Render: Moved the frontend deployment to Vercel Moved the backend API deployment to Vercel Switched the production database to Neon PostgreSQL Updated the frontend environment variable to point to the new Vercel backend Updated the backend CORS settings to allow the new Vercel frontend URL Fixed the backend serverless deployment configuration for Vercel Added the PostgreSQL dialect module explicitly so Sequelize works correctly in Vercel’s serverless environment Re-ran the production migrations and seeders on the new database Tested account registration and the main app flow again after the migration The main reason for this change was reliability. Since Render can make free services inactive when there is no traffic for a while, the app could appear broken or slow when someone tries to test it later. Moving the app to Vercel and Neon makes the project easier to access, test, and review. The new deployment is now working correctly, with the frontend, backend, database, authentication, and CORS all connected again.
Ships:
NihonGo! I made NihonGo! , a full-stack Japanese learning platform for English speakers. It includes structured lessons, interactive exercises, progress tracking, authentication, and a flashcard system where users can create decks, add cards, and practice vocabulary or writing systems like hiragana, katakana, and kanji. The most challenging part was connecting all the pieces together into a real deployed app: the React frontend, Express backend, PostgreSQL database, migrations, seed data, authentication, CORS, rate limits, and Render deployment. I also had to think carefully about how learners move through the app, so it feels like a study tool instead of just a collection of pages. I’m proud that NihonGo! is not only a UI mockup, but a working full-stack project with user accounts, saved progress, lessons, exercises, and flashcards. I’m also proud of improving the project structure, documentation, deployment setup, and overall polish so it feels more complete and usable. To test the project, create a new account or log in, then explore the dashboard, modules, lessons, trainer, and flashcards pages. The app may take a few seconds to respond the first time because the backend is hosted on Render’s free tier and can spin down when inactive....
|
1793141401.3102083
|
1793227801.3102083
|
|
21309
|
History Guesser by @Mohamed_Ayadi | Stardance
|
Mohamed_Ayadi
|
1
|
12.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T00:19:52Z", "hours": 12.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a history trivia game called History Guesser. It’s a single HTML file that runs in any browser. The concept is simple. A pin drops on a world map. A year appears at the bottom of the screen. You pick the correct historical event from four options. After you answer, the game shows you a description and a fun fact about the event. You learn something even when you get it wrong. The game has 70 events spread across nine categories. War, Science, Politics, Exploration, Culture, Disaster, Sports, Business, and a few others. There are three difficulty levels. Easy, Medium, and Hard. You can filter by category and difficulty before you start. The game tracks your score and your streak. What I’m proud of The map actually works. The pin lands in the right place for each event. I spent hours tweaking coordinates to get that right. The fun facts are my favorite part. I dug through Wikipedia to find interesting details that stick with you. Little things that make history memorable. The quit button. It took more thought than it should have. Players need a clean way to exit without refreshing the page. I added a visible button plus Escape key support. Small thing, big difference. The design feels warm, not cold and technical. Parchment colors, a compass rose, serif fonts. It feels like an old atlas. That was intentional. What was challenging The map was the hardest part. I tried drawing it with canvas polygons and failed miserably. Africa looked like a blob. Europe looked like a potato. Wasted two days on that approach. Switching to a background image solved the problem but introduced new ones. Event placement was tedious. Every pin needed exact coordinates. I manually positioned 70 events. Refresh the page, adjust by 0.005, refresh again. Over and over. Making difficulty levels feel meaningful was tricky. I mixed obscurity with age. Ancient events are harder by default. Recent ones are easier. It’s not perfect but it works. UI responsiveness took effort. Making the game work on both desktop and mobile required careful testing. Mobile-first approach, tested on actual devices. If you want to test it The game is a single file called index.html. You need a map image called img.jpg in the same folder. Any world map with clear country outlines works. Open index.html in any browser. No server required. No installation. No dependencies. Just double click and play. If the map doesn’t load, check that img.jpg is in the same folder. The file name must be exactly img.jpg. Case matters on some systems. The game also has an online fallback so it should still work. The game should load instantly. The pin should appear smoothly. Buttons respond to both mouse and touch. Everything feels snappy. Try different category and difficulty filters. Each combination changes the event pool significantly. Easy mode has mostly famous recent events. Hard mode tests more obscure moments in history. If you find a bug or have a suggestion for more events, let me know. I’d like to add more categories eventually. Maybe a leaderboard or timer mode. But for now, this version does what I set out to do. It makes history feel less like a textbook and more like a discovery.", "repo": "https://github.com/medayedi123/History-Guesser", "demo": "https://historyguesser.netlify.app/"}]...
|
[{"post_id": 10974, "ts": "202 [{"post_id": 10974, "ts": "2026-06-18T00:13:29Z", "hours": 12.0, "text": "Dev Log So I had this idea. I wanted to make history feel physical, like it actually happened somewhere. Drop a pin. Show the year. Make people guess. That felt more like a game than a textbook. The first version was a disaster. I tried drawing the world map myself using canvas polygons. Two days of tweaking coordinates and my map still looked like a deformed potato. Africa was a blob. Europe looked like it had been through a war. I finally gave up and switched to a real image. Getting the map to work took way longer than I expected. Online images were slow. Base64 was huge. SVG was a nightmare. Eventually I just told people to drop a jpg in the same folder. It’s not fancy, but it works and it’s fast. The pin placement was its own headache. Every event needed exact coordinates. Battle of Hastings needed to hit England. Columbus needed the Caribbean. Hours of refreshing the page and tweaking numbers by tiny amounts. My eyes hurt. But building the event list was actually fun. I dug through Wikipedia looking for interesting stuff. War, science, politics, exploration, culture, disaster. Each event needed a year, location, description, and a fun fact. I probably spent too much time down rabbit holes. Did you know Beethoven was completely deaf when he conducted his ninth symphony? Or that the Mona Lisa has no eyebrows? I don’t regret a single minute of that. Difficulty levels were tricky. I mixed obscurity with age. Ancient stuff is harder. Recent stuff is easier. It’s not perfect but it works. Design wise, I wanted the game to feel warm — like an old atlas, not a corporate dashboard. Parchment colors, a compass rose, serif fonts. I wanted people to feel like they were opening a book from their grandparent’s shelf. The quit button was a small thing that took too much thought. I realized people need an easy way out. So I put one in the corner and added Escape key support. Small detail, big difference. What I learned: the little stuff matters. A good map makes the game feel real. A fun fact turns a correct answer into something you actually remember. A visible quit button shows you respect the user’s time. I also learned that AI is useful for grinding through boilerplate and generating ideas faster than I could alone. But the creative stuff, the polish, the decisions about what actually feels good — that’s still on me. The AI sketches scaffolding. I build the house. The result is a game that loads instantly, works on any device, and teaches you something without feeling like school. It’s not perfect. I’d love to add more events, better visuals, maybe some sound effects. But it’s solid, it’s fun, and I’m happy with it. If you play it and learn one thing you didn’t know before, I’ll consider it a win."}]...
|
Title: History Guesser by @Mohamed_Ayadi | Stardan Title: History Guesser by @Mohamed_Ayadi | Stardance
Devlogs:
Dev Log So I had this idea. I wanted to make history feel physical, like it actually happened somewhere. Drop a pin. Show the year. Make people guess. That felt more like a game than a textbook. The first version was a disaster. I tried drawing the world map myself using canvas polygons. Two days of tweaking coordinates and my map still looked like a deformed potato. Africa was a blob. Europe looked like it had been through a war. I finally gave up and switched to a real image. Getting the map to work took way longer than I expected. Online images were slow. Base64 was huge. SVG was a nightmare. Eventually I just told people to drop a jpg in the same folder. It’s not fancy, but it works and it’s fast. The pin placement was its own headache. Every event needed exact coordinates. Battle of Hastings needed to hit England. Columbus needed the Caribbean. Hours of refreshing the page and tweaking numbers by tiny amounts. My eyes hurt. But building the event list was actually fun. I dug through Wikipedia looking for interesting stuff. War, science, politics, exploration, culture, disaster. Each event needed a year, location, description, and a fun fact. I probably spent too much time down rabbit holes. Did you know Beethoven was completely deaf when he conducted his ninth symphony? Or that the Mona Lisa has no eyebrows? I don’t regret a single minute of that. Difficulty levels were tricky. I mixed obscurity with age. Ancient stuff is harder. Recent stuff is easier. It’s not perfect but it works. Design wise, I wanted the game to feel warm — like an old atlas, not a corporate dashboard. Parchment colors, a compass rose, serif fonts. I wanted people to feel like they were opening a book from their grandparent’s shelf. The quit button was a small thing that took too much thought. I realized people need an easy way out. So I put one in the corner and added Escape key support. Small detail, big difference. What I learned: the little stuff matters. A good map makes the game feel real. A fun fact turns a correct answer into something you actually remember. A visible quit button shows you respect the user’s time. I also learned that AI is useful for grinding through boilerplate and generating ideas faster than I could alone. But the creative stuff, the polish, the decisions about what actually feels good — that’s still on me. The AI sketches scaffolding. I build the house. The result is a game that loads instantly, works on any device, and teaches you something without feeling like school. It’s not perfect. I’d love to add more events, better visuals, maybe some sound effects. But it’s solid, it’s fun, and I’m happy with it. If you play it and learn one thing you didn’t know before, I’ll consider it a win.
Ships:
I made a history trivia game called History Guesser. It’s a single HTML file that runs in any browser. The concept is simple. A pin drops on a world map. A year appears at the bottom of the screen. You pick the correct historical event from four options. After you answer, the game shows you a description and a fun fact about the event. You learn something even when you get it wrong. The game has 70 events spread across nine categories. War, Science, Politics, Exploration, Culture, Disaster, Sports, Business, and a few others. There are three difficulty levels. Easy, Medium, and Hard. You can filter by category and difficulty before you start. The game tracks your score and your streak. What I’m proud of The map actually works. The pin lands in the right place for each event. I spent hours tweaking coordinates to get that right. The fun facts are my favorite part. I dug through Wikipedia to find interesting details that stick with you. Little things that make history memorable. The quit button. It took more thought than it should have. Players need a clean way to exit without refreshing the page. I added a visible button plus Escape key support. Small thing, big difference. The design feels warm, not cold and technical. Parchment colors, a compass rose, serif fonts. It feels like an old atlas. That was intentional. What was challenging The map was the hardest part. I tried drawing it with canvas polygons and failed miserably. Africa looked like a blob. Europe looked like a potato. Wasted two days on that approach. Switching to a background image solved the problem but introduced new ones. Event placement was tedious. Every pin needed exact coordinates. I manually positioned 70 events. Refresh the page, adjust by 0.005, refresh again. Over and over. Making difficulty levels feel meaningful was tricky. I mixed obscurity with age. Ancient events are harder by default. Recent ones are easier. It’s not perfect but it works. UI responsiveness took effort. Making the game work on both desktop and mobile required careful testing. Mobile-first approach, tested on actual devices. If you want to test it The game is a single file called index.html. You need a map image called img.jpg in the same folder. Any world map with clear country outlines works. Open index.html in any browser. No server required. No installation. No dependencies. Just double click and play. If the map doesn’t load, check that img.jpg is in the same folder. The file name must be exactly img.jpg. Case matters on some systems. The game also has an online fallback so it should still work. The game should load instantly. The pin should appear smoothly. Buttons respond to both mouse and touch. Everything feels snappy. Try different category and difficulty filters. Each combination changes the event pool significantly. Easy mode has mostly famous recent events. Hard mode tests more obscure moments in history. If you find a bug or have a suggestion for more events, let me know. I’d like to add more categories eventually. Maybe a leaderboard or timer mode. But for now, this version does what I set out to do. It makes history feel less like a textbook and more like a discovery....
|
1792878803.6204576
|
1793742803.6204576
|
|
21312
|
DevLauch by @ItaloJDev | Stardance
|
ItaloJDev
|
1
|
4.24
|
20
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-19T18:15:24Z", "hours": 3.0, "multiplier": 7.24, "payout": 20, "blessing": "neutral", "text": "What I built DevLaunch is a modern full-stack SaaS platform built to help developers, students, makers, and startup founders transform ideas into finished products. Many people start projects with excitement but lose momentum due to poor organization, scattered tools, and unclear next steps. DevLaunch solves this by providing a centralized workspace where users can plan, manage, track, and launch their projects from a single dashboard. The platform includes: Secure user authentication Project creation and management Task organization and progress tracking Project roadmaps and milestones Modern responsive user interface Scalable full-stack architecture My goal was to create a tool that reduces the friction between having an idea and successfully launching a product. What was challenging The most challenging part was designing a platform that feels simple to use while remaining scalable behind the scenes. I had to think carefully about application architecture, user experience, database structure, authentication flows, and how future features could be integrated without requiring major rewrites. Balancing usability, performance, and maintainability was a significant part of the development process. What I’m proud of I’m proud of building something that solves a problem I’ve personally experienced. As someone interested in technology and product development, I’ve seen how easy it is for projects to become disorganized and eventually abandoned. DevLaunch was created to address that challenge directly. I’m also proud that the project was built with a long-term vision rather than as a simple prototype. The architecture is designed to support future features such as AI-assisted planning, intelligent task generation, team collaboration, and external integrations. How to test Create an account or log in. Access the dashboard. Create a new project. Add tasks and milestones. Track progress through the project workflow. Explore how DevLaunch helps organize the journey from idea to launch. DevLaunch is actively evolving and represents the foundation of a larger vision: making it easier for builders to create, manage, and launch meaningful products.", "repo": "https://github.com/neymardashopepaulwalker-blip/DevLaunch", "demo": "https://dev-launch-delta.vercel.app/"}]...
|
[{"post_id": 14415, "ts": "202 [{"post_id": 14415, "ts": "2026-06-23T15:19:25Z", "hours": 1.2378, "text": "Where is my starduts??"}, {"post_id": 12068, "ts": "2026-06-19T17:58:15Z", "hours": 0.2583, "text": "[FINAL SHIPPED] DevLaunch - Fullstack SaaS Template Generator Hey everyone! 👋 DevLaunch is officially LIVE and shipped to production! 🌌DevLaunch fixes the frustration every developer faces: losing time setting up standard project boilerplates (folders, dependencies, routing) every time you start a new idea. It lets users configure, preview, and download ready-to-go, production-grade project baselines instantly in .zip format.Here is a quick breakdown of the architecture, hurdles, and the final results.🛠️ Tech Stack & ArchitectureI built a modular Monorepo with decoupled Frontend and Backend services integrated with a cloud database:Frontend: Built with React.js (Vite). Features a responsive UI with side-navigation, route guarding to prevent unauthenticated access, and a Theme Engine that transitions instantly between Dark and Light Mode.Backend: A Node.js & Express API server handling secure registration, authentication flows, and profile updates (like reactive live database password changes).Database: Hosted entirely on Supabase (PostgreSQL), storing user profiles and tracking real-time project generation logs.⚡ Key Features ShippedDynamic ZIP Generation: The backend doesn’t just store old static zip files. When a user inputs a name and clicks download, the server dynamically aggregates raw code templates, compresses them on-the-fly using binary archivers, and pipes the .zip stream straight back over HTTP.Code Preview Subsystem: Built an interactive visual editor UI that mimics VS Code. Users can click through code tabs (e.g., App.jsx, server.js) to inspect the boilerplate files before generating.Account Management & Caching Fix: Shipped a clean visual update to the account settings. Fixed a critical state persistence bug where newly registered users would fallback to placeholder metadata, ensuring emails and IDs map accurately from localStorage.Free-Tier Cloud Deployment: Frontend is live on Vercel, Backend is on Render, and Database is on Supabase.🧠 Technical Hurdles & Learnings1. Node.js Memory Stream PipelineInstead of saving files locally on the server disk first, zipping them, and deleting them (which is highly inefficient and risks disk bloat), I utilized Node.js Streams. By integrating archiver, the app pipes raw data buffers directly into the Express network response stream (res). The file is compressed directly inside RAM and pushed out instantly.2. State Syncing & Visual BugsDuring staging, user data looked like it was missing. I discovered a funny bug: the user’s email was rendering perfectly from database storage, but as pure black text on an ultra-dark background! Additionally, the signup flow wasn’t caching the newly registered email address into client session storage. I rewrote the Cadastro.jsx logic to properly cache metadata upon creation and injected high-contrast styles (#38bdf8).🎯 Verification & Links[x] Registrations write to PostgreSQL flawlessly.[x] Route guards instantly eject unauthorized visitors back to /login.[x] ZIP generator pipes compressed streams immediately.Huge thanks to the Hack Club Stardance community for the fuel to push through the roadblocks! Check out the live build and let me know your thoughts!On to the next ship! 🛸✨"}, {"post_id": 12042, "ts": "2026-06-19T17:18:05Z", "hours": 1.0825, "text": "The DevLaunch is’t amazing!!"}, {"post_id": 11913, "ts": "2026-06-19T12:52:44Z", "hours": 0.4456, "text": "This is the dashboard!"}, {"post_id": 11273, "ts": "2026-06-18T13:14:45Z", "hours": 0.5256, "text": "Ok now its difficult:("}, {"post_id": 11250, "ts": "2026-06-18T12:25:58Z", "hours": 0.4742, "text": "Working in my new project right now! Front-end is going well!"}]...
|
Title: DevLauch by @ItaloJDev | Stardance
Devlogs Title: DevLauch by @ItaloJDev | Stardance
Devlogs:
Working in my new project right now! Front-end is going well!
Ok now its difficult:(
This is the dashboard!
The DevLaunch is’t amazing!!
[FINAL SHIPPED] DevLaunch - Fullstack SaaS Template Generator Hey everyone! 👋 DevLaunch is officially LIVE and shipped to production! 🌌DevLaunch fixes the frustration every developer faces: losing time setting up standard project boilerplates (folders, dependencies, routing) every time you start a new idea. It lets users configure, preview, and download ready-to-go, production-grade project baselines instantly in .zip format.Here is a quick breakdown of the architecture, hurdles, and the final results.🛠️ Tech Stack & ArchitectureI built a modular Monorepo with decoupled Frontend and Backend services integrated with a cloud database:Frontend: Built with React.js (Vite). Features a responsive UI with side-navigation, route guarding to prevent unauthenticated access, and a Theme Engine that transitions instantly between Dark and Light Mode.Backend: A Node.js & Express API server handling secure registration, authentication flows, and profile updates (like reactive live database password changes).Database: Hosted entirely on Supabase (PostgreSQL), storing user profiles and tracking real-time project generation logs.⚡ Key Features ShippedDynamic ZIP Generation: The backend doesn’t just store old static zip files. When a user inputs a name and clicks download, the server dynamically aggregates raw code templates, compresses them on-the-fly using binary archivers, and pipes the .zip stream straight back over HTTP.Code Preview Subsystem: Built an interactive visual editor UI that mimics VS Code. Users can click through code tabs (e.g., App.jsx, server.js) to inspect the boilerplate files before generating.Account Management & Caching Fix: Shipped a clean visual update to the account settings. Fixed a critical state persistence bug where newly registered users would fallback to placeholder metadata, ensuring emails and IDs map accurately from localStorage.Free-Tier Cloud Deployment: Frontend is live on Vercel, Backend is on Render, and Database is on Supabase.🧠 Technical Hurdles & Learnings1. Node.js Memory Stream PipelineInstead of saving files locally on the server disk first, zipping them, and deleting them (which is highly inefficient and risks disk bloat), I utilized Node.js Streams. By integrating archiver, the app pipes raw data buffers directly into the Express network response stream (res). The file is compressed directly inside RAM and pushed out instantly.2. State Syncing & Visual BugsDuring staging, user data looked like it was missing. I discovered a funny bug: the user’s email was rendering perfectly from database storage, but as pure black text on an ultra-dark background! Additionally, the signup flow wasn’t caching the newly registered email address into client session storage. I rewrote the Cadastro.jsx logic to properly cache metadata upon creation and injected high-contrast styles (#38bdf8).🎯 Verification & Links[x] Registrations write to PostgreSQL flawlessly.[x] Route guards instantly eject unauthorized visitors back to /login.[x] ZIP generator pipes compressed streams immediately.Huge thanks to the Hack Club Stardance community for the fuel to push through the roadblocks! Check out the live build and let me know your thoughts!On to the next ship! 🛸✨
Where is my starduts??
Ships:
What I built DevLaunch is a modern full-stack SaaS platform built to help developers, students, makers, and startup founders transform ideas into finished products. Many people start projects with excitement but lose momentum due to poor organization, scattered tools, and unclear next steps. DevLaunch solves this by providing a centralized workspace where users can plan, manage, track, and launch their projects from a single dashboard. The platform includes: Secure user authentication Project creation and management Task organization and progress tracking Project roadmaps and milestones Modern responsive user interface Scalable full-stack architecture My goal was to create a tool that reduces the friction between having an idea and successfully launching a product. What was challenging The most challenging part was designing a platform that feels simple to use while remaining scalable behind the scenes. I had to think carefully about application architecture, user experience, database structure, authentication flows, and how future features could be integrated without requiring major rewrites. Balancing usability, performance, and maintainability was a significant part of the development process. What I’m proud of I’m proud of building something that solves a problem I’ve personally experienced. As someone interested in technology and product development, I’ve seen how easy it is for projects to become disorganized and eventually abandoned. DevLaunch was created to address that challenge directly. I’m also proud that the project was built with a long-term vision rather than as a simple prototype. The architecture is designed to support future features such as AI-assisted planning, intelligent task generation, team collaboration, and external integrations. How to test Create an account or log in. Access the dashboard. Create a new project. Add tasks and milestones. Track progress through the project workflow. Explore how DevLaunch helps organize the journey from idea to launch. DevLaunch is actively evolving and represents the foundation of a larger vision: making it easier for builders to create, manage, and launch meaningful products....
|
1793252893.7481208
|
1793339293.7481208
|
|
21327
|
IgnitionBench by @kesh | Stardance
|
kesh
|
1
|
8.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-30T18:36:51Z", "hours": 8.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a rocket motor development program called IgnitionBench. This software helps you design build and test your very own solid rocket motor! This software also comes with its own AI assistant, Delta. Delta is there to answer all your questions on rocket motors and propellant. key features include the propellant engine where you can formulate your own propellant, Autocast where delta propose grain geometry and a tutorial to learn how to use the software. this software is hours of work so I am glad to present to you, IgnitionBench.", "repo": "https://github.com/kshuklaz/IgnitionBench", "demo": "https://igbench.shukla.fr"}]...
|
[{"post_id": 58189, "ts": "202 [{"post_id": 58189, "ts": "2026-08-30T15:26:09Z", "hours": 1.1397, "text": "hello everyone! this will be the last devlog before shipment. some new features include a tutorial for the motor design and the propellant engine. I have also added a file which clearly states what the software can do and what it cannot. I don’t want peoples rockets exploding and then blaming it on the software. this about wraps it up as I am about to ship this so wish me luck. if you want to use the software here is the link to the GitHub. just clone the repo and install. kudos to claude code, it helped a ton. I also made a replica of the game rocket league which is here . anyway hope everyone has a good day, goodbye."}, {"post_id": 32716, "ts": "2026-07-22T01:26:36Z", "hours": 4.2567, "text": "IgnitionBench — Devlog 001 Alright everyone — this is devlog 001 of IgnitionBench, an AI-assisted rocket motor design tool that lets anyone, at any skill level, design their first rocket motor.What’s new this cycle:Delta, the AI assistant. Delta walks you step by step through designing your first motor as safely as possible. It needs an Anthropic API key to run — everything else in IgnitionBench works fully offline.The Propellant Engine. A whole section for developing your own propellant. It opens like the projects home — a gallery of saved propellant cards you click into — with four steps: Plan (ingredients), Prepare, Cast, and Characterization. Delta will not walk you through actually mixing propellant — you should always have an expert present and never trust an app for that. Instead there’s a safety checklist and a notepad to mark off your steps.Characterization. Log your own test-firings and it fits the an and n burn-rate values for your batch, then loads them into Plan.AutoCast (Cast step). Tell Delta how you want the rocket to fly and it proposes the best grain geometry to cast — you approve before it’s applied. (Grain shape only; Delta never formulates the propellant.)Ambient pressure + presets. Set where the motor fires — sea level, mile-high, high altitude, or space/vacuum — and watch the same motor’s thrust and Isp change.Resources button on the home screen as a citation source, and a new light mode theme.Maybe coming next: sound effects, and a plugin system so people can build their own plugins for IgnitionBench. AGAIN Delta can not give you instructions on how to prepare your propellant as per safety instructions, IgnitionBench is an app and you should have a professional present when making rocket propellant and should have the required licenses for making it"}, {"post_id": 26881, "ts": "2026-07-11T22:27:07Z", "hours": 2.1311, "text": "IGNITIONBENCH DEVLOG 000 IgnitionBench is an AI-assisted rocket motor design tool I’m building for hobbyist rocketeers. Right now, if you’re a NAR/TRA hobbyist without an engineering degree, your options are professional tools built for engineers (OpenRocket, BurnSim, RASAero II) or a pile of spreadsheets and manual math. IgnitionBench closes that gap by pairing real rocket science with plain-language guidance and an AI mentor that sits alongside the calculators instead of just spitting out numbers. three main pillars. Propellant– a guided APCP database (KNSB, KNDX, HTPB) with an interactive Kn ratio calculator and plain-language, Nozzle engine — a full de Laval nozzle calculator: throat/exit area, expansion ratio, thrust coefficient (Cf), characteristic velocity (c*), specific impulse (Isp), with a live visual diagram explanations of every parameter, 3D design + simulation — grain geometry modeling (BATES, star, finocyl), animated burn regression, a 1D flight simulator, and export to .ENG/STL for OpenRocket or 3D printing. Ignitionbench is aimed for the hobbyist rocketry group. Github Link"}]...
|
Title: IgnitionBench by @kesh | Stardance
Devlogs Title: IgnitionBench by @kesh | Stardance
Devlogs:
IGNITIONBENCH DEVLOG 000 IgnitionBench is an AI-assisted rocket motor design tool I’m building for hobbyist rocketeers. Right now, if you’re a NAR/TRA hobbyist without an engineering degree, your options are professional tools built for engineers (OpenRocket, BurnSim, RASAero II) or a pile of spreadsheets and manual math. IgnitionBench closes that gap by pairing real rocket science with plain-language guidance and an AI mentor that sits alongside the calculators instead of just spitting out numbers. three main pillars. Propellant– a guided APCP database (KNSB, KNDX, HTPB) with an interactive Kn ratio calculator and plain-language, Nozzle engine — a full de Laval nozzle calculator: throat/exit area, expansion ratio, thrust coefficient (Cf), characteristic velocity (c*), specific impulse (Isp), with a live visual diagram explanations of every parameter, 3D design + simulation — grain geometry modeling (BATES, star, finocyl), animated burn regression, a 1D flight simulator, and export to .ENG/STL for OpenRocket or 3D printing. Ignitionbench is aimed for the hobbyist rocketry group. Github Link
IgnitionBench — Devlog 001 Alright everyone — this is devlog 001 of IgnitionBench, an AI-assisted rocket motor design tool that lets anyone, at any skill level, design their first rocket motor.What’s new this cycle:Delta, the AI assistant. Delta walks you step by step through designing your first motor as safely as possible. It needs an Anthropic API key to run — everything else in IgnitionBench works fully offline.The Propellant Engine. A whole section for developing your own propellant. It opens like the projects home — a gallery of saved propellant cards you click into — with four steps: Plan (ingredients), Prepare, Cast, and Characterization. Delta will not walk you through actually mixing propellant — you should always have an expert present and never trust an app for that. Instead there’s a safety checklist and a notepad to mark off your steps.Characterization. Log your own test-firings and it fits the an and n burn-rate values for your batch, then loads them into Plan.AutoCast (Cast step). Tell Delta how you want the rocket to fly and it proposes the best grain geometry to cast — you approve before it’s applied. (Grain shape only; Delta never formulates the propellant.)Ambient pressure + presets. Set where the motor fires — sea level, mile-high, high altitude, or space/vacuum — and watch the same motor’s thrust and Isp change.Resources button on the home screen as a citation source, and a new light mode theme.Maybe coming next: sound effects, and a plugin system so people can build their own plugins for IgnitionBench. AGAIN Delta can not give you instructions on how to prepare your propellant as per safety instructions, IgnitionBench is an app and you should have a professional present when making rocket propellant and should have the required licenses for making it
hello everyone! this will be the last devlog before shipment. some new features include a tutorial for the motor design and the propellant engine. I have also added a file which clearly states what the software can do and what it cannot. I don’t want peoples rockets exploding and then blaming it on the software. this about wraps it up as I am about to ship this so wish me luck. if you want to use the software here is the link to the GitHub. just clone the repo and install. kudos to claude code, it helped a ton. I also made a replica of the game rocket league which is here . anyway hope everyone has a good day, goodbye.
Ships:
I made a rocket motor development program called IgnitionBench. This software helps you design build and test your very own solid rocket motor! This software also comes with its own AI assistant, Delta. Delta is there to answer all your questions on rocket motors and propellant. key features include the propellant engine where you can formulate your own propellant, Autocast where delta propose grain geometry and a tutorial to learn how to use the software. this software is hours of work so I am glad to present to you, IgnitionBench....
|
1793141701.2385325
|
1793228101.2385325
|
|
21365
|
Disdrometer by @dylanyfraser | Stardance
|
dylanyfraser
|
1
|
2.97
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T02:29:41Z", "hours": 2.0, "multiplier": 4.95, "payout": 0, "blessing": "neutral", "text": "A macOS menu-bar app that overlays realistic rain animations on your desktop. It provides a subtle, customizable weather effect that can be used for ambience, presentations, or just for fun.", "repo": "https://github.com/SimplyPickles/disdrometer/", "demo": "https://github.com/SimplyPickles/disdrometer/releases"}]...
|
[{"post_id": 11742, "ts": "202 [{"post_id": 11742, "ts": "2026-06-19T03:51:46Z", "hours": 0.9703, "text": "new settings menu, drop style, and background dimming"}, {"post_id": 11045, "ts": "2026-06-18T02:28:07Z", "hours": 2.2122, "text": "Settings page in menubar & main app functionality finished"}]...
|
Title: Disdrometer by @dylanyfraser | Stardance
D Title: Disdrometer by @dylanyfraser | Stardance
Devlogs:
Settings page in menubar & main app functionality finished
new settings menu, drop style, and background dimming
Ships:
A macOS menu-bar app that overlays realistic rain animations on your desktop. It provides a subtle, customizable weather effect that can be used for ambience, presentations, or just for fun....
|
1793278070.4848342
|
1793364470.4848342
|
|
21371
|
Lawrencium OS by @Lawrence | Stardance
|
Lawrence
|
1
|
2.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-11T02:22:51Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made Lawrencium OS, and Arch Linux themed operating system. The main reason I made this was to get better at CSS (which was obviously the most challenging part). It currently just has a Notepad app but in the future I plan to add a terminal, file explorer, and code editor.", "repo": "https://github.com/btfcookies/lawrencium-os/", "demo": "https://lawrencium-os.netlify.app/"}]...
|
[{"post_id": 11717, "ts": "202 [{"post_id": 11717, "ts": "2026-06-19T02:31:39Z", "hours": 0.3817, "text": "Notepad App Adds: Notepad app with text input Notepad icon on app dock Deployed to Netlify site Github Site"}, {"post_id": 11506, "ts": "2026-06-18T20:00:19Z", "hours": 0.4342, "text": "App dock Adds: App icon for Notepad app App dock (modeled after MacOS app dock) Coming soon: Notepad app"}, {"post_id": 11468, "ts": "2026-06-18T19:02:17Z", "hours": 0.6764, "text": "Toggleable Windows Adds: Custom made icon to close windows (similar design to MacOS traffic lights) Header on each window that has window toggle buttons Fixes & Changes: Fixes multiple ID mismatches Windows are now only draggable from the header"}, {"post_id": 11075, "ts": "2026-06-18T03:34:14Z", "hours": 0.8461, "text": "Basic stuff Adds: draggable windows header for time display Github"}]...
|
Title: Lawrencium OS by @Lawrence | Stardance
Dev Title: Lawrencium OS by @Lawrence | Stardance
Devlogs:
Basic stuff Adds: draggable windows header for time display Github
Toggleable Windows Adds: Custom made icon to close windows (similar design to MacOS traffic lights) Header on each window that has window toggle buttons Fixes & Changes: Fixes multiple ID mismatches Windows are now only draggable from the header
App dock Adds: App icon for Notepad app App dock (modeled after MacOS app dock) Coming soon: Notepad app
Notepad App Adds: Notepad app with text input Notepad icon on app dock Deployed to Netlify site Github Site
Ships:
I made Lawrencium OS, and Arch Linux themed operating system. The main reason I made this was to get better at CSS (which was obviously the most challenging part). It currently just has a Notepad app but in the future I plan to add a terminal, file explorer, and code editor....
|
1793134426.3446937
|
1793220826.3446937
|
|
21381
|
super tuff devboard by @Sreekar | Stardance
|
Sreekar
|
1
|
0.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-28T02:35:09Z", "hours": 0.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made an rp2040 devboard with four times the memory of a pi pico, more gpio pins, usb-c connection, onboard user buttons and LEDs that can be controlled from code, proper component labels, AND super cute domo themed decoration covering as much of the board as i could physically fit. I had SO much fun making this project, i learned a lot about how to route stuff in kicad and I got to post out at outpost which was like the best thing ever", "repo": "https://github.com/Sreekar617/domo-2040/", "demo": ""}]...
|
[{"post_id": 18942, "ts": "202 [{"post_id": 18942, "ts": "2026-06-30T03:49:18Z", "hours": 14.6292, "text": "PCB – Routing (~3 hours) This was definitely the hardest part. I just sat in front of the Kicad and tried different variations on routing until I found one that was satisfactory. I had to move some of the capacitors out of the way to make space, and I ended up putting some of them underneath the chip, on the back side. The bulky 16MB chip really overcomplicated this, but at this point I was reluctant to change it out so I tried my best to work around it. Once I had all the resistors and stuff down, I had to route the 40ish header pins, which were less strict about speed and impedance and stuff so I could use vias for those. PCB – Debug (~4 hours) This was a lot of running DRC, fixing the error that came up, then running DRC and fixing the two more that pop up in its place. One thing I encoutered a lot is incomplete thermal relief where there was only one spoke instead of two spokes: I fixed this by just extending a small trace outwards from the pad, which is a solution i read somewhere on Slack and seemed to appease DRC. Also, there were sections of the ground pour that were kinda just floating and not actually connected to ground, so I added some more vias to fix that. I also cleaned up some of the suboptimal routing, and fixed some of the text being too small to print properly. Also there was some basic stuff like a couple traces/vias accidentally placed too close to each other but that was pretty simple to fix. Back to the schematic (~2 hours) I decided it was too cringe to not deviate from the original Pico design, so I decided to make use of every pin on the rp2040, and also use every single header pin on the 1x20 connectors. My original design had GP25 marked as N/C, and both the original Pico and the Orpheus Pico have two N/C pins on the headers (well technically theyre not NC on the pico but they’re basically useless to normal people). After some tweaks to the schematic, I added a user LED so it can look cool and light up, and I added another button for user input, using all the GPIO pins on the RP2040. Then, I shuffled around the header pins a bit and added one GP pin so all the slots are used, but I did my best to make it still compatible with normal Pico uses so it won’t explode or something. low cortisol decorating oops there’s a catastrophic error (~2 hours) it turns out all of the 3v3 traces need to be connected to each other and not just to their own capacitor so i had to reposition a bunch of the capacitors to make it possible to connect them together. This was pretty hard because at this stage of the design, a lot of stuff was already placed down, and i kinda had to place capacitors around the stuff. Here’s a picture of the error (notice the thin cyan lines showing it’s unconnected): and here’s my solution 😭:"}, {"post_id": 11060, "ts": "2026-06-18T02:58:33Z", "hours": 9.04, "text": "Using Kai Pereira’s devboard tutorial, I was able to get a schematic together relatively quickly. The decoupling capacitors were kinda confusing at first, but then I checked the datasheet and it made sense that since there were 8 3v3 outputs you’d use 8 capacitors for 3v3 https://cdn.hackclub.com/019ed780-8f91-724d-be31-46112cdec84a/image.png USB Starting at the top left, USB is the USB-C connection because wireless power isn’t good enough yet and micro usb is trash. The CC lines are pulled to GND via 5.1k resistors as specified by the datasheet. Data is transmitted via D- and D+, and there’s two identical outputs for each line. I just have them connected to a single line and connected to the MCU via 27 ohm resistors. The power given by the USB C receptacle is 5V, so i use an LDO to step it down to 3V3 which is much tastier and can efffectively juice up not just the components on the pcb but also any external components i may want to connect to the devboard. both the 5V and 3.3V lines have bulk caps to smooth out large voltage ripples caused by the LDO not being a massless frictionless ideal gas. DECOUPLING This is pretty simple, there’s eight small 3V3 capacitors and two 1V1 capacitors to filter out high frequency noise, one per output on the chip, and then a larger decoupling capacitor for each of the lines. CRYSTAL This is a super tuff crystal that oscillates at a known frequency to help the MCU time stuff. It needs two 33pF (tiny!) external load capacitors to work for some super cool math reasons i don’t really understand. It’s connected to the MCU through a 1k damping resistor that protects it. FLASH I deviated from the tutorial a bit here and used a 16MB flash chip instead of the 2MB that the tutorial used, so hopefully that’ll be fine. It communicates with the MCU using quad SPI for fast data transfer. Side note, the widely used terms to talk about SPI are master and slave, but the other (and imo better) way to say it is controller and peripheral. However, it’s labeled both ways on my schematic so bear with me a little. When the Slave Select (or Chip Select) pin on the flash is pulled to ground, it acts as a reset signal, so that’s what the 1k, SW, and GND are for. The rest of the time, it has to be pulled to HIGH, so we have a 10k resistor connected to 3V3 to pull up the CS pin the rest of the time. There’s a 0.1uF decoupling capacitor next to the power, and there’s four data lines going back to the MCU (hence quad spi) RP2040/OUTPUT There’s nothing super crazy going on here, from my side I just connect all the peripherals back to this, and also make sure to connect the GPIO outputs and whatnot to the header pins. PCB – Edge.Cuts, Placement, and Caps (~3 hours) The first thing I did on the PCB was make the Edge.Cuts, since I want this to be able to match the footprint of a normal Pico I matched the dimensions. I then placed down all the big components, and placed the decoupling capacitors as close as I could to the things they were supposed to decouple. Following the advice of the guide, I tried to wire the high speed components first, without using any vias. Using the 16MB chip made it kinda hard since it’s just so bulky, but eventually I got it wired pretty good. The USB-C data lines needed to be differential pairs, and they needed to be exactly the same length, but I tried for a while and I could not figure out how to use the length tuning tool, so I ended up just adding a little kink by hand.i was confused about some simple things (like “will the usb c port fit underneath the board”) so i tried asking the big claude and the big gpt but they were completely useless so i had to actually lock in and solve my problems on my own."}]...
|
Title: super tuff devboard by @Sreekar | Stardance Title: super tuff devboard by @Sreekar | Stardance
Devlogs:
Using Kai Pereira’s devboard tutorial, I was able to get a schematic together relatively quickly. The decoupling capacitors were kinda confusing at first, but then I checked the datasheet and it made sense that since there were 8 3v3 outputs you’d use 8 capacitors for 3v3 https://cdn.hackclub.com/019ed780-8f91-724d-be31-46112cdec84a/image.png USB Starting at the top left, USB is the USB-C connection because wireless power isn’t good enough yet and micro usb is trash. The CC lines are pulled to GND via 5.1k resistors as specified by the datasheet. Data is transmitted via D- and D+, and there’s two identical outputs for each line. I just have them connected to a single line and connected to the MCU via 27 ohm resistors. The power given by the USB C receptacle is 5V, so i use an LDO to step it down to 3V3 which is much tastier and can efffectively juice up not just the components on the pcb but also any external components i may want to connect to the devboard. both the 5V and 3.3V lines have bulk caps to smooth out large voltage ripples caused by the LDO not being a massless frictionless ideal gas. DECOUPLING This is pretty simple, there’s eight small 3V3 capacitors and two 1V1 capacitors to filter out high frequency noise, one per output on the chip, and then a larger decoupling capacitor for each of the lines. CRYSTAL This is a super tuff crystal that oscillates at a known frequency to help the MCU time stuff. It needs two 33pF (tiny!) external load capacitors to work for some super cool math reasons i don’t really understand. It’s connected to the MCU through a 1k damping resistor that protects it. FLASH I deviated from the tutorial a bit here and used a 16MB flash chip instead of the 2MB that the tutorial used, so hopefully that’ll be fine. It communicates with the MCU using quad SPI for fast data transfer. Side note, the widely used terms to talk about SPI are master and slave, but the other (and imo better) way to say it is controller and peripheral. However, it’s labeled both ways on my schematic so bear with me a little. When the Slave Select (or Chip Select) pin on the flash is pulled to ground, it acts as a reset signal, so that’s what the 1k, SW, and GND are for. The rest of the time, it has to be pulled to HIGH, so we have a 10k resistor connected to 3V3 to pull up the CS pin the rest of the time. There’s a 0.1uF decoupling capacitor next to the power, and there’s four data lines going back to the MCU (hence quad spi) RP2040/OUTPUT There’s nothing super crazy going on here, from my side I just connect all the peripherals back to this, and also make sure to connect the GPIO outputs and whatnot to the header pins. PCB – Edge.Cuts, Placement, and Caps (~3 hours) The first thing I did on the PCB was make the Edge.Cuts, since I want this to be able to match the footprint of a normal Pico I matched the dimensions. I then placed down all the big components, and placed the decoupling capacitors as close as I could to the things they were supposed to decouple. Following the advice of the guide, I tried to wire the high speed components first, without using any vias. Using the 16MB chip made it kinda hard since it’s just so bulky, but eventually I got it wired pretty good. The USB-C data lines needed to be differential pairs, and they needed to be exactly the same length, but I tried for a while and I could not figure out how to use the length tuning tool, so I ended up just adding a little kink by hand.i was confused about some simple things (like “will the usb c port fit underneath the board”) so i tried asking the big claude and the big gpt but they were completely useless so i had to actually lock in and solve my problems on my own.
PCB – Routing (~3 hours) This was definitely the hardest part. I just sat in front of the Kicad and tried different variations on routing until I found one that was satisfactory. I had to move some of the capacitors out of the way to make space, and I ended up putting some of them underneath the chip, on the back side. The bulky 16MB chip really overcomplicated this, but at this point I was reluctant to change it out so I tried my best to work around it. Once I had all the resistors and stuff down, I had to route the 40ish header pins, which were less strict about speed and impedance and stuff so I could use vias for those. PCB – Debug (~4 hours) This was a lot of running DRC, fixing the error that came up, then running DRC and fixing the two more that pop up in its place. One thing I encoutered a lot is incomplete thermal relief where there was only one spoke instead of two spokes: I fixed this by just extending a small trace outwards from the pad, which is a solution i read somewhere on Slack and seemed to appease DRC. Also, there were sections of the ground pour that were kinda just floating and not actually connected to ground, so I added some more vias to fix that. I also cleaned up some of the suboptimal routing, and fixed some of the text being too small to print properly. Also there was some basic stuff like a couple traces/vias accidentally placed too close to each other but that was pretty simple to fix. Back to the schematic (~2 hours) I decided it was too cringe to not deviate from the original Pico design, so I decided to make use of every pin on the rp2040, and also use every single header pin on the 1x20 connectors. My original design had GP25 marked as N/C, and both the original Pico and the Orpheus Pico have two N/C pins on the headers (well technically theyre not NC on the pico but they’re basically useless to normal people). After some tweaks to the schematic, I added a user LED so it can look cool and light up, and I added another button for user input, using all the GPIO pins on the RP2040. Then, I shuffled around the header pins a bit and added one GP pin so all the slots are used, but I did my best to make it still compatible with normal Pico uses so it won’t explode or something. low cortisol decorating oops there’s a catastrophic error (~2 hours) it turns out all of the 3v3 traces need to be connected to each other and not just to their own capacitor so i had to reposition a bunch of the capacitors to make it possible to connect them together. This was pretty hard because at this stage of the design, a lot of stuff was already placed down, and i kinda had to place capacitors around the stuff. Here’s a picture of the error (notice the thin cyan lines showing it’s unconnected): and here’s my solution 😭:
Ships:
I made an rp2040 devboard with four times the memory of a pi pico, more gpio pins, usb-c connection, onboard user buttons and LEDs that can be controlled from code, proper component labels, AND super cute domo themed decoration covering as much of the board as i could physically fit. I had SO much fun making this project, i learned a lot about how to route stuff in kicad and I got to post out at outpost which was like the best thing ever...
|
1793155695.8804164
|
1793242095.8804164
|
|
21382
|
Hadronize by @ethmarks | Stardance
|
ethmarks
|
1
|
118.0
|
2150
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-26T05:16:19Z", "hours": 118.0, "multiplier": 19.09, "payout": 2150, "blessing": "neutral", "text": "Hadronize: a quark-themed set collection game. It has a web UI with a custom SvelteKit virtual layout engine, a polyglot CLI that runs across Node, Deno, Bun, and the browser console, a QuickJS bot sandbox, a comprehensive test suite, and more. I’m really proud of Hadronize and hope that you enjoy it.", "repo": "https://github.com/ethmarks/hadronize", "demo": "https://ethmarks.github.io/hadronize/"}]...
|
[{"post_id": 35009, "ts": "202 [{"post_id": 35009, "ts": "2026-07-26T05:04:06Z", "hours": 0.4372, "text": "Shipping I did a few miscellaneous things like make the remote script endpoint production-ready, fix some typos across the project, and create a favicon in Inkscape. After I write this devlog, I’m going to press the big “Ship your project!” button. If you’re a reviewer reading this: I hope you enjoy Hadronize. It’s one of my biggest projects ever, and I’m really proud of how it’s turned out."}, {"post_id": 32762, "ts": "2026-07-22T03:54:56Z", "hours": 5.1389, "text": "Revised Readme (again) Still working on the README. I think that Hadronize is more or less ready to ship now, but there’s probably still a bit more polishing I can do. In my other Stardance projects, I’ve gotten really positive feedback on my READMEs, so apparently my writing style and README format of choice is a winning combination. I’ve been referencing my past READMEs and the Stardance README guide a lot while writing this one. The bulk of what I added was the How it Works section, which explains some of the technical details and design choices that I made. It’s a dense topic so it’s obviously a long section. At first it was just a wall of text, even when I tried to break it up with lists and subheadings. So I spent about half an hour taking screenshots and editing them in GIMP until I had decorative images that I was satisfied with for each subsection. I think that drop shadows on transparent backgrounds look really cool in README images, so I used GIMP’s drop shadow filter to add them to my screenshots (in addition to cropping, rounding corners, et cetera). I kept fiddling with the drop shadow settings and I didn’t want to go back and redo the images that I’d already done, so the shadows are kind of inconsistent, which really irks me but I don’t think is very noticeable. I also added a Running Locally section and fixed a few typos throughout the README. Lastly, I did a bit of work on the home page. I added a big screenshot below the intro paragraph, thanks to feedback from the awesome @Luksus , whose project you should totally check out ."}, {"post_id": 31601, "ts": "2026-07-20T04:06:53Z", "hours": 2.7375, "text": "Revised README I worked on updating and basically completely rewriting the README to something more polished. I still need to add more sections and revise what I have, but I think that it’s alright. I’m trying to strike a balance between not having enough content and being a wall of text. It’s also surprisingly difficult to come up with bullet points for the features list. After I finish up the README, I’m going to redesign the home page a bit. After that, I think I might be ready to ship."}, {"post_id": 31058, "ts": "2026-07-19T04:31:59Z", "hours": 6.4664, "text": "How to play page I wrote a page that explains how to play, assuming zero knowledge. I think that this’ll be helpful for onboarding, because this way they learn the rules at the same time as they learn how to use the UI, rather than reading the abstract and theoretical rules and then trial-and-erroring their way through the UI. The actual writing part took a few hours, and most of it was revision and trying to find better ways to phrase things. It’s nearly 1000 words, meaning I could turn it in for an essay assignment and not fail the word count, which is funny. But what also took a lot of time was making the visual aid. I had to record myself performing the same action in the UI many times to get a perfect take, and then I had to craft an ffmpeg command to crop and trim it because I refuse to use graphical video editors. Also my recording software kept stuffing H.264 video data in a webm container, which made ffmpeg freak out because that file is technically corrupted. I also had to figure out how to screen record on my phone to get a tap indicator, which I’d never done before. You can read the page here: https://ethmarks.github.io/hadronize/how"}, {"post_id": 30534, "ts": "2026-07-18T05:53:11Z", "hours": 3.6139, "text": "Discontinuing the ranking arena I’ve decided to stop working on the driver ranking arena. I already have an MVP that works well enough to kinda sorta determine which drivers are good and which are bad, but it’s not robust and it just sums up rankings rather than implementing an actual Elo algorithm . The reason I’m not going to continue working on it is that it seems like a lot of work, and I don’t think that it’ll provide any value. Like, at all. The root of the problem is that Hadronize just isn’t a strategic-enough game. There’s certainly some strategy, of course, and probabilistic modeling, but luck plays just as much of a factor. The cleverest Hadronize driver can still routinely lose to the dumbest one just due to slightly bad luck. So it doesn’t really make sense to build tooling for strategic bots if the strategy is not a very big aspect of the game. Thinking back, I’m not really sure why I decided to start working on the driver arena in the first place. It just seemed like the right thing to do at the time even though I now realize that it would be kind of useless. Anyways, I also created two new drivers. The first is called Kingslayer, and it just tries to steal from the player who’s currently winning. It’s not very good at actually winning, but it does make things more challenging for the other players. The second is called Gentleman (aka charm ). It’s obsessed with trying to collect charm quarks, because its a charming gentleman. I made it as a joke because I thought it was funny, but to my complete surprise it turns out to be a pretty good strategy? Not charm quarks in particular, but trying to collect a specific flavor of quark at all costs turns out to be surprisingly effective. It consistently wins more often than EVan, the driver that I specifically built to be a good strategy and that actually does probabilistic expected value calculations. I think that next I’ll start working on the README and documentation, because I haven’t updated the README in like 3 weeks and it’s extremely outdated."}, {"post_id": 29906, "ts": "2026-07-17T02:31:07Z", "hours": 1.8094, "text": "Benchmark Before I started working on the bot ranking arena, I did a quick sidequest to figure out how many games per second I could simulate. So I wrote this script to execute a bunch of games sequentially, then print the elapsed time and calculate the games per second rate. I ran the benchmark in Node 24.15.0 on my 4.40 GHz Intel i5-12450H using Bogo drivers: Simulated 82157 turns across 1000 games Took 109048ms (109.048s). Speed is 9.170273640965446 games per second So that was surprising. I was expecting a speed in the low thousands, but instead it was less than 10. I had a suspicion what was causing the slowdowns. To make sure, I swapped out the Bogo driver (which uses QuickJS) with a non-QuickJS driver that I made for testing, and reran the same benchmark: Simulated 53854 turns across 1000 games. Took 130ms (0.13s). Speed is 7692.307692307692 games per second (the turn count is smaller because the drivers used a different strategy which made games end faster) So, obviously, the slowdown is caused entirely by QuickJS. Which makes sense. Every time a QuickJS driver is invoked, it spins up a brand new QuickJS VM, configures it, executes the actual code, extracts the return value from the VM, disposes of the VM to avoid memory leaks, and then finally returns the value. Non-QuickJS drivers can just execute the code directly, and the code can be optimized very well by the JIT compiler that Node uses. So the solution seems simple, right? Just don’t use QuickJS for the drivers. Whatever the advantages of using QuickJS are, surely they aren’t worth an 839x decrease in performance. Well, unfortunately that’s not an option. More specifically, dynamically running strings of JS (like the driver code that users write at runtime) as native code is not possible, so I have to use a JS VM. And QuickJS is by far the best embeddable JS VM that I know of. So I just have to accept the slowness. This means that I’ll have to be clever about the bot arena, though. I can’t just brute-force a ranking with thousands of games if I can only run 10 games per second. btw, if you’d like to see how your PC does on my benchmark, just run these commands: git clone https://github.com/ethmarks/hadronize.git cd hadronize pnpm install pnpm bench --count 1000 --driver prng If your time is faster than mine, leave a comment to gloat."}, {"post_id": 29828, "ts": "2026-07-16T23:29:46Z", "hours": 6.7503, "text": "Bot editor I integrated the QuickJS driver code that I made last devlog into the rest of the site. Things I did: I made the QuickJS VM override the default Math.random function and replace it with a mulberry32 prng seeded by stringifying the game state and hashing it through djbs2 . So now drivers can still use Math.random without making the rng predictable or sacrificing perfect determinism. I gave the drivers names and descriptions. The prng driver is named “Bogo” (after Bogosort ) and the expected value driver is named “EVan” (because it’s a normal name that starts with the abbreviation of “ E xpected V alue”). I moved the code for the existing drivers into a centralized array, rather than in multiple different files that had to be imported individually. I’m calling this array the “stock drivers”. I added a bot editor page. You can check it out at https://ethmarks.github.io/hadronize/bots . I used contenteditable and Svelte’s bind:textContent to let users edit the title, ID, and description. I used Prism code editor as the embedded IDE for editing the actual driver code. I made the play page fetch the list of drivers from localstorage on page load, defaulting to the stock drivers. I also made the bot editor automatically sync the drivers to localstorage . I added a new driver strategy: tit for tat . As expected, it plays pretty terribly because that strategy just isn’t very good in Hadronize. I mostly made it so that users looking at the stock drivers can learn how to reference the timeline from the state. I think that next I’ll work on a driver ranking system so that when I make more drivers, I’ll know whether they’re better or worse than the others. I might research how chess ranking systems work and copy concepts from those."}, {"post_id": 29163, "ts": "2026-07-15T21:36:28Z", "hours": 1.3381, "text": "QuickJS drivers I can now store driver strategy code as strings, execute the strings as JS code using QuickJS , read the quickjs output, and use it as driver output. This might not sound like much of a difference, but it completely changes how I can run drivers. Before, all driver strategies had to be present in the actual source code. Now, they just have to be strings. Because we can manipulate strings at runtime, this means that we can create new drivers while the site is running without modifying the source code. In other words: this lays the groundwork for letting you create and play against your own drivers without making a PR to the repo. To make sure that my implementation works, I converted the expected value driver to use quickjs. I enclosed all of the actual logic in backticks, making it a giant string, and then passed the string through my quickjs driver factory function. I ran the expected value driver test suite, and it failed immediately because I forgot to remove the type annotations (quickjs can only execute plain JS, not TS). But once I fixed that, all 19 tests passed, and it seems to work perfectly from my playtests. I eventually plan on adding a page that uses Prism code editor to let users edit driver strategies and save them to localStorage. But first I’m going to add more features to the quickjs runtime. For example, I want to have it swap all Math.random() calls with a deterministic psuedorandom generator, so that way developers can use randomness without making it non-deterministic."}, {"post_id": 28712, "ts": "2026-07-15T04:13:36Z", "hours": 1.0886, "text": "New quark style I made new quark graphics, like I promised last devlog. I’m not really sure if it fits the aesthetic I’m going for, but it’s something , and I tried to make it extensible so that I can experiment with more styles later. I also added a dropdown menu in the setup flow so that you can select which style you want to use, though I might remove that in the future if I decide on one style to be the definitive one. The new style is just patterns masked onto the same flat color circles as before. Each flavor has a different pattern: up: vertical lines down: horizontal lines charm: checkerboard strange: square grid with irregular shading top: light dot grid bottom: dark rhombus grid hadron: solid (unchanged) I don’t know if this makes the quarks look nicer or not, but it definitely makes them more accessible. If the abbreviation text isn’t visible for whatever reason (e.g. because the chamber is in count layout mode), quark flavors used to be distinguished solely by color. But the new patterns make them distinguishable without color, which is important for colorblind accessibility."}, {"post_id": 28687, "ts": "2026-07-15T02:53:52Z", "hours": 2.3578, "text": "Minor graphics improvements This is a smaller devlog. Stuff I did since last devlog: Fixed the winning animation to work with the new layout planner Added transitions to the quark text. Whenever a quark changes its display text (e.g. from a ‘?’ to a flavor abbreviation like ‘s’), rather than instantly snapping to the new text, it’ll do a quick crossfade. Changing the font used for the quark text from the default to a font called Degheest that I think looks nice. Merging the layout refactor into prod because I’ve decided that it seems stable enough. Next, I’m going to work on improving the quark graphics. I’m trying to go for an aesthetic that looks like it’s from a physics textbook (hence the dot grid backdrop I’ve had for a while), so it’s already pretty close, but imo it looks a bit too plain right now. I don’t have a precise vision for exactly what I want the quarks to look like, so I’ll need to figure that out."}, {"post_id": 28484, "ts": "2026-07-14T19:10:09Z", "hours": 0.4922, "text": "Touchscreen support Idk why I was worried that this would be difficult. Less than 20 lines of code later, Hadronize now automatically detects whether you’re using a fine pointer (e.g. a mouse) or a coarse pointer (e.g. a touchscreen), and changes its behavior accordingly. So now you can select chambers on touchscreen just by tapping on them. You don’t have to drag the superposed quark, you just tap. I recorded a video showcasing this in action using Firefox’s mobile device simulator (aka RDM). As you can see, when I disable touch simulation, the chambers respond to hovering and I have to drag the quark around. But when I enable touch, the chambers don’t react at all until I click one, and then the superposed quark gets added to that chamber like normal. I’ve also tested this on an actual phone and it works perfectly, but it’s more difficult to record on there which is why I used Firefox’s simulator for the video."}, {"post_id": 28121, "ts": "2026-07-14T06:24:57Z", "hours": 8.2808, "text": "Layout optimization algorithm It took an entire day, but I did it. Hadronize will now automatically adjust 5 different layout variables in order of priority to make everything fit on screen. I think that the algorithm is probably the most complicated part of this entire project. I’m going to try to explain it really simply in this devlog, but if you want to see how it actually works, I wrote a bunch of comments that explain the priority pipeline in this file . So basically, every time a new layout update is triggered, the layout manager calculates a brand new layout plan from scratch. Once it’s finished calculating, it applies the layout plan onto the actual layout variables that are used to move the quarks on the screen. If I modified the layout variables directly, the rapid-fire modifications while calculating would trigger a bajillion reactive updates from Svelte which would slow the page down. Anyways, the way that the layout plan is calculated is that it starts by assuming ideal conditions: there is more than enough room for everything to fit comfortably. So it does the calculations using the preferred ideal variables, it modifies the plan, and then it actually checks to see if anything is overlapping. If there is any overlap, it tries to resolve it using the least-disruptive adjustment it can make. If that doesn’t work, it tries the next least-disruptive adjustment. And so on. Also, each time it moves up the chain of disruptiveness, it tries to use the ideal variables for all of the less-disruptive adjustments. If that makes sense. Here are the adjustments that it can make, in ascending order of disruptiveness: Increasing the radius of the ring of quarks of a single chamber Adjusting the radius of the ring of chambers around the center of the screen Switching chambers to use count mode, which is when it only displays the number of quarks of each flavor rather than displaying each quark individually. Switching the global layout from ring mode to grid mode. This is the thing that I built last devlog. Decreasing the size of all quarks I’m pleased to report that when I tested it on my phone, everything worked perfectly. I still haven’t implemented mobile input yet, but I started a 6-player game of all bots, and the layout planner managed to keep all of the quarks visible all of the time, even when a single chamber had more than 20 quarks. Never once did I see two chambers overlap with each other or go partially offscreen, which used to happen 100% of the time on small mobile screens. It just changed layout modes and decreased the quark size whenever it started to run out of room. Anyways, I’m not going to merge the new layout planner just yet because I’m not 100% sure how stable it is, but I’ll do that soon. Next up is mobile input."}, {"post_id": 27452, "ts": "2026-07-13T01:01:10Z", "hours": 1.7111, "text": "So the first step to mobile support is making the all of the quarks in all of the chambers actually fit on a phone screen. Right now they just overlap a bunch and you can’t tell which quarks belong to who. I have some ideas for an algorithm that can automatically adjust layout variables until everything fits, but first I need to give the algorithm things that it can adjust. The crux of the problem is that there’s simply no way to fit 6 chambers in a circular ring around the center of the screen on mobile. There’s just not enough screen space. So I made a new layout that places chambers in a grid instead of a ring. It works on desktop in addition to mobile. I don’t think it looks quite as nice, but it’s much more space efficient. I attached some side-by-side comparison screenshots. As you can see, the quarks still don’t quite fit on mobile even with the grid layout, but it’s much closer. Next step is either writing the automatic layout algorithm, or making input work on mobile."}, {"post_id": 27350, "ts": "2026-07-12T20:49:30Z", "hours": 3.1975, "text": "Sound effects! I added sound effects to the game UI. A unique sound plays for each of these: Starting a game Dragging a quark over a chamber Dropping a quark onto a chamber A quark hadronizing A quark tunneling Winning a game Closing a game I sourced them all from https://freesound.org/ , and I left attribution for each one in sounds.svelte.ts . I also modified a few in Audacity to trim them or apply simple effects. I’m not sure that I’m 100% satisfied with the sounds. I sourced almost all of the effects from different freesound sounds because I couldn’t find a sound pack that I liked, so the sounds don’t quite match tonally. Some of them are generic UI sounds while others are clearly scifi-ey. I may change some of the sounds later if I find more cohesive ones. I’d never done audio in HTML/JS before, so this was new for me. I originally just used the Audio() constructor because that was the most obvious way to play, but when I realized the many issues with it (though it did work!), I rewrote my code to use AudioContext . I also made a multi-step preloading and decoding pipeline that fetches all sound effects on page load, but doesn’t decode them until the user presses a button because otherwise JS throws a warning in the console and suspends the audio context. I think that the sound effects make Hadronize feel a lot more polished and nicer to play. Next up on my list is mobile support. I’m not looking forward to it. (Make sure to turn on sound for the video below)"}, {"post_id": 27016, "ts": "2026-07-12T04:52:57Z", "hours": 1.6675, "text": "Mouse handler refactor https://github.com/ethmarks/hadronize/commit/3a5adcb I started working on writing audio code and looking through sound effect libraries, but when I tried to hook my WIP sound-playing function into the mouse handler, I realized what an awful mess my mouse handler code was. So I spent over an hour refactoring it. While I was at it, I optimized it a tiny bit and fixed the hover thrashing bug that had been bugging me for nearly 2 weeks now."}, {"post_id": 26956, "ts": "2026-07-12T01:34:57Z", "hours": 2.6592, "text": "Style improvements and new pages So, funny story about the site styles. When I first made the CLI page 3 weeks ago (has it really been that long?! wow), I added holiday.css to make it look nice as a stopgap measure until I made the real styles. However, as the old saying goes, there’s nothing more permanent than a temporary solution. I’ve decided to just embrace using holiday.css for the entire site because it looks much nicer than anything I could make. The styles in the actual game component are entirely my own, of course, but the homepage, rule page, and rewritten CLI page all use holiday.css. “what rule page and rewritten CLI page?”, you ask? That’s the other thing that I did this devlog. I created a dedicated page on the site for the rules, and I rewrote the CLI page to only contain instructions on how to use the CLI rather than a playable browser CLI. Don’t worry, you can still play Hadronize via the browser console. The main UI has had that functionality since the beginning. I just didn’t see a reason to maintain two different game UIs, especially because the main UI can do everything that the playable CLI page could (and much more). I think that next I’ll start polishing the game UI. It’s long overdue. I’ll add sound effects, add mobile support, and maybe (don’t hold me to this) improve the graphics."}, {"post_id": 26635, "ts": "2026-07-11T15:55:24Z", "hours": 8.3731, "text": "UI Setup Flow diff from last devlog to this one I added a setup flow to the main UI page, and did a lot of refactoring. I also removed support for setting up the game via browser console. I didn’t make this choice lightly because it was a fun feature, but the tradeoffs were just too much and I decided that it wasn’t worth it, especially because the console setup is much clunkier than just using the HTML form, so I doubt anyone would even use it. But anyways, the main focus of this devlog is the setup flow on the main UI page (aka the play page). I also added some pretty sleek animations when activating and deactivating the game overlay."}, {"post_id": 20570, "ts": "2026-07-02T05:53:52Z", "hours": 3.7103, "text": "UI Refactor diff from last devlog to this one I refactored the Hadronize UI code. Rather than one giant 570-line file that handled the quark positioning, state tracking, mouse movement, and game loop, I split the code into four different files, each dedicated to one specific thing, with an average line count of ~154 (191, 184, 111, and 132, respectively). This makes the codebase way more maintainable and easy to work in. I also deduplicated most of the main game loop code. Before, I had just copied the entire content of the executeTurn() function, pasted it into the UI code, and customized it until the logic code correctly interfaced with the UI. Maintaining two separate functions that do basically the same thing is bad practice, so today I came up with an alternative solution: adding a bunch of “hooks” as optional parameters, which are just functions that the executeTurn() function runs at specific stages. In a CLI game, the hooks are never provided to the function, so they’re never run and nothing changes. But the UI code does provide hooks, to do things like trigger re-renders. This way, the same code can be reused for two different use cases (CLI and UI). Next Steps There’s still more refactoring to do, but I don’t think that I’ll do any more major restructuring."}, {"post_id": 19746, "ts": "2026-07-01T04:11:24Z", "hours": 14.7989, "text": "Huge UI Progress diff from last devlog to this one I’ve been working a lot on the Hadronize UI. Last devlog, all that it could do was render all of the quarks into a big overlapping heap and you could drag around one specific quark. Now, you can play a full game in the UI from start to finish, and it’s reasonably polished. How to play the UI prototype Visit https://ethmarks.github.io/hadronize/play . Make sure that you’ve read the game rules in the README . I haven’t implemented a setup flow in the main UI yet, so right now it’s pre-configured with two human players named Arthur and Ford, one bot player named Marvin, and seed 42. On each human player’s turn (their name will be highlighted in yellow), click and drag the superposed quark to the chamber of the player who you want to observe it. The superposed quark will collapse, get added to the chamber you selected, possibly react with existing quarks, and then play will proceed to the next player. Continue this until someone wins. It will probably be Marvin. Refresh the page to play again. Playtest I also conducted the first playtest with a few friends. Nothing broke during the playtest and they all liked it and gave positive feedback, which was really encouraging. We all got absolutely crushed by the expected value driver I built last devlog. Next Steps It sounds hyperbolic to say that this UI is the messiest code I’ve ever written, but I legitimately can’t think of any other contenders. Of the 800+ lines of code in the UI, about 570 of them are in one massive Game.svelte component. This component handles state tracking, mouse movement, the main game loop, and most of the geometry to position the quarks. The very next thing that I need to do is massively refactor the UI code. After that, I have a few ideas: A setup flow that lets the user choose the seed to use and configure the players. Sound effects, UI indicators (e.g. “you formed a baryon!”), and other game juice. Proper mobile support. Right now it kind of works on mobile, but the layout gets really cramped. I’ve been working a lot on the Hadronize UI. Last devlog, all that it could do was render all of the quarks into a big overlapping heap and you could drag around one specific quark. Now, you can play a full game in the UI from start to finish, and it’s reasonably polished."}, {"post_id": 17689, "ts": "2026-06-28T16:19:54Z", "hours": 3.3139, "text": "Drivers Each player in Hadronize is controlled by a Driver, which is basically just a function that takes the current game state as an input and outputs a player. I implemented drivers on like day #2, but I don’t think I’ve talked about them in a devlog yet. The first driver I made is the dogpile driver. It’s logic is extremely simple: it just selects the player who goes first. It doesn’t even reference the game state at all. If every player is a dogpile driver, this means that everyone just dogpiles onto the first player and ends up stealing basically all of its quarks before it can use them. This is obviously a terrible strategy because it’s not even capable of trying to score, but it was very simple to implement and I use it as a placeholder. The second driver I made is the rng driver. It just makes random decisions. However, because I insist on everything being deterministic, it can’t just use Math.random . Instead, it stringifies the game state, converts that string into a 32-bit integer via a djb2 hash, then uses that integer to seed a mulberry32 pseudorandom number generator, then uses the output of the mulberry to make its player selection. The newest driver that I just finished developing is the expected value driver. It does actual strategic calculations to determine what the expected value of choosing each player would be based on the information it has available, then selects the player that maximizes that value. Next Steps I’ve started building the UI, but I’ve still been procrastinating on actually working on it in earnest. I should probably do that."}, {"post_id": 15374, "ts": "2026-06-25T00:16:45Z", "hours": 5.18, "text": "Tests and CLI Args You can now add arguments to the Hadronize CLI in the terminal, which lets you avoid having to use the setup flow. Here’s an example. pnpm run cli --seed 12345 --player Alice:human --player Bob:bot It also works if you run the CLI as a remote script. deno run -A http://ethmarks.github.io/hadronize/cli.ts -s 8 -p a:bot -p b:bot -p c:bot This was pretty easy to implement. I just used Node’s parseArgs utility for the main arg parsing and wrote a bunch of validation logic that converts the raw arguments (which are always strings) into the data types that my code uses. Tests Over the past couple days, I’ve made a little test suite for the game logic using Vitest. I’ve written 19 individual tests, but some of them repeat multiple times with different game seeds and whatnot to ensure that it works with a variety of inputs, so Vitest actually runs 101 tests in total. All of the tests pass, and I didn’t discover any bugs, which either means that I managed to get all the game logic correct on the first try, or that there’s something wrong with my tests. Next Steps I think that I’ve probably spent too much time on the CLI. I don’t think that it was time wasted, but I probably ought to get started on the main game UI."}, {"post_id": 14724, "ts": "2026-06-23T22:42:34Z", "hours": 6.3972, "text": "CLI Remote Script You can now run Hadronize CLI in a terminal without cloning the repo. If you run the command below, Deno will automatically fetch all the dependencies. deno run -A http://ethmarks.github.io/hadronize/cli.ts Node doesn’t support remote scripts because it lacks Deno’s awesomeness, but because of the Deno binary on npm , you can run Deno (and therefore Hadronize) through any of the other package managers! npx deno run -A http://ethmarks.github.io/hadronize/cli.ts pnpm dlx deno run -A http://ethmarks.github.io/hadronize/cli.ts bunx deno run -A http://ethmarks.github.io/hadronize/cli.ts For example, in the attached screenshot, I SSH-ed into one of my home servers that hadn’t cloned the Hadronize repo nor installed Deno, and tried to run Hadronize as a remote script via pnpm . After resolving dependencies for a few seconds, it ran flawlessly. How it works I first encountered Deno remote scripts in Lume’s init command , and my implementation is heavily inspired by it. Basically, all that the cli.ts file does is fetch the CLI code from JSDelivr, which fetches it directly from the GitHub repo. From there, Deno is smart enough to resolve all of the CLI code’s dependencies and run it. Compatibility Before today’s changes, running Hadronize via Deno worked perfectly fine. deno task cli behaved identically to pnpm run cli . However, that’s because Deno has an automatic Node compatibility layer , not because Deno can actually run the code natively. That compatibility layer doesn’t really work with remote scripts (because Deno can’t find the package.json ), so when I first tried to run the remote script while developing it, it crashed and burned immediately. This was because, without the compatibility layer, Deno and Node handle things fundamentally differently. There were several differences, some of which I expected and some of which I didn’t, but the easiest one to understand is NPM imports. NPM imports My CLI code relies on the picocolors library for getting ANSI escape codes. When I was first writing the code, I added the picocolors package via NPM and imported it in the normal Node way: import pc from \" picocolors \" ; The problem is that Deno can’t parse bare imports like that. Deno expects this format, which Node cannot parse: import pc from \" npm:picocolors \" ; I tried configuring an import map in deno.json , but it didn’t work. I considered just hardcoding the ANSI escape sequences, but I decided that I would need to figure out how to polyglottally import NPM packages in both Node and Deno at some point, so I might as well figure it out now. My solution was to create a deps/picocolors.ts file to proxy the picocolors import by dynamically importing it based on whether it’s being run in Deno or not: const { default : pc } = \" Deno \" in globalThis ? await import ( \" npm:picocolors \" ) : await import ( \" picocolors \" ); export default pc ; NPM imports were only one of the issues that sprung up. Frustratingly, the only way to test whether or not a solution worked was to commit, push to main, and test on production. The whole Deno compatibility saga required 12 commits in total. Next Steps I’m still working on writing unit tests for the game logic. I already have a few tests, but they’re definitely not comprehensive. I’ll write a devlog about the tests once I’m finished with them."}, {"post_id": 13920, "ts": "2026-06-22T20:31:39Z", "hours": 5.8247, "text": "Setup Flow diff from last devlog to this one Since my last devlog, I added a flow that lets users set up each game before starting it. The setup includes specifying the seed, player count, the names of each player, and whether each player should be a human or a bot. I made it work in three different formats, each of which had to be implemented individually: The terminal : at its core, this format is just a normal TUI. It prints input prompts, awaits the user’s input using the abstracted NbrInputFunc I mentioned last time, and repeats this until the user provides an input that passes the validation function. Pretty standard stuff. The browser console : I used the same trick that I described last time to allow users to enter their input via the browser console. It creates a custom window property that resumes execution, then halts execution with a Promise<void> until the window property is called. Unfortunately, it wasn’t possible to use the anonymous getter trick that I used last time. If I did that, I would have to create custom window properties for every possible 32-bit number to allow user to enter the seed, and create custom properties for every possible string to allow users to enter player names. That obviously wasn’t possible, so instead I just created a window.r function that takes any input type. The “r” stands for “respond”. To set the seed to 42, you type r(42) into the console, which is a reasonably clean UX, I think, though not as clean as just typing 42 like you can in the terminal. The webpage : this uses HTML <input> s and SvelteKit’s reactivity. The trickiest part was navigating the fact that the value of one of the inputs (player count) controls the structure of some of the other inputs (player configs). At first I tried writing code to dynamically construct a variable-length Array, but that was a nightmare of complexity. Then I tried making all 6 possible player configs visible all the time and just adding the “Disabled” type, but that made the UI look ugly and was also kind of complicated to implement. The solution I settled on was to internally use an Array with a fixed length, automatically hide the player config UI elements with an index less than the player count value, and slice the player config Array before passing it into the main game function. I think that this solution is the best of both worlds while also being fairly simple to implement. Next Steps I know that I’ve been saying this for the past 4 days, but I need to write some internal docs for my game logic code and write tests. I haven’t noticed any bugs during my playtests while building the CLI, but I’d like the peace of mind to be fairly confident that I’ve implemented my game rules correctly."}, {"post_id": 12947, "ts": "2026-06-21T05:52:51Z", "hours": 10.3317, "text": "Browser CLI Since my last devlog, I implemented a CLI for Hadronize that works across Node, Deno, Bun, and browsers. You can try it out by visiting https://ethmarks.github.io/hadronize/cli or running the following commands (you only have to run one of the Node/Deno/Bun commands): # Clone the repo git clone https://github.com/ethmarks/hadronize.git cd hadronize # Run with Node (via npm or pnpm) npm install npm run cli # Run with Deno deno task cli # Run with Bun bun install bun run cli Link to the diff between last devlog and this one Abstraction In case you’re not familiar with the JS ecosystem, a cross-runtime CLI like this is not normal. My CLI uses styled text, but the different runtimes have different ways of logging styled text. Node, Deno, and Bun all use ANSI escape characters, but browsers use %c placeholders (Deno also supports %c because Deno is awesome, but none of the others do). Node uses the readline API to get user input, but Deno and Bun both use prompt() , and browsers don’t even have a way to get user input without clever tricks (as you’ll see later). My solution to the styled text problem was to create a custom micro-library which I call styledLog.ts (or sl for short) which invents an easy-to-use syntax for rich-text logging called slChunk , then automatically detects if it’s running in a browser and renders slChunks with either ANSI escapes or %c placeholders accordingly. Cross-runtime user input My solution to the user input problem was a little less elegant, but in my opinion it’s much cleverer. Node, Deno, and Bun were the low-hanging fruit. All I had to do was create an abstracted NbrInputFunc() function that automatically detects which runtime is running the code, then switches out the method it internally uses to fetch input accordingly. Easy. But implementing a CLI in the browser was a lot more tricky. I could have just used the window.prompt() method , but that opens a disruptive pop-up window that looks terrible. Instead, my code dynamically adds custom properties to the window object, then halts the script execution via a Promise<void> . Each custom property is named after a player name and has an anonymous getter function. When you type a player’s name (e.g. alice ) in the console, it automatically evaluates window.alice , which triggers the getter. The getter sets the userInput variable then resolves the frozen Promise to resume execution. I hope that made sense. It’s a really hacky solution, but it does work, and it provides an elegant input syntax that resembles that of terminal CLIs. My first idea (which is still used as the fallback) was to just define a window.turn() function, so you would enter your input with turn(\"alice\") . The current solution is much more elegant, in my opinion, because the user doesn’t need to type parenthesis or quotes. Here’s a link to the code if you want to check it out for yourself. Beginnings of the UI I also started working on the UI the tiniest bit. Not anything that’ll make it into the final version, mind you, but I added a page that demos the Hadronize CLI. It seemed wrong to make the demo page blank and not include instructions, so I wrote some. It seemed wrong to use unstyled bare HTML, so I added holidaycss . Next Steps I think that there’s still some work I need to do in the game logic and CLI before I start working on the UI. The CLI demo currently doesn’t have any way to customize the game settings (e.g. how many players there are and what deterministic seed to use), so I’ll probably work on that next. Thanks for reading!"}, {"post_id": 11813, "ts": "2026-06-19T07:15:15Z", "hours": 6.4697, "text": "Core Game Logic Today I implemented most of the core game logic in TypeScript. My code is pretty messy, probably has some bugs, and definitely has some idiosyncrasies that I should add docs for, but it does work correctly. Mostly. Here are a few highlights from today: Determinism The rules specify that quarks are created on-the-fly at the start of each turn, and that it’s impossible to predict what flavor a superposition will collapse into. Nondeterministic code makes me uncomfortable, so I decided to cheat a bit behind the scenes to make the whole thing pseudorandom and fully deterministic. In the game constructor, every quark that will ever be used during the game is pre-generated based on values from a mulberry32 function, then the collapsed flavor is predetermined ahead of time. Those two things: the list of future quarks that will be “created” on subsequent turns, and the flavor that each superposition will collapse into, are secret information that the players aren’t allowed to know, which means I have to be careful to sanitize the game state before it’s given to players. I hate references So, one of the first things that I did was create the Quark class. It has a few methods, but mainly it’s just a DTO for a flavor and a superposition. So my original plan was involved doing normal OOP and having each quark be owned by a Player class or the Game class itself. But once I actually started coding it, I remembered that I hate having to remember what’s stored as a value and what’s stored as a reference in JS. This is especially annoying when moving quarks between containers. So instead, I decided to just store an array of every extant quark, including not only a flavor and superposition but also an index. When a player class “owns” a quark, it really just owns that quark’s index number which corresponds to a quark in the game class’s SSoT. Crucially, the index number is a simple integer that doesn’t have any of JS’s object reference silliness. Timeline I decided that the game class should save every past state that it’s been in for some reason. I might use it in the UI to let users scroll back in time to see how the game played out, or maybe use it to make neat statistics at the end of the game, or something like that. It might also be useful for bots (more on that in a future devlog). But anyways, actually implementing the timeline was extremely frustrating, mainly due to Typescript. The final implementation that I settled on is pretty clean, but it was not my first thought, and I went through maybe a dozen different iterations over the course of an hour. Next Steps I’m probably going to spent a bit more time in the game logic before starting work on the UI. As I mentioned, I need to write docs for the idiosyncrasies of my code because otherwise I’ll forget how it works and that’s how bugs happen. Speaking of bugs, I’m sure that there are a few in my code, so I’ll probably write some tests to try to find them. Thanks for reading!"}, {"post_id": 11089, "ts": "2026-06-18T04:06:18Z", "hours": 3.65, "text": "Hadronize This is my first devlog for this project. It’s a multiplayer strategy game that you can play in your browser. https://github.com/ethmarks/hadronize Basically the only things that I’ve done so far are write the rules in the README and brainstorm a bunch. The rules are pretty important, so I’ll write them in this devlog. Because there’s a 4000-character limit to Stardance devlogs, I’m going to try to keep the rules shorter and less thorough than I did in the README. Rules Hadronize is a 2-6 player game which will probably take about ~10 minutes per game. The goal is to be the first player to hadronize 10 or more quarks. Quarks are basically the cards. There are 6 different flavors of quark: up, down, strange, charm, bottom, and top. By the way, I’m not making that part up . Quarks start out as Superposed Quarks, which are quarks in a state of superposition between three different flavors. Once the superposition collapses (more on that later), it chooses one of the three flavors in its superposition and becomes a normal quark with a single flavor. Each player starts with four collapsed quarks with randomly-chosen flavors in their respective cloud chamber . On each turn, a new superposed quark appears. The players know that the quark will be one of the three flavors in its superposition, but they don’t know which one. The player whose turn it is (aka the active player) will choose any player (including themselves) to be the observing player. The observing player observes the superposed quark, which collapses it and adds it to their cloud chamber. If the observing player has none of that flavor (e.g. the new quark collapsed into charm and the player only has down quarks), then nothing else happens and the turn ends. But if the observing player does have at least one quark of the same flavor, something does happen. If the active player chose themselves to be the observing player, the new quark reacts with all existing quarks of the same flavor, and they all hadronize together. If the active player chose a different player to be the observing player, the new quark reacts with all existing quarks of the same flavor, and they all quantum tunnel from the observing player’s chamber into the active player’s chamber. In other words, the active player steals some of the observing player’s quarks. If my explanation is unclear, check out the README because I probably explained it better there. If the README is unclear too, feel free to let me know by commenting on this devlog or opening an issue or whatever. Mantis If the rules sound familiar, it’s because I mostly just stole them from the card game Mantis by Exploding Kittens. My original idea was to just create a digital version of Mantis, but I was concerned about running into copyright trouble if I called it “Mantis” and used the same terminology and whatnot. Game mechanics can’t be copyrighted, but names and terminology absolutely can. I considered just making my game about abstract colors, but then I suddenly realized that making it about quarks would fit really well, so I did that instead. I did make a few changes to the core mechanics (e.g. using 6 flavors instead of 7 colors, and combining “scoring” and “stealing” into “observing”), but it’s still basically just a reskin of Mantis. Next Steps The next thing I’m going to work on is actually implementing the rules in TypeScript. After that I’ll probably work on the UI. P.S. I also spent like an hour making a terrible-looking banner for Hadronize to use as the Stardance project image."}]...
|
Title: Hadronize by @ethmarks | Stardance
Devlogs Title: Hadronize by @ethmarks | Stardance
Devlogs:
Hadronize This is my first devlog for this project. It’s a multiplayer strategy game that you can play in your browser. https://github.com/ethmarks/hadronize Basically the only things that I’ve done so far are write the rules in the README and brainstorm a bunch. The rules are pretty important, so I’ll write them in this devlog. Because there’s a 4000-character limit to Stardance devlogs, I’m going to try to keep the rules shorter and less thorough than I did in the README. Rules Hadronize is a 2-6 player game which will probably take about ~10 minutes per game. The goal is to be the first player to hadronize 10 or more quarks. Quarks are basically the cards. There are 6 different flavors of quark: up, down, strange, charm, bottom, and top. By the way, I’m not making that part up . Quarks start out as Superposed Quarks, which are quarks in a state of superposition between three different flavors. Once the superposition collapses (more on that later), it chooses one of the three flavors in its superposition and becomes a normal quark with a single flavor. Each player starts with four collapsed quarks with randomly-chosen flavors in their respective cloud chamber . On each turn, a new superposed quark appears. The players know that the quark will be one of the three flavors in its superposition, but they don’t know which one. The player whose turn it is (aka the active player) will choose any player (including themselves) to be the observing player. The observing player observes the superposed quark, which collapses it and adds it to their cloud chamber. If the observing player has none of that flavor (e.g. the new quark collapsed into charm and the player only has down quarks), then nothing else happens and the turn ends. But if the observing player does have at least one quark of the same flavor, something does happen. If the active player chose themselves to be the observing player, the new quark reacts with all existing quarks of the same flavor, and they all hadronize together. If the active player chose a different player to be the observing player, the new quark reacts with all existing quarks of the same flavor, and they all quantum tunnel from the observing player’s chamber into the active player’s chamber. In other words, the active player steals some of the observing player’s quarks. If my explanation is unclear, check out the README because I probably explained it better there. If the README is unclear too, feel free to let me know by commenting on this devlog or opening an issue or whatever. Mantis If the rules sound familiar, it’s because I mostly just stole them from the card game Mantis by Exploding Kittens. My original idea was to just create a digital version of Mantis, but I was concerned about running into copyright trouble if I called it “Mantis” and used the same terminology and whatnot. Game mechanics can’t be copyrighted, but names and terminology absolutely can. I considered just making my game about abstract colors, but then I suddenly realized that making it about quarks would fit really well, so I did that instead. I did make a few changes to the core mechanics (e.g. using 6 flavors instead of 7 colors, and combining “scoring” and “stealing” into “observing”), but it’s still basically just a reskin of Mantis. Next Steps The next thing I’m going to work on is actually implementing the rules in TypeScript. After that I’ll probably work on the UI. P.S. I also spent like an hour making a terrible-looking banner for Hadronize to use as the Stardance project image.
Core Game Logic Today I implemented most of the core game logic in TypeScript. My code is pretty messy, probably has some bugs, and definitely has some idiosyncrasies that I should add docs for, but it does work correctly. Mostly. Here are a few highlights from today: Determinism The rules specify that quarks are created on-the-fly at the start of each turn, and that it’s impossible to predict what flavor a superposition will collapse into. Nondeterministic code makes me uncomfortable, so I decided to cheat a bit behind the scenes to make the whole thing pseudorandom and fully deterministic. In the game constructor, every quark that will ever be used during the game is pre-generated based on values from a mulberry32 function, then the collapsed flavor is predetermined ahead of time. Those two things: the list of future quarks that will be “created” on subsequent turns, and the flavor that each superposition will collapse into, are secret information that the players aren’t allowed to know, which means I have to be careful to sanitize the game state before it’s given to players. I hate references So, one of the first things that I did was create the Quark class. It has a few methods, but mainly it’s just a DTO for a flavor and a superposition. So my original plan was involved doing normal OOP and having each quark be owned by a Player class or the Game class itself. But once I actually started coding it, I remembered that I hate having to remember what’s stored as a value and what’s stored as a reference in JS. This is especially annoying when moving quarks between containers. So instead, I decided to just store an array of every extant quark, including not only a flavor and superposition but also an index. When a player class “owns” a quark, it really just owns that quark’s index number which corresponds to a quark in the game class’s SSoT. Crucially, the index number is a simple integer that doesn’t have any of JS’s object reference silliness. Timeline I decided that the game class should save every past state that it’s been in for some reason. I might use it in the UI to let users scroll back in time to see how the game played out, or maybe use it to make neat statistics at the end of the game, or something like that. It might also be useful for bots (more on that in a future devlog). But anyways, actually implementing the timeline was extremely frustrating, mainly due to Typescript. The final implementation that I settled on is pretty clean, but it was not my first thought, and I went through maybe a dozen different iterations over the course of an hour. Next Steps I’m probably going to spent a bit more time in the game logic before starting work on the UI. As I mentioned, I need to write docs for the idiosyncrasies of my code because otherwise I’ll forget how it works and that’s how bugs happen. Speaking of bugs, I’m sure that there are a few in my code, so I’ll probably write some tests to try to find them. Thanks for reading!
Browser CLI Since my last devlog, I implemented a CLI for Hadronize that works across Node, Deno, Bun, and browsers. You can try it out by visiting https://ethmarks.github.io/hadronize/cli or running the following commands (you only have to run one of the Node/Deno/Bun commands): # Clone the repo git clone https://github.com/ethmarks/hadronize.git cd hadronize # Run with Node (via npm or pnpm) npm install npm run cli # Run with Deno deno task cli # Run with Bun bun install bun run cli Link to the diff between last devlog and this one Abstraction In case you’re not familiar with the JS ecosystem, a cross-runtime CLI like this is not normal. My CLI uses styled text, but the different runtimes have different ways of logging styled text. Node, Deno, and Bun all use ANSI escape characters, but browsers use %c placeholders (Deno also supports %c because Deno is awesome, but none of the others do). Node uses the readline API to get user input, but Deno and Bun both use prompt() , and browsers don’t even have a way to get user input without clever tricks (as you’ll see later). My solution to the styled text problem was to create a custom micro-library which I call styledLog.ts (or sl for short) which invents an easy-to-use syntax for rich-text logging called slChunk , then automatically detects if it’s running in a browser and renders slChunks with either ANSI escapes or %c placeholders accordingly. Cross-runtime user input My solution to the user input problem was a little less elegant, but in my opinion it’s much cleverer. Node, Deno, and Bun were the low-hanging fruit. All I had to do was create an abstracted NbrInputFunc() function that automatically detects which runtime is running the code, then switches out the method it internally uses to fetch input accordingly. Easy. But implementing a CLI in the browser was a lot more tricky. I could have just used the window.prompt() method , but that opens a disruptive pop-up window that looks terrible. Instead, my code dynamically adds custom properties to the window object, then halts the script execution via a Promise<void> . Each custom property is named after a player name and has an anonymous getter function. When you type a player’s name (e.g. alice ) in the console, it automatically evaluates window.alice , which triggers the getter. The getter sets the userInput variable then resolves the frozen Promise to resume execution. I hope that made sense. It’s a really hacky solution, but it does work, and it provides an elegant input syntax that resembles that of terminal CLIs. My first idea (which is still used as the fallback) was to just define a window.turn() function, so you would enter your input with turn("alice") . The current solution is much more elegant, in my opinion, because the user doesn’t need to type parenthesis or quotes. Here’s a link to the code if you want to check it out for yourself. Beginnings of the UI I also started working on the UI the tiniest bit. Not anything that’ll make it into the final version, mind you, but I added a page that demos the Hadronize CLI. It seemed wrong to make the demo page blank and not include instructions, so I wrote some. It seemed wrong to use unstyled bare HTML, so I added holidaycss . Next Steps I think that there’s still some work I need to do in the game logic and CLI before I start working on the UI. The CLI demo currently doesn’t have any way to customize the game settings (e.g. how many players there are and what deterministic seed to use), so I’ll probably work on that next. Thanks for reading!
Setup Flow diff from last devlog to this one Since my last devlog, I added a flow that lets users set up each game before starting it. The setup includes specifying the seed, player count, the names of each player, and whether each player should be a human or a bot. I made it work in three different formats, each of which had to be implemented individually: The terminal : at its core, this format is just a normal TUI. It prints input prompts, awaits the user’s input using the abstracted NbrInputFunc I mentioned last time, and repeats this until the user provides an input that passes the validation function. Pretty standard stuff. The browser console : I used the same trick that I described last time to allow users to enter their input via the browser console. It creates a custom window property that resumes execution, then halts execution with a Promise<void> until the window property is called. Unfortunately, it wasn’t possible to use the anonymous getter trick that I used last time. If I did that, I would have to create custom window properties for every possible 32-bit number to allow user to enter the seed, and create custom properties for every possible string to allow users to enter player names. That obviously wasn’t possible, so instead I just created a window.r function that takes any input type. The “r” stands for “respond”. To set the seed to 42, you type r(42) into the console, which is a reasonably clean UX, I think, though not as clean as just typing 42 like you can in the terminal. The webpage : this uses HTML <input> s and SvelteKit’s reactivity. The trickiest part was navigating the fact that the value of one of the inputs (player count) controls the structure of some of the other inputs (player configs). At first I tried writing code to dynamically construct a variable-length Array, but that was a nightmare of complexity. Then I tried making all 6 possible player configs visible all the time and just adding the “Disabled” type, but that made the UI look ugly and was also kind of complicated to implement. The solution I settled on was to internally use an Array with a fixed length, automatically hide the player config UI elements with an index less than the player count value, and slice the player config Array before passing it into the main game function. I think that this solution is the best of both worlds while also being fairly simple to implement. Next Steps I know that I’ve been saying this for the past 4 days, but I need to write some internal docs for my game logic code and write tests. I haven’t noticed any bugs during my playtests while building the CLI, but I’d like the peace of mind to be fairly confident that I’ve implemented my game rules correctly.
CLI Remote Script You can now run Hadronize CLI in a terminal without cloning the repo. If you run the command below, Deno will automatically fetch all the dependencies. deno run -A http://ethmarks.github.io/hadronize/cli.ts Node doesn’t support remote scripts because it lacks Deno’s awesomeness, but because of the Deno binary on npm , you can run Deno (and therefore Hadronize) through any of the other package managers! npx deno run -A http://ethmarks.github.io/hadronize/cli.ts pnpm dlx deno run -A http://ethmarks.github.io/hadronize/cli.ts bunx deno run -A http://ethmarks.github.io/hadronize/cli.ts For example, in the attached screenshot, I SSH-ed into one of my home servers that hadn’t cloned the Hadronize repo nor installed Deno, and tried to run Hadronize as a remote script via pnpm . After resolving dependencies for a few seconds, it ran flawlessly. How it works I first encountered Deno remote scripts in Lume’s init command , and my implementation is heavily inspired by it. Basically, all that the cli.ts file does is fetch the CLI code from JSDelivr, which fetches it directly from the GitHub repo. From there, Deno is smart enough to resolve all of the CLI code’s dependencies and run it. Compatibility Before today’s changes, running Hadronize via Deno worked perfectly fine. deno task cli behaved identically to pnpm run cli . However, that’s because Deno has an automatic Node compatibility layer , not because Deno can actually run the code natively. That compatibility layer doesn’t really work with remote scripts (because Deno can’t find the package.json ), so when I first tried to run the remote script while developing it, it crashed and burned immediately. This was because, without the compatibility layer, Deno and Node handle things fundamentally differently. There were several differences, some of which I expected and some of which I didn’t, but the easiest one to understand is NPM imports. NPM imports My CLI code relies on the picocolors library for getting ANSI escape codes. When I was first writing the code, I added the picocolors package via NPM and imported it in the normal Node way: import pc from " picocolors " ; The problem is that Deno can’t parse bare imports like that. Deno expects this format, which Node cannot parse: import pc from " npm:picocolors " ; I tried configuring an import map in deno.json , but it didn’t work. I considered just hardcoding the ANSI escape sequences, but I decided that I would need to figure out how to polyglottally import NPM packages in both Node and Deno at some point, so I might as well figure it out now. My solution was to create a deps/picocolors.ts file to proxy the picocolors import by dynamically importing it based on whether it’s being run in Deno or not: const { default : pc } = " Deno " in globalThis ? await import ( " npm:picocolors " ) : await import ( " picocolors " ); export default pc ; NPM imports were only one of the issues that sprung up. Frustratingly, the only way to test whether or not a solution worked was to commit, push to main, and test on production. The whole Deno compatibility saga required 12 commits in total. Next Steps I’m still working on writing unit tests for the game logic. I already have a few tests, but they’re definitely not comprehensive. I’ll write a devlog about the tests once I’m finished with them.
Tests and CLI Args You can now add arguments to the Hadronize CLI in the terminal, which lets you avoid having to use the setup flow. Here’s an example. pnpm run cli --seed 12345 --player Alice:human --player Bob:bot It also works if you run the CLI as a remote script. deno run -A http://ethmarks.github.io/hadronize/cli.ts -s 8 -p a:bot -p b:bot -p c:bot This was pretty easy to implement. I just used Node’s parseArgs utility for the main arg parsing and wrote a bunch of validation logic that converts the raw arguments (which are always strings) into the data types that my code uses. Tests Over the past couple days, I’ve made a little test suite for the game logic using Vitest. I’ve written 19 individual tests, but some of them repeat multiple times with different game seeds and whatnot to ensure that it works with a variety of inputs, so Vitest actually runs 101 tests in total. All of the tests pass, and I didn’t discover any bugs, which either means that I managed to get all the game logic correct on the first try, or that there’s something wrong with my tests. Next Steps I think that I’ve probably spent too much time on the CLI. I don’t think that it was time wasted, but I probably ought to get started on the main game UI.
Drivers Each player in Hadronize is controlled by a Driver, which is basically just a function that takes the current game state as an input and outputs a player. I implemented drivers on like day #2, but I don’t think I’ve talked about them in a devlog yet. The first driver I made is the dogpile driver. It’s logic is extremely simple: it just selects the player who goes first. It doesn’t even reference the game state at all. If every player is a dogpile driver, this means that everyone just dogpiles onto the first player and ends up stealing basically all of its quarks before it can use them. This is obviously a terrible strategy because it’s not even capable of trying to score, but it was very simple to implement and I use it as a placeholder. The second driver I made is the rng driver. It just makes random decisions. However, because I insist on everything being deterministic, it can’t just use Math.random . Instead, it stringifies the game state, converts that string into a 32-bit integer via a djb2 hash, then uses that integer to seed a mulberry32 pseudorandom number generator, then uses the output of the mulberry to make its player selection. The newest driver that I just finished developing is the expected value driver. It does actual strategic calculations to determine what the expected value of choosing each player would be based on the information it has available, then selects the player that maximizes that value. Next Steps I’ve started building the UI, but I’ve still been procrastinating on actually working on it in earnest. I should probably do that.
Huge UI Progress diff from last devlog to this one I’ve been working a lot on the Hadronize UI. Last devlog, all that it could do was render all of the quarks into a big overlapping heap and you could drag around one specific quark. Now, you can play a full game in the UI from start to finish, and it’s reasonably polished. How to play the UI prototype Visit https://ethmarks.github.io/hadronize/play . Make sure that you’ve read the game rules in the README . I haven’t implemented a setup flow in the main UI yet, so right now it’s pre-configured with two human players named Arthur and Ford, one bot player named Marvin, and seed 42. On each human player’s turn (their name will be highlighted in yellow), click and drag the superposed quark to the chamber of the player who you want to observe it. The superposed quark will collapse, get added to the chamber you selected, possibly react with existing quarks, and then play will proceed to the next player. Continue this until someone wins. It will probably be Marvin. Refresh the page to play again. Playtest I also conducted the first playtest with a few friends. Nothing broke during the playtest and they all liked it and gave positive feedback, which was really encouraging. We all got absolutely crushed by the expected value driver I built last devlog. Next Steps It sounds hyperbolic to say that this UI is the messiest code I’ve ever written, but I legitimately can’t think of any other contenders. Of the 800+ lines of code in the UI, about 570 of them are in one massive Game.svelte component. This component handles state tracking, mouse movement, the main game loop, and most of the geometry to position the quarks. The very next thing that I need to do is massively refactor the UI code. After that, I have a few ideas: A setup flow that lets the user choose the seed to use and configure the players. Sound effects, UI indicators (e.g. “you formed a baryon!”), and other game juice. Proper mobile support. Right now it kind of works on mobile, but the layout gets really cramped. I’ve been working a lot on the Hadronize UI. Last devlog, all that it could do was render all of the quarks into a big overlapping heap and you could drag around one specific quark. Now, you can play a full game in the UI from start to finish, and it’s reasonably polished.
UI Refactor diff from last devlog to this one I refactored the Hadronize UI code. Rather than one giant 570-line file that handled the quark positioning, state tracking, mouse movement, and game loop, I split the code into four different files, each dedicated to one specific thing, with an average line count of ~154 (191, 184, 111, and 132, respectively). This makes the codebase way more maintainable and easy to work in. I also deduplicated most of the main game loop code. Before, I had just copied the entire content of the executeTurn() function, pasted it into the UI code, and customized it until the logic code correctly interfaced with the UI. Maintaining two separate functions that do basically the same thing is bad practice, so today I came up with an alternative solution: adding a bunch of “hooks” as optional parameters, which are just functions that the executeTurn() function runs at specific stages. In a CLI game, the hooks are never provided to the function, so they’re never run and nothing changes. But the UI code does provide hooks, to do things like trigger re-renders. This way, the same code can be reused for two different use cases (CLI and UI). Next Steps There’s still more refactoring to do, but I don’t think that I’ll do any more major restructuring.
UI Setup Flow diff from last devlog to this one I added a setup flow to the main UI page, and did a lot of refactoring. I also removed support for setting up the game via browser console. I didn’t make this choice lightly because it was a fun feature, but the tradeoffs were just too much and I decided that it wasn’t worth it, especially because the console setup is much clunkier than just using the HTML form, so I doubt anyone would even use it. But anyways, the main focus of this devlog is the setup flow on the main UI page (aka the play page). I also added some pretty sleek animations when activating and deactivating the game overlay.
Style improvements and new pages So, funny story about the site styles. When I first made the CLI page 3 weeks ago (has it really been that long?! wow), I added holiday.css to make it look nice as a stopgap measure until I made the real styles. However, as the old saying goes, there’s nothing more permanent than a temporary solution. I’ve decided to just embrace using holiday.css for the entire site because it looks much nicer than anything I could make. The styles in the actual game component are entirely my own, of course, but the homepage, rule page, and rewritten CLI page all use holiday.css. “what rule page and rewritten CLI page?”, you ask? That’s the other thing that I did this devlog. I created a dedicated page on the site for the rules, and I rewrote the CLI page to only contain instructions on how to use the CLI rather than a playable browser CLI. Don’t worry, you can still play Hadronize via the browser console. The main UI has had that functionality since the beginning. I just didn’t see a reason to maintain two different game UIs, especially because the main UI can do everything that the playable CLI page could (and much more). I think that next I’ll start polishing the game UI. It’s long overdue. I’ll add sound effects, add mobile support, and maybe (don’t hold me to this) improve the graphics.
Mouse handler refactor https://github.com/ethmarks/hadronize/commit/3a5adcb I started working on writing audio code and looking through sound effect libraries, but when I tried to hook my WIP sound-playing function into the mouse handler, I realized what an awful mess my mouse handler code was. So I spent over an hour refactoring it. While I was at it, I optimized it a tiny bit and fixed the hover thrashing bug that had been bugging me for nearly 2 weeks now.
Sound effects! I added sound effects to the game UI. A unique sound plays for each of these: Starting a game Dragging a quark over a chamber Dropping a quark onto a chamber A quark hadronizing A quark tunneling Winning a game Closing a game I sourced them all from https://freesound.org/ , and I left attribution for each one in sounds.svelte.ts . I also modified a few in Audacity to trim them or apply simple effects. I’m not sure that I’m 100% satisfied with the sounds. I sourced almost all of the effects from different freesound sounds because I couldn’t find a sound pack that I liked, so the sounds don’t quite match tonally. Some of them are generic UI sounds while others are clearly scifi-ey. I may change some of the sounds later if I find more cohesive ones. I’d never done audio in HTML/JS before, so this was new for me. I originally just used the Audio() constructor because that was the most obvious way to play, but when I realized the many issues with it (though it did work!), I rewrote my code to use AudioContext . I also made a multi-step preloading and decoding pipeline that fetches all sound effects on page load, but doesn’t decode them until the user presses a button because otherwise JS throws a warning in the console and suspends the audio context. I think that the sound effects make Hadronize feel a lot more polished and nicer to play. Next up on my list is mobile support. I’m not looking forward to it. (Make sure to turn on sound for the video below)
So the first step to mobile support is making the all of the quarks in all of the chambers actually fit on a phone screen. Right now they just overlap a bunch and you can’t tell which quarks belong to who. I have some ideas for an algorithm that can automatically adjust layout variables until everything fits, but first I need to give the algorithm things that it can adjust. The crux of the problem is that there’s simply no way to fit 6 chambers in a circular ring around the center of the screen on mobile. There’s just not enough screen space. So I made a new layout that places chambers in a grid instead of a ring. It works on desktop in addition to mobile. I don’t think it looks quite as nice, but it’s much more space efficient. I attached some side-by-side comparison screenshots. As you can see, the quarks still don’t quite fit on mobile even with the grid layout, but it’s much closer. Next step is either writing the automatic layout algorithm, or making input work on mobile.
Layout optimization algorithm It took an entire day, but I did it. Hadronize will now automatically adjust 5 different layout variables in order of priority to make everything fit on screen. I think that the algorithm is probably the most complicated part of this entire project. I’m going to try to explain it really simply in this devlog, but if you want to see how it actually works, I wrote a bunch of comments that explain the priority pipeline in this file . So basically, every time a new layout update is triggered, the layout manager calculates a brand new layout plan from scratch. Once it’s finished calculating, it applies the layout plan onto the actual layout variables that are used to move the quarks on the screen. If I modified the layout variables directly, the rapid-fire modifications while calculating would trigger a bajillion reactive updates from Svelte which would slow the page down. Anyways, the way that the layout plan is calculated is that it starts by assuming ideal conditions: there is more than enough room for everything to fit comfortably. So it does the calculations using the preferred ideal variables, it modifies the plan, and then it actually checks to see if anything is overlapping. If there is any overlap, it tries to resolve it using the least-disruptive adjustment it can make. If that doesn’t work, it tries the next least-disruptive adjustment. And so on. Also, each time it moves up the chain of disruptiveness, it tries to use the ideal variables for all of the less-disruptive adjustments. If that makes sense. Here are the adjustments that it can make, in ascending order of disruptiveness: Increasing the radius of the ring of quarks of a single chamber Adjusting the radius of the ring of chambers around the center of the screen Switching chambers to use count mode, which is when it only displays the number of quarks of each flavor rather than displaying each quark individually. Switching the global layout from ring mode to grid mode. This is the thing that I built last devlog. Decreasing the size of all quarks I’m pleased to report that when I tested it on my phone, everything worked perfectly. I still haven’t implemented mobile input yet, but I started a 6-player game of all bots, and the layout planner managed to keep all of the quarks visible all of the time, even when a single chamber had more than 20 quarks. Never once did I see two chambers overlap with each other or go partially offscreen, which used to happen 100% of the time on small mobile screens. It just changed layout modes and decreased the quark size whenever it started to run out of room. Anyways, I’m not going to merge the new layout planner just yet because I’m not 100% sure how stable it is, but I’ll do that soon. Next up is mobile input.
Touchscreen support Idk why I was worried that this would be difficult. Less than 20 lines of code later, Hadronize now automatically detects whether you’re using a fine pointer (e.g. a mouse) or a coarse pointer (e.g. a touchscreen), and changes its behavior accordingly. So now you can select chambers on touchscreen just by tapping on them. You don’t have to drag the superposed quark, you just tap. I recorded a video showcasing this in action using Firefox’s mobile device simulator (aka RDM). As you can see, when I disable touch simulation, the chambers respond to hovering and I have to drag the quark around. But when I enable touch, the chambers don’t react at all until I click one, and then the superposed quark gets added to that chamber like normal. I’ve also tested this on an actual phone and it works perfectly, but it’s more difficult to record on there which is why I used Firefox’s simulator for the video.
Minor graphics improvements This is a smaller devlog. Stuff I did since last devlog: Fixed the winning animation to work with the new layout planner Added transitions to the quark text. Whenever a quark changes its display text (e.g. from a ‘?’ to a flavor abbreviation like ‘s’), rather than instantly snapping to the new text, it’ll do a quick crossfade. Changing the font used for the quark text from the default to a font called Degheest that I think looks nice. Merging the layout refactor into prod because I’ve decided that it seems stable enough. Next, I’m going to work on improving the quark graphics. I’m trying to go for an aesthetic that looks like it’s from a physics textbook (hence the dot grid backdrop I’ve had for a while), so it’s already pretty close, but imo it looks a bit too plain right now. I don’t have a precise vision for exactly what I want the quarks to look like, so I’ll need to figure that out.
New quark style I made new quark graphics, like I promised last devlog. I’m not really sure if it fits the aesthetic I’m going for, but it’s something , and I tried to make it extensible so that I can experiment with more styles later. I also added a dropdown menu in the setup flow so that you can select which style you want to use, though I might remove that in the future if I decide on one style to be the definitive one. The new style is just patterns masked onto the same flat color circles as before. Each flavor has a different pattern: up: vertical lines down: horizontal lines charm: checkerboard strange: square grid with irregular shading top: light dot grid bottom: dark rhombus grid hadron: solid (unchanged) I don’t know if this makes the quarks look nicer or not, but it definitely makes them more accessible. If the abbreviation text isn’t visible for whatever reason (e.g. because the chamber is in count layout mode), quark flavors used to be distinguished solely by color. But the new patterns make them distinguishable without color, which is important for colorblind accessibility.
QuickJS drivers I can now store driver strategy code as strings, execute the strings as JS code using QuickJS , read the quickjs output, and use it as driver output. This might not sound like much of a difference, but it completely changes how I can run drivers. Before, all driver strategies had to be present in the actual source code. Now, they just have to be strings. Because we can manipulate strings at runtime, this means that we can create new drivers while the site is running without modifying the source code. In other words: this lays the groundwork for letting you create and play against your own drivers without making a PR to the repo. To make sure that my implementation works, I converted the expected value driver to use quickjs. I enclosed all of the actual logic in backticks, making it a giant string, and then passed the string through my quickjs driver factory function. I ran the expected value driver test suite, and it failed immediately because I forgot to remove the type annotations (quickjs can only execute plain JS, not TS). But once I fixed that, all 19 tests passed, and it seems to work perfectly from my playtests. I eventually plan on adding a page that uses Prism code editor to let users edit driver strategies and save them to localStorage. But first I’m going to add more features to the quickjs runtime. For example, I want to have it swap all Math.random() calls with a deterministic psuedorandom generator, so that way developers can use randomness without making it non-deterministic.
Bot editor I integrated the QuickJS driver code that I made last devlog into the rest of the site. Things I did: I made the QuickJS VM override the default Math.random function and replace it with a mulberry32 prng seeded by stringifying the game state and hashing it through djbs2 . So now drivers can still use Math.random without making the rng predictable or sacrificing perfect determinism. I gave the drivers names and descriptions. The prng driver is named “Bogo” (after Bogosort ) and the expected value driver is named “EVan” (because it’s a normal name that starts with the abbreviation of “ E xpected V alue”). I moved the code for the existing drivers into a centralized array, rather than in multiple different files that had to be imported individually. I’m calling this array the “stock drivers”. I added a bot editor page. You can check it out at https://ethmarks.github.io/hadronize/bots . I used contenteditable and Svelte’s bind:textContent to let users edit the title, ID, and description. I used Prism code editor as the embedded IDE for editing the actual driver code. I made the play page fetch the list of drivers from localstorage on page load, defaulting to the stock drivers. I also made the bot editor automatically sync the drivers to localstorage . I added a new driver strategy: tit for tat . As expected, it plays pretty terribly because that strategy just isn’t very good in Hadronize. I mostly made it so that users looking at the stock drivers can learn how to reference the timeline from the state. I think that next I’ll work on a driver ranking system so that when I make more drivers, I’ll know whether they’re better or worse than the others. I might research how chess ranking systems work and copy concepts from those.
Benchmark Before I started working on the bot ranking arena, I did a quick sidequest to figure out how many games per second I could simulate. So I wrote this script to execute a bunch of games sequentially, then print the elapsed time and calculate the games per second rate. I ran the benchmark in Node 24.15.0 on my 4.40 GHz Intel i5-12450H using Bogo drivers: Simulated 82157 turns across 1000 games Took 109048ms (109.048s). Speed is 9.170273640965446 games per second So that was surprising. I was expecting a speed in the low thousands, but instead it was less than 10. I had a suspicion what was causing the slowdowns. To make sure, I swapped out the Bogo driver (which uses QuickJS) with a non-QuickJS driver that I made for testing, and reran the same benchmark: Simulated 53854 turns across 1000 games. Took 130ms (0.13s). Speed is 7692.307692307692 games per second (the turn count is smaller because the drivers used a different strategy which made games end faster) So, obviously, the slowdown is caused entirely by QuickJS. Which makes sense. Every time a QuickJS driver is invoked, it spins up a brand new QuickJS VM, configures it, executes the actual code, extracts the return value from the VM, disposes of the VM to avoid memory leaks, and then finally returns the value. Non-QuickJS drivers can just execute the code directly, and the code can be optimized very well by the JIT compiler that Node uses. So the solution seems simple, right? Just don’t use QuickJS for the drivers. Whatever the advantages of using QuickJS are, surely they aren’t worth an 839x decrease in performance. Well, unfortunately that’s not an option. More specifically, dynamically running strings of JS (like the driver code that users write at runtime) as native code is not possible, so I have to use a JS VM. And QuickJS is by far the best embeddable JS VM that I know of. So I just have to accept the slowness. This means that I’ll have to be clever about the bot arena, though. I can’t just brute-force a ranking with thousands of games if I can only run 10 games per second. btw, if you’d like to see how your PC does on my benchmark, just run these commands: git clone https://github.com/ethmarks/hadronize.git cd hadronize pnpm install pnpm bench --count 1000 --driver prng If your time is faster than mine, leave a comment to gloat.
Discontinuing the ranking arena I’ve decided to stop working on the driver ranking arena. I already have an MVP that works well enough to kinda sorta determine which drivers are good and which are bad, but it’s not robust and it just sums up rankings rather than implementing an actual Elo algorithm . The reason I’m not going to continue working on it is that it seems like a lot of work, and I don’t think that it’ll provide any value. Like, at all. The root of the problem is that Hadronize just isn’t a strategic-enough game. There’s certainly some strategy, of course, and probabilistic modeling, but luck plays just as much of a factor. The cleverest Hadronize driver can still routinely lose to the dumbest one just due to slightly bad luck. So it doesn’t really make sense to build tooling for strategic bots if the strategy is not a very big aspect of the game. Thinking back, I’m not really sure why I decided to start working on the driver arena in the first place. It just seemed like the right thing to do at the time even though I now realize that it would be kind of useless. Anyways, I also created two new drivers. The first is called Kingslayer, and it just tries to steal from the player who’s currently winning. It’s not very good at actually winning, but it does make things more challenging for the other players. The second is called Gentleman (aka charm ). It’s obsessed with trying to collect charm quarks, because its a charming gentleman. I made it as a joke because I thought it was funny, but to my complete surprise it turns out to be a pretty good strategy? Not charm quarks in particular, but trying to collect a specific flavor of quark at all costs turns out to be surprisingly effective. It consistently wins more often than EVan, the driver that I specifically built to be a good strategy and that actually does probabilistic expected value calculations. I think that next I’ll start working on the README and documentation, because I haven’t updated the README in like 3 weeks and it’s extremely outdated.
How to play page I wrote a page that explains how to play, assuming zero knowledge. I think that this’ll be helpful for onboarding, because this way they learn the rules at the same time as they learn how to use the UI, rather than reading the abstract and theoretical rules and then trial-and-erroring their way through the UI. The actual writing part took a few hours, and most of it was revision and trying to find better ways to phrase things. It’s nearly 1000 words, meaning I could turn it in for an essay assignment and not fail the word count, which is funny. But what also took a lot of time was making the visual aid. I had to record myself performing the same action in the UI many times to get a perfect take, and then I had to craft an ffmpeg command to crop and trim it because I refuse to use graphical video editors. Also my recording software kept stuffing H.264 video data in a webm container, which made ffmpeg freak out because that file is technically corrupted. I also had to figure out how to screen record on my phone to get a tap indicator, which I’d never done before. You can read the page here: https://ethmarks.github.io/hadronize/how
Revised README I worked on updating and basically completely rewriting the README to something more polished. I still need to add more sections and revise what I have, but I think that it’s alright. I’m trying to strike a balance between not having enough content and being a wall of text. It’s also surprisingly difficult to come up with bullet points for the features list. After I finish up the README, I’m going to redesign the home page a bit. After that, I think I might be ready to ship.
Revised Readme (again) Still working on the README. I think that Hadronize is more or less ready to ship now, but there’s probably still a bit more polishing I can do. In my other Stardance projects, I’ve gotten really positive feedback on my READMEs, so apparently my writing style and README format of choice is a winning combination. I’ve been referencing my past READMEs and the Stardance README guide a lot while writing this one. The bulk of what I added was the How it Works section, which explains some of the technical details and design choices that I made. It’s a dense topic so it’s obviously a long section. At first it was just a wall of text, even when I tried to break it up with lists and subheadings. So I spent about half an hour taking screenshots and editing them in GIMP until I had decorative images that I was satisfied with for each subsection. I think that drop shadows on transparent backgrounds look really cool in README images, so I used GIMP’s drop shadow filter to add them to my screenshots (in addition to cropping, rounding corners, et cetera). I kept fiddling with the drop shadow settings and I didn’t want to go back and redo the images that I’d already done, so the shadows are kind of inconsistent, which really irks me but I don’t think is very noticeable. I also added a Running Locally section and fixed a few typos throughout the README. Lastly, I did a bit of work on the home page. I added a big screenshot below the intro paragraph, thanks to feedback from the awesome @Luksus , whose project you should totally check out .
Shipping I did a few miscellaneous things like make the remote script endpoint production-ready, fix some typos across the project, and create a favicon in Inkscape. After I write this devlog, I’m going to press the big “Ship your project!” button. If you’re a reviewer reading this: I hope you enjoy Hadronize. It’s one of my biggest projects ever, and I’m really proud of how it’s turned out.
Ships:
Hadronize: a quark-themed set collection game. It has a web UI with a custom SvelteKit virtual layout engine, a polyglot CLI that runs across Node, Deno, Bun, and the browser console, a QuickJS bot sandbox, a comprehensive test suite, and more. I’m really proud of Hadronize and hope that you enjoy it....
|
1793246175.3156857
|
1793332575.3156857
|
|
21420
|
BikiniBot(tom) by @SP14 | Stardance
|
SP14
|
1
|
29.0
|
136
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-19T15:14:59Z", "hours": 29.0, "multiplier": 5.98, "payout": 136, "blessing": "neutral", "text": "BikiniBot(tom) is a 24/7 Slack RPG bot built around SpongeBob characters, fishing, quests, inventory, and a simple economy. I started with a basic setup where commands existed but nothing connected, nothing saved, and everything reset on restart. Over time I turned it into a working game loop where progress actually sticks using JSON storage for XP, levels, items, Sand Dollars, and quests that update as you play. Fishing has rarity tiers now and items actually change outcomes, quests track what you do in normal gameplay, and everything feeds into the same system instead of being separate commands. I also made the characters feel more distinct with better responses and small behavior changes over time, plus added a couple API commands for extra randomness. The hardest part was getting everything to work together cleanly without breaking persistence or Slack command structure as things got more complex. What I’m happiest about is that it finally feels like one connected game instead of a bunch of separate features. :))", "repo": "https://github.com/SP14-cyber/bikinibottom", "demo": "https://hackclub.enterprise.slack.com/archives/C0BBE4LHKQF"}]...
|
[{"post_id": 11952, "ts": "202 [{"post_id": 11952, "ts": "2026-06-19T14:38:22Z", "hours": 15.9189, "text": "I am ready to ship!!I started with a basic bot where most systems were just placeholders. Fishing, inventory, and shop commands existed, but they weren’t connected in any way. Nothing persisted, the economy didn’t really function, and everything reset on restart, which made it feel more like a demo than an actual game. By the end of this coding session, BikiniBot has completely turned into a real persistent RPG system inside Slack!! Inventory and Sand Dollar balances now persist using JSON storage, so every user’s progress is saved. An XP and leveling system lets players grow over time, and a full quest system now tracks objectives and rewards directly in gameplay. Item effects also matter now, like boosting fishing luck, and leaderboard/cooldown systems were improved to balance progression. API commands were upgraded with fact and joke integrations, and character systems now include milestone-based behavior changes. Gary also exists now and he responds with “meow” :)) Before this update, nothing carried over between sessions. Now every user has a persistent game state that evolves over time, making the experience feel like a real RPG. For example, the inventory now reflects actual progression such as levels, XP (like 310/500), Sand Dollars, and items like Rusty Spatulas, Glowing Coral, and Krabby Patties. Quests update automatically as you play, like collecting specific items during fishing or work actions.The core persistence system uses JSON-based user storage with auto-save on every action and safe defaults to prevent crashes. Fishing was also overhauled with rarity tiers (common through legendary), where tools like the Fishing Net increase rare drop chances from ~3% to ~8%.Quests are now fully integrated into gameplay, XP ties everything together into a progression loop, and API-based character commands add personality with safe error handling. A hidden milestone system also changes character behavior at usage thresholds (10, 25, 50, 100), adding long-term variation. So happy with how this turned out and thank you so much for following along throughout my journey!! :))"}, {"post_id": 11372, "ts": "2026-06-18T16:42:12Z", "hours": 10.2147, "text": "Today I kept building out BikiniBot and it’s starting to feel WAY more like an actual game inside Slack :)) I expanded a bunch of slash commands (about 15-16 more commands) and cleaned up how the characters respond so they don’t feel repetitive anymore. SpongeBob, Patrick, Squidward, Mr. Krabs, Sandy, Plankton, and Bubble Bass all have way more personality now and way more different responses depending on what you say !!I also connected a lot of the “game” side commands like /bikinibot-jellyfish, /bikinibot-fish, /bikinibot-work, /bikinibot-shop, /bikinibot-inventory, /bikinibot-krabby, and /bikinibot-order so they feel like they’re part of one system instead of random separate features. It’s starting to feel like an actual Bikini Bottom loop where you earn stuff, get random outcomes, and mess around with it all :) Had to fix a lot of structure issues too (Slack commands not responding, formatting inconsistencies, and making sure everything follows the same pattern), but it’s way more stable now!! Next I’m planning to keep adding MORE variety to all commands, connect inventory properly to what you actually earn (fish/jellyfish/work rewards), and keep building the economy + loot system so everything actually links together instead of being isolated features! Excited for my final steps! I’m really close to shipping :)))"}, {"post_id": 11109, "ts": "2026-06-18T05:18:22Z", "hours": 2.6897, "text": "Today I started building a Slack bot called BikiniBot!! :)) If you add a -tom to the end, it becomes the name of where the show SpongeBob Squarepants takes place! As you might guess from that fact, BikiniBot(tom) is a SpongeBob-themed bot that runs 24/7 and responds to slash commands with different Bikini Bottom characters like SpongeBob, Patrick, Squidward, Mr. Krabs, Sandy, and Plankton!! The idea is that each character has its own personality and reacts differently depending on what you type, so it feels more like interacting with characters instead of just a normal bot. I set up the whole project using Node.js and got the bot properly running in Slack. I also set up my .env file with all the tokens and got the basic structure working. After that I created a bunch of slash commands like /bikinibot-spongebob, /bikinibot-patrick, /bikinibot-squidward, /bikinibot-mrkrabs, /bikinibot-sandy, and /bikinibot-plankton!! Then I started building out different response styles for each character so they actually feel unique instead of all sounding the same. Right now SpongeBob is super energetic and excited all the time, Patrick is silly and random, Squidward is more tired and sarcastic, Mr. Krabs is all about money and profit, Sandy is more logical and science-based, and Plankton is chaotic and always talking about plans and the secret formula!! I also added some helper functions like clean(), has(), and pick() so it’s easier to handle user input and make the bot react based on keywords like “help”, “money”, “sad”, or “hello” instead of just random replies. The hardest part today was getting everything to actually respond correctly in Slack. Some commands weren’t triggering at first even though the code looked fine, so I had to go back and double check the Slack command setup and naming. It was a bit confusing because some commands worked perfectly while others just didn’t respond at all, but eventually I figured out it was just small setup issues and mismatches.Now the bot is finally running properly and feels way more interactive!! :)) It actually responds differently depending on what you say instead of just being static replies, which makes it feel a lot more alive. Next I want to add more game-like features like jellyfish catching, sand dollar money system, inventory, and maybe even a shop so it turns into a full little Bikini Bottom game inside Slack!!"}]...
|
Title: BikiniBot(tom) by @SP14 | Stardance
Devlog Title: BikiniBot(tom) by @SP14 | Stardance
Devlogs:
Today I started building a Slack bot called BikiniBot!! :)) If you add a -tom to the end, it becomes the name of where the show SpongeBob Squarepants takes place! As you might guess from that fact, BikiniBot(tom) is a SpongeBob-themed bot that runs 24/7 and responds to slash commands with different Bikini Bottom characters like SpongeBob, Patrick, Squidward, Mr. Krabs, Sandy, and Plankton!! The idea is that each character has its own personality and reacts differently depending on what you type, so it feels more like interacting with characters instead of just a normal bot. I set up the whole project using Node.js and got the bot properly running in Slack. I also set up my .env file with all the tokens and got the basic structure working. After that I created a bunch of slash commands like /bikinibot-spongebob, /bikinibot-patrick, /bikinibot-squidward, /bikinibot-mrkrabs, /bikinibot-sandy, and /bikinibot-plankton!! Then I started building out different response styles for each character so they actually feel unique instead of all sounding the same. Right now SpongeBob is super energetic and excited all the time, Patrick is silly and random, Squidward is more tired and sarcastic, Mr. Krabs is all about money and profit, Sandy is more logical and science-based, and Plankton is chaotic and always talking about plans and the secret formula!! I also added some helper functions like clean(), has(), and pick() so it’s easier to handle user input and make the bot react based on keywords like “help”, “money”, “sad”, or “hello” instead of just random replies. The hardest part today was getting everything to actually respond correctly in Slack. Some commands weren’t triggering at first even though the code looked fine, so I had to go back and double check the Slack command setup and naming. It was a bit confusing because some commands worked perfectly while others just didn’t respond at all, but eventually I figured out it was just small setup issues and mismatches.Now the bot is finally running properly and feels way more interactive!! :)) It actually responds differently depending on what you say instead of just being static replies, which makes it feel a lot more alive. Next I want to add more game-like features like jellyfish catching, sand dollar money system, inventory, and maybe even a shop so it turns into a full little Bikini Bottom game inside Slack!!
Today I kept building out BikiniBot and it’s starting to feel WAY more like an actual game inside Slack :)) I expanded a bunch of slash commands (about 15-16 more commands) and cleaned up how the characters respond so they don’t feel repetitive anymore. SpongeBob, Patrick, Squidward, Mr. Krabs, Sandy, Plankton, and Bubble Bass all have way more personality now and way more different responses depending on what you say !!I also connected a lot of the “game” side commands like /bikinibot-jellyfish, /bikinibot-fish, /bikinibot-work, /bikinibot-shop, /bikinibot-inventory, /bikinibot-krabby, and /bikinibot-order so they feel like they’re part of one system instead of random separate features. It’s starting to feel like an actual Bikini Bottom loop where you earn stuff, get random outcomes, and mess around with it all :) Had to fix a lot of structure issues too (Slack commands not responding, formatting inconsistencies, and making sure everything follows the same pattern), but it’s way more stable now!! Next I’m planning to keep adding MORE variety to all commands, connect inventory properly to what you actually earn (fish/jellyfish/work rewards), and keep building the economy + loot system so everything actually links together instead of being isolated features! Excited for my final steps! I’m really close to shipping :)))
I am ready to ship!!I started with a basic bot where most systems were just placeholders. Fishing, inventory, and shop commands existed, but they weren’t connected in any way. Nothing persisted, the economy didn’t really function, and everything reset on restart, which made it feel more like a demo than an actual game. By the end of this coding session, BikiniBot has completely turned into a real persistent RPG system inside Slack!! Inventory and Sand Dollar balances now persist using JSON storage, so every user’s progress is saved. An XP and leveling system lets players grow over time, and a full quest system now tracks objectives and rewards directly in gameplay. Item effects also matter now, like boosting fishing luck, and leaderboard/cooldown systems were improved to balance progression. API commands were upgraded with fact and joke integrations, and character systems now include milestone-based behavior changes. Gary also exists now and he responds with “meow” :)) Before this update, nothing carried over between sessions. Now every user has a persistent game state that evolves over time, making the experience feel like a real RPG. For example, the inventory now reflects actual progression such as levels, XP (like 310/500), Sand Dollars, and items like Rusty Spatulas, Glowing Coral, and Krabby Patties. Quests update automatically as you play, like collecting specific items during fishing or work actions.The core persistence system uses JSON-based user storage with auto-save on every action and safe defaults to prevent crashes. Fishing was also overhauled with rarity tiers (common through legendary), where tools like the Fishing Net increase rare drop chances from ~3% to ~8%.Quests are now fully integrated into gameplay, XP ties everything together into a progression loop, and API-based character commands add personality with safe error handling. A hidden milestone system also changes character behavior at usage thresholds (10, 25, 50, 100), adding long-term variation. So happy with how this turned out and thank you so much for following along throughout my journey!! :))
Ships:
BikiniBot(tom) is a 24/7 Slack RPG bot built around SpongeBob characters, fishing, quests, inventory, and a simple economy. I started with a basic setup where commands existed but nothing connected, nothing saved, and everything reset on restart. Over time I turned it into a working game loop where progress actually sticks using JSON storage for XP, levels, items, Sand Dollars, and quests that update as you play. Fishing has rarity tiers now and items actually change outcomes, quests track what you do in normal gameplay, and everything feeds into the same system instead of being separate commands. I also made the characters feel more distinct with better responses and small behavior changes over time, plus added a couple API commands for extra randomness. The hardest part was getting everything to work together cleanly without breaking persistence or Slack command structure as things got more complex. What I’m happiest about is that it finally feels like one connected game instead of a bunch of separate features. :))...
|
1792878661.294996
|
1793742661.294996
|
|
21448
|
ChudBot by @skornuta | Stardance
|
skornuta
|
1
|
0.0
|
1
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-19T18:57:06Z", "hours": 0.0, "multiplier": 2.23, "payout": 1, "blessing": "neutral", "text": "I made a simple Slack chatbot using Python and the Bolt framework that can be run either locally or containerized. The hardest part for me was getting the Slack API permissions and environment variables properly configured, but I’m proud of how lightweight and fast the final setup turned out. To test it out, all you need to do is clone the repo, drop your workspace tokens into a .env file, and spin it up using python or even Docker. I linked the #bot-spam channel, because that is where you can test the bot for yourself!", "repo": "https://github.com/skornuta/slack-chudbot", "demo": "https://hackclub.enterprise.slack.com/archives/C0P5NE354"}]...
|
[{"post_id": 12084, "ts": "202 [{"post_id": 12084, "ts": "2026-06-19T18:36:55Z", "hours": 0.3264, "text": "With an array of commands, ChudBot is the perfect addition to the HackClub slack. I took my commands from my discord bot, and wrote it into a Slack bot! I hope everyone can enjoy this project as much as I did making it."}]...
|
Title: ChudBot by @skornuta | Stardance
Devlogs:
Title: ChudBot by @skornuta | Stardance
Devlogs:
With an array of commands, ChudBot is the perfect addition to the HackClub slack. I took my commands from my discord bot, and wrote it into a Slack bot! I hope everyone can enjoy this project as much as I did making it.
Ships:
I made a simple Slack chatbot using Python and the Bolt framework that can be run either locally or containerized. The hardest part for me was getting the Slack API permissions and environment variables properly configured, but I’m proud of how lightweight and fast the final setup turned out. To test it out, all you need to do is clone the repo, drop your workspace tokens into a .env file, and spin it up using python or even Docker. I linked the #bot-spam channel, because that is where you can test the bot for yourself!...
|
1793220620.965333
|
1793307020.965333
|
|
21463
|
prazzzz by @prazwalroka | Stardance
|
prazwalroka
|
1
|
11.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-01T06:42:01Z", "hours": 11.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "i made a video calling and real time chat app using mern stack i have faces multiple of challenges in hosting because it is my first real time project so backend and frontend databse linking was quite stressfull but i have used ai in many parts which helped me a lot ,those who are using my project can enjoy chatting with proples the caaling procedure is quite not atractive but it was my first project so i am proud of that and i have made ayotube video of this demo https://www.youtube.com/watch?v=DXuS3Huncng&t=3s but the url is chnaged beacuse i want to make make online for many hours so ichange render to vercel or backend and i have used uptime robot", "repo": "https://github.com/Prazwal30/Connectify", "demo": "https://connecttifyyy.netlify.app/"}]...
|
[{"post_id": 19827, "ts": "202 [{"post_id": 19827, "ts": "2026-07-01T06:32:44Z", "hours": 11.1064, "text": "i have completed the video calling app in under 12 hrs"}]...
|
Title: prazzzz by @prazwalroka | Stardance
Devlog Title: prazzzz by @prazwalroka | Stardance
Devlogs:
i have completed the video calling app in under 12 hrs
Ships:
i made a video calling and real time chat app using mern stack i have faces multiple of challenges in hosting because it is my first real time project so backend and frontend databse linking was quite stressfull but i have used ai in many parts which helped me a lot ,those who are using my project can enjoy chatting with proples the caaling procedure is quite not atractive but it was my first project so i am proud of that and i have made ayotube video of this demo https://www.youtube.com/watch?v=DXuS3Huncng&t=3s but the url is chnaged beacuse i want to make make online for many hours so ichange render to vercel or backend and i have used uptime robot...
|
1793245967.2471194
|
1793332367.2471194
|
|
21464
|
OpenCV Gesture Based Online Arcade by @anushkaa | OpenCV Gesture Based Online Arcade by @anushkaa | Stardance...
|
anushkaa
|
1
|
31.0
|
502
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-21T19:22:32Z", "hours": 31.0, "multiplier": 16.45, "payout": 502, "blessing": "neutral", "text": "Built a hand gesture controlled arcade where you play games using just your webcam! Three games: Hand Pong, Space Shooter and Snake, each using a different gesture. Started in Python with OpenCV and MediaPipe, rebuilt in JavaScript so it runs in the browser with no downloads needed. Not the smoothest or best arcade ever but definitely built with a lot of struggle and I’m still working on making it better everyday! Learned both languages from scratch during this project. The hardest part was getting MediaPipe working in the browser, went through four different CDN links before finding one that worked!", "repo": "https://github.com/anushkabasu/gesture-arcade-web", "demo": "https://anushkabasu.github.io/gesture-arcade-web/"}]...
|
[{"post_id": 32453, "ts": "202 [{"post_id": 32453, "ts": "2026-07-21T17:30:33Z", "hours": 0.5886, "text": "Devlog 03 — Fixing, Tuning and Ready to Ship What I Fixed This Session Spent this session purely on debugging and tuning. No new features — just making everything feel right. Snake controls — went through three different control schemes. Tried fist tilt, tried swipe gestures, finally landed on index finger pointing. The snake steers toward wherever your finger is pointing relative to the snake’s head. Tiny finger movements don’t accidentally change direction: const dist = Math . sqrt ( dx * dx + dy * dy ) if ( dist > CELL * 3 ) { } Space Shooter — enemies were spawning too slowly and too late. Fixed spawn timer to start at 999 so enemies appear immediately, and doubled the spawn rate. Waves feel much more intense now. Instructions — Added the instructions page correctly so anyone can click [I] to understand required gestures. Mirror flipping — cursor and menu hover were using inconsistent coordinate systems. Unified everything so palmX is flipped once at the source and all games use the same value. What the Project Is Now A fully browser-based hand gesture arcade with three games: Hand Pong — palm height controls your paddle Space Shooter — palm position aims, pinch fires Snake — point your index finger to steer No downloads. No installs. Just a webcam and a browser. Shipping Pushing to GitHub Pages today. Anyone with a webcam can play instantly at the live URL. Finally ready to ship!"}, {"post_id": 32340, "ts": "2026-07-21T13:26:49Z", "hours": 10.1625, "text": "Devlog 02 - Rebuilding Gesture Arcade for the Web The Big Decision Scrapped the entire Python version and rebuilt from scratch in JavaScript. Python with pygame cannot run in a browser, and without a live demo URL Stardance reviewers can’t try the project. The whole point is gesture control — and that needs a webcam running locally. Only solution was JavaScript. Problem? I had never written it before. Learning JavaScript from Scratch Coming from Python the syntax felt familiar but the logic was completely different. Hardest part was MediaPipe. In Python it’s 2 lines: import mediapipe as mp hands = mp . solutions . hands . Hands () In JavaScript it’s a whole async setup that took me forever to get right: const fs = await FilesetResolver . forVisionTasks ( \" https://cdn.jsdelivr.net/npm/@mediapipe/ [email protected] /wasm \" ) const hl = await HandLandmarker . createFromOptions ( fs , { baseOptions : { modelAssetPath : \" ... \" }, numHands : 1 , runningMode : \" VIDEO \" }) Went through 4 different CDN links before finding one that worked. CORS errors, 404s, wrong module formats — been through everything. Eventually got it working with Skypack. How the Hand Tracking Works Every frame the camera captures an image, MediaPipe finds 21 landmark points on your hand, and I calculate useful values from those points: hand . palmX = ( lm [ 0 ]. x + lm [ 5 ]. x + lm [ 9 ]. x + lm [ 13 ]. x + lm [ 17 ]. x ) / 5 hand . palmY = ( lm [ 0 ]. y + lm [ 5 ]. y + lm [ 9 ]. y + lm [ 13 ]. y + lm [ 17 ]. y ) / 5 const dx = lm [ 4 ]. x - lm [ 8 ]. x const dy = lm [ 4 ]. y - lm [ 8 ]. y hand . pinching = Math . sqrt ( dx * dx + dy * dy ) < 0.07 const up = [ lm [ 8 ]. y < lm [ 6 ]. y , lm [ 12 ]. y < lm [ 10 ]. y , lm [ 16 ]. y < lm [ 14 ]. y , lm [ 20 ]. y < lm [ 18 ]. y ] hand . fist = up . every ( f => ! f ) All 3 games share the same hand object that gets updated every single frame. Bugs I Ran Into Mirror flipping — spent ages debugging why the cursor moved the wrong way. Camera captures a mirrored image so moving right makes x go in the -x direction. Fixed by flipping palmX at the source: hand . palmX = 1 - ( lm [ 0 ]. x + lm [ 5 ]. x + lm [ 9 ]. x + lm [ 13 ]. x + lm [ 17 ]. x ) / 5 CDN failures — MediaPipe’s official CDN kept returning 404. Tried jsdelivr, unpkg, and two others before Skypack worked. Module type errors — JavaScript modules need type=\"module\" on the script tag otherwise imports don’t work at all. What Needs Fixing Next Space Shooter — not enough enemies spawning, waves feel too sparse. AI enemies too aggressive, players can’t score enough Hand Cursor — white circle cursor looks too similar to the pong ball, confusing during gameplay. Needs a better indicator GitHub Pages — need to push everything live so there’s an actual demo URL"}, {"post_id": 24213, "ts": "2026-07-07T17:05:18Z", "hours": 5.6992, "text": "Devlog 2.01 - Building the Web Version of Gesture Arcade What I worked on today Rebuilt the entire Gesture Arcade frontend from Python and Pygame to a fully web-based version using HTML, CSS, and JavaScript! This was a big decision and here’s why I made it… Why I switched from Python -> Web The Python version runs almost perfectly as a desktop app (that’s a lie, I’ve been struggling a bit with one of the games) but cannot be played in a browser! Gesture control requires webcam access which Python/Pygame cannot expose over the internet. A browser version means -> anyone with a webcam can play instantly! An ‘.exe’ limits who can actually try it. This also counts as an extended Python version. So, consider this an improvement on the last version. Here on, I’m going to refine the UI/UX, basic gameplay, better my logs, and finish this in a better error-less manner. Ignore all logs till now, it’s only about to get better! What I built today Retro monospace homepage in HTML/CSS. (Screenshot attached) Integrated MediaPipe Hand Landmarker via JavaScript for real-time hand tracking. Challenges I ran into MediaPipe CDN kept returning 404 errors (went through about 4 different CDN links before finding one that worked) ‘type=“module”’ was required for the import to work correctly. What’s Next Build Hand Pong in JavaScript using HTML5 Canvas(??) Connect hand tracking to paddle movement. Add all 4 games one by one. Host on GitHub Pages for a live URL. Tech Stack HTML + CSS + JavaScript MediaPipe Tasks Vsion 0.10.3. Skypack CDN for module imports."}, {"post_id": 19407, "ts": "2026-06-30T18:35:44Z", "hours": 7.1633, "text": "Snake game added! Finished making the Snake game for the arcade! It’s working, but I don’t think it’s where I want it to be yet. Right now the controls use fist direction, but I’m thinking of switching to palm direction instead because I feel like it’d be more smooth to play. I also haven’t fully figured out optimizing for different screen sizes yet, and the grid still needs some work so gameplay feels more consistent across displays. Visually, I want to tweak the snake design a bit too and make it feel less placeholder and more polished. Still a bunch of things to improve, but honestly every game has been teaching me something new and I’m slowly figuring things out as I go :)"}, {"post_id": 14288, "ts": "2026-06-23T10:51:09Z", "hours": 3.1236, "text": "Small Update - I’m sort of done making Pong! The paddle on your side is controlled by how far or low you position your palm in front of the camera. It definitely doesn’t work as well as I want it to yet 😭🙏 but getting the basic gameplay running feels like a milestone! Right now I’m trying to improve responsiveness, fix weird behavior, and generally figure out as I go. Still lots to improve, but one game down and have learnt a ton. :D"}, {"post_id": 13831, "ts": "2026-06-22T17:43:08Z", "hours": 3.9269, "text": "OpenCV Hand Gesture Controlled Gaming Arcade 🎮 Hi! I’m currently building a hand gesture controlled gaming arcade using OpenCV! I’m still pretty new to programming, so this project doesn’t involve a lot of fancy or advanced programming, I’m using it as a way to learn and understand Python. I’ve been reading a lot of documentation, experimenting, failing, and debugging, more than I’d like to admit. To help plan everything out, I also made a simple flowchart to map the project structure and workflow. I’ve attached it as an image. The current plan is to include these four games: Hand Pong Fruit Ninja Space Shooter Snake Here’s the homepage I’ve made. Along with a popup instructions panel. If anyone has suggestions on libraries/ references I should use, please let me know."}]...
|
Title: OpenCV Gesture Based Online Arcade by @anus Title: OpenCV Gesture Based Online Arcade by @anushkaa | Stardance
Devlogs:
OpenCV Hand Gesture Controlled Gaming Arcade 🎮 Hi! I’m currently building a hand gesture controlled gaming arcade using OpenCV! I’m still pretty new to programming, so this project doesn’t involve a lot of fancy or advanced programming, I’m using it as a way to learn and understand Python. I’ve been reading a lot of documentation, experimenting, failing, and debugging, more than I’d like to admit. To help plan everything out, I also made a simple flowchart to map the project structure and workflow. I’ve attached it as an image. The current plan is to include these four games: Hand Pong Fruit Ninja Space Shooter Snake Here’s the homepage I’ve made. Along with a popup instructions panel. If anyone has suggestions on libraries/ references I should use, please let me know.
Small Update - I’m sort of done making Pong! The paddle on your side is controlled by how far or low you position your palm in front of the camera. It definitely doesn’t work as well as I want it to yet 😭🙏 but getting the basic gameplay running feels like a milestone! Right now I’m trying to improve responsiveness, fix weird behavior, and generally figure out as I go. Still lots to improve, but one game down and have learnt a ton. :D
Snake game added! Finished making the Snake game for the arcade! It’s working, but I don’t think it’s where I want it to be yet. Right now the controls use fist direction, but I’m thinking of switching to palm direction instead because I feel like it’d be more smooth to play. I also haven’t fully figured out optimizing for different screen sizes yet, and the grid still needs some work so gameplay feels more consistent across displays. Visually, I want to tweak the snake design a bit too and make it feel less placeholder and more polished. Still a bunch of things to improve, but honestly every game has been teaching me something new and I’m slowly figuring things out as I go :)
Devlog 2.01 - Building the Web Version of Gesture Arcade What I worked on today Rebuilt the entire Gesture Arcade frontend from Python and Pygame to a fully web-based version using HTML, CSS, and JavaScript! This was a big decision and here’s why I made it… Why I switched from Python -> Web The Python version runs almost perfectly as a desktop app (that’s a lie, I’ve been struggling a bit with one of the games) but cannot be played in a browser! Gesture control requires webcam access which Python/Pygame cannot expose over the internet. A browser version means -> anyone with a webcam can play instantly! An ‘.exe’ limits who can actually try it. This also counts as an extended Python version. So, consider this an improvement on the last version. Here on, I’m going to refine the UI/UX, basic gameplay, better my logs, and finish this in a better error-less manner. Ignore all logs till now, it’s only about to get better! What I built today Retro monospace homepage in HTML/CSS. (Screenshot attached) Integrated MediaPipe Hand Landmarker via JavaScript for real-time hand tracking. Challenges I ran into MediaPipe CDN kept returning 404 errors (went through about 4 different CDN links before finding one that worked) ‘type=“module”’ was required for the import to work correctly. What’s Next Build Hand Pong in JavaScript using HTML5 Canvas(??) Connect hand tracking to paddle movement. Add all 4 games one by one. Host on GitHub Pages for a live URL. Tech Stack HTML + CSS + JavaScript MediaPipe Tasks Vsion 0.10.3. Skypack CDN for module imports.
Devlog 02 - Rebuilding Gesture Arcade for the Web The Big Decision Scrapped the entire Python version and rebuilt from scratch in JavaScript. Python with pygame cannot run in a browser, and without a live demo URL Stardance reviewers can’t try the project. The whole point is gesture control — and that needs a webcam running locally. Only solution was JavaScript. Problem? I had never written it before. Learning JavaScript from Scratch Coming from Python the syntax felt familiar but the logic was completely different. Hardest part was MediaPipe. In Python it’s 2 lines: import mediapipe as mp hands = mp . solutions . hands . Hands () In JavaScript it’s a whole async setup that took me forever to get right: const fs = await FilesetResolver . forVisionTasks ( " https://cdn.jsdelivr.net/npm/@mediapipe/ [email protected] /wasm " ) const hl = await HandLandmarker . createFromOptions ( fs , { baseOptions : { modelAssetPath : " ... " }, numHands : 1 , runningMode : " VIDEO " }) Went through 4 different CDN links before finding one that worked. CORS errors, 404s, wrong module formats — been through everything. Eventually got it working with Skypack. How the Hand Tracking Works Every frame the camera captures an image, MediaPipe finds 21 landmark points on your hand, and I calculate useful values from those points: hand . palmX = ( lm [ 0 ]. x + lm [ 5 ]. x + lm [ 9 ]. x + lm [ 13 ]. x + lm [ 17 ]. x ) / 5 hand . palmY = ( lm [ 0 ]. y + lm [ 5 ]. y + lm [ 9 ]. y + lm [ 13 ]. y + lm [ 17 ]. y ) / 5 const dx = lm [ 4 ]. x - lm [ 8 ]. x const dy = lm [ 4 ]. y - lm [ 8 ]. y hand . pinching = Math . sqrt ( dx * dx + dy * dy ) < 0.07 const up = [ lm [ 8 ]. y < lm [ 6 ]. y , lm [ 12 ]. y < lm [ 10 ]. y , lm [ 16 ]. y < lm [ 14 ]. y , lm [ 20 ]. y < lm [ 18 ]. y ] hand . fist = up . every ( f => ! f ) All 3 games share the same hand object that gets updated every single frame. Bugs I Ran Into Mirror flipping — spent ages debugging why the cursor moved the wrong way. Camera captures a mirrored image so moving right makes x go in the -x direction. Fixed by flipping palmX at the source: hand . palmX = 1 - ( lm [ 0 ]. x + lm [ 5 ]. x + lm [ 9 ]. x + lm [ 13 ]. x + lm [ 17 ]. x ) / 5 CDN failures — MediaPipe’s official CDN kept returning 404. Tried jsdelivr, unpkg, and two others before Skypack worked. Module type errors — JavaScript modules need type="module" on the script tag otherwise imports don’t work at all. What Needs Fixing Next Space Shooter — not enough enemies spawning, waves feel too sparse. AI enemies too aggressive, players can’t score enough Hand Cursor — white circle cursor looks too similar to the pong ball, confusing during gameplay. Needs a better indicator GitHub Pages — need to push everything live so there’s an actual demo URL
Devlog 03 — Fixing, Tuning and Ready to Ship What I Fixed This Session Spent this session purely on debugging and tuning. No new features — just making everything feel right. Snake controls — went through three different control schemes. Tried fist tilt, tried swipe gestures, finally landed on index finger pointing. The snake steers toward wherever your finger is pointing relative to the snake’s head. Tiny finger movements don’t accidentally change direction: const dist = Math . sqrt ( dx * dx + dy * dy ) if ( dist > CELL * 3 ) { } Space Shooter — enemies were spawning too slowly and too late. Fixed spawn timer to start at 999 so enemies appear immediately, and doubled the spawn rate. Waves feel much more intense now. Instructions — Added the instructions page correctly so anyone can click [I] to understand required gestures. Mirror flipping — cursor and menu hover were using inconsistent coordinate systems. Unified everything so palmX is flipped once at the source and all games use the same value. What the Project Is Now A fully browser-based hand gesture arcade with three games: Hand Pong — palm height controls your paddle Space Shooter — palm position aims, pinch fires Snake — point your index finger to steer No downloads. No installs. Just a webcam and a browser. Shipping Pushing to GitHub Pages today. Anyone with a webcam can play instantly at the live URL. Finally ready to ship!
Ships:
Built a hand gesture controlled arcade where you play games using just your webcam! Three games: Hand Pong, Space Shooter and Snake, each using a different gesture. Started in Python with OpenCV and MediaPipe, rebuilt in JavaScript so it runs in the browser with no downloads needed. Not the smoothest or best arcade ever but definitely built with a lot of struggle and I’m still working on making it better everyday! Learned both languages from scratch during this project. The hardest part was getting MediaPipe working in the browser, went through four different CDN links before finding one that worked!...
|
1793127056.8839183
|
1793213456.8839183
|
|
21500
|
HCR2 Setups Guide by @Alloy | Stardance
|
Alloy
|
1
|
63.0
|
846
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-25T11:58:58Z", "hours": 63.0, "multiplier": 13.44, "payout": 846, "blessing": "neutral", "text": "I made a web based information app that shows setups for each vehicle and track combination in the time attack game mode of Hill Climb Racing 2 (HCR2). The hardest thing was all of the queries for specific statistics, and since some of them also filtered by world records I just made a function to make world record queries cleaner and less messy. A second major problem was the filters on the search page, at the start were just simple select elements but they only take one value so the user can’t filter by more than one of each at once, to fix this I wanted to add a checkbox to each option but selects don’t support that so I needed to break my entire css by switching to details elements and restyling them so they stack nicely like the select elements before.", "repo": "https://github.com/Alloy-MVP/HCR2-Setups-Guide", "demo": "https://frenchtoast.pythonanywhere.com/"}]...
|
[{"post_id": 73537, "ts": "202 [{"post_id": 73537, "ts": "2026-09-25T10:57:09Z", "hours": 0.8028, "text": "FINAL DEVLOG: Added the new parts; Echo and Amplifier, added another part slot, increasing it to 4 since all world records use 4 parts now instead of 3. Took 4 hours to insert the world record setups (only all vehicle world records) for all 197 tracks as of 25/9/2026."}, {"post_id": 73425, "ts": "2026-09-25T02:03:28Z", "hours": 4.7644, "text": "Fixed a bug where inserting setups with a negative number were getting through because they are the only inputs not validated by sqlalchemy. Changed the validation to use the database data instead of the lists at the top of the .py, and therefore also added every single vehicle, part, and track to replace it in the db. Installed pylint to help my code look cleaner and changed everything it was complaining about. Also cleared the database so its empty and added all of the in game tracks and vehicles to replace the test data."}, {"post_id": 52034, "ts": "2026-08-22T02:16:53Z", "hours": 2.0461, "text": "Changed the tuning parts on setups and search page to icons, reversed the order of setups on the setups page so recently added ones are shown at the top, added a max time limit (32 bit integer limit). Tons of bug fixes: the search filters now handle more than one value, checking “World Records” doesnt wipe other filters, filters arent wiped when the page reloads after searching for a setup, rows per page defaults to 50, fixed the settings returning the error statement if rows per page is empty."}, {"post_id": 51494, "ts": "2026-08-21T07:31:36Z", "hours": 0.7431, "text": "Small tweak to the backend validation for the settings inputs, database path is now relative instead of absolute, added a second SQLAlchemy error catcher on top of the python ones, removed the .venv so a new one is made when the repository is cloned. (now it should be runable)"}, {"post_id": 51359, "ts": "2026-08-20T23:45:02Z", "hours": 0.8308, "text": "Changed most of the lists to now use list comprehension, made the error handler handle every error code from 400 to 599. Updated the error page to not break the flow. The app is now fully runable (hopefully) with instructions on the readme."}, {"post_id": 50800, "ts": "2026-08-20T06:19:49Z", "hours": 2.0058, "text": "Added a clear filters button to the insert form, added a shadow to the home page title. Changed the backend for time to not allow times > 32 bit int limit, changed the rows per page setting to be able to type custom amounts while still suggesting 5,10,20,30,40,50 with back end validation. Added a small section in information about insert field parameters. The setups table order is now reversed so new inserts are shown at the top. Settings errors are now shown on pages. Cleaned up some backend validation, the error messages now dont show for empty fields, created a requrements.txt and a readme on how to run the app."}, {"post_id": 49273, "ts": "2026-08-17T23:45:16Z", "hours": 0.8703, "text": "Added a 404 error handler and images of tuning parts to replace the text."}, {"post_id": 47929, "ts": "2026-08-16T06:12:15Z", "hours": 3.1731, "text": "Finished most of the home page, added a information section with a video, added 3 containers with quick navigation links, statistics, and fastest times on the home page, also added a background."}, {"post_id": 47790, "ts": "2026-08-15T23:28:52Z", "hours": 1.8481, "text": "Made the button borders brighter to be more visible, changed the content backgrounds to a gradient. Changed the setups table to look identical to search. Added a delete button to the all setups table to easily delete specific setups."}, {"post_id": 47320, "ts": "2026-08-15T06:19:10Z", "hours": 4.9217, "text": "Big Update: Moved links to the right and added a settings menu, added a title, made all inputs and filters have hover effects. Settings menu has a toggle for light/dark theme, and a way to select how many rows are shown in all tables (default is 10). Changed all of the css colors to variables for the settings."}, {"post_id": 46610, "ts": "2026-08-13T23:34:27Z", "hours": 2.1578, "text": "Search bar now fully supports searching for more than one word."}, {"post_id": 45471, "ts": "2026-08-11T23:30:33Z", "hours": 1.6261, "text": "The player, vehicle, and track filters can all take more than one filter so the search page can now show results from multiple players, vehicles, and tracks."}, {"post_id": 43698, "ts": "2026-08-09T03:15:24Z", "hours": 2.5139, "text": "Revamped the css again, the insert and delete forms are being moved to the setups table. No screenshot until the next devlog because its a mess right now."}, {"post_id": 43069, "ts": "2026-08-08T04:14:05Z", "hours": 1.5303, "text": "Added a leaderboard for the most used part setups, Changed how the parts are submitted, they are now sorted so there cant be multiple setups of the same parts combination but different orders, duplicates will just reuse an already existing one."}, {"post_id": 42928, "ts": "2026-08-07T22:11:58Z", "hours": 2.7381, "text": "Added a script that counts how many wrs every single player has and displays on the leaderboard page. Made the player field autoselect a name if you type it with wrong capitalization, for example ndwg will autoswitch to Ndwg."}, {"post_id": 39258, "ts": "2026-08-02T03:35:36Z", "hours": 2.9344, "text": "Completely finished styling the search page, also changed the filters to details instead of select so i can use checkboxes inside."}, {"post_id": 39170, "ts": "2026-08-01T22:55:05Z", "hours": 0.7469, "text": "World records filter is fully finished"}, {"post_id": 38508, "ts": "2026-07-31T22:44:24Z", "hours": 3.4031, "text": "Finished the backend of the wr filter, the fastest time with x vehicle and y track is highlighted in yellow."}, {"post_id": 36188, "ts": "2026-07-28T03:29:06Z", "hours": 1.2111, "text": "Finally found out about back_populates, players that arent currently in a setup now get deleted."}, {"post_id": 35045, "ts": "2026-07-26T06:34:23Z", "hours": 1.4058, "text": "Styled the filters section, added hover styling for links, buttons, and table data."}, {"post_id": 34983, "ts": "2026-07-26T03:54:43Z", "hours": 3.9231, "text": "Completely restarted the css, started styling the search bar filters and navigation bar."}, {"post_id": 29886, "ts": "2026-07-17T01:32:40Z", "hours": 1.055, "text": "Changed the filters to only show players,tracks, and vehicles that actually have a setup. Made the vehicle and track filter setups by time (lowest to highes) so the first time (fastest) is at the top."}, {"post_id": 29282, "ts": "2026-07-16T02:58:34Z", "hours": 0.8175, "text": "Added warnings for invalid filters (changed the values using inspect)"}, {"post_id": 28723, "ts": "2026-07-15T05:01:13Z", "hours": 1.4858, "text": "Made the filter fields functional but are misssing back end validation"}, {"post_id": 26951, "ts": "2026-07-12T01:24:49Z", "hours": 2.71, "text": "Added a stats/search page and moved the search bar there, also added a way to filter by players and vehicles (unfuctional)."}, {"post_id": 21229, "ts": "2026-07-03T02:00:51Z", "hours": 1.4261, "text": "Added a search bar to filter specific setups but still has some bugs (first table is all data, second table is data from the search)"}, {"post_id": 19058, "ts": "2026-06-30T07:43:15Z", "hours": 1.2028, "text": "Made the delete table functional and removes rows from setups but not the sub tables where the individual data is."}, {"post_id": 16718, "ts": "2026-06-27T05:02:23Z", "hours": 2.5661, "text": "Added checks for duplicates, missing fields, and times automatically updates if a time that is faster than the previous for a specific setup is submitted. Automatically adds the data to the setups table and puts the individual field data into their respective tables as well."}, {"post_id": 15998, "ts": "2026-06-25T23:45:29Z", "hours": 2.5778, "text": "Added some back end validation checks and added a list to check if the track field matches what can actually be inserted, also used a jinja loop to make options for each individual track in the list for the form."}, {"post_id": 14169, "ts": "2026-06-23T04:56:34Z", "hours": 2.9508, "text": "Basic input form for the database if every field is filled and correct"}]...
|
Title: HCR2 Setups Guide by @Alloy | Stardance
De Title: HCR2 Setups Guide by @Alloy | Stardance
Devlogs:
Basic input form for the database if every field is filled and correct
Added some back end validation checks and added a list to check if the track field matches what can actually be inserted, also used a jinja loop to make options for each individual track in the list for the form.
Added checks for duplicates, missing fields, and times automatically updates if a time that is faster than the previous for a specific setup is submitted. Automatically adds the data to the setups table and puts the individual field data into their respective tables as well.
Made the delete table functional and removes rows from setups but not the sub tables where the individual data is.
Added a search bar to filter specific setups but still has some bugs (first table is all data, second table is data from the search)
Added a stats/search page and moved the search bar there, also added a way to filter by players and vehicles (unfuctional).
Made the filter fields functional but are misssing back end validation
Added warnings for invalid filters (changed the values using inspect)
Changed the filters to only show players,tracks, and vehicles that actually have a setup. Made the vehicle and track filter setups by time (lowest to highes) so the first time (fastest) is at the top.
Completely restarted the css, started styling the search bar filters and navigation bar.
Styled the filters section, added hover styling for links, buttons, and table data.
Finally found out about back_populates, players that arent currently in a setup now get deleted.
Finished the backend of the wr filter, the fastest time with x vehicle and y track is highlighted in yellow.
World records filter is fully finished
Completely finished styling the search page, also changed the filters to details instead of select so i can use checkboxes inside.
Added a script that counts how many wrs every single player has and displays on the leaderboard page. Made the player field autoselect a name if you type it with wrong capitalization, for example ndwg will autoswitch to Ndwg.
Added a leaderboard for the most used part setups, Changed how the parts are submitted, they are now sorted so there cant be multiple setups of the same parts combination but different orders, duplicates will just reuse an already existing one.
Revamped the css again, the insert and delete forms are being moved to the setups table. No screenshot until the next devlog because its a mess right now.
The player, vehicle, and track filters can all take more than one filter so the search page can now show results from multiple players, vehicles, and tracks.
Search bar now fully supports searching for more than one word.
Big Update: Moved links to the right and added a settings menu, added a title, made all inputs and filters have hover effects. Settings menu has a toggle for light/dark theme, and a way to select how many rows are shown in all tables (default is 10). Changed all of the css colors to variables for the settings.
Made the button borders brighter to be more visible, changed the content backgrounds to a gradient. Changed the setups table to look identical to search. Added a delete button to the all setups table to easily delete specific setups.
Finished most of the home page, added a information section with a video, added 3 containers with quick navigation links, statistics, and fastest times on the home page, also added a background.
Added a 404 error handler and images of tuning parts to replace the text.
Added a clear filters button to the insert form, added a shadow to the home page title. Changed the backend for time to not allow times > 32 bit int limit, changed the rows per page setting to be able to type custom amounts while still suggesting 5,10,20,30,40,50 with back end validation. Added a small section in information about insert field parameters. The setups table order is now reversed so new inserts are shown at the top. Settings errors are now shown on pages. Cleaned up some backend validation, the error messages now dont show for empty fields, created a requrements.txt and a readme on how to run the app.
Changed most of the lists to now use list comprehension, made the error handler handle every error code from 400 to 599. Updated the error page to not break the flow. The app is now fully runable (hopefully) with instructions on the readme.
Small tweak to the backend validation for the settings inputs, database path is now relative instead of absolute, added a second SQLAlchemy error catcher on top of the python ones, removed the .venv so a new one is made when the repository is cloned. (now it should be runable)
Changed the tuning parts on setups and search page to icons, reversed the order of setups on the setups page so recently added ones are shown at the top, added a max time limit (32 bit integer limit). Tons of bug fixes: the search filters now handle more than one value, checking “World Records” doesnt wipe other filters, filters arent wiped when the page reloads after searching for a setup, rows per page defaults to 50, fixed the settings returning the error statement if rows per page is empty.
Fixed a bug where inserting setups with a negative number were getting through because they are the only inputs not validated by sqlalchemy. Changed the validation to use the database data instead of the lists at the top of the .py, and therefore also added every single vehicle, part, and track to replace it in the db. Installed pylint to help my code look cleaner and changed everything it was complaining about. Also cleared the database so its empty and added all of the in game tracks and vehicles to replace the test data.
FINAL DEVLOG: Added the new parts; Echo and Amplifier, added another part slot, increasing it to 4 since all world records use 4 parts now instead of 3. Took 4 hours to insert the world record setups (only all vehicle world records) for all 197 tracks as of 25/9/2026.
Ships:
I made a web based information app that shows setups for each vehicle and track combination in the time attack game mode of Hill Climb Racing 2 (HCR2). The hardest thing was all of the queries for specific statistics, and since some of them also filtered by world records I just made a function to make world record queries cleaner and less messy. A second major problem was the filters on the search page, at the start were just simple select elements but they only take one value so the user can’t filter by more than one of each at once, to fix this I wanted to add a checkbox to each option but selects don’t support that so I needed to break my entire css by switching to details elements and restyling them so they stack nicely like the select elements before....
|
1793152584.3327835
|
1793238984.3327835
|
|
21501
|
Nicholas' OS by @nicholas1023 | Stardance
|
nicholas1023
|
1
|
7.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-23T03:52:32Z", "hours": 7.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a web-based OS that includes a panel with a clock and power off button, a file viewer, a terminal version of my personal website, and a web app installer that allows you to install websites that are not web app as well. The most challenging part was the web app installer as I needed to develop the logic to integrate the website as an app and allow them to have a top bar as well. I was quite surprised with the result, as it was able to make a website look like a native app (In fact, the terminal is a web app!) and the power off button made it really look like a real low level OS running on a computer. One thing to note is that the installer is not able to launch sites that disallow 3rd party embedding.", "repo": "https://github.com/Nicholas1023/Nicholas-OS", "demo": "https://nicholas1023.github.io/Nicholas-OS/"}]...
|
[{"post_id": 14133, "ts": "202 [{"post_id": 14133, "ts": "2026-06-23T03:35:05Z", "hours": 2.4094, "text": "New app installer for my OS! In this devlog, I have created an app installer that installs a website as an app, much like how a web app works. However, this function only works for URLs that allow embedding. I have also solved a bug where apps dragged past the viewport creates a scrollable viewport by adding this: overflow-y : hidden ; overflow-x : hidden ; I’ll be shipping it soon! Try my OS out at https://nicholas1023.github.io/Nicholas-OS/ ! Here’s a demo video of the installer installing hackclub.com as an app!"}, {"post_id": 13649, "ts": "2026-06-22T12:24:39Z", "hours": 2.3744, "text": "Added new apps to my OS! I’ve added a file viewer and terminal app to my operating system! What’s new? Window dragging finally works! Windows are able to move to the front! Problems I’ve faced I had issues making a window come to the front when clicked or move. Initially, I was using .style.zIndex++ , but it did not seem to work when a window was clicked multiple times. To solve this, I changed all the z-index of all windows when one is clicked, to ensure all of the values sync. The buttons on the top bar are currently text-based, so I’ll be creating icons for them, and to declutter the buttons top bar on apps."}, {"post_id": 13528, "ts": "2026-06-22T04:24:03Z", "hours": 2.0283, "text": "Finished the windowing system and a bottom panel! What’s new Loading screen Windows with maximise, minimise and close buttons Bottom panel with time and power off button What I’ll be working on next Next, I will be making the windows draggable, and creating icons for the apps. I’ll also be improving the loading screen, which currently only consists of the following code. <div id= \"boot\" > <div style= \"text-align: center;\" > <h1> Nicholas' Operating System </h1> <p id= \"loading\" > Loading... </p> </div> </div> Problems I faced When creating the window functions, which manages maximise, minimise and close buttons, it did not seem to work. I realised later that the function name was actually overwriting a built-in function as it was initially named close() ! In the end I renamed it to closeW() , where W stands for window. I also faced issues with the height of the <main> . Initially, the height of main was set to 100% , which failed to work. After some searches online, I tried replacing 100% with 100dvh , which worked perfectly!"}]...
|
Title: Nicholas' OS by @nicholas1023 | Stardan Title: Nicholas' OS by @nicholas1023 | Stardance
Devlogs:
Finished the windowing system and a bottom panel! What’s new Loading screen Windows with maximise, minimise and close buttons Bottom panel with time and power off button What I’ll be working on next Next, I will be making the windows draggable, and creating icons for the apps. I’ll also be improving the loading screen, which currently only consists of the following code. <div id= "boot" > <div style= "text-align: center;" > <h1> Nicholas' Operating System </h1> <p id= "loading" > Loading... </p> </div> </div> Problems I faced When creating the window functions, which manages maximise, minimise and close buttons, it did not seem to work. I realised later that the function name was actually overwriting a built-in function as it was initially named close() ! In the end I renamed it to closeW() , where W stands for window. I also faced issues with the height of the <main> . Initially, the height of main was set to 100% , which failed to work. After some searches online, I tried replacing 100% with 100dvh , which worked perfectly!
Added new apps to my OS! I’ve added a file viewer and terminal app to my operating system! What’s new? Window dragging finally works! Windows are able to move to the front! Problems I’ve faced I had issues making a window come to the front when clicked or move. Initially, I was using .style.zIndex++ , but it did not seem to work when a window was clicked multiple times. To solve this, I changed all the z-index of all windows when one is clicked, to ensure all of the values sync. The buttons on the top bar are currently text-based, so I’ll be creating icons for them, and to declutter the buttons top bar on apps.
New app installer for my OS! In this devlog, I have created an app installer that installs a website as an app, much like how a web app works. However, this function only works for URLs that allow embedding. I have also solved a bug where apps dragged past the viewport creates a scrollable viewport by adding this: overflow-y : hidden ; overflow-x : hidden ; I’ll be shipping it soon! Try my OS out at https://nicholas1023.github.io/Nicholas-OS/ ! Here’s a demo video of the installer installing hackclub.com as an app!
Ships:
I made a web-based OS that includes a panel with a clock and power off button, a file viewer, a terminal version of my personal website, and a web app installer that allows you to install websites that are not web app as well. The most challenging part was the web app installer as I needed to develop the logic to integrate the website as an app and allow them to have a top bar as well. I was quite surprised with the result, as it was able to make a website look like a native app (In fact, the terminal is a web app!) and the power off button made it really look like a real low level OS running on a computer. One thing to note is that the installer is not able to launch sites that disallow 3rd party embedding....
|
1793292546.174636
|
1793378946.174636
|
|
21505
|
Kotlin bus tracker wrapper by @Marios | Stardance
|
Marios
|
1
|
20.04
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T08:59:17Z", "hours": 5.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I built a wrapper for a local bus tracking api that provides some quality of life features that allows for easy interop between kotlin apps and it. The challenging part was that it was my first kotlin library and a while since I messed with java/intellij/kotlin. I used for the first time KTOR and it was a really interesting experience. Type-safe requests are really amazing and quite a bit superior to the other coding languages a libraries I used to interop with. I’m proud of how seamlessly I was able to use it - you can test it by implementing the maven central library linked", "repo": "https://github.com/GalaxyGamingBoy/kt-bus", "demo": "https://central.sonatype.com/artifact/io.gitlab.mitsiosm/oseth"}]...
|
[{"post_id": 32901, "ts": "202 [{"post_id": 32901, "ts": "2026-07-22T11:16:00Z", "hours": 6.0169, "text": "Working on the v2 version of the API, it will have OpenData support and syncing capabilities. Now all of the data will be internal to a database and allow users to custom insert their own routes/trips/schedules. That way it allows for easier access. Unfortunately with this comes the deprecation of the older API specifications but the newer one seems cleaner."}, {"post_id": 16291, "ts": "2026-06-26T14:29:51Z", "hours": 9.0183, "text": "Woah, more changes since the last devlog, and many helpful ones. In my attempt to provide a more developer friendly library, I switched from using the API to using saved data. The tldr is that after a bit of research, I was able to find an official GTFS (General Transit Feed Specification) from the transit entity under my gov’s opendata platform. As such, I am beginning the process of an automated migration of those data to an internal library database. Furthermore, i fundamentally reworked the library to use multiplatform compose - and as such support to many platforms."}, {"post_id": 11173, "ts": "2026-06-18T08:31:29Z", "hours": 5.4889, "text": "Finished iteration v1.0 of the bus tracking api with a tracker using kotlin coroutines and channels"}]...
|
Title: Kotlin bus tracker wrapper by @Marios | Sta Title: Kotlin bus tracker wrapper by @Marios | Stardance
Devlogs:
Finished iteration v1.0 of the bus tracking api with a tracker using kotlin coroutines and channels
Woah, more changes since the last devlog, and many helpful ones. In my attempt to provide a more developer friendly library, I switched from using the API to using saved data. The tldr is that after a bit of research, I was able to find an official GTFS (General Transit Feed Specification) from the transit entity under my gov’s opendata platform. As such, I am beginning the process of an automated migration of those data to an internal library database. Furthermore, i fundamentally reworked the library to use multiplatform compose - and as such support to many platforms.
Working on the v2 version of the API, it will have OpenData support and syncing capabilities. Now all of the data will be internal to a database and allow users to custom insert their own routes/trips/schedules. That way it allows for easier access. Unfortunately with this comes the deprecation of the older API specifications but the newer one seems cleaner.
Ships:
I built a wrapper for a local bus tracking api that provides some quality of life features that allows for easy interop between kotlin apps and it. The challenging part was that it was my first kotlin library and a while since I messed with java/intellij/kotlin. I used for the first time KTOR and it was a really interesting experience. Type-safe requests are really amazing and quite a bit superior to the other coding languages a libraries I used to interop with. I’m proud of how seamlessly I was able to use it - you can test it by implementing the maven central library linked...
|
1793289388.2779074
|
1793375788.2779074
|
|
21510
|
AI Roaster by @brijeshkumar724282 | Stardance
|
brijeshkumar724282
|
1
|
5.21
|
22
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-19T14:22:57Z", "hours": 4.0, "multiplier": 5.98, "payout": 22, "blessing": "neutral", "text": "I made an AI chatbot website where users send something about themselves and the AI will roast the user. Basically the most challenging part was that my project was working fine in the local server but when I hosted it, It only showed HTML structure. I am proud that even after many errors, i tried my best to not quit. Prople should know how to type to test my project :).", "repo": "https://github.com/brijeshkumar724282-beep/RoasterAI", "demo": "https://roaster-ai-xzi9.vercel.app/"}]...
|
[{"post_id": 12957, "ts": "202 [{"post_id": 12957, "ts": "2026-06-21T06:32:11Z", "hours": 0.4192, "text": "I tried many AI and my best but I couldn’t solve the error, So I rolled back to the previous version :( but don’t worry, In future I think I would try to fix it!"}, {"post_id": 12931, "ts": "2026-06-21T05:15:21Z", "hours": 0.4386, "text": "so, my website was so inconsistent, I came to an conclusion that the model I was using had rate limits and all. I had to purchase AI credits with my money and it worked, but the thing was that users can exploit the AI credits by using it massively or something, So then I added rate limits of 20 requests per IP address. The site worked well when i was testing it locally but it crashed when I hosted it to vercel. I think i might need more time to fix this bug."}, {"post_id": 12416, "ts": "2026-06-20T08:12:59Z", "hours": 0.3497, "text": "I had to change the AI model, free AI models were having rate limit issues, so i had to use a paid one. It’s working fine now! you can check it out."}, {"post_id": 11942, "ts": "2026-06-19T14:06:14Z", "hours": 0.9728, "text": "Tracked down why the website was working fine and not working when deployed. The main change was to make the app serve static assets correctly from the origin. The website is live now!"}, {"post_id": 11830, "ts": "2026-06-19T08:26:23Z", "hours": 1.4083, "text": "Again changed thee UI to classy and elegant look, i don’t think i would change again.Added mouse follower and mouse magnet (they look cool!). I was trying to host it for testing but i was getting and error. I have to work a little more on the front end then i will more to the back end error solving."}, {"post_id": 11394, "ts": "2026-06-18T17:30:53Z", "hours": 0.3628, "text": "integrated AI api for roast and Testing it :)"}, {"post_id": 11329, "ts": "2026-06-18T15:15:03Z", "hours": 0.7231, "text": "Didn’t liked the ui of the last one, so I changed the UI and added chat system (just the frontend testing part)."}, {"post_id": 11222, "ts": "2026-06-18T11:25:17Z", "hours": 0.35, "text": "I am working on the front end part, i have made two cards for input and output and a header."}]...
|
Title: AI Roaster by @brijeshkumar724282 | Stardan Title: AI Roaster by @brijeshkumar724282 | Stardance
Devlogs:
I am working on the front end part, i have made two cards for input and output and a header.
Didn’t liked the ui of the last one, so I changed the UI and added chat system (just the frontend testing part).
integrated AI api for roast and Testing it :)
Again changed thee UI to classy and elegant look, i don’t think i would change again.Added mouse follower and mouse magnet (they look cool!). I was trying to host it for testing but i was getting and error. I have to work a little more on the front end then i will more to the back end error solving.
Tracked down why the website was working fine and not working when deployed. The main change was to make the app serve static assets correctly from the origin. The website is live now!
I had to change the AI model, free AI models were having rate limit issues, so i had to use a paid one. It’s working fine now! you can check it out.
so, my website was so inconsistent, I came to an conclusion that the model I was using had rate limits and all. I had to purchase AI credits with my money and it worked, but the thing was that users can exploit the AI credits by using it massively or something, So then I added rate limits of 20 requests per IP address. The site worked well when i was testing it locally but it crashed when I hosted it to vercel. I think i might need more time to fix this bug.
I tried many AI and my best but I couldn’t solve the error, So I rolled back to the previous version :( but don’t worry, In future I think I would try to fix it!
Ships:
I made an AI chatbot website where users send something about themselves and the AI will roast the user. Basically the most challenging part was that my project was working fine in the local server but when I hosted it, It only showed HTML structure. I am proud that even after many errors, i tried my best to not quit. Prople should know how to type to test my project :)....
|
1793134277.9722233
|
1793220677.9722233
|
|
21514
|
3D Sniper by @Ettihad | Stardance
|
Ettihad
|
1
|
0.0
|
1
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-18T19:36:21Z", "hours": 0.0, "multiplier": 2.15, "payout": 1, "blessing": "neutral", "text": "Step into the future of browser gaming! 3D Shooter is an immersive, high-octane 3D target arcade built on state-of-the-art Web Computer Vision (CV). Use your webcam to turn your actual index finger into a laser cannon, or swap back to a high-speed mouse configuration for classic click-and-destroy action. Blast glowing cosmic targets, beat the countdown, and dominate the leaderboard! 🚀 Why You’ll Love 3D Shooter : No Equipment Needed: Zero expensive VR/AR gear required. Just your device’s standard webcam and any clear background. Insanely Responsive Control: Features advanced AI hand-joint smoothing to filter out micro-shakes, ensuring highly responsive and satisfying drift-free tracking. Immersive Arcade Vibe: Clean, cyberpunk modern aesthetics with crisp typography, glowing neon laser trails, dynamic sound cues, and exploding target particle systems. Dual-Input Freedom: Swap seamlessly between futuristic hand-gesture tracking and lightning-fast classic mouse aim on the fly. 🎮 Core Game Modes: Whether you have 30 seconds or want a prolonged survival run, there is a gameplay mode tailored for you: Instant Shooting The perfect warm-up arena! Blast popping targets as rapidly as they appear and study target trajectories with no ticking countdown. 60s Time Attack An action-packed race against the clock. Blast as many targets as possible inside a tense 60-second limit. Accuracy and sheer hand speed are key. Time Survival (Ultimate Challenge): Survival of the quickest. You start with a ticking clock; successfully hitting targets rewards you with extra seconds, while missing targets drains precious seconds. How long can you survive the heat? 🔍 How It Works (The Functions): Tip Tracking: The computer vision engine targets the floating crosshair directly over your index finger tip (Landmark 8) for natural 1:1 aiming. The Firing Pinch: Ready to blast? Simply pinch your index finger and thumb together in a quick motion, then release to fire a laser shot! Global Leaderboards: Log your custom Ranger name locally to log high scores, view historic accuracy statistics, and track your aiming improvement over multiple sessions. Custom Calibration: Built-in tracker HUD shows real-time tracking FPS, camera quality status, and aiming sensitivity controls (Responsive, Balanced, Classic) right in the options panel.", "repo": "https://github.com/Ettihad/3D-Sniper", "demo": "https://service-3d-shooter-336798175667.asia-southeast1.run.app"}]...
|
[{"post_id": 11483, "ts": "202 [{"post_id": 11483, "ts": "2026-06-18T19:18:04Z", "hours": 0.2531, "text": "First time writing a devlog. So I made a 3D Shooting game which uses camera detection. One day I was scrolling and found this reel about hand tracking. So I decided to make a game out of it. I got to work, spending a lot of time on this game. Basically all you do is use your index to aim and pinch index and thumb to shoot. I hope you all have fun playing it as it’s my first project :) You can try it out here: https://service-3d-shooter-336798175667.asia-southeast1.run.app"}]...
|
Title: 3D Sniper by @Ettihad | Stardance
Devlogs: Title: 3D Sniper by @Ettihad | Stardance
Devlogs:
First time writing a devlog. So I made a 3D Shooting game which uses camera detection. One day I was scrolling and found this reel about hand tracking. So I decided to make a game out of it. I got to work, spending a lot of time on this game. Basically all you do is use your index to aim and pinch index and thumb to shoot. I hope you all have fun playing it as it’s my first project :) You can try it out here: https://service-3d-shooter-336798175667.asia-southeast1.run.app
Ships:
Step into the future of browser gaming! 3D Shooter is an immersive, high-octane 3D target arcade built on state-of-the-art Web Computer Vision (CV). Use your webcam to turn your actual index finger into a laser cannon, or swap back to a high-speed mouse configuration for classic click-and-destroy action. Blast glowing cosmic targets, beat the countdown, and dominate the leaderboard! 🚀 Why You’ll Love 3D Shooter : No Equipment Needed: Zero expensive VR/AR gear required. Just your device’s standard webcam and any clear background. Insanely Responsive Control: Features advanced AI hand-joint smoothing to filter out micro-shakes, ensuring highly responsive and satisfying drift-free tracking. Immersive Arcade Vibe: Clean, cyberpunk modern aesthetics with crisp typography, glowing neon laser trails, dynamic sound cues, and exploding target particle systems. Dual-Input Freedom: Swap seamlessly between futuristic hand-gesture tracking and lightning-fast classic mouse aim on the fly. 🎮 Core Game Modes: Whether you have 30 seconds or want a prolonged survival run, there is a gameplay mode tailored for you: Instant Shooting The perfect warm-up arena! Blast popping targets as rapidly as they appear and study target trajectories with no ticking countdown. 60s Time Attack An action-packed race against the clock. Blast as many targets as possible inside a tense 60-second limit. Accuracy and sheer hand speed are key. Time Survival (Ultimate Challenge): Survival of the quickest. You start with a ticking clock; successfully hitting targets rewards you with extra seconds, while missing targets drains precious seconds. How long can you survive the heat? 🔍 How It Works (The Functions): Tip Tracking: The computer vision engine targets the floating crosshair directly over your index finger tip (Landmark 8) for natural 1:1 aiming. The Firing Pinch: Ready to blast? Simply pinch your index finger and thumb together in a quick motion, then release to fire a laser shot! Global Leaderboards: Log your custom Ranger name locally to log high scores, view historic accuracy statistics, and track your aiming improvement over multiple sessions. Custom Calibration: Built-in tracker HUD shows real-time tracking FPS, camera quality status, and aiming sensitivity controls (Responsive, Balanced, Classic) right in the options panel....
|
1793296624.285498
|
1793383024.285498
|
|
21532
|
Real OS from scratch solo ( I named it NovaOS ) by Real OS from scratch solo ( I named it NovaOS ) by @tonyx | Stardance...
|
tonyx
|
1
|
0.36
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-19T14:29:13Z", "hours": 0.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "NovaOS is an experimental operating system built from scratch, designed to deeply explore how a full OS works. It includes a custom kernel, hardware drivers, a graphical interface system, a network stack, a file system, and a set of system applications. The project covers the entire stack, from low-level boot processes to the user environment, and is actively evolving with a modular architecture aimed at building a complete, structured, and extensible operating system.", "repo": "https://github.com/Juste1dev/NovaOS", "demo": "https://github.com/Juste1dev/NovaOS/releases/tag/TheOS"}]...
|
[{"post_id": 12498, "ts": "202 [{"post_id": 12498, "ts": "2026-06-20T12:32:43Z", "hours": 0.3558, "text": "Working on the users sessions updating and optimizing"}, {"post_id": 11919, "ts": "2026-06-19T13:07:58Z", "hours": 0.3125, "text": "Working On the web browser adding more tabs and shortcuts"}]...
|
Title: Real OS from scratch solo ( I named it Nova Title: Real OS from scratch solo ( I named it NovaOS ) by @tonyx | Stardance
Devlogs:
Working On the web browser adding more tabs and shortcuts
Working on the users sessions updating and optimizing
Ships:
NovaOS is an experimental operating system built from scratch, designed to deeply explore how a full OS works. It includes a custom kernel, hardware drivers, a graphical interface system, a network stack, a file system, and a set of system applications. The project covers the entire stack, from low-level boot processes to the user environment, and is actively evolving with a modular architecture aimed at building a complete, structured, and extensible operating system....
|
1793278306.2267754
|
1793364706.2267754
|
|
21549
|
MCBot by @Serra00 | Stardance
|
Serra00
|
1
|
16.65
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-08T23:42:33Z", "hours": 8.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made an AI bot that can do various tasks. It was hard to make the player see the other players, since the server was offline and for some reason mineflayer refused to read namelists and locations when server is off. I had fun playing with it for some time, until my game crashed and my save file got corrupted somehow, but it is fun to play with it, especially with friends because you literally have an ai to mine and do the most boring and time consuming tasks.", "repo": "https://github.com/Serra110/mcbot", "demo": "https://github.com/Serra110/mcbot/releases/tag/v1.0.0"}]...
|
[{"post_id": 64101, "ts": "202 [{"post_id": 64101, "ts": "2026-09-08T09:09:20Z", "hours": 7.3094, "text": "Bug fixes, mainly I have: improved AI model to gpt 5.4 mini so it is a lil bit “smarter”, gave also better rules so it doesnt just build a house 100% glass with no door and no tools."}, {"post_id": 46379, "ts": "2026-08-13T15:37:03Z", "hours": 1.3433, "text": "made installation easier for my bot"}, {"post_id": 25029, "ts": "2026-07-08T23:30:55Z", "hours": 3.2044, "text": "I made the bot and it works, i tried finishing it ASAP so i could then lock in for my main project, a game, but it still works really well. it can mine, battle with mobs, follow and other stuff, since it is controlled by an ai and can be made to do something."}, {"post_id": 12199, "ts": "2026-06-19T22:13:49Z", "hours": 3.2828, "text": "I am starting to hate this dumb bot, but oh well, ill try using my mc license for the bot so i can make the server online to see if the bot sees players… i think ill need to buy a new minecraft tho not sure 😭, i tried adding like 4 fallbacks to see if it would follow something, but it only detected itself and decided to follow itself, great idea, yep thats it, at least it says hi very efficiently and fast"}, {"post_id": 11375, "ts": "2026-06-18T16:45:06Z", "hours": 1.6778, "text": "I made the bot itself, instaleld the dependencies, like mineflayer and dotenv, tried running it, had problems with the node version so i needed to install a new version and then it ran! It still doesnt work much, just spawns and says the message that i programmed it to say (i was bored dont judge 😭) lol, oh also it has a weird bug that it crashes whenever it gets damage"}]...
|
Title: MCBot by @Serra00 | Stardance
Devlogs:
I m Title: MCBot by @Serra00 | Stardance
Devlogs:
I made the bot itself, instaleld the dependencies, like mineflayer and dotenv, tried running it, had problems with the node version so i needed to install a new version and then it ran! It still doesnt work much, just spawns and says the message that i programmed it to say (i was bored dont judge 😭) lol, oh also it has a weird bug that it crashes whenever it gets damage
I am starting to hate this dumb bot, but oh well, ill try using my mc license for the bot so i can make the server online to see if the bot sees players… i think ill need to buy a new minecraft tho not sure 😭, i tried adding like 4 fallbacks to see if it would follow something, but it only detected itself and decided to follow itself, great idea, yep thats it, at least it says hi very efficiently and fast
I made the bot and it works, i tried finishing it ASAP so i could then lock in for my main project, a game, but it still works really well. it can mine, battle with mobs, follow and other stuff, since it is controlled by an ai and can be made to do something.
made installation easier for my bot
Bug fixes, mainly I have: improved AI model to gpt 5.4 mini so it is a lil bit “smarter”, gave also better rules so it doesnt just build a house 100% glass with no door and no tools.
Ships:
I made an AI bot that can do various tasks. It was hard to make the player see the other players, since the server was offline and for some reason mineflayer refused to read namelists and locations when server is off. I had fun playing with it for some time, until my game crashed and my save file got corrupted somehow, but it is fun to play with it, especially with friends because you literally have an ai to mine and do the most boring and time consuming tasks....
|
1793296339.4078264
|
1793382739.4078264
|