|
30919
|
White Monster Vending Machine by @techsam12 | Star White Monster Vending Machine by @techsam12 | Stardance...
|
techsam12
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: White Monster Vending Machine by @techsam12 Title: White Monster Vending Machine by @techsam12 | Stardance...
|
1792731053.0976872
|
1793335853.0976872
|
|
4208
|
Slice of a pie - goal tracker by @adwitha | Starda Slice of a pie - goal tracker by @adwitha | Stardance...
|
adwitha
|
0
|
13.14
|
0
|
[]
|
[{"post_id": 47769, "ts": "202 [{"post_id": 47769, "ts": "2026-08-15T22:41:18Z", "hours": 1.0153, "text": "I worked on adding two new functionalities for this devlog, which were the new sidebar and making the check-in frequency value chosen be used for its intended purpose Goal The main goal of this devlog was just setting up the necessary features for the big upcoming addition which is the daily check-in feature where the app keeps track of what progress has been made on goals that have check-ins due on that day. This information will also be used for the journal feature that will be added later on. The Sidebar For the sidebar, I realized that I wouldn’t need a dedicated sidebar to store all the buttons for navigation, as there aren’t many buttons necessary, so I decided to create a sort of hybrid sidebar that just lived on the side of the main page. I also think this is much more visually pleasin design as the floating logos glide behind it and it feels very integrated. This was a simple addition where I just made a sidebar outside of the main homepage content div and styled it to look the way it is. It also has a hover effect, which simply makes the background’s opacity increase. Currently, I have not built either of these menus yet so the buttons do not do anything. I will be adding functionality to the Daily Check-in button in the next devlog. Check-in frequency This is what I originally started working on for this devlog, but I realized that I don’t even have a way to get to the check-in page besides when it automatically pops up once daily. Therefore, I added the sidebar. As for progress on this, I have made the goal object take in the chosen option and store it in a variable. I have added a function which uses this info and the last done check-in to find out whether there is a check-in due on that particular day for the passed in goal. This will be called in the daily check-in menu function that I will be making next. If this gives true, then that goal will have a check-in in today’s check-in"}, {"post_id": 44793, "ts": "2026-08-10T20:06:52Z", "hours": 0.8836, "text": "I worked on two new features for this devlog. One was kind of an impulse decision to add floating logos that bounce off the edges of the main page, like the DVD logo, and the other was making the time remaining section work on the goal cards instead of being a placeholder. Floating logos I felt like the background was super plain here and it felt kind of soulless, so I decided to give it that little nostalgic touch and have logos bounce around the user’s screen without making them too distracting. I made this by adding 7 floating logos outside of the main HTML, and then I Used the Math.random function to randomize the object’s size, speed, and starting point Adjusted the opacity of them so they won’t be too annoying Bounded the speed so they all are roughly moving at the same type of speed with slight variation Made them bounce off the edges of the screen using the window width and height and negating their speed value when they come in contact with the boundary With that done, I was testing the app’s functionality and discovered that the days remaining was still using a placeholder of “5 days,” which I had put there earlier. Days Remaining I made this work by writing a function that calculated how many days remained between the current day and the chosen completion date. I did this by using the new date() function to get dates in the format where I could directly subtract them to get the remaining days. This made it very convenient to work with."}, {"post_id": 44411, "ts": "2026-08-10T04:17:17Z", "hours": 3.1861, "text": "I have been working on adding functionality to the app as I was getting pretty satisfied with how the UI looked. I started by adding the functionality for the goals to be saved as one object so they can be stored and retrieved easily Setting up goals I did this by creating a goals array that holds each goal, and I added a function that is triggered when the “add goal” button is pressed in the add goal menu. Within this function, I added a goal object which held the following: A randomly generated ID to easily access a goal The title The description The completion date The category of the goal The chosen check-in frequency The milestones With this, the goal could be easily stored, accessed, and edited by simply changing the information within the goal object in the goals array. With this made, I needed a way to display the information entered on the screen, so I created what I call goal cards. Goal Cards Making the goal cards was a very cool learning experience as I got to deal more with dynamic HTML creation. Once the Add Goal button was clicked, it would call the displayGoal function. This function would: Get all the information from the particular goal object we are displaying Create the goal card using dynamic object creation and add CSS classes that have been made for it Update the goal card every time it is edited, like when milestones are checked off; it will update the progress bar. Speaking of the progress bar, clicking on the goal card brings up the menu shown in the image below, which allows the user to see a bigger view of the goal and allows them to check off milestones. I plan on expanding this to add editability to goals and other functionality. Goal menu This was created using the same technique as the add goal menu from a previous devlog, but instead of showing the same information for everything, it changes based on the goal object being targeted. The styling is not perfect yet, as I was focusing on the functionality more, but as more is changed, it will look closer to the true final product. Conclusion Overall, this was a very productive devlog, and I think I learned a lot of new valuable skills in JavaScript. I think the next thing I will work on is adding the check-ins and setting up the data to be stored locally so it doesn’t go away after a page refresh."}, {"post_id": 32686, "ts": "2026-07-22T00:16:02Z", "hours": 6.3917, "text": "I have been working on the frontend of the app updating it to look more like how I want it to when the app is published. The first image showcases the main page of the app where the goals that are added will show up seperated by short term, medium term, and long term. New goals can be added by pressing the add goal button under each subdivision. Pressing that button brings up the menu from the second image, which is the menu to add a new goal. This menu sets up not only a goal to achieve, but a plan to stick to it. This includes setting up a check-in frequency that tells the app how often in the daily check-ins there should be a progress update for this particular goal. This also includes setting up milestones/steps to achieving a certain goal. This allows for progress tracking of a goal that was set up, and even a feature where the app tells you if you are behind, on track, or ahead on your goal. The biggest challenge I faced while creating this was the feature for adding your own custom milestones, as it was designed to give a lot of freedom to the user. You can move the milestones that were added, give them specific completion dates, or choose to let the app space them evenly. You can add as many milestones as you want, and you can even choose not to add specific milestones and let the app deduce how many and how to split up the milestones. The reason this was difficult was that I have very minimal experience with JavaScript, so this took a lot of time to design, troubleshoot, and iron out. My next steps are to start working on the backend so that the stuff that is entered in the goal setup menu is actually reflected in the main page, and the daily check-in system is setup"}, {"post_id": 7627, "ts": "2026-06-12T19:05:30Z", "hours": 1.6583, "text": "Hi, I am currently learning HTML, CSS, and JavaScript, and along the way, I wanted to make a project to solidify my learning: A goal tracking app! I am very excited to share my current progress, as I was able to make an overlay menu that displays over the app without going to a different page. This was a difficult task as I had not worked with JavaScript before, but with the help of resources like Stack Overflow, I was able to figure out how to implement it! I used an on() and an off() function that displayed a full-screen overlay, which had a child overlay containing the pop-up menu. This can be seen in the second picture below. The overlay is display= “none” by default and then gets set to display= “flex” when the on() function is called. Off() sets it back to none. I haven’t added the exact content that I want or styled anything yet, but I just wanted to share this milestone! The app that I am making is a goal-tracking app that allows the user to add different types of goals (short, medium, long term) to keep track of their goals. The app will also keep the user accountable as it will require the user to set steps/mini goals that need to be achieved, and will have the user complete a daily check-in to track their progress. Different types of goals can have different time frames, and the app will account for that. The user can input a time frame, or the app will use pre-determined values."}]...
|
Title: Slice of a pie - goal tracker by @adwitha | Title: Slice of a pie - goal tracker by @adwitha | Stardance
Devlogs:
Hi, I am currently learning HTML, CSS, and JavaScript, and along the way, I wanted to make a project to solidify my learning: A goal tracking app! I am very excited to share my current progress, as I was able to make an overlay menu that displays over the app without going to a different page. This was a difficult task as I had not worked with JavaScript before, but with the help of resources like Stack Overflow, I was able to figure out how to implement it! I used an on() and an off() function that displayed a full-screen overlay, which had a child overlay containing the pop-up menu. This can be seen in the second picture below. The overlay is display= “none” by default and then gets set to display= “flex” when the on() function is called. Off() sets it back to none. I haven’t added the exact content that I want or styled anything yet, but I just wanted to share this milestone! The app that I am making is a goal-tracking app that allows the user to add different types of goals (short, medium, long term) to keep track of their goals. The app will also keep the user accountable as it will require the user to set steps/mini goals that need to be achieved, and will have the user complete a daily check-in to track their progress. Different types of goals can have different time frames, and the app will account for that. The user can input a time frame, or the app will use pre-determined values.
I have been working on the frontend of the app updating it to look more like how I want it to when the app is published. The first image showcases the main page of the app where the goals that are added will show up seperated by short term, medium term, and long term. New goals can be added by pressing the add goal button under each subdivision. Pressing that button brings up the menu from the second image, which is the menu to add a new goal. This menu sets up not only a goal to achieve, but a plan to stick to it. This includes setting up a check-in frequency that tells the app how often in the daily check-ins there should be a progress update for this particular goal. This also includes setting up milestones/steps to achieving a certain goal. This allows for progress tracking of a goal that was set up, and even a feature where the app tells you if you are behind, on track, or ahead on your goal. The biggest challenge I faced while creating this was the feature for adding your own custom milestones, as it was designed to give a lot of freedom to the user. You can move the milestones that were added, give them specific completion dates, or choose to let the app space them evenly. You can add as many milestones as you want, and you can even choose not to add specific milestones and let the app deduce how many and how to split up the milestones. The reason this was difficult was that I have very minimal experience with JavaScript, so this took a lot of time to design, troubleshoot, and iron out. My next steps are to start working on the backend so that the stuff that is entered in the goal setup menu is actually reflected in the main page, and the daily check-in system is setup
I have been working on adding functionality to the app as I was getting pretty satisfied with how the UI looked. I started by adding the functionality for the goals to be saved as one object so they can be stored and retrieved easily Setting up goals I did this by creating a goals array that holds each goal, and I added a function that is triggered when the “add goal” button is pressed in the add goal menu. Within this function, I added a goal object which held the following: A randomly generated ID to easily access a goal The title The description The completion date The category of the goal The chosen check-in frequency The milestones With this, the goal could be easily stored, accessed, and edited by simply changing the information within the goal object in the goals array. With this made, I needed a way to display the information entered on the screen, so I created what I call goal cards. Goal Cards Making the goal cards was a very cool learning experience as I got to deal more with dynamic HTML creation. Once the Add Goal button was clicked, it would call the displayGoal function. This function would: Get all the information from the particular goal object we are displaying Create the goal card using dynamic object creation and add CSS classes that have been made for it Update the goal card every time it is edited, like when milestones are checked off; it will update the progress bar. Speaking of the progress bar, clicking on the goal card brings up the menu shown in the image below, which allows the user to see a bigger view of the goal and allows them to check off milestones. I plan on expanding this to add editability to goals and other functionality. Goal menu This was created using the same technique as the add goal menu from a previous devlog, but instead of showing the same information for everything, it changes based on the goal object being targeted. The styling is not perfect yet, as I was focusing on the functionality more, but as more is changed, it will look closer to the true final product. Conclusion Overall, this was a very productive devlog, and I think I learned a lot of new valuable skills in JavaScript. I think the next thing I will work on is adding the check-ins and setting up the data to be stored locally so it doesn’t go away after a page refresh.
I worked on two new features for this devlog. One was kind of an impulse decision to add floating logos that bounce off the edges of the main page, like the DVD logo, and the other was making the time remaining section work on the goal cards instead of being a placeholder. Floating logos I felt like the background was super plain here and it felt kind of soulless, so I decided to give it that little nostalgic touch and have logos bounce around the user’s screen without making them too distracting. I made this by adding 7 floating logos outside of the main HTML, and then I Used the Math.random function to randomize the object’s size, speed, and starting point Adjusted the opacity of them so they won’t be too annoying Bounded the speed so they all are roughly moving at the same type of speed with slight variation Made them bounce off the edges of the screen using the window width and height and negating their speed value when they come in contact with the boundary With that done, I was testing the app’s functionality and discovered that the days remaining was still using a placeholder of “5 days,” which I had put there earlier. Days Remaining I made this work by writing a function that calculated how many days remained between the current day and the chosen completion date. I did this by using the new date() function to get dates in the format where I could directly subtract them to get the remaining days. This made it very convenient to work with.
I worked on adding two new functionalities for this devlog, which were the new sidebar and making the check-in frequency value chosen be used for its intended purpose Goal The main goal of this devlog was just setting up the necessary features for the big upcoming addition which is the daily check-in feature where the app keeps track of what progress has been made on goals that have check-ins due on that day. This information will also be used for the journal feature that will be added later on. The Sidebar For the sidebar, I realized that I wouldn’t need a dedicated sidebar to store all the buttons for navigation, as there aren’t many buttons necessary, so I decided to create a sort of hybrid sidebar that just lived on the side of the main page. I also think this is much more visually pleasin design as the floating logos glide behind it and it feels very integrated. This was a simple addition where I just made a sidebar outside of the main homepage content div and styled it to look the way it is. It also has a hover effect, which simply makes the background’s opacity increase. Currently, I have not built either of these menus yet so the buttons do not do anything. I will be adding functionality to the Daily Check-in button in the next devlog. Check-in frequency This is what I originally started working on for this devlog, but I realized that I don’t even have a way to get to the check-in page besides when it automatically pops up once daily. Therefore, I added the sidebar. As for progress on this, I have made the goal object take in the chosen option and store it in a variable. I have added a function which uses this info and the last done check-in to find out whether there is a check-in due on that particular day for the passed in goal. This will be called in the daily check-in menu function that I will be making next. If this gives true, then that goal will have a check-in in today’s check-in...
|
1792731051.952001
|
1793335851.952001
|
|
28687
|
My very own WebOS by @trynadoshi | Stardance
|
trynadoshi
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @trynadoshi | Stardanc Title: My very own WebOS by @trynadoshi | Stardance...
|
1792731051.1095285
|
1793335851.1095285
|
|
28370
|
A Gift For My Mum by @PatheticFish | Stardance
|
PatheticFish
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: A Gift For My Mum by @PatheticFish | Starda Title: A Gift For My Mum by @PatheticFish | Stardance...
|
1792731050.2360775
|
1793335850.2360775
|
|
3914
|
My first slack bot! by @Sparrow216 | Stardance
|
Sparrow216
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @Sparrow216 | Starda Title: My first slack bot! by @Sparrow216 | Stardance...
|
1792731049.3763742
|
1793335849.3763742
|
|
34673
|
My very own WebOS by @enarr2 | Stardance
|
enarr2
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @enarr2 | Stardance
|
1792731048.5078778
|
1793335848.5078778
|
|
27458
|
Frictionless by @Saimss | Stardance
|
Saimss
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Frictionless by @Saimss | Stardance
|
1792731047.6587725
|
1793335847.6587725
|
|
3299
|
i need to delete this by @LEOM | Stardance
|
LEOM
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: i need to delete this by @LEOM | Stardance
|
1792731046.7644343
|
1793335846.7644343
|
|
13846
|
Untitled by @DevArora | Stardance
|
DevArora
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @DevArora | Stardance
|
1792731045.9310322
|
1793335845.9310322
|
|
32506
|
Packet Atlas by @Sedryn | Stardance
|
Sedryn
|
0
|
14.03
|
0
|
[]
|
[{"post_id": 31897, "ts": "202 [{"post_id": 31897, "ts": "2026-07-20T17:41:42Z", "hours": 7.5522, "text": "DEVLOG 5 I finished implementing packet trails along with a basic hover system that displays the IP address of the machine under the cursor. Both systems still need a lot of polishing and additional features before they’re anywhere close to a full release. I also tweaked the parser slightly to better match the format expected by the animation engine. Outside of programming, I spent some time creating a logo and banner for the project page. They’re still works in progress, but I’m happy with the direction they’re heading. Current Progress Done: PCAP parser Animation engine Packet trails Basic hover system Planned: Camera controls Timeline 3)Packet information/stats 4)Dynamic grid Search feature General UI/UX improvements"}, {"post_id": 27227, "ts": "2026-07-12T16:41:36Z", "hours": 3.9689, "text": "DEVLOG -004: Completed Implementing the Animation Engine To start, I had a great programming session today. As you can see, I logged almost 4 hours on this feature, and every minute went into building the foundation of the animation system. As the title suggests, I completed the first version of the animation engine using Pygame. I chose Pygame because I already have experience building games with the JavaScript Canvas API, so all I really needed was a lightweight way to draw graphics and animate objects. From what I found while researching, learning a full GUI framework would have taken significantly longer, so Pygame was the most practical choice for this stage of the project. I also used ChatGPT to generate a sample conversations object (covered in previous devlogs), which served as mock data while developing the renderer. From there, I implemented the engine myself. After spending about ten minutes pacing around my room thinking through the architecture, I settled on an animation loop consisting of four stages. The Setup The setup stage initializes the application and creates the machines dictionary. This dictionary acts as a hash lookup, mapping every unique IP address found in the conversations to its corresponding Machine object. IP Address → Machine() For organization, I created a Machine class that stores the data and rendering information associated with each endpoint. This allows packets to instantly locate their source and destination machines without searching through a list. Loading the Gun I’ll use a gun as an analogy for the remaining stages. Instead of iterating through every packet in every conversation every frame, packets waiting to be animated are moved into an activePackets list. This separates packets that are currently “in flight” from packets that are simply stored in the conversation data. Each conversation contains three important pieces of information: index — Tracks the next packet to be animated. state — Indicates whether the conversation is idle or running. info — Stores the actual packet data. A CheckState() function examines each conversation. If a conversation is idle, it jumps directly to the packet indicated by the current index (avoiding iteration through previous packets), creates a Packet object, places it into activePackets, and marks the conversation as running. Pulling the Trigger This stage is intentionally simple. The update function only iterates over the packets currently stored in activePackets. Each packet updates its position by interpolating (lerping) toward the destination machine’s coordinates. No packets outside of the active list are processed during this stage. The Bullet Once fired, the packet enters the running state. As it travels toward the destination, it continuously checks the remaining distance to its target. When that distance falls below a predefined threshold, the packet marks itself as done. Finally, a cleanup function removes all completed packets from activePackets. If the conversation still has packets remaining, its state returns to idle, allowing the next packet to be loaded and fired. Here is the code and a demo of version 0.1"}, {"post_id": 26115, "ts": "2026-07-10T18:25:24Z", "hours": 0.4314, "text": "DEVLOG 003 Today’s devlog will be a bit short because I didn’t have time to sit down for a proper programming session. I spent some time experimenting with the pygame-ce library to get a feel for it. Since I’ve made games using the raw JavaScript Canvas API in the past, picking it up was fairly quick. I ended up creating a simple square that moves using the keyboard—not anything polished yet, but it’s a good first step toward getting comfortable with the library before building the animation system for Packet Atlas."}, {"post_id": 25215, "ts": "2026-07-09T10:26:44Z", "hours": 0.9386, "text": "DEVLOG 002 - Finished the parser Second devlog the title says it all i finished the parser that is section 1 complete! -REFERENCES- https://medium.com/a-bit-off/scapy-ways-of-reading-pcaps-1367a05e98a8 Great article about different ways you can read pcap files https://tcpreplay.appneta.com/wiki/captures.html this is where i got the pcap file THE IDEA Now time for the parser ,i used scapy because its a widely used library for manipulating packets and also has great documentation. The end goal would be to create a conversations object in which each isolated conversation of various machines would be stored so that the animator can easily move through the data without having to do any extra work per frame. -IMPLEMENTATION- Implementation was relatively straightforward. I iterate through the packets returned by rdpcap(), create an empty conversation object, and insert each packet into its corresponding conversation. If a matching conversation already exists, the packet is appended. Otherwise, a new conversation is created. at the end the conversations dict will be looking something like this conversations = {convo1: [{ time:12, ip:12.32.45 ..etc},{ time:13, ip:12.32.45 ..etc}], convo2: ….} Struggles I first planned to use a hashmap keyed by timestamps, but duplicate timestamps and decimal precision quickly made that idea messy. Instead, I grouped packets into conversations and let the animator iterate through them chronologically like a playhead. It keeps the parser simple and makes the animation side much easier. Making everything asynchronous is Future Me’s problem. Anyways, here’s the code…"}, {"post_id": 24838, "ts": "2026-07-08T17:31:56Z", "hours": 1.1344, "text": "DEVLOG 001 - Project Creation and structure This is my first devlog i did write some code but the real progress was made with the structure of this project. PACKET ATLAS Packet Atlas will be a tool used to visualize network traffic while tools like nmap and wire shark show this with lines on a terminal ,Packet atlas will display every active machine and the data sent between them on a map with a scrollable timeline and animations. All of which come from a packet capture file(.pcap) I will be using python as the language with scapy for handling the pcap files and pygame for the animations the project will have 2 main sections Section 1 - Parsing this will be dedicated to making a parser to organize all the data to make the animation and interactive part easier as mentioned before i will be using scapy for dissecting the packets and seperating distinct conversations between machines in the bulk capture file Section 2 - Animating This will be the interactive part including animations for all the different machines making the animations etc. I have a plan to seperate the different layers and adding different panes for them like the ones seen in the OSI model but i want to build some momentum in the project first before planning that Section 3 - Bonus If i have time left i will try and make this into a realtime app similar to a weather radar but for the internet! Anyways heres some code i just created the folder and messed around with the scapy syntax to get a feel for the library"}]...
|
Title: Packet Atlas by @Sedryn | Stardance
Devlog Title: Packet Atlas by @Sedryn | Stardance
Devlogs:
DEVLOG 001 - Project Creation and structure This is my first devlog i did write some code but the real progress was made with the structure of this project. PACKET ATLAS Packet Atlas will be a tool used to visualize network traffic while tools like nmap and wire shark show this with lines on a terminal ,Packet atlas will display every active machine and the data sent between them on a map with a scrollable timeline and animations. All of which come from a packet capture file(.pcap) I will be using python as the language with scapy for handling the pcap files and pygame for the animations the project will have 2 main sections Section 1 - Parsing this will be dedicated to making a parser to organize all the data to make the animation and interactive part easier as mentioned before i will be using scapy for dissecting the packets and seperating distinct conversations between machines in the bulk capture file Section 2 - Animating This will be the interactive part including animations for all the different machines making the animations etc. I have a plan to seperate the different layers and adding different panes for them like the ones seen in the OSI model but i want to build some momentum in the project first before planning that Section 3 - Bonus If i have time left i will try and make this into a realtime app similar to a weather radar but for the internet! Anyways heres some code i just created the folder and messed around with the scapy syntax to get a feel for the library
DEVLOG 002 - Finished the parser Second devlog the title says it all i finished the parser that is section 1 complete! -REFERENCES- https://medium.com/a-bit-off/scapy-ways-of-reading-pcaps-1367a05e98a8 Great article about different ways you can read pcap files https://tcpreplay.appneta.com/wiki/captures.html this is where i got the pcap file THE IDEA Now time for the parser ,i used scapy because its a widely used library for manipulating packets and also has great documentation. The end goal would be to create a conversations object in which each isolated conversation of various machines would be stored so that the animator can easily move through the data without having to do any extra work per frame. -IMPLEMENTATION- Implementation was relatively straightforward. I iterate through the packets returned by rdpcap(), create an empty conversation object, and insert each packet into its corresponding conversation. If a matching conversation already exists, the packet is appended. Otherwise, a new conversation is created. at the end the conversations dict will be looking something like this conversations = {convo1: [{ time:12, ip:12.32.45 ..etc},{ time:13, ip:12.32.45 ..etc}], convo2: ….} Struggles I first planned to use a hashmap keyed by timestamps, but duplicate timestamps and decimal precision quickly made that idea messy. Instead, I grouped packets into conversations and let the animator iterate through them chronologically like a playhead. It keeps the parser simple and makes the animation side much easier. Making everything asynchronous is Future Me’s problem. Anyways, here’s the code…
DEVLOG 003 Today’s devlog will be a bit short because I didn’t have time to sit down for a proper programming session. I spent some time experimenting with the pygame-ce library to get a feel for it. Since I’ve made games using the raw JavaScript Canvas API in the past, picking it up was fairly quick. I ended up creating a simple square that moves using the keyboard—not anything polished yet, but it’s a good first step toward getting comfortable with the library before building the animation system for Packet Atlas.
DEVLOG -004: Completed Implementing the Animation Engine To start, I had a great programming session today. As you can see, I logged almost 4 hours on this feature, and every minute went into building the foundation of the animation system. As the title suggests, I completed the first version of the animation engine using Pygame. I chose Pygame because I already have experience building games with the JavaScript Canvas API, so all I really needed was a lightweight way to draw graphics and animate objects. From what I found while researching, learning a full GUI framework would have taken significantly longer, so Pygame was the most practical choice for this stage of the project. I also used ChatGPT to generate a sample conversations object (covered in previous devlogs), which served as mock data while developing the renderer. From there, I implemented the engine myself. After spending about ten minutes pacing around my room thinking through the architecture, I settled on an animation loop consisting of four stages. The Setup The setup stage initializes the application and creates the machines dictionary. This dictionary acts as a hash lookup, mapping every unique IP address found in the conversations to its corresponding Machine object. IP Address → Machine() For organization, I created a Machine class that stores the data and rendering information associated with each endpoint. This allows packets to instantly locate their source and destination machines without searching through a list. Loading the Gun I’ll use a gun as an analogy for the remaining stages. Instead of iterating through every packet in every conversation every frame, packets waiting to be animated are moved into an activePackets list. This separates packets that are currently “in flight” from packets that are simply stored in the conversation data. Each conversation contains three important pieces of information: index — Tracks the next packet to be animated. state — Indicates whether the conversation is idle or running. info — Stores the actual packet data. A CheckState() function examines each conversation. If a conversation is idle, it jumps directly to the packet indicated by the current index (avoiding iteration through previous packets), creates a Packet object, places it into activePackets, and marks the conversation as running. Pulling the Trigger This stage is intentionally simple. The update function only iterates over the packets currently stored in activePackets. Each packet updates its position by interpolating (lerping) toward the destination machine’s coordinates. No packets outside of the active list are processed during this stage. The Bullet Once fired, the packet enters the running state. As it travels toward the destination, it continuously checks the remaining distance to its target. When that distance falls below a predefined threshold, the packet marks itself as done. Finally, a cleanup function removes all completed packets from activePackets. If the conversation still has packets remaining, its state returns to idle, allowing the next packet to be loaded and fired. Here is the code and a demo of version 0.1
DEVLOG 5 I finished implementing packet trails along with a basic hover system that displays the IP address of the machine under the cursor. Both systems still need a lot of polishing and additional features before they’re anywhere close to a full release. I also tweaked the parser slightly to better match the format expected by the animation engine. Outside of programming, I spent some time creating a logo and banner for the project page. They’re still works in progress, but I’m happy with the direction they’re heading. Current Progress Done: PCAP parser Animation engine Packet trails Basic hover system Planned: Camera controls Timeline 3)Packet information/stats 4)Dynamic grid Search feature General UI/UX improvements...
|
1792731044.8120642
|
1793335844.8120642
|
|
14024
|
My first slack bot! by @kaprikanchan09 | Stardance
|
kaprikanchan09
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @kaprikanchan09 | St Title: My first slack bot! by @kaprikanchan09 | Stardance...
|
1792731043.9733353
|
1793335843.9733353
|
|
39574
|
Music Player by @Pathaks_OP | Stardance
|
Pathaks_OP
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Music Player by @Pathaks_OP | Stardance
|
1792731043.1470656
|
1793335843.1470656
|
|
17001
|
Untitled by @ImNotIvy | Stardance
|
ImNotIvy
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @ImNotIvy | Stardance
|
1792731042.2987106
|
1793335842.2987106
|
|
13998
|
My very own WebOS by @amk9809 | Stardance
|
amk9809
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @amk9809 | Stardance
|
1792731041.4603038
|
1793335841.4603038
|
|
8372
|
Printer Vendo by @rul3zero | Stardance
|
rul3zero
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Printer Vendo by @rul3zero | Stardance
|
1792731040.6249046
|
1793335840.6249046
|
|
38574
|
Untitled project by @aygerim | Stardance
|
aygerim
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @aygerim | Stardance
|
1792731039.7873297
|
1793335839.7873297
|
|
37724
|
yber Smart Clock Air Quality, Pomodoro Alarm by @T yber Smart Clock Air Quality, Pomodoro Alarm by @TRIX | Stardance...
|
TRIX
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: yber Smart Clock Air Quality, Pomodoro Alar Title: yber Smart Clock Air Quality, Pomodoro Alarm by @TRIX | Stardance...
|
1792731038.9547327
|
1793335838.9547327
|
|
6399
|
My awesome macropad! by @Belar | Stardance
|
Belar
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Belar | Stardance
|
1792731038.0921018
|
1793335838.0921018
|
|
32983
|
LoLOS by @alinurLoL228 | Stardance
|
alinurLoL228
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: LoLOS by @alinurLoL228 | Stardance
|
1792731037.2351472
|
1793335837.2351472
|
|
38355
|
WarioWare Game by @Sky_ | Stardance
|
Sky_
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: WarioWare Game by @Sky_ | Stardance
|
1792731036.3897913
|
1793335836.3897913
|
|
31359
|
Frictionless by @rhianna | Stardance
|
rhianna
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Frictionless by @rhianna | Stardance
|
1792731035.5281365
|
1793335835.5281365
|
|
13067
|
Untitled project by @rajdeepm | Stardance
|
rajdeepm
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @rajdeepm | Stardance
|
1792731034.699601
|
1793335834.699601
|
|
37734
|
My very own WebOS by @SkilledBtLzy | Stardance
|
SkilledBtLzy
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @SkilledBtLzy | Starda Title: My very own WebOS by @SkilledBtLzy | Stardance...
|
1792731033.8574288
|
1793335833.8574288
|
|
25626
|
My first slack bot! by @naif | Stardance
|
naif
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @naif | Stardance
|
1792731032.9885495
|
1793335832.9885495
|
|
7458
|
My first slack bot! by @solarlunarr | Stardance
|
solarlunarr
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @solarlunarr | Stard Title: My first slack bot! by @solarlunarr | Stardance...
|
1792731032.1155777
|
1793335832.1155777
|
|
25136
|
Untitled by @araadh3111 | Stardance
|
araadh3111
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @araadh3111 | Stardance
|
1792731031.26348
|
1793335831.26348
|
|
8060
|
My awesome macropad! by @adittyanischal | Stardanc My awesome macropad! by @adittyanischal | Stardance...
|
adittyanischal
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @adittyanischal | S Title: My awesome macropad! by @adittyanischal | Stardance...
|
1792731030.4055738
|
1793335830.4055738
|
|
8238
|
Heaven demands death' by @lebiraja2007_9699 | Heaven demands death' by @lebiraja2007_9699 | Stardance...
|
lebiraja2007_9699
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Heaven demands death' by @lebiraja2007_ Title: Heaven demands death' by @lebiraja2007_9699 | Stardance...
|
1792731029.4607577
|
1793335829.4607577
|
|
31534
|
Untitled by @Anq | Stardance
|
Anq
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @Anq | Stardance
|
1792731028.6087608
|
1793335828.6087608
|
|
3862
|
Untitled by @hello4312 | Stardance
|
hello4312
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @hello4312 | Stardance
|
1792731027.7545352
|
1793335827.7545352
|
|
13123
|
My very own WebOS by @Hapis | Stardance
|
Hapis
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @Hapis | Stardance
|
1792731026.900149
|
1793335826.900149
|
|
11920
|
Dinosaur game by @ardeno99 | Stardance
|
ardeno99
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Dinosaur game by @ardeno99 | Stardance
|
1792731026.0649753
|
1793335826.0649753
|
|
7929
|
My first slack bot! by @delete | Stardance
|
delete
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @delete | Stardance
|
1792731025.1952605
|
1793335825.1952605
|
|
14132
|
My awesome macropad! by @LukeG | Stardance
|
LukeG
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @LukeG | Stardance
|
1792731024.3565383
|
1793335824.3565383
|
|
25254
|
Lunar Gaurdian by @inbaarasan215 | Stardance
|
inbaarasan215
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Lunar Gaurdian by @inbaarasan215 | Stardanc Title: Lunar Gaurdian by @inbaarasan215 | Stardance...
|
1792731023.4980123
|
1793335823.4980123
|
|
6435
|
wmata sound emulator by @sleekez | Stardance
|
sleekez
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: wmata sound emulator by @sleekez | Stardanc Title: wmata sound emulator by @sleekez | Stardance...
|
1792731022.639626
|
1793335822.639626
|
|
22505
|
Frictionless by @davidm | Stardance
|
davidm
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Frictionless by @davidm | Stardance
|
1792731021.7595768
|
1793335821.7595768
|
|
35389
|
My own site! by @AriannaA | Stardance
|
AriannaA
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My own site! by @AriannaA | Stardance
|
1792731018.2847664
|
1793335818.2847664
|
|
27504
|
My very own WebOS by @SilverCanvas | Stardance
|
SilverCanvas
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @SilverCanvas | Starda Title: My very own WebOS by @SilverCanvas | Stardance...
|
1792731017.4065208
|
1793335817.4065208
|
|
3186
|
My awesome macropad! by @Madfish | Stardance
|
Madfish
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Madfish | Stardanc Title: My awesome macropad! by @Madfish | Stardance...
|
1792731016.5043757
|
1793335816.5043757
|
|
16154
|
My awesome macropad! by @Mako | Stardance
|
Mako
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Mako | Stardance
|
1792731015.638841
|
1793335815.638841
|
|
25940
|
My very own WebOS by @Just | Stardance
|
Just
|
0
|
9.9
|
0
|
[]
|
[{"post_id": 23299, "ts": "202 [{"post_id": 23299, "ts": "2026-07-06T05:28:14Z", "hours": 0.3789, "text": "Analyzing my code and attempting to debug the close and open window functions."}, {"post_id": 22634, "ts": "2026-07-05T05:54:27Z", "hours": 2.9222, "text": "Found and the syntax issue due to the help from staredance help."}, {"post_id": 21977, "ts": "2026-07-04T06:10:30Z", "hours": 4.0372, "text": "I continued to follow the web os tutorial and spent almost two hours on a syntax error… I still haven’t fixed it :("}, {"post_id": 21345, "ts": "2026-07-03T07:22:04Z", "hours": 1.4, "text": "Started to work on part 2 of the web os tutorial."}, {"post_id": 20535, "ts": "2026-07-02T04:42:42Z", "hours": 0.6428, "text": "I learned how to run html files. (Yay!)"}, {"post_id": 19796, "ts": "2026-07-01T05:47:02Z", "hours": 0.5167, "text": "Started to work on my own web OS!"}]...
|
Title: My very own WebOS by @Just | Stardance
Dev Title: My very own WebOS by @Just | Stardance
Devlogs:
Started to work on my own web OS!
I learned how to run html files. (Yay!)
Started to work on part 2 of the web os tutorial.
I continued to follow the web os tutorial and spent almost two hours on a syntax error… I still haven’t fixed it :(
Found and the syntax issue due to the help from staredance help.
Analyzing my code and attempting to debug the close and open window functions....
|
1792731014.6830738
|
1793335814.6830738
|
|
224
|
Untitled by @Niko | Stardance
|
Niko
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @Niko | Stardance
|
1792731013.8275313
|
1793335813.8275313
|
|
7955
|
My awesome macropad! by @aditya2pathak_7747 | Star My awesome macropad! by @aditya2pathak_7747 | Stardance...
|
aditya2pathak_7747
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @aditya2pathak_7747 Title: My awesome macropad! by @aditya2pathak_7747 | Stardance...
|
1792731012.9669292
|
1793335812.9669292
|
|
24629
|
My first slack bot! by @dilnurauralova25 | Stardan My first slack bot! by @dilnurauralova25 | Stardance...
|
dilnurauralova25
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @dilnurauralova25 | Title: My first slack bot! by @dilnurauralova25 | Stardance...
|
1792731012.1176302
|
1793335812.1176302
|
|
20854
|
My very own WebOS by @shivam21prateek | Stardance
|
shivam21prateek
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @shivam21prateek | Sta Title: My very own WebOS by @shivam21prateek | Stardance...
|
1792731011.246994
|
1793335811.246994
|
|
19479
|
Stardeck by @YodaheWondimu | Stardance
|
YodaheWondimu
|
0
|
31.27
|
0
|
[]
|
[{"post_id": 49980, "ts": "202 [{"post_id": 49980, "ts": "2026-08-19T00:17:58Z", "hours": 11.2794, "text": "Devlog #4: Iterating CAD for component assembly and adding necessary detail With the hardware flow open, I received feedback on my hardware project. A reviewer returned my funding request and advised me to work on adding more detail to my CAD model, since it’s important for actually putting the hardware together and makes CAD your best wingman. Detailed Assembly The detailed assembly would be close to the concept from Devlog #2, but: Instead of blocks for every hardware component, I’ll use open-source .step files as 1:1 reference models. If the model accurately represents the real part and tolerances are accounted for, Onshape fits should represent reality. (Attribution is given in docs/ATTRIBUTIONS.md in my GitHub repository.) Fasteners mattered now, so there was no more pairing of generic screws with generic nuts and calling it a day. The clearance holes from before weren’t as reliable as threaded bosses for mounting purposes, so I had to make replacements where necessary. Hardware Modeling and Fit Raspberry Pi 4B Importing the model for the Raspberry Pi 4B revealed an incorrect assumption. I assumed its 4 mounting holes sat near the corners of the board, but they were actually positioned differently. I adjusted the gap between the mounting rails to allow the Pi to rest and moved the mounting holes to where the Pi could line up on top of them, resulting in a mounting-aware pair of rails that I fastened shortly after. Elecrow RC070 7-inch Touchscreen Display I took the given file from its product page and merged its individual parts into one composite part. After composing, I added mounting holes matching those of the real component. The screen’s width fit perfectly into the top enclosure’s cutout (same width dimension), and with that, I added 0.5mm clearance to all sides of the top enclosure half’s screen cutout in case tolerance reality decides to strike my hardware. Anker Portable Charger/Power Bank This was where it got tricky. There was no available CAD model for the battery pack online, so I had to reverse engineer it myself. Our more realistic battery model had a length of ~153mm, while our placeholder had a length of ~115mm. Since our battery tray was initially modeled to fit snugly around the placeholder model (back when we just needed everything to fit together), our actual battery wasn’t going to fit. Our much more realistic model won over, and I reworked the battery tray with a looser but not as risky fit, centered closer to the side opposite the mounting rails of the inner enclosure’s bottom half. MicroCenter Flash Drive This part required some more of the same principle - reverse engineering - and having the flash drive with me made it easier to create a reference model. Dimensions that are reasonably close to the real thing in Onshape allow us to achieve the same purpose: testing the spacing and enclosure considerations of Stardeck. Challenges Reverse engineering the battery and flash drive was where I learned the most during this revision. I implemented the dimensions that were most relevant to each part’s size and connectivity (since I didn’t need 10/10 looks here) to concoct replicas that came pretty close to the real thing. I also had to design holes that would work with a custom Featurescript for threading. I tried to increase the thickness of certain sides with mounting holes for ThreadCreator’s sake, but what ended up working was switching to a similar Featurescript called BoazThread. What’s complete: Refined key details of the component assembly Related my enclosure hardware to 1:1 hardware models Reverse engineered parts without publicly available CAD models Next up: Refine design further (if required for funding) Receive physical parts Assemble Stardeck IRL Get Stardeck to boot"}, {"post_id": 29786, "ts": "2026-07-16T21:57:29Z", "hours": 8.1269, "text": "Devlog #3 - Printing the Physical Enclosure Good news! This week, I managed to get my 3D printer up and running. Weeks of CAD work finally culminated in a pair of printed enclosure halves. Since I was going for a clamshell design for the first print, I printed both the top and bottom halves to see how they would go together. I knew I was technically doing this to test out tolerances and whatever, but I was secretly excited to be building something outside of Onshape for a change. Settings I mostly used my printer’s default profile, adding tree supports for the floating cantilever sections in the internal mounting rails. They printed cleanly and snapped away easily after fabrication. (Detailed slicer settings are documented separately in docs/printer_settings.md .) The only supports needed were for those mounting rails in the bottom half and the alignment lip on the top half. The results, as you’re about to see, went smoothly. Print Results Fresh off the 3D printer, I had both enclosure halves. The clamshell enclosure worked exactly how I’d hoped, and it seems like it will make disassembly easy enough to fill the internals with electronics (once I have them) and assembly easy enough to not irritate users. The alignment lips kept both halves aligned, and the lip mounting holes worked as a visual aid that told you whether or not each enclosure half was level or not - a perfect circle meant aligned, sliding semicircles meant you had to nudge it a bit. The other visible features - the display mounting area, port cutout, and battery tray - also turned out great. I was surprised to see the top half fit like a glove onto the bottom half first-try. After all, I’ve heard scary stories around an imaginary campfire where one tolerance requires reprinting everything (spooky). Luckily, no such thing happened here. And the mounting holes? They all came out exactly as modeled. The M3 holes on the alignment lips and the M2.5 holes on the display mounts and Pi rails matched the dimensions I designed. Considering how much I’d heard about tolerance problems, seeing everything line up on the first print felt like a small victory. When I Thought I Messed Up So…something happened. I noticed fringing filament that was sticking out of certain surfaces. I thought this would compromise the design’s integrity, and so I searched up the problem. After looking online, I found that this event was known as stringing, where melted filament can ooze from the nozzle during travel and solidify on top of whatever it lands on. I was relieved to figure out that this wasn’t a structural problem, but rather an aesthetic one, which I solved by clipping off any excess filament similar to the tree supports. Summary Printing the enclosure completely changed how the project felt. Up until this point, Stardeck had only existed inside Onshape. Holding both halves in my hands made it feel less like an idea and more like something I was actually going to finish. I don’t have my electronics just yet, but I believe that Hack Club’s funding process will give me the parts that I need to turn my idea into a reality. Speaking of the funding process, I’ve also spent a great deal of time in consecutive work sessions just documenting. I’ve been preparing my JOURNAL.md to showcase day-to-day summaries of progress, screenshotting my Onshape designs, and sharing my fabrication workflow. Steps like these are what allow a project to be considered for hardware grants later, which I need to receive the electronics that’ll make Stardeck a real cyberdeck. The enclosure may only be plastic for now, but it’s the first physical piece of Stardeck. Next comes the stage I’ve been designing around from the beginning: bringing it to life with actual hardware. Next Up: Finish up documentation/design tweaks Submit design for hardware funding Assemble components into the enclosure Craft a booting prototype?"}, {"post_id": 20417, "ts": "2026-07-02T00:37:00Z", "hours": 10.4044, "text": "Devlog #2 - Component Assembly and Design Tuning This week, I was tuning my Stardeck designs to reach feasibility before submitting my design to Stardance for review. I started to test my initial design decisions using Onshape to model the spacing that each part would need, and I used that to finish up a component assembly that reflected how my parts would fit together in the real world. CAD Assembly Space was a critical factor in my cyberdeck because it was what everything inside of my enclosure lived on. Furthermore, my enclosure design evolved often to account for unanticipated constraints. A few of my enclosure features for Stardeck surprised me as I never even knew that I needed them at first. Clamshell Design: Remember how in the first devlog, I was considering using a rectangular prism with a carved-out back to house all the internal components? I found out very quickly that this would still make for a hard assembly once more than two parts came in. A clamshell design - top half, bottom half - would allow me to make the most of the space given because it would allow me to actually reach many parts of the internals. Alignment Lips: This took me a long time to conceptualize after hearing about these for the first time, but it became easy once I thought of a shoebox. The top of any shoebox fits on the bottom half and rests there - not because it’s screwed in place, but because the top half sort of wraps around the bottom half. These made the clamshell more robust as the “shoebox method” promised a safer screwdriver assembly as well. Mounting Rails: Placing the Raspberry Pi, which would be the basis of Stardeck’s computing subsystem, in the exact middle of the enclosure meant that other components - battery, screen, flash drive, etc - could reach it easily. However, it can’t just levitate, so it uses mounting rails to keep it up. The rails also come with holes for the Pi to be mounted onto for added security. Port Cutout: I felt so relieved after realizing that I needed this before shipping off all my CAD files to display on GitHub. The reason why was because it’s the hole in the enclosure that allows external cables to access the Pi’s USB ports. This makes essential functions such as swapping flash drives and connecting keyboards much easier. Overall, it’s a small design feature that makes assembly and maintenance much easier. System Architecture From the last devlog, we already knew how each component would connect to one another in practice. However, I found that for this iteration, the system could be modeled effectively at the subsystem level without a full PCB design or detailed electrical schematic. To follow, I created a System Architecture diagram to demonstrate how the parts of Stardeck interact with each other. After solving the electrical problem, I managed - with several days of me modeling components to depict and assemble - to solve the mechanical problem instead. Both were closely related to each other, which made for a lot of work when planning port maps, looking at diagrams of the port locations on a Raspberry Pi, finding components for the BOM that I want for my build, and so on. Summary I learned a lot about hardware selection, using Onshape to work around physical constraints, and building prototypes with future me in mind. I’m confident this design is ready to be submitted at its current state to Stardance. It’s simple and has just enough functionality without going overboard for a minimal viable product. With funding help from them, I’ll have the parts necessary to go from designing a prototype to fabricating a prototype. Exploded View Part Numbers Top Enclosure Bottom Enclosure Raspberry Pi Battery Pack Screen Flash Drive Alignment Lip Battery Tray Mounting Rails Next up: Print enclosure Assemble real-world components Iterate on the design (if met with an obstacle during fabrication)"}, {"post_id": 10294, "ts": "2026-06-16T22:41:46Z", "hours": 1.4614, "text": "Devlog #1 — Initial Architecture and Packaging Study 🎉What I did this week: Defined system architecture for the cyberdeck (power, computer, input, output) Selected Raspberry Pi 4B as the main controller Created an initial system schematic/diagram to model subsystem interactions Performed a first packaging study in Onshape Verified that all core components fit within the proposed enclosure concept 🎚️Initial Schematic Note: This is a system-level schematic used to understand how components in the cyberdeck interact with each other, paired with a packaging study to estimate spatial requirements. This is an early-stage design exploration. The goal of this stage was to answer the question: What parts will Stardeck consist of, and how do they interact with one another? System Overview The cyberdeck is composed of four primary subsystems: Power Computer Input Output System Description Power subsystem: Provides energy to all other subsystems. This is the foundation of the system. Computer subsystem: The Raspberry Pi acts as the central controller, managing both input and output operations. Input subsystem: The keyboard is the primary input method. Additional input devices may be added later through USB expansion. Output subsystem: The display serves as the primary output device, showing system activity and user interface. 🪛Design Direction After reviewing publicly available cyberdeck designs, I decided on a compact tablet-like form factor. The current design consists of: A front-mounted display embedded into the case A Raspberry Pi and power bank mounted inside the enclosure behind the screen This configuration is chosen to prioritize reaching a functional MVP quickly. Future iterations may introduce improvements such as a rotating or laptop-style hinged display. 🔬Packaging Study Findings All dimensions are approximate and based on early-stage placeholder modeling. Units are in millimeters (length x width x height). Case: 230 x 160 x 40 Includes a cutout on the front face for the embedded display. Screen (initial placeholder): 200 x 120 x 15 Screen (final target, 7 inch): 155 x 87 x 15 Raspberry Pi 4B: 90 x 60 x 25 Slightly oversized in the model to account for cables, connectors, and mounting tolerance. Power bank: 110 x 70 x 20 Based on a typical 10,000 mAh USB battery. Final dimensions may change depending on selected model. Key Finding: The initial screen model was too large. The original estimate produced a diagonal of approximately 233 mm (about 9.2 inches), which did not match the intended 7 inch display size. After correction, the 155 x 87 mm screen model aligns with a 7 inch diagonal and is now used as the baseline for enclosure design. Current Conclusion The current enclosure design appears sufficient to house all core components based on the current placeholder assembly in Onshape. Remaining uncertainties primarily involve final battery selection and cable routing. 👣Next Steps Finalize selection of power bank Choose exact display model Begin KiCad schematic for wiring and power design Refine enclosure geometry in Onshape based on finalized components God bless you, Yodahe"}]...
|
Title: Stardeck by @YodaheWondimu | Stardance
Dev Title: Stardeck by @YodaheWondimu | Stardance
Devlogs:
Devlog #1 — Initial Architecture and Packaging Study 🎉What I did this week: Defined system architecture for the cyberdeck (power, computer, input, output) Selected Raspberry Pi 4B as the main controller Created an initial system schematic/diagram to model subsystem interactions Performed a first packaging study in Onshape Verified that all core components fit within the proposed enclosure concept 🎚️Initial Schematic Note: This is a system-level schematic used to understand how components in the cyberdeck interact with each other, paired with a packaging study to estimate spatial requirements. This is an early-stage design exploration. The goal of this stage was to answer the question: What parts will Stardeck consist of, and how do they interact with one another? System Overview The cyberdeck is composed of four primary subsystems: Power Computer Input Output System Description Power subsystem: Provides energy to all other subsystems. This is the foundation of the system. Computer subsystem: The Raspberry Pi acts as the central controller, managing both input and output operations. Input subsystem: The keyboard is the primary input method. Additional input devices may be added later through USB expansion. Output subsystem: The display serves as the primary output device, showing system activity and user interface. 🪛Design Direction After reviewing publicly available cyberdeck designs, I decided on a compact tablet-like form factor. The current design consists of: A front-mounted display embedded into the case A Raspberry Pi and power bank mounted inside the enclosure behind the screen This configuration is chosen to prioritize reaching a functional MVP quickly. Future iterations may introduce improvements such as a rotating or laptop-style hinged display. 🔬Packaging Study Findings All dimensions are approximate and based on early-stage placeholder modeling. Units are in millimeters (length x width x height). Case: 230 x 160 x 40 Includes a cutout on the front face for the embedded display. Screen (initial placeholder): 200 x 120 x 15 Screen (final target, 7 inch): 155 x 87 x 15 Raspberry Pi 4B: 90 x 60 x 25 Slightly oversized in the model to account for cables, connectors, and mounting tolerance. Power bank: 110 x 70 x 20 Based on a typical 10,000 mAh USB battery. Final dimensions may change depending on selected model. Key Finding: The initial screen model was too large. The original estimate produced a diagonal of approximately 233 mm (about 9.2 inches), which did not match the intended 7 inch display size. After correction, the 155 x 87 mm screen model aligns with a 7 inch diagonal and is now used as the baseline for enclosure design. Current Conclusion The current enclosure design appears sufficient to house all core components based on the current placeholder assembly in Onshape. Remaining uncertainties primarily involve final battery selection and cable routing. 👣Next Steps Finalize selection of power bank Choose exact display model Begin KiCad schematic for wiring and power design Refine enclosure geometry in Onshape based on finalized components God bless you, Yodahe
Devlog #2 - Component Assembly and Design Tuning This week, I was tuning my Stardeck designs to reach feasibility before submitting my design to Stardance for review. I started to test my initial design decisions using Onshape to model the spacing that each part would need, and I used that to finish up a component assembly that reflected how my parts would fit together in the real world. CAD Assembly Space was a critical factor in my cyberdeck because it was what everything inside of my enclosure lived on. Furthermore, my enclosure design evolved often to account for unanticipated constraints. A few of my enclosure features for Stardeck surprised me as I never even knew that I needed them at first. Clamshell Design: Remember how in the first devlog, I was considering using a rectangular prism with a carved-out back to house all the internal components? I found out very quickly that this would still make for a hard assembly once more than two parts came in. A clamshell design - top half, bottom half - would allow me to make the most of the space given because it would allow me to actually reach many parts of the internals. Alignment Lips: This took me a long time to conceptualize after hearing about these for the first time, but it became easy once I thought of a shoebox. The top of any shoebox fits on the bottom half and rests there - not because it’s screwed in place, but because the top half sort of wraps around the bottom half. These made the clamshell more robust as the “shoebox method” promised a safer screwdriver assembly as well. Mounting Rails: Placing the Raspberry Pi, which would be the basis of Stardeck’s computing subsystem, in the exact middle of the enclosure meant that other components - battery, screen, flash drive, etc - could reach it easily. However, it can’t just levitate, so it uses mounting rails to keep it up. The rails also come with holes for the Pi to be mounted onto for added security. Port Cutout: I felt so relieved after realizing that I needed this before shipping off all my CAD files to display on GitHub. The reason why was because it’s the hole in the enclosure that allows external cables to access the Pi’s USB ports. This makes essential functions such as swapping flash drives and connecting keyboards much easier. Overall, it’s a small design feature that makes assembly and maintenance much easier. System Architecture From the last devlog, we already knew how each component would connect to one another in practice. However, I found that for this iteration, the system could be modeled effectively at the subsystem level without a full PCB design or detailed electrical schematic. To follow, I created a System Architecture diagram to demonstrate how the parts of Stardeck interact with each other. After solving the electrical problem, I managed - with several days of me modeling components to depict and assemble - to solve the mechanical problem instead. Both were closely related to each other, which made for a lot of work when planning port maps, looking at diagrams of the port locations on a Raspberry Pi, finding components for the BOM that I want for my build, and so on. Summary I learned a lot about hardware selection, using Onshape to work around physical constraints, and building prototypes with future me in mind. I’m confident this design is ready to be submitted at its current state to Stardance. It’s simple and has just enough functionality without going overboard for a minimal viable product. With funding help from them, I’ll have the parts necessary to go from designing a prototype to fabricating a prototype. Exploded View Part Numbers Top Enclosure Bottom Enclosure Raspberry Pi Battery Pack Screen Flash Drive Alignment Lip Battery Tray Mounting Rails Next up: Print enclosure Assemble real-world components Iterate on the design (if met with an obstacle during fabrication)
Devlog #3 - Printing the Physical Enclosure Good news! This week, I managed to get my 3D printer up and running. Weeks of CAD work finally culminated in a pair of printed enclosure halves. Since I was going for a clamshell design for the first print, I printed both the top and bottom halves to see how they would go together. I knew I was technically doing this to test out tolerances and whatever, but I was secretly excited to be building something outside of Onshape for a change. Settings I mostly used my printer’s default profile, adding tree supports for the floating cantilever sections in the internal mounting rails. They printed cleanly and snapped away easily after fabrication. (Detailed slicer settings are documented separately in docs/printer_settings.md .) The only supports needed were for those mounting rails in the bottom half and the alignment lip on the top half. The results, as you’re about to see, went smoothly. Print Results Fresh off the 3D printer, I had both enclosure halves. The clamshell enclosure worked exactly how I’d hoped, and it seems like it will make disassembly easy enough to fill the internals with electronics (once I have them) and assembly easy enough to not irritate users. The alignment lips kept both halves aligned, and the lip mounting holes worked as a visual aid that told you whether or not each enclosure half was level or not - a perfect circle meant aligned, sliding semicircles meant you had to nudge it a bit. The other visible features - the display mounting area, port cutout, and battery tray - also turned out great. I was surprised to see the top half fit like a glove onto the bottom half first-try. After all, I’ve heard scary stories around an imaginary campfire where one tolerance requires reprinting everything (spooky). Luckily, no such thing happened here. And the mounting holes? They all came out exactly as modeled. The M3 holes on the alignment lips and the M2.5 holes on the display mounts and Pi rails matched the dimensions I designed. Considering how much I’d heard about tolerance problems, seeing everything line up on the first print felt like a small victory. When I Thought I Messed Up So…something happened. I noticed fringing filament that was sticking out of certain surfaces. I thought this would compromise the design’s integrity, and so I searched up the problem. After looking online, I found that this event was known as stringing, where melted filament can ooze from the nozzle during travel and solidify on top of whatever it lands on. I was relieved to figure out that this wasn’t a structural problem, but rather an aesthetic one, which I solved by clipping off any excess filament similar to the tree supports. Summary Printing the enclosure completely changed how the project felt. Up until this point, Stardeck had only existed inside Onshape. Holding both halves in my hands made it feel less like an idea and more like something I was actually going to finish. I don’t have my electronics just yet, but I believe that Hack Club’s funding process will give me the parts that I need to turn my idea into a reality. Speaking of the funding process, I’ve also spent a great deal of time in consecutive work sessions just documenting. I’ve been preparing my JOURNAL.md to showcase day-to-day summaries of progress, screenshotting my Onshape designs, and sharing my fabrication workflow. Steps like these are what allow a project to be considered for hardware grants later, which I need to receive the electronics that’ll make Stardeck a real cyberdeck. The enclosure may only be plastic for now, but it’s the first physical piece of Stardeck. Next comes the stage I’ve been designing around from the beginning: bringing it to life with actual hardware. Next Up: Finish up documentation/design tweaks Submit design for hardware funding Assemble components into the enclosure Craft a booting prototype?
Devlog #4: Iterating CAD for component assembly and adding necessary detail With the hardware flow open, I received feedback on my hardware project. A reviewer returned my funding request and advised me to work on adding more detail to my CAD model, since it’s important for actually putting the hardware together and makes CAD your best wingman. Detailed Assembly The detailed assembly would be close to the concept from Devlog #2, but: Instead of blocks for every hardware component, I’ll use open-source .step files as 1:1 reference models. If the model accurately represents the real part and tolerances are accounted for, Onshape fits should represent reality. (Attribution is given in docs/ATTRIBUTIONS.md in my GitHub repository.) Fasteners mattered now, so there was no more pairing of generic screws with generic nuts and calling it a day. The clearance holes from before weren’t as reliable as threaded bosses for mounting purposes, so I had to make replacements where necessary. Hardware Modeling and Fit Raspberry Pi 4B Importing the model for the Raspberry Pi 4B revealed an incorrect assumption. I assumed its 4 mounting holes sat near the corners of the board, but they were actually positioned differently. I adjusted the gap between the mounting rails to allow the Pi to rest and moved the mounting holes to where the Pi could line up on top of them, resulting in a mounting-aware pair of rails that I fastened shortly after. Elecrow RC070 7-inch Touchscreen Display I took the given file from its product page and merged its individual parts into one composite part. After composing, I added mounting holes matching those of the real component. The screen’s width fit perfectly into the top enclosure’s cutout (same width dimension), and with that, I added 0.5mm clearance to all sides of the top enclosure half’s screen cutout in case tolerance reality decides to strike my hardware. Anker Portable Charger/Power Bank This was where it got tricky. There was no available CAD model for the battery pack online, so I had to reverse engineer it myself. Our more realistic battery model had a length of ~153mm, while our placeholder had a length of ~115mm. Since our battery tray was initially modeled to fit snugly around the placeholder model (back when we just needed everything to fit together), our actual battery wasn’t going to fit. Our much more realistic model won over, and I reworked the battery tray with a looser but not as risky fit, centered closer to the side opposite the mounting rails of the inner enclosure’s bottom half. MicroCenter Flash Drive This part required some more of the same principle - reverse engineering - and having the flash drive with me made it easier to create a reference model. Dimensions that are reasonably close to the real thing in Onshape allow us to achieve the same purpose: testing the spacing and enclosure considerations of Stardeck. Challenges Reverse engineering the battery and flash drive was where I learned the most during this revision. I implemented the dimensions that were most relevant to each part’s size and connectivity (since I didn’t need 10/10 looks here) to concoct replicas that came pretty close to the real thing. I also had to design holes that would work with a custom Featurescript for threading. I tried to increase the thickness of certain sides with mounting holes for ThreadCreator’s sake, but what ended up working was switching to a similar Featurescript called BoazThread. What’s complete: Refined key details of the component assembly Related my enclosure hardware to 1:1 hardware models Reverse engineered parts without publicly available CAD models Next up: Refine design further (if required for funding) Receive physical parts Assemble Stardeck IRL Get Stardeck to boot...
|
1792731010.1167269
|
1793335810.1167269
|
|
25529
|
My very own WebOS by @jose_gurgel | Stardance
|
jose_gurgel
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @jose_gurgel | Stardan Title: My very own WebOS by @jose_gurgel | Stardance...
|
1792731009.285552
|
1793335809.285552
|
|
16820
|
Orbital Mechanics Visualizer by @duaesakinahasan | Orbital Mechanics Visualizer by @duaesakinahasan | Stardance...
|
duaesakinahasan
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Orbital Mechanics Visualizer by @duaesakina Title: Orbital Mechanics Visualizer by @duaesakinahasan | Stardance...
|
1792731008.4499586
|
1793335808.4499586
|
|
16260
|
My awesome macropad! by @Tobgamer | Stardance
|
Tobgamer
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Tobgamer | Stardan Title: My awesome macropad! by @Tobgamer | Stardance...
|
1792731007.6003668
|
1793335807.6003668
|