|
986
|
xp95 Atari by @xp95codes | Stardance
|
xp95codes
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: xp95 Atari by @xp95codes | Stardance
|
1792526137.9359877
|
1793130937.9359877
|
|
985
|
Starventure by @averyocean65 | Stardance
|
averyocean65
|
0
|
16.81
|
0
|
[]
|
[{"post_id": 7370, "ts": "2026 [{"post_id": 7370, "ts": "2026-06-12T09:00:57Z", "hours": 1.3567, "text": "I can’t find a solution that works for me with the default Unity Rigidbody system. So I have an idea.. What if I write my own? I could write my own physics system so I can have more control over how the velocity is calculated in an object. But, then I’d also need to do my own collision system logic, so I’ve been thinking… what if I make this game with a bareknuckles engine, like raylib? It honestly feels like it might be easier for me, since it would load and run faster than Unity, use way less resources which would let me develop quicker on my laptop. One can maybe see the Unity project as a prototype. It served the purpose of showcasing that I can figure out the necessities for making a game of this caliber, and to show me how much I dislike Unity’s physics system for this sort of work, especially with how my laptop interacts with Unity. I’m gonna look into a new engine for this project. And worst case, I’ll write one myself. Maybe I’ll just write my own physics engine in Unity so I can keep the comfort features of the engine. We’ll see. Happy coding."}, {"post_id": 5167, "ts": "2026-06-08T21:00:18Z", "hours": 1.1794, "text": "Phew, this took me a while, mainly because my school laptop is slow as heck! But, hey, now you can have rotating objects! As seen here, the player stays aligned with the object until it leaves the confines of the “atmosphere” of the spaceship, where you can then see the spaceship swing around the planet in an ellipse shape as it spins! How much fun! I also fixed a fix I made for the visitor system, as well as changing the crosshair (I’ll be adding interactables soon and so I want to have different crosshairs for when you can interact with something and when you can’t). Oh, and, I fixed the realignment code for the player to snap the player to the desired gravity after the while-loop is complete. This is mainly so if I adjust the realignment speed to something ridiculous that it will still result in the correct gravity being set. Anyhow, that is all for now. Have a lovely day fellas, and I hope me being sick doesn’t interfere with the development of this too much. Tomorrow I want to add interactables and an inventory system, although I should probably focus on the player movement rewrite. I guess we’ll see! Happy coding!"}, {"post_id": 4514, "ts": "2026-06-07T21:03:32Z", "hours": 2.7433, "text": "So, I’ve been working on two very cool things for Starventure in the past few days. First off, a sprinting system! Fairly obvious, you can sprint and you can drain stamina, just like the jetpack. Easy as that! Speaking of stamina, I changed the DepletableResource script to only accept drainers, because trying to balance drainers and restorers became very confusing and inefficient when you only had two systems using the same resource, so I fixed that, yay! I have also abstracted a good chunk of the gravity/planet system, so now we can have cool things such as homogeneous gravity fields! This is, as you can see, going to be used in space stations, because.. well it’d be weird if your gravity was spherical whilst you were standing on a plane, right? I’d definitely say so. So, what’s up next? Well, I do wanna work more on the player controller to fix a bug that’s been plaguing me a good deal ever since I made the player force-based, when I limit the player gravity, I also limit the fall speed and jetpack force of the player! This wouldn’t be an issue if I was using regular gravity systems, but due to the complexity of gravity that is ever-changing and affects multiple axes at times, I’ll have to think of a solution. My main idea right now is to either get rid of acceleration forces and only move the player through impulses, which means there’s no need for a speed limiter, or something else. Or calculating the actual gravity velocity at runtime and approximating the raw movement forces. Or maybe I just calculate the forces right then and there and call rb.AddForce with ForceMode.VelocityChange at each FixedUpdate call once.. … that last one seems the most doable. I’ll keep y’all in the loop. For now, I’ll work a bit on the camera rotation system, since travelling between gravity sources while your camera is rotating is… not fun. See y’all!"}, {"post_id": 2399, "ts": "2026-06-04T21:10:44Z", "hours": 3.3364, "text": "Alright, let’s do this. So, as I promised, I finally did something about the horrendous visuals of the past devlogs. Now, it’s still not the prettiest game ever, but I think the textures I got from ambientCG definitely make this more pleasing to look at! Also, I revamped the player movement and jumping… why? Because moving on moving planets didn’t work at all! So, now the player movement mainly consists of a bunch of wacky _rb.AddForce(…) calls, as well as a somewhat janky speed limiter that I definitely have to work on, or… I could call the slow falling speed a feature… let’s do that, it’s a feature of the jetpack now. Also, as I just mentioned, the jump has been replaced by a jetback! Now you can float around a planet… until your stamina (or fuel) runs out. Oh, right, that blue bar in the top left of the game view is the stamina bar, just incase you had no idea what it’s there for. So all of that definitely took me a considerable amount of time, especially since I had to wrap my mind around how I wanna handle jumping and gravity and limiting the player’s speed all at the same time. The system isn’t perfect, but, eh, screw it. Good enough. Now I will head off, talk with some friends, and maybe code more after that. But for now, I’m gonna take a break until tomorrow. Happy coding! And remember that you are all awesome!"}, {"post_id": 1703, "ts": "2026-06-03T21:20:38Z", "hours": 1.0617, "text": "Welp, this took me longer than I want to admit, but… you can finally jump between planets without your player’s view suddenly snapping and disorienting you. Now it still disorients you, but smoothly~ I’m very happy with how this is turning out and I am honestly just so glad I finally have this working, it was such a major headache. I really, really, wanted to use DOTween for this, but for the sake of me I cannot figure out how to make it work properly, actually writing this I have an idea. I’m gonna try that, but for now, I’m using a regular coroutine. Now, I’m getting bored of looking at these bland cubes, spheres and this default skybox. I wanna make it feel more like space. Time for dev art! Happy coding!"}, {"post_id": 1671, "ts": "2026-06-03T20:13:49Z", "hours": 2.2319, "text": "Alright, more stuff to showcase! This time I worked on an orbiting system, so I can make stuff spin around other stuff, how neat! I’m mainly going to be using this system for stuff like space stations, which I’ll add later on in development, or moons. Also, since I made it so the orbit ellipse is actually an ellipse! Which means I could make a full on solar system! I am planning to do that, btw, I made a whole visitor system which parents StellarObjects like the player or scrap you might drag along with you to the player they’re currently on (which is determind by if they’ve collided with the AtmosphereCollider). So, hey. Things are looking pretty good, if I do say so myself. Now, I’m gonna go fix up the system for changing the player rotation when you jump between planets. Happy coding!"}, {"post_id": 827, "ts": "2026-06-02T14:50:19Z", "hours": 3.2586, "text": "Alright! More stuff to showcase! Been doing lots of work on the player controller today, mainly trying to figure out how the heck to make it function properly. My first approach was to make a Rigidbody player controller like I did lots of times for my (failed) FPS projects. However, that resulted in my character either not moving, or slingshotting at mach 10 across space. And since it’s encouraged to post hilarious fails, here you go. First attachment is exactly that lol. Doing some research, I found that you can also move Rigidbody players via Rigidbody.MovePosition(…), so I opted for that instead. Then I added a jump, then some ground detection, and also (finally) a look controller so you can look around. Honestly, pretty proud of my work so far. Only issue is that at the very top of planets, your player gets locked into place and all they can do is spin uncontrollably. But, that’s an issue I’m going to fix soon, as well as some small visuals, like a better skybox. Also, you can hop between planets! I haven’t added camera smoothing to it yet, but it’s still super cool to do. Jumping off a planet’s atmosphere just to fly into another’s… so much fun! Maybe you’ll be able to do that with asteroids in the future or something… We’ll see! For now, thanks for reading, and happy coding!"}, {"post_id": 344, "ts": "2026-06-01T17:26:08Z", "hours": 0.4478, "text": "I added custom gravity, yay! It was honestly weirdly simple. The most complex part of it was honestly calculating the gravity vector for the rigidbody class. But now, I can have my cubes falling onto a planet, or even cruising through zero G! This is such a small thing, but it’s so exciting for me. Time to work on the player controller!"}, {"post_id": 226, "ts": "2026-06-01T10:34:39Z", "hours": 0.8183, "text": "Ok, I’ve been working on getting the StellarRigidbodies to detect when they enter a planet. For that I made a brand new AtmosphereCollider class, as well as a new tag, just so thinks set themselves up automatically. Now I just need to calculate the gravity vector and somehow apply it on the rigidbody and we should have (very basic) planet gravity working! Yay! Thanks for reading, and happy coding!"}, {"post_id": 217, "ts": "2026-06-01T09:36:53Z", "hours": 0.3786, "text": "Hello there! I’ve just started work on a project I’ve been meaning to work on for a long time… Starventure! Starventure is going to be a survival-sandbox game where you can explore procedurally generated space, like in No Man’s Sky! You’ll have to fly down to new planets to keep yourself alive, whilst also building settlements in the orbits of planets. Or at least, that’s the hope! Right now I’ve got a simple visualizer and outline for the PlanetGravity class working, soon this class will be used by StellarRigidbodies to figure out what kind of gravity should be applied to a physics object. Let’s hope this goes well, and happy coding! (also happy pride month!)"}]...
|
Title: Starventure by @averyocean65 | Stardance
D Title: Starventure by @averyocean65 | Stardance
Devlogs:
Hello there! I’ve just started work on a project I’ve been meaning to work on for a long time… Starventure! Starventure is going to be a survival-sandbox game where you can explore procedurally generated space, like in No Man’s Sky! You’ll have to fly down to new planets to keep yourself alive, whilst also building settlements in the orbits of planets. Or at least, that’s the hope! Right now I’ve got a simple visualizer and outline for the PlanetGravity class working, soon this class will be used by StellarRigidbodies to figure out what kind of gravity should be applied to a physics object. Let’s hope this goes well, and happy coding! (also happy pride month!)
Ok, I’ve been working on getting the StellarRigidbodies to detect when they enter a planet. For that I made a brand new AtmosphereCollider class, as well as a new tag, just so thinks set themselves up automatically. Now I just need to calculate the gravity vector and somehow apply it on the rigidbody and we should have (very basic) planet gravity working! Yay! Thanks for reading, and happy coding!
I added custom gravity, yay! It was honestly weirdly simple. The most complex part of it was honestly calculating the gravity vector for the rigidbody class. But now, I can have my cubes falling onto a planet, or even cruising through zero G! This is such a small thing, but it’s so exciting for me. Time to work on the player controller!
Alright! More stuff to showcase! Been doing lots of work on the player controller today, mainly trying to figure out how the heck to make it function properly. My first approach was to make a Rigidbody player controller like I did lots of times for my (failed) FPS projects. However, that resulted in my character either not moving, or slingshotting at mach 10 across space. And since it’s encouraged to post hilarious fails, here you go. First attachment is exactly that lol. Doing some research, I found that you can also move Rigidbody players via Rigidbody.MovePosition(…), so I opted for that instead. Then I added a jump, then some ground detection, and also (finally) a look controller so you can look around. Honestly, pretty proud of my work so far. Only issue is that at the very top of planets, your player gets locked into place and all they can do is spin uncontrollably. But, that’s an issue I’m going to fix soon, as well as some small visuals, like a better skybox. Also, you can hop between planets! I haven’t added camera smoothing to it yet, but it’s still super cool to do. Jumping off a planet’s atmosphere just to fly into another’s… so much fun! Maybe you’ll be able to do that with asteroids in the future or something… We’ll see! For now, thanks for reading, and happy coding!
Alright, more stuff to showcase! This time I worked on an orbiting system, so I can make stuff spin around other stuff, how neat! I’m mainly going to be using this system for stuff like space stations, which I’ll add later on in development, or moons. Also, since I made it so the orbit ellipse is actually an ellipse! Which means I could make a full on solar system! I am planning to do that, btw, I made a whole visitor system which parents StellarObjects like the player or scrap you might drag along with you to the player they’re currently on (which is determind by if they’ve collided with the AtmosphereCollider). So, hey. Things are looking pretty good, if I do say so myself. Now, I’m gonna go fix up the system for changing the player rotation when you jump between planets. Happy coding!
Welp, this took me longer than I want to admit, but… you can finally jump between planets without your player’s view suddenly snapping and disorienting you. Now it still disorients you, but smoothly~ I’m very happy with how this is turning out and I am honestly just so glad I finally have this working, it was such a major headache. I really, really, wanted to use DOTween for this, but for the sake of me I cannot figure out how to make it work properly, actually writing this I have an idea. I’m gonna try that, but for now, I’m using a regular coroutine. Now, I’m getting bored of looking at these bland cubes, spheres and this default skybox. I wanna make it feel more like space. Time for dev art! Happy coding!
Alright, let’s do this. So, as I promised, I finally did something about the horrendous visuals of the past devlogs. Now, it’s still not the prettiest game ever, but I think the textures I got from ambientCG definitely make this more pleasing to look at! Also, I revamped the player movement and jumping… why? Because moving on moving planets didn’t work at all! So, now the player movement mainly consists of a bunch of wacky _rb.AddForce(…) calls, as well as a somewhat janky speed limiter that I definitely have to work on, or… I could call the slow falling speed a feature… let’s do that, it’s a feature of the jetpack now. Also, as I just mentioned, the jump has been replaced by a jetback! Now you can float around a planet… until your stamina (or fuel) runs out. Oh, right, that blue bar in the top left of the game view is the stamina bar, just incase you had no idea what it’s there for. So all of that definitely took me a considerable amount of time, especially since I had to wrap my mind around how I wanna handle jumping and gravity and limiting the player’s speed all at the same time. The system isn’t perfect, but, eh, screw it. Good enough. Now I will head off, talk with some friends, and maybe code more after that. But for now, I’m gonna take a break until tomorrow. Happy coding! And remember that you are all awesome!
So, I’ve been working on two very cool things for Starventure in the past few days. First off, a sprinting system! Fairly obvious, you can sprint and you can drain stamina, just like the jetpack. Easy as that! Speaking of stamina, I changed the DepletableResource script to only accept drainers, because trying to balance drainers and restorers became very confusing and inefficient when you only had two systems using the same resource, so I fixed that, yay! I have also abstracted a good chunk of the gravity/planet system, so now we can have cool things such as homogeneous gravity fields! This is, as you can see, going to be used in space stations, because.. well it’d be weird if your gravity was spherical whilst you were standing on a plane, right? I’d definitely say so. So, what’s up next? Well, I do wanna work more on the player controller to fix a bug that’s been plaguing me a good deal ever since I made the player force-based, when I limit the player gravity, I also limit the fall speed and jetpack force of the player! This wouldn’t be an issue if I was using regular gravity systems, but due to the complexity of gravity that is ever-changing and affects multiple axes at times, I’ll have to think of a solution. My main idea right now is to either get rid of acceleration forces and only move the player through impulses, which means there’s no need for a speed limiter, or something else. Or calculating the actual gravity velocity at runtime and approximating the raw movement forces. Or maybe I just calculate the forces right then and there and call rb.AddForce with ForceMode.VelocityChange at each FixedUpdate call once.. … that last one seems the most doable. I’ll keep y’all in the loop. For now, I’ll work a bit on the camera rotation system, since travelling between gravity sources while your camera is rotating is… not fun. See y’all!
Phew, this took me a while, mainly because my school laptop is slow as heck! But, hey, now you can have rotating objects! As seen here, the player stays aligned with the object until it leaves the confines of the “atmosphere” of the spaceship, where you can then see the spaceship swing around the planet in an ellipse shape as it spins! How much fun! I also fixed a fix I made for the visitor system, as well as changing the crosshair (I’ll be adding interactables soon and so I want to have different crosshairs for when you can interact with something and when you can’t). Oh, and, I fixed the realignment code for the player to snap the player to the desired gravity after the while-loop is complete. This is mainly so if I adjust the realignment speed to something ridiculous that it will still result in the correct gravity being set. Anyhow, that is all for now. Have a lovely day fellas, and I hope me being sick doesn’t interfere with the development of this too much. Tomorrow I want to add interactables and an inventory system, although I should probably focus on the player movement rewrite. I guess we’ll see! Happy coding!
I can’t find a solution that works for me with the default Unity Rigidbody system. So I have an idea.. What if I write my own? I could write my own physics system so I can have more control over how the velocity is calculated in an object. But, then I’d also need to do my own collision system logic, so I’ve been thinking… what if I make this game with a bareknuckles engine, like raylib? It honestly feels like it might be easier for me, since it would load and run faster than Unity, use way less resources which would let me develop quicker on my laptop. One can maybe see the Unity project as a prototype. It served the purpose of showcasing that I can figure out the necessities for making a game of this caliber, and to show me how much I dislike Unity’s physics system for this sort of work, especially with how my laptop interacts with Unity. I’m gonna look into a new engine for this project. And worst case, I’ll write one myself. Maybe I’ll just write my own physics engine in Unity so I can keep the comfort features of the engine. We’ll see. Happy coding....
|
1792565352.900176
|
1793170152.900176
|
|
984
|
EVENT HORIZON by @Yourhomie | Stardance
|
Yourhomie
|
0
|
5.41
|
0
|
[]
|
[{"post_id": 9883, "ts": "2026 [{"post_id": 9883, "ts": "2026-06-16T11:10:29Z", "hours": 0.9714, "text": "hey ! again looks like there is no one watching ,y progress no worries i will still devlog because its hard to not share this is my 3 rd devlog , i am working on project event horizon a 3d interactive web project for control the giants of universe like wormhole and black holes with some other funs like stars , galaxy etc. the second big hurdle the travel motion of the owrmhole is completed the travel from galaxy a to b get ready to get a bit hynosis by the fading and circular motion in the gameplay . despite being a project which require big and heavy gpu to process the black hole and wormhole i have made it simply lovely by applying the correct physics but also having good hader graphics which can easily soothe your gpu without getting the fans on overhaul🤣. this is the video of the wormhole travel see for youself and once again dont get hypnotized by it and starting to dreamwalk 😂🤣🤣. project currently in making , status dev -3 ."}, {"post_id": 5663, "ts": "2026-06-09T15:18:27Z", "hours": 3.355, "text": "good news the black hole rendering code worked , i thought the marching effects would cook my gpu but it somehow help up. the wormhole is currently in making ."}, {"post_id": 225, "ts": "2026-06-01T10:34:31Z", "hours": 1.0886, "text": "A cool space and universe simulator with simulation to interact like black holes , wormholes , galaxy , and even goverming those scary equations of sir. Einstein. bear you gpu for some feat because this simulation uses real time equation solving to give the best simulation possible on your device . currently in making ."}]...
|
Title: EVENT HORIZON by @Yourhomie | Stardance
De Title: EVENT HORIZON by @Yourhomie | Stardance
Devlogs:
A cool space and universe simulator with simulation to interact like black holes , wormholes , galaxy , and even goverming those scary equations of sir. Einstein. bear you gpu for some feat because this simulation uses real time equation solving to give the best simulation possible on your device . currently in making .
good news the black hole rendering code worked , i thought the marching effects would cook my gpu but it somehow help up. the wormhole is currently in making .
hey ! again looks like there is no one watching ,y progress no worries i will still devlog because its hard to not share this is my 3 rd devlog , i am working on project event horizon a 3d interactive web project for control the giants of universe like wormhole and black holes with some other funs like stars , galaxy etc. the second big hurdle the travel motion of the owrmhole is completed the travel from galaxy a to b get ready to get a bit hynosis by the fading and circular motion in the gameplay . despite being a project which require big and heavy gpu to process the black hole and wormhole i have made it simply lovely by applying the correct physics but also having good hader graphics which can easily soothe your gpu without getting the fans on overhaul🤣. this is the video of the wormhole travel see for youself and once again dont get hypnotized by it and starting to dreamwalk 😂🤣🤣. project currently in making , status dev -3 ....
|
1792688033.4240205
|
1793292833.4240205
|
|
983
|
BAYMAX by @not_BPS | Stardance
|
not_BPS
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: BAYMAX by @not_BPS | Stardance
|
1792565466.4369223
|
1793170266.4369223
|
|
982
|
Untitled by @xp95_dude | Stardance
|
xp95_dude
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @xp95_dude | Stardance
|
1792680755.3405619
|
1793285555.3405619
|
|
981
|
2DPX by @QKing | Stardance
|
QKing
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: 2DPX by @QKing | Stardance
|
1792489780.7132776
|
1793094580.7132776
|
|
980
|
My awesome macropad! by @xp95_dude | Stardance
|
xp95_dude
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @xp95_dude | Starda Title: My awesome macropad! by @xp95_dude | Stardance...
|
1792799627.0794532
|
1793404427.0794532
|
|
979
|
Chess 2 by @kalabros64 | Stardance
|
kalabros64
|
0
|
1.19
|
0
|
[]
|
[{"post_id": 613, "ts": "2026- [{"post_id": 613, "ts": "2026-06-02T03:34:33Z", "hours": 1.1894, "text": "Made board generate based on a Width and Row. It can also ignore specific tiles if needed"}]...
|
Title: Chess 2 by @kalabros64 | Stardance
Devlogs Title: Chess 2 by @kalabros64 | Stardance
Devlogs:
Made board generate based on a Width and Row. It can also ignore specific tiles if needed...
|
1792713219.949977
|
1793318019.949977
|
|
978
|
Untitled project by @aiden | Stardance
|
aiden
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @aiden | Stardance
|
1792648345.5215175
|
1793253145.5215175
|
|
977
|
Untitled project by @itzstt | Stardance
|
itzstt
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @itzstt | Stardance
|
1792615922.0617266
|
1793220722.0617266
|
|
976
|
CCPLOS by @QKing | Stardance
|
QKing
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: CCPLOS by @QKing | Stardance
|
1792497231.589814
|
1793102031.589814
|
|
975
|
JevTalk by @ciaran | Stardance
|
ciaran
|
0
|
5.19
|
0
|
[]
|
[{"post_id": 79672, "ts": "202 [{"post_id": 79672, "ts": "2026-10-15T01:01:48Z", "hours": 0.8447, "text": "The web interface is now in full working order, so now it’s time to make it look pretty."}, {"post_id": 79663, "ts": "2026-10-14T23:56:22Z", "hours": 0.9208, "text": "OHHHH, that’s why it was talking to itself."}, {"post_id": 78003, "ts": "2026-10-09T04:36:29Z", "hours": 3.4222, "text": "I’ve got the main groundwork done. At first i tried just having a model consult Jev but it was really just the model talking, so i had jev select each word from a pool given by 6 luna. After that, sometimes Jev’d start responding as the user, but its mostly fixed. Plus, its so earnest that its kinda just cute. Just needs a web UI."}]...
|
Title: JevTalk by @ciaran | Stardance
Devlogs:
I’ Title: JevTalk by @ciaran | Stardance
Devlogs:
I’ve got the main groundwork done. At first i tried just having a model consult Jev but it was really just the model talking, so i had jev select each word from a pool given by 6 luna. After that, sometimes Jev’d start responding as the user, but its mostly fixed. Plus, its so earnest that its kinda just cute. Just needs a web UI.
OHHHH, that’s why it was talking to itself.
The web interface is now in full working order, so now it’s time to make it look pretty....
|
1792716632.18975
|
1793321432.18975
|
|
974
|
My first slack bot! by @Dhyan | Stardance
|
Dhyan
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @Dhyan | Stardance
|
1792734459.0071332
|
1793339259.0071332
|
|
973
|
My first slack bot! by @obob | Stardance
|
obob
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @obob | Stardance
|
1792522160.042375
|
1793126960.042375
|
|
972
|
M’groq by @Trick | Stardance
|
Trick
|
0
|
3.39
|
0
|
[]
|
[{"post_id": 1673, "ts": "2026 [{"post_id": 1673, "ts": "2026-06-03T20:20:34Z", "hours": 0.6069, "text": "i’ve fixed the calculator thingy and by doing so it’s not going to meet any similar problems in the futre i think i’ll release a demo soon (probably going to do a long session after this to improve everything)"}, {"post_id": 1048, "ts": "2026-06-02T21:03:50Z", "hours": 1.4656, "text": "i’ve implemnted file creation, app opening AND website opening, nearly went mad but did it (groq has a passion for calculator tools and refuses to open the normal calculator if i don’t find a solution i’ll ban calculator tools)"}, {"post_id": 747, "ts": "2026-06-02T11:41:28Z", "hours": 1.3153, "text": "i managed to get him working and talking in a pretty natural way and integrated voice, next step is to make sure he can create files on desktop, he’s pretty good at learning so far with all the chats we’ve done. also he creates a file at the tasrt of a chat and stores all chats there so that he remembers (this one is a demo so i started with a new chat)"}]...
|
Title: M’groq by @Trick | Stardance
Devlogs:
i ma Title: M’groq by @Trick | Stardance
Devlogs:
i managed to get him working and talking in a pretty natural way and integrated voice, next step is to make sure he can create files on desktop, he’s pretty good at learning so far with all the chats we’ve done. also he creates a file at the tasrt of a chat and stores all chats there so that he remembers (this one is a demo so i started with a new chat)
i’ve implemnted file creation, app opening AND website opening, nearly went mad but did it (groq has a passion for calculator tools and refuses to open the normal calculator if i don’t find a solution i’ll ban calculator tools)
i’ve fixed the calculator thingy and by doing so it’s not going to meet any similar problems in the futre i think i’ll release a demo soon (probably going to do a long session after this to improve everything)...
|
1792478962.6879306
|
1793083762.6879306
|
|
971
|
PFP MAKER by @siddharthan | Stardance
|
siddharthan
|
0
|
9.12
|
0
|
[]
|
[{"post_id": 4168, "ts": "2026 [{"post_id": 4168, "ts": "2026-06-07T11:51:56Z", "hours": 9.1181, "text": "Heya! Guys, take a look at the pfp maker that I made for beest!"}]...
|
Title: PFP MAKER by @siddharthan | Stardance
Devl Title: PFP MAKER by @siddharthan | Stardance
Devlogs:
Heya! Guys, take a look at the pfp maker that I made for beest!...
|
1792738277.1819127
|
1793343077.1819127
|
|
970
|
My awesome macropad! by @rx76d | Stardance
|
rx76d
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @rx76d | Stardance
|
1792914764.9621553
|
1793778764.9621553
|
|
969
|
Kerr Simulator by @krazyminer001 | Stardance
|
krazyminer001
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Kerr Simulator by @krazyminer001 | Stardanc Title: Kerr Simulator by @krazyminer001 | Stardance...
|
1792507990.342979
|
1793112790.342979
|
|
968
|
Yerba Linux by @ArslaanPathan | Stardance
|
ArslaanPathan
|
0
|
32.13
|
0
|
[]
|
[{"post_id": 66974, "ts": "202 [{"post_id": 66974, "ts": "2026-09-12T23:36:05Z", "hours": 2.4903, "text": "NETWORKING WORKS. LET’S GO YEAHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!! I GOT IT TO FETCH A DNF REPO Oh and I also just happened to discover that DNF WONT WORK AS MY PM EITHER SO NOW IM SCRAMBLING TO FIND A WORKING ROOTLESS PACKAGE MANAGER BEFORE STARDANCE ENDS ON SEPTEMBER 30TH IVE ALREADY BURNT LIKE A WEEK ON THIS RAAAAAAAAAAAAAAAAAA"}, {"post_id": 63291, "ts": "2026-09-07T01:18:06Z", "hours": 3.5978, "text": "I spent AGES trying to get pkgsrc to work as the package manager. It does NOT build in Yocto. I TAKE BACK EVERYTHING GOOD I SAID ABOUT PKGSRC THE BUILD SYSTEM IS SO SHIT AND IT DOESNT WORK AND IT USES NON STANDARD BUILD AND AAAAHHHHHHHHHHHHHHHHHHHHHH REST IN PISS PKGSRC YOU WILL NOT BE MISSED I ended up using DNF/RPM (yes, the package manager from Fedora!) You will see in the screenshot below that DNF is failing to update repos, that’s because I kind of forgot to get networking working before trying the package manager (also using Fedora repo just for testing, will not be in final one)"}, {"post_id": 59879, "ts": "2026-09-01T21:18:01Z", "hours": 2.7003, "text": "Goodbye GNU, hello BSD! I spent some time modifying my Linux distro BitBake/Yocto recipes to migrate from GNU coreutils (and BusyBox) to FreeBSD coreutils, specifically chimerautils, the ported FreeBSD core utilities used in Chimera Linux. I did this to add some extra security (*BSD is normally more security-focused and scrutinized, afaik) and to align a bit more with UNIX philosophy ^_^"}, {"post_id": 57223, "ts": "2026-08-29T10:09:19Z", "hours": 0.4067, "text": "I spent a LOT of time debugging the build system. Last time I worked on this was 2 months ago, and that was before I switched to Void Linux (musl) from Gentoo. Logged time for this devlog is so low because it’s 99% debugging black magic logs and 1% of actually modifying the configs. Lessons learned: don’t trust the GNU mirrors. don’t trust BitBake to do its job, and don’t set a custom DL_DIR for BitBake because it will not use it properly and cause issues. also do not do Yocto development on musl libc. It turns out that Yocto compilation also just dies on musl so I’m now running the build in Docker (recurring theme with my projects, isn’t it?) I think I’ve almost got the build to start working again, just need to fix some locales in the Docker container and we should be good to go!"}, {"post_id": 56916, "ts": "2026-08-28T22:45:52Z", "hours": 0.7997, "text": "Switching the focus of this project Hey everyone! I know I’ve been gone for a while, I’ve been distracted by many other projects and ideas and also trying to work on the package manager for this distro. (got distracted with that too) I’m not sure what this logged time on this devlog is for, it might be for some few changes I didn’t devlog last time I worked on this project. I think I’m going to switch the focus of this distro from here, to not just be minimalist and a knockoff of Void, but to be a Void-like minimalist distro with secureblue/GrapheneOS-level security. It’s probably going to be hard to pull off but I think it will be worth it. Thanks all!"}, {"post_id": 12730, "ts": "2026-06-20T20:07:43Z", "hours": 0.5997, "text": "I DID IT IT WORKS I CAN LOGIN AS YERBA NOW WITH THE PASSWORD yerba !!!! it was PAM. it’s always PAM. I just needed to install PAM."}, {"post_id": 12294, "ts": "2026-06-20T02:01:10Z", "hours": 0.9867, "text": "I got it to run QEMU with a graphical window, AND I also made a logo!!! I followed the guide from https://anchor.hackclub.com to make this logo, thanks Anchor! I am still trying to figure out why login for yerba doesnt work"}, {"post_id": 11850, "ts": "2026-06-19T08:51:15Z", "hours": 4.0556, "text": "I’ve got privilege escalation to work along with networking (dhcpcd) and am working on getting audio to work! I’m trying to make a non-root user with a password, for some reason Yocto is yelling at me a lot (its been hours, helpppp) (p.s. I do not have a relevant screenshot at the moment, and it has been a long day, so here is a filler red gradient that I have for some reason)"}, {"post_id": 9804, "ts": "2026-06-16T07:29:06Z", "hours": 4.7003, "text": "Sorry I haven’t been devlogging for a while! I got way too focused on getting back to where I was before on the new Yocto build system! I have got Yocto to create a working rootfs and load the runit init system!"}, {"post_id": 6720, "ts": "2026-06-11T08:00:22Z", "hours": 0.4353, "text": "Yep, another clean slate it is. This time, it’s Yocto, and it’s here to stay (insha allah)."}, {"post_id": 6696, "ts": "2026-06-11T06:54:34Z", "hours": 1.7858, "text": "I HATE YOu NIX. AAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAAAAAAAAA STOP LINKING AGAINST /NIX/STORE PATHS iknow nix is meant to be a package manager but WHAT OTHER OPTIONS DO I HAVEEEEE MAKEFILE IS SCUFFED, BUILDROOT IS MORE EMBEDDED, ETC atp im just gonna switch off of nix (yes, clean slate for the distro V2…. yay.. /s) (i mean i guess i wont be fighting with nix)"}, {"post_id": 6114, "ts": "2026-06-10T08:57:58Z", "hours": 0.2614, "text": "IT WORKS IT WORKS IT WORKS THE INIT SYSTEM DOES THE THING AND SHOWS GETTY RUNIT WORKS IT WORKS!!!!!!!!!!!! Edit: The solution was to launch /usr/bin/runit directly instead of using /usr/bin/runit-init. This is not necessarily correct, but /usr/bin/runit-init is currently broken due to Nixpkgs assuming this is a Nix-based distro when it is not. Insha allah later during the development cycle, I will replace the Nixpkgs flake with my own flake that accounts for this. For now, too bad, the distro boots"}, {"post_id": 6108, "ts": "2026-06-10T08:40:27Z", "hours": 1.5533, "text": "I’ve got musl to load into the initramfs, and am working on adding runit as the init system I am very confused as to why runit fails to switch_root, the error is very cryptic EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}, {"post_id": 5436, "ts": "2026-06-09T06:30:38Z", "hours": 0.7472, "text": "I GOT THE THING TO WORK!! THE GRAPHICAL TTY!! are you serious rn, it was a single kernel config opt. i spent very very long debugging this. a lot longer than i anticipated. BUT STILL IT WORKED YAYAYAYAYAYAYAYAYAYAY"}, {"post_id": 4766, "ts": "2026-06-08T07:26:58Z", "hours": 1.5283, "text": "IT BOOTS!!! IT FREAKING BOOTS!!!!! THE BUSYBOX BUILD WORKS!! THE ROOTFS BUILDS!! IT LOADS THE SQUASHFS WITH OVERLAYFS!!!! YAYAYAYAYAYAYAYAY"}, {"post_id": 3995, "ts": "2026-06-07T04:15:08Z", "hours": 0.9253, "text": "Made a lot of refactors, and added placeholder targets Also got the kernel build to work!!"}, {"post_id": 3931, "ts": "2026-06-07T01:48:43Z", "hours": 1.7028, "text": "Made a clean slate and switched my distro’s build system to Nix for reproducibility and to get away from my Makefile that used scuffed hacks This doesn’t mean my distro will use Nix or be like NixOS, but it will help improve development speed and quality Finally got it to nix build an initramfs without errors!"}, {"post_id": 714, "ts": "2026-06-02T09:30:38Z", "hours": 1.2764, "text": "Finally got it to create a live ISO and boot with Limine!!!!"}, {"post_id": 681, "ts": "2026-06-02T07:32:05Z", "hours": 0.8617, "text": "Did a bit of debugging and testing, and got the initramfs to boot. TODO: Make it create a squashfs root"}, {"post_id": 232, "ts": "2026-06-01T11:00:28Z", "hours": 0.7181, "text": "Got a basic build system working for my in-progress distro, Yerba Linux Builds the Linux kernel, BusyBox, and creates a minimal BusyBox initramfs that drops you to a shell TODO: Make it create an ISO with GRUB/any bootloader"}]...
|
Title: Yerba Linux by @ArslaanPathan | Stardance
Title: Yerba Linux by @ArslaanPathan | Stardance
Devlogs:
Got a basic build system working for my in-progress distro, Yerba Linux Builds the Linux kernel, BusyBox, and creates a minimal BusyBox initramfs that drops you to a shell TODO: Make it create an ISO with GRUB/any bootloader
Did a bit of debugging and testing, and got the initramfs to boot. TODO: Make it create a squashfs root
Finally got it to create a live ISO and boot with Limine!!!!
Made a clean slate and switched my distro’s build system to Nix for reproducibility and to get away from my Makefile that used scuffed hacks This doesn’t mean my distro will use Nix or be like NixOS, but it will help improve development speed and quality Finally got it to nix build an initramfs without errors!
Made a lot of refactors, and added placeholder targets Also got the kernel build to work!!
IT BOOTS!!! IT FREAKING BOOTS!!!!! THE BUSYBOX BUILD WORKS!! THE ROOTFS BUILDS!! IT LOADS THE SQUASHFS WITH OVERLAYFS!!!! YAYAYAYAYAYAYAYAY
I GOT THE THING TO WORK!! THE GRAPHICAL TTY!! are you serious rn, it was a single kernel config opt. i spent very very long debugging this. a lot longer than i anticipated. BUT STILL IT WORKED YAYAYAYAYAYAYAYAYAYAY
I’ve got musl to load into the initramfs, and am working on adding runit as the init system I am very confused as to why runit fails to switch_root, the error is very cryptic EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
IT WORKS IT WORKS IT WORKS THE INIT SYSTEM DOES THE THING AND SHOWS GETTY RUNIT WORKS IT WORKS!!!!!!!!!!!! Edit: The solution was to launch /usr/bin/runit directly instead of using /usr/bin/runit-init. This is not necessarily correct, but /usr/bin/runit-init is currently broken due to Nixpkgs assuming this is a Nix-based distro when it is not. Insha allah later during the development cycle, I will replace the Nixpkgs flake with my own flake that accounts for this. For now, too bad, the distro boots
I HATE YOu NIX. AAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAAAAAAAAA STOP LINKING AGAINST /NIX/STORE PATHS iknow nix is meant to be a package manager but WHAT OTHER OPTIONS DO I HAVEEEEE MAKEFILE IS SCUFFED, BUILDROOT IS MORE EMBEDDED, ETC atp im just gonna switch off of nix (yes, clean slate for the distro V2…. yay.. /s) (i mean i guess i wont be fighting with nix)
Yep, another clean slate it is. This time, it’s Yocto, and it’s here to stay (insha allah).
Sorry I haven’t been devlogging for a while! I got way too focused on getting back to where I was before on the new Yocto build system! I have got Yocto to create a working rootfs and load the runit init system!
I’ve got privilege escalation to work along with networking (dhcpcd) and am working on getting audio to work! I’m trying to make a non-root user with a password, for some reason Yocto is yelling at me a lot (its been hours, helpppp) (p.s. I do not have a relevant screenshot at the moment, and it has been a long day, so here is a filler red gradient that I have for some reason)
I got it to run QEMU with a graphical window, AND I also made a logo!!! I followed the guide from https://anchor.hackclub.com to make this logo, thanks Anchor! I am still trying to figure out why login for yerba doesnt work
I DID IT IT WORKS I CAN LOGIN AS YERBA NOW WITH THE PASSWORD yerba !!!! it was PAM. it’s always PAM. I just needed to install PAM.
Switching the focus of this project Hey everyone! I know I’ve been gone for a while, I’ve been distracted by many other projects and ideas and also trying to work on the package manager for this distro. (got distracted with that too) I’m not sure what this logged time on this devlog is for, it might be for some few changes I didn’t devlog last time I worked on this project. I think I’m going to switch the focus of this distro from here, to not just be minimalist and a knockoff of Void, but to be a Void-like minimalist distro with secureblue/GrapheneOS-level security. It’s probably going to be hard to pull off but I think it will be worth it. Thanks all!
I spent a LOT of time debugging the build system. Last time I worked on this was 2 months ago, and that was before I switched to Void Linux (musl) from Gentoo. Logged time for this devlog is so low because it’s 99% debugging black magic logs and 1% of actually modifying the configs. Lessons learned: don’t trust the GNU mirrors. don’t trust BitBake to do its job, and don’t set a custom DL_DIR for BitBake because it will not use it properly and cause issues. also do not do Yocto development on musl libc. It turns out that Yocto compilation also just dies on musl so I’m now running the build in Docker (recurring theme with my projects, isn’t it?) I think I’ve almost got the build to start working again, just need to fix some locales in the Docker container and we should be good to go!
Goodbye GNU, hello BSD! I spent some time modifying my Linux distro BitBake/Yocto recipes to migrate from GNU coreutils (and BusyBox) to FreeBSD coreutils, specifically chimerautils, the ported FreeBSD core utilities used in Chimera Linux. I did this to add some extra security (*BSD is normally more security-focused and scrutinized, afaik) and to align a bit more with UNIX philosophy ^_^
I spent AGES trying to get pkgsrc to work as the package manager. It does NOT build in Yocto. I TAKE BACK EVERYTHING GOOD I SAID ABOUT PKGSRC THE BUILD SYSTEM IS SO SHIT AND IT DOESNT WORK AND IT USES NON STANDARD BUILD AND AAAAHHHHHHHHHHHHHHHHHHHHHH REST IN PISS PKGSRC YOU WILL NOT BE MISSED I ended up using DNF/RPM (yes, the package manager from Fedora!) You will see in the screenshot below that DNF is failing to update repos, that’s because I kind of forgot to get networking working before trying the package manager (also using Fedora repo just for testing, will not be in final one)
NETWORKING WORKS. LET’S GO YEAHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!! I GOT IT TO FETCH A DNF REPO Oh and I also just happened to discover that DNF WONT WORK AS MY PM EITHER SO NOW IM SCRAMBLING TO FIND A WORKING ROOTLESS PACKAGE MANAGER BEFORE STARDANCE ENDS ON SEPTEMBER 30TH IVE ALREADY BURNT LIKE A WEEK ON THIS RAAAAAAAAAAAAAAAAAA...
|
1792677065.8179553
|
1793281865.8179553
|
|
967
|
DartLedger by @kiri | Stardance
|
kiri
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: DartLedger by @kiri | Stardance
|
1792604903.7096164
|
1793209703.7096164
|
|
966
|
NULL
|
NULL
|
0
|
0.0
|
0
|
[]
|
[]
|
|
1792939656.4251943
|
1793803656.4251943
|
|
965
|
My first slack bot! by @kiri | Stardance
|
kiri
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @kiri | Stardance
|
1792777776.00065
|
1793382576.00065
|
|
964
|
My first slack bot! by @PhoenixFire | Stardance
|
PhoenixFire
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @PhoenixFire | Stard Title: My first slack bot! by @PhoenixFire | Stardance...
|
1792529457.3467653
|
1793134257.3467653
|
|
963
|
CLADES by @onyxtheone | Stardance
|
onyxtheone
|
1
|
14.46
|
262
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-02T21:06:45Z", "hours": 14.0, "multiplier": 18.66, "payout": 262, "blessing": "neutral", "text": "I made a disease epidemiology simulator, and then extended it with age stratification and multiple strain support. A major challenge was figuring out the math behind it and pulling it together at each new component. I am proud to say that, as far as I know, the data is actually worthwhile and should track with reality, but I am not an epidemiologist. I made a simple site for people to check it out, and if you want to try it properly you can build from source (P.S. Its just 2 commands:))) )", "repo": "https://github.com/onyx-the-one/CLADES", "demo": "https://onyx-the-one.github.io/CLADES/clades.html"}]...
|
[{"post_id": 4887, "ts": "2026 [{"post_id": 4887, "ts": "2026-06-08T13:33:09Z", "hours": 0.4636, "text": "As advised by @Amu I made the README nicer, font bigger, and put compiled packages on github via actions."}, {"post_id": 1047, "ts": "2026-06-02T21:00:34Z", "hours": 2.1097, "text": "Fixed some text alignment, and the multistrain component giving completely wrong results. Everything actually (seemingly) works pretty well."}, {"post_id": 905, "ts": "2026-06-02T17:12:43Z", "hours": 4.3306, "text": "Worked on support for multistrain, and while it is somewhat implemented it gonna stay off main branch, theres a lot left to do with it."}, {"post_id": 515, "ts": "2026-06-02T00:07:59Z", "hours": 4.4047, "text": "I implemented age stratification as a separate mode, and will work on integrating them more closely. Very minor text alignment issues left but it is time to sleep."}, {"post_id": 309, "ts": "2026-06-01T15:57:13Z", "hours": 3.1822, "text": "I wrote the core architecture of the simulator, with almost no larger features yet but it should be functional. I have also ran into a build error and fixed it and now built successfully (with 1 error)."}]...
|
Title: CLADES by @onyxtheone | Stardance
Devlogs: Title: CLADES by @onyxtheone | Stardance
Devlogs:
I wrote the core architecture of the simulator, with almost no larger features yet but it should be functional. I have also ran into a build error and fixed it and now built successfully (with 1 error).
I implemented age stratification as a separate mode, and will work on integrating them more closely. Very minor text alignment issues left but it is time to sleep.
Worked on support for multistrain, and while it is somewhat implemented it gonna stay off main branch, theres a lot left to do with it.
Fixed some text alignment, and the multistrain component giving completely wrong results. Everything actually (seemingly) works pretty well.
As advised by @Amu I made the README nicer, font bigger, and put compiled packages on github via actions.
Ships:
I made a disease epidemiology simulator, and then extended it with age stratification and multiple strain support. A major challenge was figuring out the math behind it and pulling it together at each new component. I am proud to say that, as far as I know, the data is actually worthwhile and should track with reality, but I am not an epidemiologist. I made a simple site for people to check it out, and if you want to try it properly you can build from source (P.S. Its just 2 commands:))) )...
|
1792875203.5267386
|
1793739203.5267386
|
|
962
|
My awesome macropad! by @PhoenixFire | Stardance
|
PhoenixFire
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @PhoenixFire | Star Title: My awesome macropad! by @PhoenixFire | Stardance...
|
1792673313.6861966
|
1793278113.6861966
|
|
961
|
SkyBlock Weapons by @lily | Stardance
|
lily
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: SkyBlock Weapons by @lily | Stardance
|
1792540059.5071633
|
1793144859.5071633
|
|
960
|
Biothesiometer by @aaditrai | Stardance
|
aaditrai
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Biothesiometer by @aaditrai | Stardance
|
1792655683.729059
|
1793260483.729059
|
|
959
|
Ebeep by @Avizi | Stardance
|
Avizi
|
1
|
85.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-23T10:29:40Z", "hours": 85.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "my project is a “beeper” with an eink display, it features three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday later this month!", "repo": "https://github.com/Av1zi/Ebeep", "demo": ""}]...
|
[{"post_id": 33374, "ts": "202 [{"post_id": 33374, "ts": "2026-07-23T07:45:06Z", "hours": 11.1325, "text": "Devlog #18 - The Final One my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I built two of them and gifted one to my GF for her birthday! so this is it, the last devlog for Ebeep. i finished the Blender showcase animation, check it out ⬇️⬇️⬇️ took way longer than expected since I’ve never really used blender for anything like this before, but I’m happy with how it turned out. (or kicad) as for the PCB, the design is fully done, routed, and ready to export to gerbers, but I decided not to actually order it right now. the perfboard build already works and does the job, and the PCB was mostly a “because I can” side project once I started documenting everything (devlog #16 lol). might revisit it in the future if I ever want to build a v2 or make more of these, but for now the current build is what’s shipping as “done.” looking back this project went through basically everything a project can go through: missed deadlines, a broken 3d printer, a bug that silently deleted my girlfriend’s messages for a week without me noticing, failed prints, finals eating my motivation and somehow it still came out the other side working, on both devices, doing everything I wanted it to do. if I had to do it again I’d probably: start the PCB earlier instead of perfboard + rework set up proper MQTT retained-message handling from day one instead of patching it in later. budget way more time for the case than I did CAD alone ate multiple redesigns and i still needed help from my friend to finish it i really need to work on my CAD skills but honestly, for a project that started as “let’s port some code to an esp32 I’m scared to solder,” I’m really proud of where it landed. whats next? id really love to keep working and making it the best i can (the 3d render is really rough as i had to finish it TODAY and some of the code is still messy), but realistically, nothing planned this is the ‘finish’ line. maybe a better PCB with a good showcase with cleaner code and a case that actually houses the PCB someday, maybe not. either way, thanks to everyone who followed along since the start. TL;DR finished the showcase render, PCB design is complete but staying unbuilt for now, and the project is officially ‘done’. thanks for reading 🎉"}, {"post_id": 32922, "ts": "2026-07-22T12:11:04Z", "hours": 8.3689, "text": "Devlog #17 pcb is done and showcase animation my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! i finished the pcb and refined it! yesterday ish i had like an idea to make an animation in blender to showcase the device for the final devlog so i started working on it nect devlog will be the final one! (i think)"}, {"post_id": 30954, "ts": "2026-07-18T23:27:55Z", "hours": 10.3483, "text": "Devlog #16 documenting (and accidental PCB?) my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! so i finally sat down to start documenting my work, but while doing so… i might have gone a little over the top and started designing a custom PCB for the project ;-;it’s pretty fun ngl, i’m really enjoying working on it! ohh also, i fixed a MAJOR bug in my code. i have absolutely no clue how i didn’t notice it earlier, but when i was trying to fix bugs last week, i accidentally introduced a new one that deleted messages the exact second they arrived. so yeah… i didn’t get any messages from my girlfriend for a whole week lol. oops. and if anyone here knows how to make pcbs please help me i have no clue what im doing thanks!"}, {"post_id": 29566, "ts": "2026-07-16T16:26:24Z", "hours": 1.05, "text": "Devlog #15 Small changes my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together.I’ll be building two of them and gifting one to my GF for her birthday! i a couple of issues with blackjack: * can now display around 11 cards(more than that is extremly unlikely so i didnt bother) * dealer no longer draws cards if u bust * now the split looks much much cleaner now even if one device is disconnected the msg will be stored and displayed when the device connects to the wifi some other stuff i forgot"}, {"post_id": 28397, "ts": "2026-07-14T17:07:08Z", "hours": 3.7961, "text": "Devlog #14 - The project is compleated! (if there arent ane new bugs) my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! what did i do? i added connect 4 & blackJack both of em should work now i fixed a problem with the wifi connection made new art for the connect 4 & blackjack to replace the place holders. i have already gifted the other device and shes probably reading this devlog so hello and sorry it took long all i have to do is finish up the docs and the github page and then were ready to ship"}, {"post_id": 25346, "ts": "2026-07-09T16:06:15Z", "hours": 6.6869, "text": "Devlog #13 The project is completed (mostly) my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together.I’ll be building two of them and gifting one to my GF for her birthday! Just finished building my second ebeep device! The good news are it came out SO much better than the first one, It might not be super obvious from the photos but trust me the difference IRL is HUGE. The Type-C connection actually fits properly this time! and the two devices are communicating great, and I even managed to run multiple rounds of Tic-Tac-Toe. . As for the bad news, It seems like every other day I encounter a new issue usually related to Wi-Fi or server connectivity. hopefully my janky code i wrote so far successfully patched them out. I’m trying to squash as many as possible before I gift one to my girlfriend later this week. If I have time, I’ll try to finish up Connect 4 as well and i think ill give up on the poker game i dont want to delay it any longer lol. . Also, for those who were wondering, we landed in 30th place (out of 36?) at the FRC competition"}, {"post_id": 19344, "ts": "2026-06-30T16:56:56Z", "hours": 4.9703, "text": "Devlog #12 THE FIRST ONE IS DONE my project in short to those who havent seen it yet: My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! I soldered everything up, crammed it into the box, and it works now. hooray! The only issue I had was that the negative terminal on the bottom of the esp32 disconnected when I tried to fit it into the box. I’m now in the process of testing and ironing out bugs. So far i found two the battery readout is weird but it works, and the battery runs out way too quickly, so I’m trying to fix those issues. unfortunately, I don’t know when I’ll be able to finish the second one since the 3D printer broke down (I literally bought it last week ) It took me a while to finish this one since I had an FRC competition to attend and couldnt finish everything in 1 day."}, {"post_id": 16357, "ts": "2026-06-26T16:42:53Z", "hours": 6.3789, "text": "Devlog #11 we are 80% there! my project in short my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up.ill be building two of them and gifting one to my GF on her birthday! what did i do? i finished the CAD (i hope), and started soldering everything together with the help of my dad(hes the best) the electronic plate is coming together nicly its not done yet but its mostly done!! and i will probably finish the first beeper TODAY!"}, {"post_id": 14554, "ts": "2026-06-23T18:34:15Z", "hours": 2.7692, "text": "Devlog #10 i missed the deadline :( (failed print after failed print) my project in short my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday! Her birthday was yesterday, i missed the deadline and my motivation is at an all time low. The code is done (i hope) but the 3d case is so horrible. its way too big and wastes so much material on useless spots and way too little on places in places that need it. the whole thing needs a redesign and I’m working on that but unfortunately ill have to postpone it by at least two days since i have 1 more final exam i need to take. and i just feel awful that i have to give her the birthday present with a week+ delay TL;DR i missed the dead line and I’m really down, the case needs a major redesign and im yet to even start soldering the code probably is done"}, {"post_id": 13239, "ts": "2026-06-21T17:54:28Z", "hours": 2.5981, "text": "Devlog #9 (1 day until GF birthday) TL;DR: finished tic tac toe, added icons to show if the bepper lost internet connection and updated the 3d model my project in short my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday later this month! what did i do? online tic tac toe works now icons to show if the connection is lost and automatically reconnect updated 3d model to actually use M4 screws how do they talk to eachother? i made a comic to demonstrate it cuz ik yall aint reading all that but if u want to read it in more detail: the first player sends to the other a message “TTT_JOIN” in /games then start listening to /games/TTT (channel where all the game communication will happen) the second player will receive that message and will get a notification that someone is waiting to play tic tac toe then if he wants he will join the the game and send a msg on /games/TTT that he joined both screens will update and show the tic tac toe board. each player will take his turn and send a message in /games/TTT with a row and a column of the place he chose to play and the screen will update accordingly. when the game ends they could request a rematch and will start this whole process again"}, {"post_id": 12102, "ts": "2026-06-19T19:09:33Z", "hours": 8.5831, "text": "Devlog 8 (3 DAYS LEFT UNTILL GF BIRTHDAY) CAD IS DONE what did i do? finished the cad hopefully will start printing on sunday when my new 3d printer arrives (and hopefully wont have to change anything bc i have 3 DAYS LEFT ) I REWORKED THE ENTIRE MQTT CODE (made the beeper talk to each other differently in order to make games possible) almost done with the online tic tac toe (the more indepth devlog will be the next one) fixed like 4 bugs and another 2 popped up kill me whats next? finish EVERYTHING before my GF birthday on Tuesday (sorry for this short devlog dont have much to say about the cad model the one on the code will come tmr hopefully)"}, {"post_id": 7523, "ts": "2026-06-12T15:45:53Z", "hours": 4.0075, "text": "Devlog #7 Its a big one what did i do? added a way to set the wifi password from your phone made the beeper actually able to talk and send messages fixed a lot of bugs that popped up after the switch to esp32 added a way to scroll faster for convince me and my friend started designing a case we will 3d print whats next? finish design a 3d printed case maybe finish one of the games side notes: i added a short video with a demo of everything working together would love to hear your thoughts about it background music: In the pool by kensuke ushio (forgor who made the piano cover im using) update on me: physics finals is in 3 days and I’m so cooked might not be able to design the case for a while"}, {"post_id": 6183, "ts": "2026-06-10T11:59:50Z", "hours": 2.0744, "text": "Devlog #6 my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday later this month! what did i do? the esp32 arrived yesterday its much much smaller than i expected and i have no clue how im going to solder it later ;-; anyways so i worked on porting my current code from arduino to esp32, its seems to be working as intended. now i just need to add all the missing features like the mqtt protocol and wifi portal. whats next? add the wifi portal (so i wont have to hardcode the wifi credentials in the code) make the esp32 work with the mqtt protocol design a 3d printed case finish the games (not really a priority right now) update on me: more finals soon yay :/"}, {"post_id": 4877, "ts": "2026-06-08T13:14:45Z", "hours": 1.6892, "text": "Devlog #5! to those haven’t seen my project yet in short: my project is a “beeper” with an eink display ill be building two of them and gifting one to my GF on her birthday later this month! it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up what did i do? i was bored since i cant really work on the project and have to wait for my esp32 to arrive >:( so i went on a side quest and added the game select menu, nothing major i also need to design the icons since they are just place holders from google whats next? wait for esp32 to arrive >:( actually make blackjack and the other games ask my friend to 3d help me 3d model the case update on me: sorry for the long wait i had a bunch of shit 2 do and war with iran ;-;"}, {"post_id": 3074, "ts": "2026-06-05T23:33:08Z", "hours": 2.1186, "text": "Devlog #4! . to those haven’t seen my project yet in short: my project is a “beeper” with an eink display ill be building two of them and gifting one to my GF on her birthday later this month! it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up what did i do? . i tired connecting my current setup to the MQTT broker and make it actually able to talk to other devices BUT IT DIDNT WORK i spent hours debugging it, only to come to the conclusion that i CANT do it with my current setup and i NEED the esp32 to continue coding or at least it will be much easier every day that passes i hate AliExpress even more it should have arrived 4 days ago ;-; the only useful i did is figure out how .gitignore work so now i dont need a hotspot lol whats next? wait for esp32 to arrive >:( update on me: . nothing rely new from yesterday . side note i just noticed ive never actually shown you how the UI i made previously works. so i attached a short walk through"}, {"post_id": 2424, "ts": "2026-06-04T22:02:29Z", "hours": 1.2675, "text": "Devlog #3 . to those haven’t seen my project yet in short: . my project is a “beeper” with an eink display (like the name suggests). ill be building two of them and gifting one to my GF on her birthday later this month! it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up what did i do today? . today i added Wifi! since i still dont have my esp32 (damm you AliExpress and your slow shipping), i wont be able to use the cool web UI library i wanted to use… so i changed my phones hotspot to the most boring name & password i could think of and hard coded those credentials in (i dont know how to hide sensitive info from GitHub and didn’t want to add my real wifi lol) edit: i also added the little wifi ui thingy you see in the picture whats next? i will research more about the MQTT protocol my two devices will use to communicate add end to end encryption (both devices will have a hard coded secret “password” they will use to encrypt and decrypt the messages) if esp arrives soon (WHICH IT SHOULD) ill connect it to the bread board and change the code accordingly and much more just later on id love to hear what your thoughts in the comments :) update on me: today was my computer science finals and it was 5 hours. i was pretty burned out after that so didn’t do that much today either :/ the next couple days are packed with personal stuff and more final exams so u might not hear from me soon… ill try to work on this project at least an hour every day so if u do it will be small changes unfortunately"}, {"post_id": 1723, "ts": "2026-06-03T21:50:03Z", "hours": 1.3117, "text": "Devlog #2 My project Ebeep is starting to take a bit more shape! . my project is a “beeper” with an eink display (like the name suggests). ill be building two of them and gifting one to my GF on her birthday later this month! . i rewrote almost the ENTIRE UI since last time the code i wrote was pretty bad and it had terrible UI. hopefully tomorrow i could work on actually connecting it to the internet and work on basic end to end encryption (maybe?). also i really hope ill get my esp32s soon so i could actually test my code on that instead of my arduino and design my 3d case for it. . today and yesterday werent very productive since my CS finals are tomorrow! so wish me luck!"}, {"post_id": 1088, "ts": "2026-06-02T22:16:57Z", "hours": 5.4681, "text": "day 1 of my ebeep project, i managed to make the eInk display work properly after HOURS of trouble shooting code. (apparently if it says 3.3V only it means dont connect a 5V Arduino to it oops) i managed to make the sick UI hopefully the esp32 and the battery will come soon so i can start designing the case for it"}]...
|
Title: Ebeep by @Avizi | Stardance
Devlogs:
day 1 Title: Ebeep by @Avizi | Stardance
Devlogs:
day 1 of my ebeep project, i managed to make the eInk display work properly after HOURS of trouble shooting code. (apparently if it says 3.3V only it means dont connect a 5V Arduino to it oops) i managed to make the sick UI hopefully the esp32 and the battery will come soon so i can start designing the case for it
Devlog #2 My project Ebeep is starting to take a bit more shape! . my project is a “beeper” with an eink display (like the name suggests). ill be building two of them and gifting one to my GF on her birthday later this month! . i rewrote almost the ENTIRE UI since last time the code i wrote was pretty bad and it had terrible UI. hopefully tomorrow i could work on actually connecting it to the internet and work on basic end to end encryption (maybe?). also i really hope ill get my esp32s soon so i could actually test my code on that instead of my arduino and design my 3d case for it. . today and yesterday werent very productive since my CS finals are tomorrow! so wish me luck!
Devlog #3 . to those haven’t seen my project yet in short: . my project is a “beeper” with an eink display (like the name suggests). ill be building two of them and gifting one to my GF on her birthday later this month! it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up what did i do today? . today i added Wifi! since i still dont have my esp32 (damm you AliExpress and your slow shipping), i wont be able to use the cool web UI library i wanted to use… so i changed my phones hotspot to the most boring name & password i could think of and hard coded those credentials in (i dont know how to hide sensitive info from GitHub and didn’t want to add my real wifi lol) edit: i also added the little wifi ui thingy you see in the picture whats next? i will research more about the MQTT protocol my two devices will use to communicate add end to end encryption (both devices will have a hard coded secret “password” they will use to encrypt and decrypt the messages) if esp arrives soon (WHICH IT SHOULD) ill connect it to the bread board and change the code accordingly and much more just later on id love to hear what your thoughts in the comments :) update on me: today was my computer science finals and it was 5 hours. i was pretty burned out after that so didn’t do that much today either :/ the next couple days are packed with personal stuff and more final exams so u might not hear from me soon… ill try to work on this project at least an hour every day so if u do it will be small changes unfortunately
Devlog #4! . to those haven’t seen my project yet in short: my project is a “beeper” with an eink display ill be building two of them and gifting one to my GF on her birthday later this month! it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up what did i do? . i tired connecting my current setup to the MQTT broker and make it actually able to talk to other devices BUT IT DIDNT WORK i spent hours debugging it, only to come to the conclusion that i CANT do it with my current setup and i NEED the esp32 to continue coding or at least it will be much easier every day that passes i hate AliExpress even more it should have arrived 4 days ago ;-; the only useful i did is figure out how .gitignore work so now i dont need a hotspot lol whats next? wait for esp32 to arrive >:( update on me: . nothing rely new from yesterday . side note i just noticed ive never actually shown you how the UI i made previously works. so i attached a short walk through
Devlog #5! to those haven’t seen my project yet in short: my project is a “beeper” with an eink display ill be building two of them and gifting one to my GF on her birthday later this month! it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up what did i do? i was bored since i cant really work on the project and have to wait for my esp32 to arrive >:( so i went on a side quest and added the game select menu, nothing major i also need to design the icons since they are just place holders from google whats next? wait for esp32 to arrive >:( actually make blackjack and the other games ask my friend to 3d help me 3d model the case update on me: sorry for the long wait i had a bunch of shit 2 do and war with iran ;-;
Devlog #6 my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday later this month! what did i do? the esp32 arrived yesterday its much much smaller than i expected and i have no clue how im going to solder it later ;-; anyways so i worked on porting my current code from arduino to esp32, its seems to be working as intended. now i just need to add all the missing features like the mqtt protocol and wifi portal. whats next? add the wifi portal (so i wont have to hardcode the wifi credentials in the code) make the esp32 work with the mqtt protocol design a 3d printed case finish the games (not really a priority right now) update on me: more finals soon yay :/
Devlog #7 Its a big one what did i do? added a way to set the wifi password from your phone made the beeper actually able to talk and send messages fixed a lot of bugs that popped up after the switch to esp32 added a way to scroll faster for convince me and my friend started designing a case we will 3d print whats next? finish design a 3d printed case maybe finish one of the games side notes: i added a short video with a demo of everything working together would love to hear your thoughts about it background music: In the pool by kensuke ushio (forgor who made the piano cover im using) update on me: physics finals is in 3 days and I’m so cooked might not be able to design the case for a while
Devlog 8 (3 DAYS LEFT UNTILL GF BIRTHDAY) CAD IS DONE what did i do? finished the cad hopefully will start printing on sunday when my new 3d printer arrives (and hopefully wont have to change anything bc i have 3 DAYS LEFT ) I REWORKED THE ENTIRE MQTT CODE (made the beeper talk to each other differently in order to make games possible) almost done with the online tic tac toe (the more indepth devlog will be the next one) fixed like 4 bugs and another 2 popped up kill me whats next? finish EVERYTHING before my GF birthday on Tuesday (sorry for this short devlog dont have much to say about the cad model the one on the code will come tmr hopefully)
Devlog #9 (1 day until GF birthday) TL;DR: finished tic tac toe, added icons to show if the bepper lost internet connection and updated the 3d model my project in short my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday later this month! what did i do? online tic tac toe works now icons to show if the connection is lost and automatically reconnect updated 3d model to actually use M4 screws how do they talk to eachother? i made a comic to demonstrate it cuz ik yall aint reading all that but if u want to read it in more detail: the first player sends to the other a message “TTT_JOIN” in /games then start listening to /games/TTT (channel where all the game communication will happen) the second player will receive that message and will get a notification that someone is waiting to play tic tac toe then if he wants he will join the the game and send a msg on /games/TTT that he joined both screens will update and show the tic tac toe board. each player will take his turn and send a message in /games/TTT with a row and a column of the place he chose to play and the screen will update accordingly. when the game ends they could request a rematch and will start this whole process again
Devlog #10 i missed the deadline :( (failed print after failed print) my project in short my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday! Her birthday was yesterday, i missed the deadline and my motivation is at an all time low. The code is done (i hope) but the 3d case is so horrible. its way too big and wastes so much material on useless spots and way too little on places in places that need it. the whole thing needs a redesign and I’m working on that but unfortunately ill have to postpone it by at least two days since i have 1 more final exam i need to take. and i just feel awful that i have to give her the birthday present with a week+ delay TL;DR i missed the dead line and I’m really down, the case needs a major redesign and im yet to even start soldering the code probably is done
Devlog #11 we are 80% there! my project in short my project is a “beeper” with an eink display, it will feature three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up.ill be building two of them and gifting one to my GF on her birthday! what did i do? i finished the CAD (i hope), and started soldering everything together with the help of my dad(hes the best) the electronic plate is coming together nicly its not done yet but its mostly done!! and i will probably finish the first beeper TODAY!
Devlog #12 THE FIRST ONE IS DONE my project in short to those who havent seen it yet: My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! I soldered everything up, crammed it into the box, and it works now. hooray! The only issue I had was that the negative terminal on the bottom of the esp32 disconnected when I tried to fit it into the box. I’m now in the process of testing and ironing out bugs. So far i found two the battery readout is weird but it works, and the battery runs out way too quickly, so I’m trying to fix those issues. unfortunately, I don’t know when I’ll be able to finish the second one since the 3D printer broke down (I literally bought it last week ) It took me a while to finish this one since I had an FRC competition to attend and couldnt finish everything in 1 day.
Devlog #13 The project is completed (mostly) my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together.I’ll be building two of them and gifting one to my GF for her birthday! Just finished building my second ebeep device! The good news are it came out SO much better than the first one, It might not be super obvious from the photos but trust me the difference IRL is HUGE. The Type-C connection actually fits properly this time! and the two devices are communicating great, and I even managed to run multiple rounds of Tic-Tac-Toe. . As for the bad news, It seems like every other day I encounter a new issue usually related to Wi-Fi or server connectivity. hopefully my janky code i wrote so far successfully patched them out. I’m trying to squash as many as possible before I gift one to my girlfriend later this week. If I have time, I’ll try to finish up Connect 4 as well and i think ill give up on the poker game i dont want to delay it any longer lol. . Also, for those who were wondering, we landed in 30th place (out of 36?) at the FRC competition
Devlog #14 - The project is compleated! (if there arent ane new bugs) my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! what did i do? i added connect 4 & blackJack both of em should work now i fixed a problem with the wifi connection made new art for the connect 4 & blackjack to replace the place holders. i have already gifted the other device and shes probably reading this devlog so hello and sorry it took long all i have to do is finish up the docs and the github page and then were ready to ship
Devlog #15 Small changes my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together.I’ll be building two of them and gifting one to my GF for her birthday! i a couple of issues with blackjack: * can now display around 11 cards(more than that is extremly unlikely so i didnt bother) * dealer no longer draws cards if u bust * now the split looks much much cleaner now even if one device is disconnected the msg will be stored and displayed when the device connects to the wifi some other stuff i forgot
Devlog #16 documenting (and accidental PCB?) my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! so i finally sat down to start documenting my work, but while doing so… i might have gone a little over the top and started designing a custom PCB for the project ;-;it’s pretty fun ngl, i’m really enjoying working on it! ohh also, i fixed a MAJOR bug in my code. i have absolutely no clue how i didn’t notice it earlier, but when i was trying to fix bugs last week, i accidentally introduced a new one that deleted messages the exact second they arrived. so yeah… i didn’t get any messages from my girlfriend for a whole week lol. oops. and if anyone here knows how to make pcbs please help me i have no clue what im doing thanks!
Devlog #17 pcb is done and showcase animation my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I’ll be building two of them and gifting one to my GF for her birthday! i finished the pcb and refined it! yesterday ish i had like an idea to make an animation in blender to showcase the device for the final devlog so i started working on it nect devlog will be the final one! (i think)
Devlog #18 - The Final One my project in short to those who havent seen it yet My project is a “beeper” with an e-ink display. It features three low-profile mechanical switches, an ESP32, a battery, and a 3D-printed case to tie it all together. I built two of them and gifted one to my GF for her birthday! so this is it, the last devlog for Ebeep. i finished the Blender showcase animation, check it out ⬇️⬇️⬇️ took way longer than expected since I’ve never really used blender for anything like this before, but I’m happy with how it turned out. (or kicad) as for the PCB, the design is fully done, routed, and ready to export to gerbers, but I decided not to actually order it right now. the perfboard build already works and does the job, and the PCB was mostly a “because I can” side project once I started documenting everything (devlog #16 lol). might revisit it in the future if I ever want to build a v2 or make more of these, but for now the current build is what’s shipping as “done.” looking back this project went through basically everything a project can go through: missed deadlines, a broken 3d printer, a bug that silently deleted my girlfriend’s messages for a week without me noticing, failed prints, finals eating my motivation and somehow it still came out the other side working, on both devices, doing everything I wanted it to do. if I had to do it again I’d probably: start the PCB earlier instead of perfboard + rework set up proper MQTT retained-message handling from day one instead of patching it in later. budget way more time for the case than I did CAD alone ate multiple redesigns and i still needed help from my friend to finish it i really need to work on my CAD skills but honestly, for a project that started as “let’s port some code to an esp32 I’m scared to solder,” I’m really proud of where it landed. whats next? id really love to keep working and making it the best i can (the 3d render is really rough as i had to finish it TODAY and some of the code is still messy), but realistically, nothing planned this is the ‘finish’ line. maybe a better PCB with a good showcase with cleaner code and a case that actually houses the PCB someday, maybe not. either way, thanks to everyone who followed along since the start. TL;DR finished the showcase render, PCB design is complete but staying unbuilt for now, and the project is officially ‘done’. thanks for reading 🎉
Ships:
my project is a “beeper” with an eink display, it features three low profile mechanical switches, esp32, battery and a 3d printed case to tie it all up. ill be building two of them and gifting one to my GF on her birthday later this month!...
|
1792997652.3780808
|
1793084052.3780808
|
|
958
|
My first slack bot! by @boring-name | Stardance
|
boring-name
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @boring-name | Stard Title: My first slack bot! by @boring-name | Stardance...
|
1792554732.788748
|
1793159532.788748
|
|
957
|
Anti-theft laser detecter by @Srijit | Stardance
|
Srijit
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Anti-theft laser detecter by @Srijit | Star Title: Anti-theft laser detecter by @Srijit | Stardance...
|
1792659088.7670248
|
1793263888.7670248
|
|
956
|
not-so-scary-game by @hiral | Stardance
|
hiral
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: not-so-scary-game by @hiral | Stardance
|
1792478921.657442
|
1793083721.657442
|
|
955
|
My first slack bot! by @shravs | Stardance
|
shravs
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @shravs | Stardance
|
1792810200.1596885
|
1793415000.1596885
|
|
954
|
My awesome macropad! by @aaditrai | Stardance
|
aaditrai
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @aaditrai | Stardan Title: My awesome macropad! by @aaditrai | Stardance...
|
1792788583.1426423
|
1793393383.1426423
|
|
953
|
Untitled project by @shaan | Stardance
|
shaan
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @shaan | Stardance
|
1792756221.7080698
|
1793361021.7080698
|
|
952
|
Defqon Stage Editor by @defqonstage | Stardance
|
defqonstage
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Defqon Stage Editor by @defqonstage | Stard Title: Defqon Stage Editor by @defqonstage | Stardance...
|
1792778051.785657
|
1793382851.785657
|
|
951
|
Website by @Kanata | Stardance
|
Kanata
|
1
|
1.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-01T11:45:45Z", "hours": 1.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I created a simple website to learn HTML. It includes headings, links, lists, tables, and a form.The most challenging part was publishing the website with GitHub Pages. I had to learn how GitHub Pages works and how to configure the project correctly.I am proud that I built and published my first website by myself.This project is a beginner HTML practice project. It focuses on learning the basics rather than creating a professional website.", "repo": "https://github.com/k4n474/Website", "demo": "https://k4n474.github.io/Website/"}]...
|
[{"post_id": 230, "ts": "2026- [{"post_id": 230, "ts": "2026-06-01T10:58:25Z", "hours": 0.8114, "text": "I wrote code using a wider variety of tags."}, {"post_id": 204, "ts": "2026-06-01T08:05:04Z", "hours": 0.3136, "text": "I’m creating a simple webpage to learn HTML"}]...
|
Title: Website by @Kanata | Stardance
Devlogs:
I’ Title: Website by @Kanata | Stardance
Devlogs:
I’m creating a simple webpage to learn HTML
I wrote code using a wider variety of tags.
Ships:
I created a simple website to learn HTML. It includes headings, links, lists, tables, and a form.The most challenging part was publishing the website with GitHub Pages. I had to learn how GitHub Pages works and how to configure the project correctly.I am proud that I built and published my first website by myself.This project is a beginner HTML practice project. It focuses on learning the basics rather than creating a professional website....
|
1792990326.8442092
|
1793076726.8442092
|
|
950
|
Volvo API playground by @Kl | Stardance
|
Kl
|
1
|
130.69
|
2165
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-06T20:19:02Z", "hours": 113.0, "multiplier": 19.09, "payout": 2165, "blessing": "neutral", "text": "A Milestone Welcome everybody to the first ship of this project. What is this project? This project simulates how the Volvo API works. Why was this project created in the first place? So it’s easier to create and test your app that uses the Volvo API without using ready-made libraries. I can’t find the features you mentioned in the devlog? Check the scope branch or the upcoming dev branch. What I’m proud of: I learned a lot of things (this is my first big public project): Tailwind Python stuff (I started with C++) Writing documentation (Markdown) I also learned the basics of OAuth2 and how APIs work. Making a project with all the features needed to get started. I created an additional document for you, Stardancers: Stardance PATH What is still on the TODO list? More APIs Scopes docker image See the roadmap . What to see? error logger recreated endpoints dashboard web socket realtime changes internal endpints interactivity of the car", "repo": "https://github.com/klswar0/Volvo-API-playground", "demo": "https://playground.kls.hackclub.app/"}]...
|
[{"post_id": 79861, "ts": "202 [{"post_id": 79861, "ts": "2026-10-15T17:17:04Z", "hours": 7.1881, "text": "Devlog A very long time no see. I have made a lot of progress on adding an SQL database. Testing on MySQL The backup server provider gives me access to one. SQL changes A lot of BIG changes. The reason why I haven’t posted for so long is that I didn’t want to post about something that doesn’t work. Created new classes to intercept data changes, both in case of direct dict changes and when going through the SQL model library. (I didn’t change much in the code, just imported it under the same name as the old database.) And it works! At the start, only reading data worked, but now it can send data back to the database. Added a regen function to make sure built-in API keys are always the same after a restart. Fixed the car creation function (but when I started storing the additional data in SQL, it broke AGAIN). Added configuration attributes. At first, just the database type, but then all the information needed to connect to a MySQL database. Fixed the scenario readconfig (wasn’t it updated in the past?). A really small number of things I added? Yes, but the amount of debugging and changing built-in functions in classes took me so long. (Could be because of school and not having time to do everything in one sitting.) But I learned how to make a dummy dict with a class, as I called it in the commit: proxy . Problems The SQL database can’t create new cars. Need to check all internal endpoints to make sure they work. Still haven’t merged the DEV branch (TODO). All information is stored in one column as JSON. It works, buuuut I don’t like it that way. Need to clean up the proxy classes. updating docs What failed this time? The second photo attached shows it. Have a look before reading more. _contains__ If you see it, congrats! But if you have a screen full of code, it’s harder to spot. It should be __contains__ , and I spent, I think, two days debugging why all in statements just didn’t work. I was so happy when I finally found it! XAMPP and Apple Silicon The manager app doesn’t open after a restart, so after consulting Google and AI, I found a command that I use: sudo /Applications/XAMPP/xamppfiles/xampp start xampp If someone is asking why I didn’t use the server provided one it just wasn’t practical for now."}, {"post_id": 73730, "ts": "2026-09-25T19:56:38Z", "hours": 4.9217, "text": "Devlog A lot of breaking changes later and getting closer to PR and going to 2 ship Token lifetime WORKS made time when token is expired is rounded to int endpoint for invalidating token possibility for enabling expiring token for a specific token when it’s disabled for all in config file misc pytest for location and energy API fix the url for the enrgy API (it started with connectivity url not wi the energy api) cleanup import created new files to make the code more readable dashboard added location values added capabilities and values auto token generation and expiration in dashboard"}, {"post_id": 69307, "ts": "2026-09-16T19:32:57Z", "hours": 5.58, "text": "Read till the end PLEASE 🥺 Devlog A lot of changes from the last devlog only 5 hrs Mostly bc I add stuff on top of but I will suffer in the future (See dev branch for these changes) Change all connectivity API to start with /connected-vehicle/v2/ to make room for different APIs After that I fixed pytest to reflect that I added a location API with a ONE endpoint There were few iterations Added scopes for this API location:read If I remember correctly Unique error responses (because location error look like old (v1) connectivity API Fixed that operationID could be a constant Added a config option to use longer API keys About here I Fixed the url for location api because it used the connectivity scheme Started working on energy API I added all data from it to this project In short one endpoints says what this car is capable of And the other says the values TODO: add its unique error its half done Scopes corresponding to energy API Fixed that some values and capabilities had the same name (bc of that some bool values where number so a it was important) WIP Oauth2 update: JWT tokens for access tokens WIP token can expire! what are JWT token? There consist of three parts header payload and signature The two first is important for my project the 3 isn’t . They store info about issuer, when token is active, scopes… A lot of useless data for this project or useful? We will see Life Bc of school I didn’t have a lot of time to write devlog (and write code) but I try to do my best before the end of stardance The next ship is planned for 28 September BIRTHDAY TODAY (16 September) Im celebrating my birthday 😄 If you write me a few good words It would be motivating for me."}, {"post_id": 63130, "ts": "2026-09-06T19:20:58Z", "hours": 1.6042, "text": "Devlog MAIN added a startup baner fixed snapshots not saving if website was used scope If you didn’t follow from start this branch contains the experimental scope support which is mostly done but I can guarantee stability that’s why it isn’t pushed to main in fist ship made the scope page work added a back button added button to scope on main page fixed snapshots loading/saving"}, {"post_id": 61052, "ts": "2026-09-03T19:22:00Z", "hours": 2.8836, "text": "Long time no see… The school started aaand I didn’t have time I had low motivation The only thing to do before first ship is docs but I could find time to finish them. Buut I back now. AND I promise to ship it before 7 of September. If you are voting on this project PLEASE do not skip. I have my birthday coming and if the shipwrights doesn’t have a long list it could mean this project payout could be my birthday gift. If I ofc ship it 😅 devlog Small marketing changes everywhere to say that this project doesn’t have any ready code to use Added info about error logger on the landing page Scopes A long way from last devlog Fixed pytest ( A second time) TEMPORARY FIX added so the scope error doesn’t - throw just internal error FIXed the Oauth2 endpoint at least 3 times Added a WIP endpoint to edit scope data from API Fixed how cars are created so they work with both - Oauth and scopes stuff Only looking dashboard page for scopes compare I think I forgot to say something in last devlog config file if you would like to use different instance Toml oillevel to oilLever AI disclaimer that I used this project to learn tailwind Make the doors have different statuses in mean time Untracked WIKI Redo the home page Started working on stardance path A lot of misc that I don’t remember other I created a small modified volvo example app to show that my app works like the real one"}, {"post_id": 55226, "ts": "2026-08-26T20:27:11Z", "hours": 4.2503, "text": "Devlog Error logger added colors to the terminal print out using: \\033[31m \\033[0m Good to know that it is so easy to add colors to text added timestamps to log file and - between errors Changes how it reads body once again and fixed url encoded requests logging My additional information I put in detail in the json response (the real API can send it like that buttty I didn’t see it. info from docs ) additional changes: New scenarios mostly about service warnings You can add notes to the website thru config files Scopes I started working on scopes. What are they? They are really permissions (you can know them from discord bots or if you login thru GitHub etc.) I don’t want to put them in this first ship but I needed to work on something (while I work on wiki) and I CAN’T guarantee every thing works after adding them. You can see it in the scopes branch. what is done: I have made preparation so the additional database (dict) I use for OAuth can store more data have updated website func to work with changes and also pytest added all possible conve (connectivity API) scopes WIKI when I add everything to them I will finally try making a ship added the error logger page updated the sidebar scenario and snapshots page a lot of misc Bonus photos from vacation on baltic sea"}, {"post_id": 49931, "ts": "2026-08-18T21:59:53Z", "hours": 3.1292, "text": "Devlog There was a small (or big) problem in my playground. If an error was returned in the response, you could only see it if your app handled it or by printing the response. That’s why I added an error logger. It can show errors in two ways: Terminal Log file How it works There were two ways of doing it (from what I learned): Middleware that captures all responses (this could be helpful in the future). Exception handlers (this is what I chose). I use two handlers: @app.exception_handler(RequestValidationError) @app.exception_handler(HTTPException) It was a horrible time searching for why it didn’t work. At first, I worked in a separate file, but I couldn’t get the (fastapi) app variable into those functions. So I copied them into main file to make them work first. I had to change some JSON responses to HTTPException to make the second handler work. After I captured the first request and printed it, I worked on one function that writes a log and another that prints to the terminal. I also created a class to store useful data. It works like this: Exception handler-> ->Put data into class -> ->Create response -> ->Return response ->Create a background task that logs the error I create a background task so the response doesn’t wait or even worse fails In the end I found that I can wrap these func with this simple func to make them work in different file def setup_error_logging(app: FastAPI): Added a config option: To disable it completely. To disable only the log file. It also bypasses all internal endpoints to make the logs more readable. The best fail… 😅 I returned an exception instead of raising it. I spent a good 15 minutes wondering why the response had status code 200 with a JSON body saying status code 400 . response changes I also checked how the authorization errors look and added two new ones: Missing Authorization header. Invalid vcc-api-key header. WIKI (not counted) I focus on making a GitHub wiki (new docs) After ending them and the error logger. Its time for the first ship !!!!!!! Nest instability: I made a backup server : https://frog01-21185.wykr.es/ Its not ideal one, bc some asian countries are blocked but its shouldn’t have any downtime (I hope so) If an Admin read it why I must copy enter from different text input 😭"}, {"post_id": 48444, "ts": "2026-08-16T19:51:20Z", "hours": 2.4822, "text": "Devlog SITE changes I found that some number inputs didn’t use the utility classes. I gave them inputText because they are really the same; the only difference is the HTML type . I also forgot to update the reloadable fuel section. It now uses the shorter utility class. Made sure that all text in the header is the same size (they weren’t). I copied all changes back to the main branch. config changes Then I added a config file using the configparser library. also added an option to disable the FastAPI docs. I started working on Wiki: reworking docs.md into a GitHub Wiki with up to date information. Error logger, so you can see what’s wrong without printing the API response in your code. I had some problems with catching the fastapi automatic response but I will leave it for next devlog"}, {"post_id": 46236, "ts": "2026-08-13T10:31:45Z", "hours": 4.6175, "text": "Devlog I forgot to add that I worked on the tests in the test branch, not the main one. OAuth2 PKCE testing. Helped me find an error where, if the code was used (it was reset to \"\" ), it was accepted as \"\" . Now it correctly returns an error. OAuth2 flow testing. Warnings and diagnostics now have some simple checks too. And I merged it into main . Then I started cleaning up the Tailwind CSS. NOTE: they are in new branch dashboard/cleanup Why? Because I used the Play CDN in the past, so I couldn’t create utility classes in a CSS file. Soooo I didn’t. Andddd there were a lot of Tailwind classes that didn’t fit on my screen. Now that I started precompiling it, I could add them. I added 5 unique utility classes. All of them combined are used around ~120 times across all HTMLs. The longest one: @utility inputSelection { @apply w-full px-4 py-2 .5 bg-zinc-950 border border-zinc-800 rounded-xl text-zinc-100 focus : outline-none focus : ring-2 focus : ring-blue-300 focus : border-transparent transition-all appearance-none text-center [ text-align-last : center ] cursor-pointer ; } I also minified the CSS file. If I understand it, it removes anything the browser doesn’t need to understand the CSS (new lines, unnecessary spaces…). It’s better because those characters are still sent over the network, and fewer bytes mean less traffic. While using the new utility classes, I tried to preserve the layout, so everything should look the same as before."}, {"post_id": 44802, "ts": "2026-08-10T20:28:29Z", "hours": 3.7639, "text": "Devlog Working hard on pytest tests. I learn how assert works and how to name . I never used or created test in any language so I think they aren’t perfect (not like they should),but they work😄. I looked like AI made few and how other people and read some stuff online Tests created for these endpoints Around 25 of them List cars About car Engine info Engine start/stop Climate start/stop Windows Doors Lock/Unlock Reduced Guard Lock Flash, Honk, and Combination Tyres Statistics Fuel Odometer Engine diagnostics Brakes Command accessibility Still to do Warnings and diagnostics Commands More changes The tests helped me find and clean up several issues: Documentation updates. The honk endpoint was ../horn but should be /honk . Some values ( odometer , fuel ) are int , just like in the OpenAPI specification, not as described in the official docs. Fixed spelling mistakes: - oillevel to oilLevel - coolantLever to coolantLevel Want to help and has access to volvo with active VOC I need to test engine and climate endpoints but I don’t have an access to a car with it. Soooo if you can contact me on slack"}, {"post_id": 42512, "ts": "2026-08-07T09:41:54Z", "hours": 4.2411, "text": "Devlog Tracking headers implemented : There are two vcc-api-operationId - UUID traceparent - W3C traceparent (for now only sends it back) dashboard should look good on small screen (its very long but I don’t want to redesign it now) This is the reason why I there is much time in this devlog. It was a lot of try and error before something looked good both on mobile and desktop and I liked it . But at least it works know 🙃. some small cleanup of comments I worked again on internal updates endpoint (hopefully works now) started working on pytests (but I will talk about in next devlog (I gave my self 2 days for it) I really want to get the first ship out, so it isn’t going to be perfect. I still have a lot of features and improvements I’d like to add."}, {"post_id": 40711, "ts": "2026-08-04T12:41:43Z", "hours": 4.4231, "text": "Devlog I had a problem when I wanted to rewrite the scenario system. It only changed the local version of the Car (It means it really didn’t update anything). I wanted to update a backup version first, and only if everything was correct, replace the original with the backup. In the end, I used an already created function to first test and then apply to the car . Main PKCE misspelling fixed. Added a landing page with an option to disable it and redirect directly to the login screen (like in the last devlog I have photos of making it). Worked on the lights section. Fixed the docs URLs. Dashboard and WebSocket toggles now work. Rewrote and enabled the updates endpoint. Validation now catches values that can’t be converted to int . Scenario loading into a car instance should now be more consistent with the other functions. Improved mobile responsiveness (and then fixed the desktop one). Some elements were outside the screen on mobile (nothing important, but it didn’t look good). NOTE: the dashboard with car attributes still needs to be adapted. Added windows (because I forgot to 😅) to the dashboard and organised the lighting section. OAuth2 and Snapshots buttons should now always be centred. TODO Debug and tracing headers (from the real API). Additional instructions. Then I think it’s finally ready for the first ship. There are still a lot of things I want to add, but I can’t work indefinitely. Compare The compare app now has the Content-Type fix enabled (like the official API). Compiled the Tailwind CSS for the compare app. NOTE: I will add here more screenshots as link later Also thinking about adding it frictionless mission but I’m not sure."}, {"post_id": 39642, "ts": "2026-08-02T19:24:37Z", "hours": 3.62, "text": "Devlog Snapshots loading page (screenshots while I worked. I had more but the limit was 4). As suggested by the Tailwind CSS tools, changed some classes to more canonical ones. You can now delete cars through both the API and the dashboard. Snapshot corruption (when the app is force quit) should be fixed. Started working on the landing page, but I’ll leave it for the next devlog (mostly because I have on my other laptop). Fixes to do Sometimes the new OAuth2 and Snapshots buttons are off-center. Compare app needs fixing (need to enable the Content-Type fix from the official API). PKCE spelling in the internal API."}, {"post_id": 37827, "ts": "2026-07-30T19:39:54Z", "hours": 4.1028, "text": "Devlog The Content-Type problem is SOLVED …… What was the problem? (My reading skills? ) there are two headers with application/json : Content-Type (POST) Accept (GET) The Accept header isn’t required ( can be */* , application/* or application/json ). So the Content-Type mystery is mostly FIXED but I still need to check with a real Volvo car if Content-Type is actually required. (I’ll do it tomorrow.) Changes: Accept is now handled by my API like in the official API. Added Content-Type checks (like the docs say, meaning it’s required). While proofreading the docs, I found that PKCE is written as PCKE in one internal endpoint. (Not fixed yet.) Small README update (I try to keep it up to date). Scenario page: You can now load a scenario using the GUI. Recompiled the Tailwind CSS. I attached screenshots showing it (you can also see snapshot button but its not implemented YET)"}, {"post_id": 36608, "ts": "2026-07-28T20:31:07Z", "hours": 0.5122, "text": "The comparison app is now online! Comparison app: https://compareplay.kls.hackclub.app/ I also updated the main app with the new dashboard design: https://playground.kls.hackclub.app/internal/welcome devlog Tailwind CSS is no longer loaded from the CDN. I think its now precompiled. Note to others: Remember to update your banner to feature your app (see #stardance on Slack). Otherwise, your ship will be rejected. EDIT: A lot of bots try to connect to my apps do you think I should make a honeypot?"}, {"post_id": 36297, "ts": "2026-07-28T09:47:40Z", "hours": 3.2881, "text": "Devlog I found another way to hide the fuel stat when it isn’t useful for a particular type of car: the HTML hidden attribute. At first, I thought I should add or remove the element hidden, but that turned out to be more complicated than I expected. I think using hidden is still a cleaner solution but I still using templates files. While working on the dashboard, I wanted to add units like km , L , and % to some values. Instead of handling that in Python, I added another div with some margins and, in a few places, used flex so everything stays on the same line without adding more backend logic. Added more page changes thru HTMX (nearly all pages use it). Creating a new car now refreshes the page. when an error occurs, I use HX-Reswap and the HX-Retarget response header (when creating new car as proof of concept). Added HTMX transitions to the OAuth2 settings page.(all pages have transitions) What to do before the first release (Mostly a checklist for myself 😅) Content-Type checks. Scenario and snapshot system support in the dashboard. Main showcase page. Finish the remaining documentation. Two READMEs: one for the main repository and one for the companion app repository. I’m thinking about having one technical README and another one that’s easier to understand for people who don’t code. Better error handling in the dashboard. Right now, most errors are just displayed as plain text instead of being part of the page. deploy updated version on nest I wanted to add a video but MacOS made me a half gig and I don’t think stardance would handle"}, {"post_id": 35043, "ts": "2026-07-26T06:29:01Z", "hours": 5.5947, "text": "Devlog Most of my time was spent working on the dashboard with Tailwind CSS. It took a lot of experimenting to find a design I actually like. I also changed how HTMX updates the dashboard through WebSockets. Before: A dedicated template was rendered every time to update that part of the dashboard. Now: Only the text containing the updated value is replaced. That said, in the future it won’t always be just text. For example, if the fuel type changes from hybrid to electric , the fuel level should disappear from the dashboard instead of just changing its value. While working on this, I found a bug caused by HTMX sending boolean values as strings. This caused climate settings to be marked as invalid. I need to distinguish between an invalid value and an invalid attribute instead of always treating the entire attribute as invalid. Note to myself Add transitions. Make all HTML pages use the same CSS file from now on. Update the version on nest server and make a public companion instance Aaand that’s all. Making websites is painfully slow."}, {"post_id": 33472, "ts": "2026-07-23T13:34:25Z", "hours": 4.2786, "text": "Devlog I don’t know if I mentioned it before, but for now the Content-Type checks are disabled. I need to learn more about them and implement better validation. Created an updated OAuth2 settings page and a car selection screen (with Tailwind CSS, of course). Started experimenting with a new dashboard. It’s still a work in progress, but it will most likely become the main design. I’m also thinking about adding a second dashboard style, although I’m not sure if I’ll do that before the first release. I definitely want to clean up the HTML/Tailwind code by moving repeated styles into reusable classes or something similar. I’m also thinking about using more HTMX so that more pages can update data without needing a full page reload. Wrote more documentation. I still need to verify the fuel endpoint because I don’t remember whether it handles different engine types correctly. ( The new OAuth2 settings page and the car selection screen. For next develop I think I will make a video of how everything works)"}, {"post_id": 32303, "ts": "2026-07-21T11:58:32Z", "hours": 2.6278, "text": "Devlog Companion app I said it was finished for now, but I forgot to add one more thing (the one on the left in the screenshots): a dashboard redirect. Main app I’m still investigating the Content-Type problem. I verified that the official Volvo API behaves correctly, so I’m working on matching that behavior. Added work-in-progress Content-Type checks. Started reworking the CSS using Tailwind CSS. It’s still mixed with some plain CSS for now. Enabled support for the reduced guard lock command. You have to manually mark it as supported, and for now it behaves the same as the normal lock command. Let me know which design you like more: the new one (center) or the old one (right)."}, {"post_id": 31979, "ts": "2026-07-20T20:18:13Z", "hours": 3.7667, "text": "Devlog I’m mainly focused on finishing the companion app. I started working on the CSS. Most of my time was spent learning Tailwind CSS (so I didn’t track it). I think it’s a better fit for me than writing plain CSS. Added Tailwind CSS to all pages of the companion app. (I think I need to redo the main app now. 😅) Added a small README with information about the main app. I think it done now but I will come back to it before first ship Main app While working on the companion app, I found another issue. The Content-Type: application/json behavior doesn’t match the official API. I verified that the official API works as expected, checks for it mine doesn’t (I think)"}, {"post_id": 30890, "ts": "2026-07-18T21:12:58Z", "hours": 3.2169, "text": "Devlog Companion app Added manual mode for comparison. Engine start/stop now works in normal mode. Before pushing, I forgot to fix one thing: { \"error\" : \"Failed to retrieve data from unofficial API.\" , \"detail\" :{ \"detail\" :[{ \"type\" : \"dict_type\" , \"loc\" :[ \"body\" ], \"msg\" : \"Input should be a valid dictionary\" , \"input\" : \"{ \\\" runtimeMinutes \\\" : 10}\" }]}} The fix was simple: I forgot to use json.loads() . I pushed a quick fix commit right after. The photo shows the manual comparison page. I’m still working on the comparison logic, which is why it doesn’t have any CSS yet. Sorry for not adding Volvo API keys so you can see the differences between both APIs, but that would have taken too much time today. Its also the reason why Im creating this app Main app Worked on the documentation. The notifier now supports more than one updated attribute at the same time. It’s not the best implementation, but I’ll improve it after the first ship. Fixed snapshot loading and added exception handling. Scenario loading now reports malformed JSON files. Fixed a dashboard bug where tire information was shown three times. I think I planned to add more data there… and then forgot. I should probably test everything before making a devlog or committing, but I also don’t want my devlogs to have to much time."}, {"post_id": 29435, "ts": "2026-07-16T11:46:44Z", "hours": 0.5936, "text": "A public online demo!!!!! The project is finally available online! https://playground.kls.hackclub.app/internal/welcome Please don’t be the bad guy and fight with other people over access. ❤️ That’s all I wanted to say because this is a really big milestone for me. There will also be another commit today to make sure everyone can run their own instance of the project. I found a few issues that only appeared outside of my local environment: Some WebSocket features break when using HTTPS. The dashboard had problems when the instance wasn’t running on the same computer. Those should be fixed in today’s commit. If you find any errors please comment or contact me on slack Also thanks to nest hackclub for hosting"}, {"post_id": 29164, "ts": "2026-07-15T21:37:24Z", "hours": 2.8483, "text": "Devlog Authorization was my mistake. It should have been accessToken , not Authorization . Why I thought that? I have no idea. No it was good before I was sleepy I think when I did that The snapshots system now works. Why it didn’t work as expected: I forgot to use copy(deep=True) . One of the small dictionaries was written incorrectly. Added saving and loading snapshots from a file. The scenarios system now works and has been tested. Difference between snapshots and scenarios Snapshots copy all data about a car. They are persistent and can be saved to a file. Scenarios only change selected attributes. They are designed to be created and edited manually in a JSON file. Main app The main app is mostly ready. Before the first release, I still need to: Finish the documentation. Add a roadmap with future updates. Verify error responses against the real API. Finish the comparison feature in the companion app. Add more ready-to-use scenarios and API keys. Companion app Manual login now works, so only the comparison logic is left. I found a bug where api_key_p was None because one endpoint redirected using api_key instead. Started working on the comparison feature. PS: A photo of why the api_key_p was none"}, {"post_id": 27883, "ts": "2026-07-13T19:57:06Z", "hours": 3.8994, "text": "Devlog Writing documentation is a good way to check whether the code you wrote actually works. I already found four bugs while documenting the project. For example, I forgot to pass the redirect URI in a function in main.py , even though it was already implemented in internal.py . I also fixed a bug where notifications could sometimes contain an older value. The dashboard has been moved into a separate file. Snapshots currently have a problem. They are very similar to the Car class, so I’ll debug it and explain what the issue was in the next devlog. Companion app The companion app is meant to showcase the differences between my implementation and the official Volvo Demo Car Sandbox. It also makes testing easier, since you don’t have to write your own application just to try the API. I had a problem with the built-in LibreSSL because one of the dependencies didn’t support it. I had to reinstall Python so that uv would detect the new OpenSSL installation. After that, I was finally able to start the app and get it working. Auto-login and automatic creation of a test car are now working. There’s is no css but I will do it after logic works One more thing: the reason the devlogs have been quieter recently is that I’ve been dealing with some administrative paperwork. I’ll get back to posting them more regularly once that’s sorted out."}, {"post_id": 25868, "ts": "2026-07-10T10:58:56Z", "hours": 4.3936, "text": "Devlog How I don’t like web development… did I already say that? I’ll say it again. I’m working on the OAuth2 settings, and I had a problem where one of the query parameters wasn’t reaching the backend. I still don’t know what actually fixed it. Then I had another problem. I have a function that changes values in the backend, but only one button worked while everything else didn’t. It turned out to be because I debugged the first problem with AI. Always trust your own mind before trusting AI. The problem was hx-trigger . I also had problems applying CSS through HTMX. In the end, I solved it by using hx-redirect . But in the end everything works (you can see it one the phtoto) I also worked on the scenario system, which loads scenarios from a JSON file. It isn’t tested yet, and I still need to work on state snapshots. The idea is that you’ll be able to save a moment in time and restore it later, so you can test the same scenario as many times as you want without setting up all the data again. I also started working on a companion app to showcase the differences between my implementation and the official demo car sandbox. I’ll write more about it in the next devlog."}, {"post_id": 24338, "ts": "2026-07-07T20:58:43Z", "hours": 3.7069, "text": "Devlog A small error from the last devlog: it’s PKCE , not PCKE . I had to rename a lot of variables because of that. More customizable data Gearbox Model year More diagnostic data for lights (hazard, fog, brake, high beam, low beam, and more) Other additions Added a new default API key with 3 cars, each having different values. Wrote more docs. Started working on scenarios (templates for new or existing cars to make setup faster). I’m thinking about loading them from a file so users can create their own. Started working on setting up OAuth2 through the dashboard. Fixed most command responses because when I first created them, I forgot to wrap everything inside { \"data\": {} } . Added light options to the dashboard. Working: PKCE How does it work? The application generates a random secret. Before redirecting the user to the login page, it sends only a hashed version of that secret. After the user logs in, the application receives an authorization code. When exchanging the code for tokens, it sends the original secret. The server checks whether it matches the previously received hash. If it does, the tokens are issued. It normally protects from having the tokens stolen New promoting picture I made in canva have a look"}, {"post_id": 23100, "ts": "2026-07-05T20:54:08Z", "hours": 3.3289, "text": "Devlog Small additions to the new documentation. changes how the api handles errors BIG ADDITION OAuth2 without PKCE. I started working on PKCE, but I thought I should write a devlog before adding it. Added a login website (I know I mentioned it last time). Added a way to enable and disable OAuth2. Authentication now checks whether OAuth2 is enabled. If it is, requests are authenticated using OAuth2. Tokens don’t expire yet, but that will be added soon. Added endpoints for refreshing tokens and exchanging an authorization code for tokens. How does OAuth2 work? The app redirects the user to a login page. After logging in, the website redirects the user back to the callback URL provided by the app. The app receives an authorization code, which it exchanges for two tokens: a long-lived refresh token and a short-lived access token. When the access token expires, the app can use the refresh endpoint to obtain a new access token. What is PKCE? I’ll write more about it once it’s added to the project. In short, PKCE protects the authorization flow by ensuring that only the application that started the login process can exchange the authorization code for tokens. The application first generates a random secret (called a code verifier). Before the login request is sent, a hashed version of that secret (the code challenge) is sent to the server. Later, when exchanging the authorization code for tokens, the application sends the original secret. The server verifies that it matches the previously received hash before issuing any tokens. I’ll explain the complete flow in the next devlog."}, {"post_id": 20221, "ts": "2026-07-01T19:28:27Z", "hours": 5.3022, "text": "Devlog This devlog will be a short one because I’ve been focusing on implementing OAuth 2.0. I’ll cover that in more detail in the next update but I will add photo of a “login” screen that I created for it (it looks bad on purpose). What’s new The terminal now works with more than one static car. The dashboard can (once again) create new cars. The codebase has been split into multiple files instead of a single large file: main still contains the public API endpoints. internal contains the dashboard logic and internal API endpoints. database will contain multiple predefined car scenarios. I also started writing a new manual that documents the quirks of the Volvo API and my implementation ( and edge cases). I will write more about in next 2 devlogs What’s left before the first ship An example application demonstrating the differences between the official Volvo Sandbox and this project. OAuth 2.0 with PKCE (it would be great to have before the first ship). Documentation. A major code cleanup and refactoring."}, {"post_id": 17924, "ts": "2026-06-28T21:18:15Z", "hours": 2.7358, "text": "Devlog I added two static (for now) endpoints: statistics and warning . The statistics endpoint mostly returns data, so there isn’t much to test. The warning endpoint has a very large response that would require a lot of new code, and for now I don’t want to implement all of it. I started working on adding cars through the dashboard (you could already see part of it in the last devlog), but I found out it doesn’t work, so I need to fix it before the next devlog. Climate and engine STOP commands now respond correctly. In the last invoice update, they incorrectly returned RUNNING . Added checks for the new command endpoints to verify whether the car supports a given command. Added a small terminal page that outputs changes. In the future, you’ll be able to choose whether to display only Volvo changes, all changes, or all information (for example, if you checked whether the windows status). I also used it to verify that the normal WebSocket status works. Added the foundations for disabling WebSockets on startup. Only a configuration file is left to implement. Added UNAVAILABLE reason invoice logic mostly something like this: If the reason is NO_INTERNET , the invoice becomes CONNECTION_FAILURE . If the reason is POWER_SAVING_MODE , the invoice becomes VEHICLE_IN_SLEEP . Made some improvements to the dashboard’s appearance."}, {"post_id": 15774, "ts": "2026-06-25T17:19:10Z", "hours": 7.1422, "text": "Devlog A funny story: I built the invoice system but didn’t always assign values correctly, so the values got mixed up. I spent a long time debugging before realizing that was the cause. { \"error\" : { \"message\" : \"VALUE_ERROR\" , \"description\" : \" \\\" Car \\\" object has no field \\\" 123 \\\" \" } } I also spent a lot of time on CSS. Most of that time went into learning: classes IDs box shadows CSS Grid The reason it took so long since the last devlog is CSS. As I said before, I don’t really like web development, so my motivation was pretty low. I used some AI, but I worked hard to remove most of the generated code. At this point, most of the site’s design looks the way I want it to and will probably stay that way until the end of the project. Made invoices have some logic instead of always sending the same value. That means: If no invoice status is set, it sends COMPLETED or RUNNING depending on whether the engine or climate is running. Loc like actions can’t have a RUNNING invoice status. Added a distinction between successful and failed invoices. PS: Always remember to stop the server with Ctrl+C , not Ctrl+Z , because Ctrl+Z can leave the process running and keep the port blocked."}, {"post_id": 14241, "ts": "2026-06-23T07:56:55Z", "hours": 6.0522, "text": "Devlog It has been a long time since my last devlog, but I was more focused on learning than adding new stuff. Right now, I am focusing on learning HTML, htmx, and Jinja. The welcome page logic is mostly working. I had some problems with it because I used htmx to add new code, but the JavaScript from the is not reloaded with that. Now, I use the HX-Redirect response. I also learned how WebSockets work with FastAPI and htmx. I also designed how the dashboard will look (I attached my drawings. Good luck reading them!)."}, {"post_id": 11274, "ts": "2026-06-18T13:16:22Z", "hours": 3.5742, "text": "Devlog centralLock is called carLocked in the docs. The docs seem to be outdated. I think the OpenAPI specification is more accurate and contains fewer errors. I added a way to validate data using class functions. Implemented timestamps. Using datetime function from python Added tyre endpoints. Added a way to generate new API keys and create new cars (I used python secrets). (getting ready to make first public running version) Roadmap.md file with status of this project What is next to do Start using the updated method for changing data. Update the dashboard to reflect and modify the new data. Add WebSocket support. Add the remaining 2 vehicle and warning endpoints. Create an example app for testers. Redesign dashboard. It looks awful I had a 2 days off because I was on school trip but I back. Next thing on my list is an updated dashboard"}, {"post_id": 9202, "ts": "2026-06-15T13:28:28Z", "hours": 1.9225, "text": "Devlog You can edit data through the dashboard now. It’s not the best solution, and I want to change how it works (probably start from scratch), but not now. Diagnostics endpoints. I had a very good time with them today. Why? Because of the “/diagnostics” docs. I attached a screenshot showing an example from the official website and data from a real car (left: real API, right: docs). If you look at them, you can see two errors and one very small issue that you would only notice if you read the whole documentation: In serviceWarning, you can see the value is NORMAL, but NORMAL is not a valid value for it. It should be NO_WARNING. This is the small one. In engineHoursToService, the API response contains a unit, but the docs don’t mention it at all. And the worst one (and the only real error): there is no information about washerFluidLevelWarning in the docs, but it appears in the data from the car. What do you think I should do? Should I write to them about it? I think you can comment on the post, so let me know what you think."}, {"post_id": 8961, "ts": "2026-06-14T22:15:21Z", "hours": 1.7606, "text": "Devlog Added odometer and fuel endpoints. Funny thing is that Volvo sends in what unit the data is, but the docs say that only metric units are valid, so it really sends always the same unit. Most likely they wanted to add imperial later, or they left it like this for simplicity. Added first version of dashboard. For now, it’s using polling every 5 seconds (I have planned to change it to WebSocket). It only displays some information and can’t edit anything. Also, I wrote some HTML and JavaScript. I never liked web development, so I don’t know a lot (I’m learning while I code 😅). It could be that it will look very rough till the end because I don’t have any patience for HTML and CSS. I “will” do it when I have a very good day, or AI will do it? I would like not to use AI in this way, but I will see. Edit: Forgot to push the updated version to GitHub I will do it tomorrow because it’s late (it’s tomorrow )"}, {"post_id": 8322, "ts": "2026-06-13T20:45:50Z", "hours": 2.8264, "text": "Devlog Added a command accessibility endpoint (it tells if the car can receive commands). I refactored duplicate code in the climate endpoint. Added engine endpoints (they aren’t perfect, but this isn’t the final code). It was also a frustrating day because I repeatedly forgot to save my code before testing (my bad). A photo of the error that cost me way too much time today. (I changed it to “/vehicles/{VIN}/engine-status”, but I didn’t save the file.)"}, {"post_id": 7410, "ts": "2026-06-12T10:41:57Z", "hours": 0.9136, "text": "I setup my codespace and started working on first few endpoints. Additionally I looked how most of Volvos apis looks that gave me direction to go. That was all time I had today. Also I could add screenshot here because of macOS :("}]...
|
Title: Volvo API playground by @Kl | Stardance
De Title: Volvo API playground by @Kl | Stardance
Devlogs:
I setup my codespace and started working on first few endpoints. Additionally I looked how most of Volvos apis looks that gave me direction to go. That was all time I had today. Also I could add screenshot here because of macOS :(
Devlog Added a command accessibility endpoint (it tells if the car can receive commands). I refactored duplicate code in the climate endpoint. Added engine endpoints (they aren’t perfect, but this isn’t the final code). It was also a frustrating day because I repeatedly forgot to save my code before testing (my bad). A photo of the error that cost me way too much time today. (I changed it to “/vehicles/{VIN}/engine-status”, but I didn’t save the file.)
Devlog Added odometer and fuel endpoints. Funny thing is that Volvo sends in what unit the data is, but the docs say that only metric units are valid, so it really sends always the same unit. Most likely they wanted to add imperial later, or they left it like this for simplicity. Added first version of dashboard. For now, it’s using polling every 5 seconds (I have planned to change it to WebSocket). It only displays some information and can’t edit anything. Also, I wrote some HTML and JavaScript. I never liked web development, so I don’t know a lot (I’m learning while I code 😅). It could be that it will look very rough till the end because I don’t have any patience for HTML and CSS. I “will” do it when I have a very good day, or AI will do it? I would like not to use AI in this way, but I will see. Edit: Forgot to push the updated version to GitHub I will do it tomorrow because it’s late (it’s tomorrow )
Devlog You can edit data through the dashboard now. It’s not the best solution, and I want to change how it works (probably start from scratch), but not now. Diagnostics endpoints. I had a very good time with them today. Why? Because of the “/diagnostics” docs. I attached a screenshot showing an example from the official website and data from a real car (left: real API, right: docs). If you look at them, you can see two errors and one very small issue that you would only notice if you read the whole documentation: In serviceWarning, you can see the value is NORMAL, but NORMAL is not a valid value for it. It should be NO_WARNING. This is the small one. In engineHoursToService, the API response contains a unit, but the docs don’t mention it at all. And the worst one (and the only real error): there is no information about washerFluidLevelWarning in the docs, but it appears in the data from the car. What do you think I should do? Should I write to them about it? I think you can comment on the post, so let me know what you think.
Devlog centralLock is called carLocked in the docs. The docs seem to be outdated. I think the OpenAPI specification is more accurate and contains fewer errors. I added a way to validate data using class functions. Implemented timestamps. Using datetime function from python Added tyre endpoints. Added a way to generate new API keys and create new cars (I used python secrets). (getting ready to make first public running version) Roadmap.md file with status of this project What is next to do Start using the updated method for changing data. Update the dashboard to reflect and modify the new data. Add WebSocket support. Add the remaining 2 vehicle and warning endpoints. Create an example app for testers. Redesign dashboard. It looks awful I had a 2 days off because I was on school trip but I back. Next thing on my list is an updated dashboard
Devlog It has been a long time since my last devlog, but I was more focused on learning than adding new stuff. Right now, I am focusing on learning HTML, htmx, and Jinja. The welcome page logic is mostly working. I had some problems with it because I used htmx to add new code, but the JavaScript from the is not reloaded with that. Now, I use the HX-Redirect response. I also learned how WebSockets work with FastAPI and htmx. I also designed how the dashboard will look (I attached my drawings. Good luck reading them!).
Devlog A funny story: I built the invoice system but didn’t always assign values correctly, so the values got mixed up. I spent a long time debugging before realizing that was the cause. { "error" : { "message" : "VALUE_ERROR" , "description" : " \" Car \" object has no field \" 123 \" " } } I also spent a lot of time on CSS. Most of that time went into learning: classes IDs box shadows CSS Grid The reason it took so long since the last devlog is CSS. As I said before, I don’t really like web development, so my motivation was pretty low. I used some AI, but I worked hard to remove most of the generated code. At this point, most of the site’s design looks the way I want it to and will probably stay that way until the end of the project. Made invoices have some logic instead of always sending the same value. That means: If no invoice status is set, it sends COMPLETED or RUNNING depending on whether the engine or climate is running. Loc like actions can’t have a RUNNING invoice status. Added a distinction between successful and failed invoices. PS: Always remember to stop the server with Ctrl+C , not Ctrl+Z , because Ctrl+Z can leave the process running and keep the port blocked.
Devlog I added two static (for now) endpoints: statistics and warning . The statistics endpoint mostly returns data, so there isn’t much to test. The warning endpoint has a very large response that would require a lot of new code, and for now I don’t want to implement all of it. I started working on adding cars through the dashboard (you could already see part of it in the last devlog), but I found out it doesn’t work, so I need to fix it before the next devlog. Climate and engine STOP commands now respond correctly. In the last invoice update, they incorrectly returned RUNNING . Added checks for the new command endpoints to verify whether the car supports a given command. Added a small terminal page that outputs changes. In the future, you’ll be able to choose whether to display only Volvo changes, all changes, or all information (for example, if you checked whether the windows status). I also used it to verify that the normal WebSocket status works. Added the foundations for disabling WebSockets on startup. Only a configuration file is left to implement. Added UNAVAILABLE reason invoice logic mostly something like this: If the reason is NO_INTERNET , the invoice becomes CONNECTION_FAILURE . If the reason is POWER_SAVING_MODE , the invoice becomes VEHICLE_IN_SLEEP . Made some improvements to the dashboard’s appearance.
Devlog This devlog will be a short one because I’ve been focusing on implementing OAuth 2.0. I’ll cover that in more detail in the next update but I will add photo of a “login” screen that I created for it (it looks bad on purpose). What’s new The terminal now works with more than one static car. The dashboard can (once again) create new cars. The codebase has been split into multiple files instead of a single large file: main still contains the public API endpoints. internal contains the dashboard logic and internal API endpoints. database will contain multiple predefined car scenarios. I also started writing a new manual that documents the quirks of the Volvo API and my implementation ( and edge cases). I will write more about in next 2 devlogs What’s left before the first ship An example application demonstrating the differences between the official Volvo Sandbox and this project. OAuth 2.0 with PKCE (it would be great to have before the first ship). Documentation. A major code cleanup and refactoring.
Devlog Small additions to the new documentation. changes how the api handles errors BIG ADDITION OAuth2 without PKCE. I started working on PKCE, but I thought I should write a devlog before adding it. Added a login website (I know I mentioned it last time). Added a way to enable and disable OAuth2. Authentication now checks whether OAuth2 is enabled. If it is, requests are authenticated using OAuth2. Tokens don’t expire yet, but that will be added soon. Added endpoints for refreshing tokens and exchanging an authorization code for tokens. How does OAuth2 work? The app redirects the user to a login page. After logging in, the website redirects the user back to the callback URL provided by the app. The app receives an authorization code, which it exchanges for two tokens: a long-lived refresh token and a short-lived access token. When the access token expires, the app can use the refresh endpoint to obtain a new access token. What is PKCE? I’ll write more about it once it’s added to the project. In short, PKCE protects the authorization flow by ensuring that only the application that started the login process can exchange the authorization code for tokens. The application first generates a random secret (called a code verifier). Before the login request is sent, a hashed version of that secret (the code challenge) is sent to the server. Later, when exchanging the authorization code for tokens, the application sends the original secret. The server verifies that it matches the previously received hash before issuing any tokens. I’ll explain the complete flow in the next devlog.
Devlog A small error from the last devlog: it’s PKCE , not PCKE . I had to rename a lot of variables because of that. More customizable data Gearbox Model year More diagnostic data for lights (hazard, fog, brake, high beam, low beam, and more) Other additions Added a new default API key with 3 cars, each having different values. Wrote more docs. Started working on scenarios (templates for new or existing cars to make setup faster). I’m thinking about loading them from a file so users can create their own. Started working on setting up OAuth2 through the dashboard. Fixed most command responses because when I first created them, I forgot to wrap everything inside { "data": {} } . Added light options to the dashboard. Working: PKCE How does it work? The application generates a random secret. Before redirecting the user to the login page, it sends only a hashed version of that secret. After the user logs in, the application receives an authorization code. When exchanging the code for tokens, it sends the original secret. The server checks whether it matches the previously received hash. If it does, the tokens are issued. It normally protects from having the tokens stolen New promoting picture I made in canva have a look
Devlog How I don’t like web development… did I already say that? I’ll say it again. I’m working on the OAuth2 settings, and I had a problem where one of the query parameters wasn’t reaching the backend. I still don’t know what actually fixed it. Then I had another problem. I have a function that changes values in the backend, but only one button worked while everything else didn’t. It turned out to be because I debugged the first problem with AI. Always trust your own mind before trusting AI. The problem was hx-trigger . I also had problems applying CSS through HTMX. In the end, I solved it by using hx-redirect . But in the end everything works (you can see it one the phtoto) I also worked on the scenario system, which loads scenarios from a JSON file. It isn’t tested yet, and I still need to work on state snapshots. The idea is that you’ll be able to save a moment in time and restore it later, so you can test the same scenario as many times as you want without setting up all the data again. I also started working on a companion app to showcase the differences between my implementation and the official demo car sandbox. I’ll write more about it in the next devlog.
Devlog Writing documentation is a good way to check whether the code you wrote actually works. I already found four bugs while documenting the project. For example, I forgot to pass the redirect URI in a function in main.py , even though it was already implemented in internal.py . I also fixed a bug where notifications could sometimes contain an older value. The dashboard has been moved into a separate file. Snapshots currently have a problem. They are very similar to the Car class, so I’ll debug it and explain what the issue was in the next devlog. Companion app The companion app is meant to showcase the differences between my implementation and the official Volvo Demo Car Sandbox. It also makes testing easier, since you don’t have to write your own application just to try the API. I had a problem with the built-in LibreSSL because one of the dependencies didn’t support it. I had to reinstall Python so that uv would detect the new OpenSSL installation. After that, I was finally able to start the app and get it working. Auto-login and automatic creation of a test car are now working. There’s is no css but I will do it after logic works One more thing: the reason the devlogs have been quieter recently is that I’ve been dealing with some administrative paperwork. I’ll get back to posting them more regularly once that’s sorted out.
Devlog Authorization was my mistake. It should have been accessToken , not Authorization . Why I thought that? I have no idea. No it was good before I was sleepy I think when I did that The snapshots system now works. Why it didn’t work as expected: I forgot to use copy(deep=True) . One of the small dictionaries was written incorrectly. Added saving and loading snapshots from a file. The scenarios system now works and has been tested. Difference between snapshots and scenarios Snapshots copy all data about a car. They are persistent and can be saved to a file. Scenarios only change selected attributes. They are designed to be created and edited manually in a JSON file. Main app The main app is mostly ready. Before the first release, I still need to: Finish the documentation. Add a roadmap with future updates. Verify error responses against the real API. Finish the comparison feature in the companion app. Add more ready-to-use scenarios and API keys. Companion app Manual login now works, so only the comparison logic is left. I found a bug where api_key_p was None because one endpoint redirected using api_key instead. Started working on the comparison feature. PS: A photo of why the api_key_p was none
A public online demo!!!!! The project is finally available online! https://playground.kls.hackclub.app/internal/welcome Please don’t be the bad guy and fight with other people over access. ❤️ That’s all I wanted to say because this is a really big milestone for me. There will also be another commit today to make sure everyone can run their own instance of the project. I found a few issues that only appeared outside of my local environment: Some WebSocket features break when using HTTPS. The dashboard had problems when the instance wasn’t running on the same computer. Those should be fixed in today’s commit. If you find any errors please comment or contact me on slack Also thanks to nest hackclub for hosting
Devlog Companion app Added manual mode for comparison. Engine start/stop now works in normal mode. Before pushing, I forgot to fix one thing: { "error" : "Failed to retrieve data from unofficial API." , "detail" :{ "detail" :[{ "type" : "dict_type" , "loc" :[ "body" ], "msg" : "Input should be a valid dictionary" , "input" : "{ \" runtimeMinutes \" : 10}" }]}} The fix was simple: I forgot to use json.loads() . I pushed a quick fix commit right after. The photo shows the manual comparison page. I’m still working on the comparison logic, which is why it doesn’t have any CSS yet. Sorry for not adding Volvo API keys so you can see the differences between both APIs, but that would have taken too much time today. Its also the reason why Im creating this app Main app Worked on the documentation. The notifier now supports more than one updated attribute at the same time. It’s not the best implementation, but I’ll improve it after the first ship. Fixed snapshot loading and added exception handling. Scenario loading now reports malformed JSON files. Fixed a dashboard bug where tire information was shown three times. I think I planned to add more data there… and then forgot. I should probably test everything before making a devlog or committing, but I also don’t want my devlogs to have to much time.
Devlog I’m mainly focused on finishing the companion app. I started working on the CSS. Most of my time was spent learning Tailwind CSS (so I didn’t track it). I think it’s a better fit for me than writing plain CSS. Added Tailwind CSS to all pages of the companion app. (I think I need to redo the main app now. 😅) Added a small README with information about the main app. I think it done now but I will come back to it before first ship Main app While working on the companion app, I found another issue. The Content-Type: application/json behavior doesn’t match the official API. I verified that the official API works as expected, checks for it mine doesn’t (I think)
Devlog Companion app I said it was finished for now, but I forgot to add one more thing (the one on the left in the screenshots): a dashboard redirect. Main app I’m still investigating the Content-Type problem. I verified that the official Volvo API behaves correctly, so I’m working on matching that behavior. Added work-in-progress Content-Type checks. Started reworking the CSS using Tailwind CSS. It’s still mixed with some plain CSS for now. Enabled support for the reduced guard lock command. You have to manually mark it as supported, and for now it behaves the same as the normal lock command. Let me know which design you like more: the new one (center) or the old one (right).
Devlog I don’t know if I mentioned it before, but for now the Content-Type checks are disabled. I need to learn more about them and implement better validation. Created an updated OAuth2 settings page and a car selection screen (with Tailwind CSS, of course). Started experimenting with a new dashboard. It’s still a work in progress, but it will most likely become the main design. I’m also thinking about adding a second dashboard style, although I’m not sure if I’ll do that before the first release. I definitely want to clean up the HTML/Tailwind code by moving repeated styles into reusable classes or something similar. I’m also thinking about using more HTMX so that more pages can update data without needing a full page reload. Wrote more documentation. I still need to verify the fuel endpoint because I don’t remember whether it handles different engine types correctly. ( The new OAuth2 settings page and the car selection screen. For next develop I think I will make a video of how everything works)
Devlog Most of my time was spent working on the dashboard with Tailwind CSS. It took a lot of experimenting to find a design I actually like. I also changed how HTMX updates the dashboard through WebSockets. Before: A dedicated template was rendered every time to update that part of the dashboard. Now: Only the text containing the updated value is replaced. That said, in the future it won’t always be just text. For example, if the fuel type changes from hybrid to electric , the fuel level should disappear from the dashboard instead of just changing its value. While working on this, I found a bug caused by HTMX sending boolean values as strings. This caused climate settings to be marked as invalid. I need to distinguish between an invalid value and an invalid attribute instead of always treating the entire attribute as invalid. Note to myself Add transitions. Make all HTML pages use the same CSS file from now on. Update the version on nest server and make a public companion instance Aaand that’s all. Making websites is painfully slow.
Devlog I found another way to hide the fuel stat when it isn’t useful for a particular type of car: the HTML hidden attribute. At first, I thought I should add or remove the element hidden, but that turned out to be more complicated than I expected. I think using hidden is still a cleaner solution but I still using templates files. While working on the dashboard, I wanted to add units like km , L , and % to some values. Instead of handling that in Python, I added another div with some margins and, in a few places, used flex so everything stays on the same line without adding more backend logic. Added more page changes thru HTMX (nearly all pages use it). Creating a new car now refreshes the page. when an error occurs, I use HX-Reswap and the HX-Retarget response header (when creating new car as proof of concept). Added HTMX transitions to the OAuth2 settings page.(all pages have transitions) What to do before the first release (Mostly a checklist for myself 😅) Content-Type checks. Scenario and snapshot system support in the dashboard. Main showcase page. Finish the remaining documentation. Two READMEs: one for the main repository and one for the companion app repository. I’m thinking about having one technical README and another one that’s easier to understand for people who don’t code. Better error handling in the dashboard. Right now, most errors are just displayed as plain text instead of being part of the page. deploy updated version on nest I wanted to add a video but MacOS made me a half gig and I don’t think stardance would handle
The comparison app is now online! Comparison app: https://compareplay.kls.hackclub.app/ I also updated the main app with the new dashboard design: https://playground.kls.hackclub.app/internal/welcome devlog Tailwind CSS is no longer loaded from the CDN. I think its now precompiled. Note to others: Remember to update your banner to feature your app (see #stardance on Slack). Otherwise, your ship will be rejected. EDIT: A lot of bots try to connect to my apps do you think I should make a honeypot?
Devlog The Content-Type problem is SOLVED …… What was the problem? (My reading skills? ) there are two headers with application/json : Content-Type (POST) Accept (GET) The Accept header isn’t required ( can be */* , application/* or application/json ). So the Content-Type mystery is mostly FIXED but I still need to check with a real Volvo car if Content-Type is actually required. (I’ll do it tomorrow.) Changes: Accept is now handled by my API like in the official API. Added Content-Type checks (like the docs say, meaning it’s required). While proofreading the docs, I found that PKCE is written as PCKE in one internal endpoint. (Not fixed yet.) Small README update (I try to keep it up to date). Scenario page: You can now load a scenario using the GUI. Recompiled the Tailwind CSS. I attached screenshots showing it (you can also see snapshot button but its not implemented YET)
Devlog Snapshots loading page (screenshots while I worked. I had more but the limit was 4). As suggested by the Tailwind CSS tools, changed some classes to more canonical ones. You can now delete cars through both the API and the dashboard. Snapshot corruption (when the app is force quit) should be fixed. Started working on the landing page, but I’ll leave it for the next devlog (mostly because I have on my other laptop). Fixes to do Sometimes the new OAuth2 and Snapshots buttons are off-center. Compare app needs fixing (need to enable the Content-Type fix from the official API). PKCE spelling in the internal API.
Devlog I had a problem when I wanted to rewrite the scenario system. It only changed the local version of the Car (It means it really didn’t update anything). I wanted to update a backup version first, and only if everything was correct, replace the original with the backup. In the end, I used an already created function to first test and then apply to the car . Main PKCE misspelling fixed. Added a landing page with an option to disable it and redirect directly to the login screen (like in the last devlog I have photos of making it). Worked on the lights section. Fixed the docs URLs. Dashboard and WebSocket toggles now work. Rewrote and enabled the updates endpoint. Validation now catches values that can’t be converted to int . Scenario loading into a car instance should now be more consistent with the other functions. Improved mobile responsiveness (and then fixed the desktop one). Some elements were outside the screen on mobile (nothing important, but it didn’t look good). NOTE: the dashboard with car attributes still needs to be adapted. Added windows (because I forgot to 😅) to the dashboard and organised the lighting section. OAuth2 and Snapshots buttons should now always be centred. TODO Debug and tracing headers (from the real API). Additional instructions. Then I think it’s finally ready for the first ship. There are still a lot of things I want to add, but I can’t work indefinitely. Compare The compare app now has the Content-Type fix enabled (like the official API). Compiled the Tailwind CSS for the compare app. NOTE: I will add here more screenshots as link later Also thinking about adding it frictionless mission but I’m not sure.
Devlog Tracking headers implemented : There are two vcc-api-operationId - UUID traceparent - W3C traceparent (for now only sends it back) dashboard should look good on small screen (its very long but I don’t want to redesign it now) This is the reason why I there is much time in this devlog. It was a lot of try and error before something looked good both on mobile and desktop and I liked it . But at least it works know 🙃. some small cleanup of comments I worked again on internal updates endpoint (hopefully works now) started working on pytests (but I will talk about in next devlog (I gave my self 2 days for it) I really want to get the first ship out, so it isn’t going to be perfect. I still have a lot of features and improvements I’d like to add.
Devlog Working hard on pytest tests. I learn how assert works and how to name . I never used or created test in any language so I think they aren’t perfect (not like they should),but they work😄. I looked like AI made few and how other people and read some stuff online Tests created for these endpoints Around 25 of them List cars About car Engine info Engine start/stop Climate start/stop Windows Doors Lock/Unlock Reduced Guard Lock Flash, Honk, and Combination Tyres Statistics Fuel Odometer Engine diagnostics Brakes Command accessibility Still to do Warnings and diagnostics Commands More changes The tests helped me find and clean up several issues: Documentation updates. The honk endpoint was ../horn but should be /honk . Some values ( odometer , fuel ) are int , just like in the OpenAPI specification, not as described in the official docs. Fixed spelling mistakes: - oillevel to oilLevel - coolantLever to coolantLevel Want to help and has access to volvo with active VOC I need to test engine and climate endpoints but I don’t have an access to a car with it. Soooo if you can contact me on slack
Devlog I forgot to add that I worked on the tests in the test branch, not the main one. OAuth2 PKCE testing. Helped me find an error where, if the code was used (it was reset to "" ), it was accepted as "" . Now it correctly returns an error. OAuth2 flow testing. Warnings and diagnostics now have some simple checks too. And I merged it into main . Then I started cleaning up the Tailwind CSS. NOTE: they are in new branch dashboard/cleanup Why? Because I used the Play CDN in the past, so I couldn’t create utility classes in a CSS file. Soooo I didn’t. Andddd there were a lot of Tailwind classes that didn’t fit on my screen. Now that I started precompiling it, I could add them. I added 5 unique utility classes. All of them combined are used around ~120 times across all HTMLs. The longest one: @utility inputSelection { @apply w-full px-4 py-2 .5 bg-zinc-950 border border-zinc-800 rounded-xl text-zinc-100 focus : outline-none focus : ring-2 focus : ring-blue-300 focus : border-transparent transition-all appearance-none text-center [ text-align-last : center ] cursor-pointer ; } I also minified the CSS file. If I understand it, it removes anything the browser doesn’t need to understand the CSS (new lines, unnecessary spaces…). It’s better because those characters are still sent over the network, and fewer bytes mean less traffic. While using the new utility classes, I tried to preserve the layout, so everything should look the same as before.
Devlog SITE changes I found that some number inputs didn’t use the utility classes. I gave them inputText because they are really the same; the only difference is the HTML type . I also forgot to update the reloadable fuel section. It now uses the shorter utility class. Made sure that all text in the header is the same size (they weren’t). I copied all changes back to the main branch. config changes Then I added a config file using the configparser library. also added an option to disable the FastAPI docs. I started working on Wiki: reworking docs.md into a GitHub Wiki with up to date information. Error logger, so you can see what’s wrong without printing the API response in your code. I had some problems with catching the fastapi automatic response but I will leave it for next devlog
Devlog There was a small (or big) problem in my playground. If an error was returned in the response, you could only see it if your app handled it or by printing the response. That’s why I added an error logger. It can show errors in two ways: Terminal Log file How it works There were two ways of doing it (from what I learned): Middleware that captures all responses (this could be helpful in the future). Exception handlers (this is what I chose). I use two handlers: @app.exception_handler(RequestValidationError) @app.exception_handler(HTTPException) It was a horrible time searching for why it didn’t work. At first, I worked in a separate file, but I couldn’t get the (fastapi) app variable into those functions. So I copied them into main file to make them work first. I had to change some JSON responses to HTTPException to make the second handler work. After I captured the first request and printed it, I worked on one function that writes a log and another that prints to the terminal. I also created a class to store useful data. It works like this: Exception handler-> ->Put data into class -> ->Create response -> ->Return response ->Create a background task that logs the error I create a background task so the response doesn’t wait or even worse fails In the end I found that I can wrap these func with this simple func to make them work in different file def setup_error_logging(app: FastAPI): Added a config option: To disable it completely. To disable only the log file. It also bypasses all internal endpoints to make the logs more readable. The best fail… 😅 I returned an exception instead of raising it. I spent a good 15 minutes wondering why the response had status code 200 with a JSON body saying status code 400 . response changes I also checked how the authorization errors look and added two new ones: Missing Authorization header. Invalid vcc-api-key header. WIKI (not counted) I focus on making a GitHub wiki (new docs) After ending them and the error logger. Its time for the first ship !!!!!!! Nest instability: I made a backup server : https://frog01-21185.wykr.es/ Its not ideal one, bc some asian countries are blocked but its shouldn’t have any downtime (I hope so) If an Admin read it why I must copy enter from different text input 😭
Devlog Error logger added colors to the terminal print out using: \033[31m \033[0m Good to know that it is so easy to add colors to text added timestamps to log file and - between errors Changes how it reads body once again and fixed url encoded requests logging My additional information I put in detail in the json response (the real API can send it like that buttty I didn’t see it. info from docs ) additional changes: New scenarios mostly about service warnings You can add notes to the website thru config files Scopes I started working on scopes. What are they? They are really permissions (you can know them from discord bots or if you login thru GitHub etc.) I don’t want to put them in this first ship but I needed to work on something (while I work on wiki) and I CAN’T guarantee every thing works after adding them. You can see it in the scopes branch. what is done: I have made preparation so the additional database (dict) I use for OAuth can store more data have updated website func to work with changes and also pytest added all possible conve (connectivity API) scopes WIKI when I add everything to them I will finally try making a ship added the error logger page updated the sidebar scenario and snapshots page a lot of misc Bonus photos from vacation on baltic sea
Long time no see… The school started aaand I didn’t have time I had low motivation The only thing to do before first ship is docs but I could find time to finish them. Buut I back now. AND I promise to ship it before 7 of September. If you are voting on this project PLEASE do not skip. I have my birthday coming and if the shipwrights doesn’t have a long list it could mean this project payout could be my birthday gift. If I ofc ship it 😅 devlog Small marketing changes everywhere to say that this project doesn’t have any ready code to use Added info about error logger on the landing page Scopes A long way from last devlog Fixed pytest ( A second time) TEMPORARY FIX added so the scope error doesn’t - throw just internal error FIXed the Oauth2 endpoint at least 3 times Added a WIP endpoint to edit scope data from API Fixed how cars are created so they work with both - Oauth and scopes stuff Only looking dashboard page for scopes compare I think I forgot to say something in last devlog config file if you would like to use different instance Toml oillevel to oilLever AI disclaimer that I used this project to learn tailwind Make the doors have different statuses in mean time Untracked WIKI Redo the home page Started working on stardance path A lot of misc that I don’t remember other I created a small modified volvo example app to show that my app works like the real one
Devlog MAIN added a startup baner fixed snapshots not saving if website was used scope If you didn’t follow from start this branch contains the experimental scope support which is mostly done but I can guarantee stability that’s why it isn’t pushed to main in fist ship made the scope page work added a back button added button to scope on main page fixed snapshots loading/saving
Read till the end PLEASE 🥺 Devlog A lot of changes from the last devlog only 5 hrs Mostly bc I add stuff on top of but I will suffer in the future (See dev branch for these changes) Change all connectivity API to start with /connected-vehicle/v2/ to make room for different APIs After that I fixed pytest to reflect that I added a location API with a ONE endpoint There were few iterations Added scopes for this API location:read If I remember correctly Unique error responses (because location error look like old (v1) connectivity API Fixed that operationID could be a constant Added a config option to use longer API keys About here I Fixed the url for location api because it used the connectivity scheme Started working on energy API I added all data from it to this project In short one endpoints says what this car is capable of And the other says the values TODO: add its unique error its half done Scopes corresponding to energy API Fixed that some values and capabilities had the same name (bc of that some bool values where number so a it was important) WIP Oauth2 update: JWT tokens for access tokens WIP token can expire! what are JWT token? There consist of three parts header payload and signature The two first is important for my project the 3 isn’t . They store info about issuer, when token is active, scopes… A lot of useless data for this project or useful? We will see Life Bc of school I didn’t have a lot of time to write devlog (and write code) but I try to do my best before the end of stardance The next ship is planned for 28 September BIRTHDAY TODAY (16 September) Im celebrating my birthday 😄 If you write me a few good words It would be motivating for me.
Devlog A lot of breaking changes later and getting closer to PR and going to 2 ship Token lifetime WORKS made time when token is expired is rounded to int endpoint for invalidating token possibility for enabling expiring token for a specific token when it’s disabled for all in config file misc pytest for location and energy API fix the url for the enrgy API (it started with connectivity url not wi the energy api) cleanup import created new files to make the code more readable dashboard added location values added capabilities and values auto token generation and expiration in dashboard
Devlog A very long time no see. I have made a lot of progress on adding an SQL database. Testing on MySQL The backup server provider gives me access to one. SQL changes A lot of BIG changes. The reason why I haven’t posted for so long is that I didn’t want to post about something that doesn’t work. Created new classes to intercept data changes, both in case of direct dict changes and when going through the SQL model library. (I didn’t change much in the code, just imported it under the same name as the old database.) And it works! At the start, only reading data worked, but now it can send data back to the database. Added a regen function to make sure built-in API keys are always the same after a restart. Fixed the car creation function (but when I started storing the additional data in SQL, it broke AGAIN). Added configuration attributes. At first, just the database type, but then all the information needed to connect to a MySQL database. Fixed the scenario readconfig (wasn’t it updated in the past?). A really small number of things I added? Yes, but the amount of debugging and changing built-in functions in classes took me so long. (Could be because of school and not having time to do everything in one sitting.) But I learned how to make a dummy dict with a class, as I called it in the commit: proxy . Problems The SQL database can’t create new cars. Need to check all internal endpoints to make sure they work. Still haven’t merged the DEV branch (TODO). All information is stored in one column as JSON. It works, buuuut I don’t like it that way. Need to clean up the proxy classes. updating docs What failed this time? The second photo attached shows it. Have a look before reading more. _contains__ If you see it, congrats! But if you have a screen full of code, it’s harder to spot. It should be __contains__ , and I spent, I think, two days debugging why all in statements just didn’t work. I was so happy when I finally found it! XAMPP and Apple Silicon The manager app doesn’t open after a restart, so after consulting Google and AI, I found a command that I use: sudo /Applications/XAMPP/xamppfiles/xampp start xampp If someone is asking why I didn’t use the server provided one it just wasn’t practical for now.
Ships:
A Milestone Welcome everybody to the first ship of this project. What is this project? This project simulates how the Volvo API works. Why was this project created in the first place? So it’s easier to create and test your app that uses the Volvo API without using ready-made libraries. I can’t find the features you mentioned in the devlog? Check the scope branch or the upcoming dev branch. What I’m proud of: I learned a lot of things (this is my first big public project): Tailwind Python stuff (I started with C++) Writing documentation (Markdown) I also learned the basics of OAuth2 and how APIs work. Making a project with all the features needed to get started. I created an additional document for you, Stardancers: Stardance PATH What is still on the TODO list? More APIs Scopes docker image See the roadmap . What to see? error logger recreated endpoints dashboard web socket realtime changes internal endpints interactivity of the car...
|
1793004616.137251
|
1793091016.137251
|
|
949
|
Untitled project by @Kanata | Stardance
|
Kanata
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @Kanata | Stardance
|
1792734584.5063086
|
1793339384.5063086
|
|
948
|
My awesome macropad! by @Kanata | Stardance
|
Kanata
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @Kanata | Stardance
|
1792778036.074678
|
1793382836.074678
|
|
947
|
BlackShell Golf by @BlackShell | Stardance
|
BlackShell
|
0
|
7.94
|
0
|
[]
|
[{"post_id": 77965, "ts": "202 [{"post_id": 77965, "ts": "2026-10-09T01:20:22Z", "hours": 2.4283, "text": "Build watch App!!"}, {"post_id": 77722, "ts": "2026-10-08T02:55:39Z", "hours": 5.1039, "text": "Liquid Glass update!!!"}, {"post_id": 212, "ts": "2026-06-01T08:45:03Z", "hours": 0.4108, "text": "Today I prepared BlackShell Golf for Stardance and published the project on GitHub. BlackShell Golf is a Flutter app for live multiplayer golf scoring. Players can create a room, join a room, and track golf rounds together. Today I connected the project repository, organized the codebase, and tested the app in the browser. Next, I plan to improve score saving, round history, and the overall user experience. Screenshot attached."}]...
|
Title: BlackShell Golf by @BlackShell | Stardance
Title: BlackShell Golf by @BlackShell | Stardance
Devlogs:
Today I prepared BlackShell Golf for Stardance and published the project on GitHub. BlackShell Golf is a Flutter app for live multiplayer golf scoring. Players can create a room, join a room, and track golf rounds together. Today I connected the project repository, organized the codebase, and tested the app in the browser. Next, I plan to improve score saving, round history, and the overall user experience. Screenshot attached.
Liquid Glass update!!!
Build watch App!!...
|
1792558507.209931
|
1793163307.209931
|
|
946
|
MacroPad V4 by @TAP | Stardance
|
TAP
|
0
|
0.73
|
0
|
[]
|
[{"post_id": 25162, "ts": "202 [{"post_id": 25162, "ts": "2026-07-09T06:36:22Z", "hours": 0.7272, "text": "MADE THE SCHEMATIC! This is probably one of the most cutest schematic I have ever made! Its a pretty simple plan tho! This has 3x3 switch matrix, 9 sk6812 mini-e in a daisy chain and an 0.91” OLED"}]...
|
Title: MacroPad V4 by @TAP | Stardance
Devlogs:
M Title: MacroPad V4 by @TAP | Stardance
Devlogs:
MADE THE SCHEMATIC! This is probably one of the most cutest schematic I have ever made! Its a pretty simple plan tho! This has 3x3 switch matrix, 9 sk6812 mini-e in a daisy chain and an 0.91” OLED...
|
1792939933.6606238
|
1793803933.6606238
|
|
945
|
StudyQuest by @BlackShell | Stardance
|
BlackShell
|
0
|
5.81
|
0
|
[]
|
[{"post_id": 77724, "ts": "202 [{"post_id": 77724, "ts": "2026-10-08T03:02:24Z", "hours": 2.9167, "text": "I developing on mac"}, {"post_id": 2568, "ts": "2026-06-05T04:19:09Z", "hours": 0.9864, "text": "StudyQuest progress Implemented the core progression system: • XP system • Level system • Level up at 100 XP • XP progress bar • Study session tracking • Study time tracking The app now tracks study sessions and study time while rewarding progress with XP and levels. Built with Flutter."}, {"post_id": 2162, "ts": "2026-06-04T14:35:48Z", "hours": 0.8278, "text": "StudyQuest now runs on iOS 📱 Current features: XP system Level system Level up at 100 XP Next features: XP progress bar Study timer Streak tracking Built with Flutter."}, {"post_id": 1951, "ts": "2026-06-04T06:18:37Z", "hours": 1.0806, "text": "Started development on StudyQuest, a gamified study tracker built with Flutter. Today I: Created the Flutter project structure Set up GitHub and pushed the initial code Built the first home screen Added placeholders for XP, levels, study time, and streaks Learned more about Flutter widgets and layout structure Next, I plan to add a study timer and an XP system."}]...
|
Title: StudyQuest by @BlackShell | Stardance
Devl Title: StudyQuest by @BlackShell | Stardance
Devlogs:
Started development on StudyQuest, a gamified study tracker built with Flutter. Today I: Created the Flutter project structure Set up GitHub and pushed the initial code Built the first home screen Added placeholders for XP, levels, study time, and streaks Learned more about Flutter widgets and layout structure Next, I plan to add a study timer and an XP system.
StudyQuest now runs on iOS 📱 Current features: XP system Level system Level up at 100 XP Next features: XP progress bar Study timer Streak tracking Built with Flutter.
StudyQuest progress Implemented the core progression system: • XP system • Level system • Level up at 100 XP • XP progress bar • Study session tracking • Study time tracking The app now tracks study sessions and study time while rewarding progress with XP and levels. Built with Flutter.
I developing on mac...
|
1792569278.6678202
|
1793174078.6678202
|
|
944
|
Timer! by @TAP | Stardance
|
TAP
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Timer! by @TAP | Stardance
|
1792803031.500145
|
1793407831.500145
|
|
943
|
Project See The Voices Nepal's website by @Pas Project See The Voices Nepal's website by @Pasta | Stardance...
|
Pasta
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Project See The Voices Nepal's website Title: Project See The Voices Nepal's website by @Pasta | Stardance...
|
1792630457.32414
|
1793235257.32414
|
|
942
|
Munni and prism by @Munnisparkle | Stardance
|
Munnisparkle
|
0
|
0.35
|
0
|
[]
|
[{"post_id": 208, "ts": "2026- [{"post_id": 208, "ts": "2026-06-01T08:32:11Z", "hours": 0.3517, "text": "Started setting up the project folder and files for Munni and Prism in VS Code! Created index.html, style.css and game.js. now wrote little bit of html i know thats the conversation blw the characters in the game"}]...
|
Title: Munni and prism by @Munnisparkle | Stardanc Title: Munni and prism by @Munnisparkle | Stardance
Devlogs:
Started setting up the project folder and files for Munni and Prism in VS Code! Created index.html, style.css and game.js. now wrote little bit of html i know thats the conversation blw the characters in the game...
|
1792670068.659922
|
1793274868.659922
|
|
941
|
Untitled project by @Ila | Stardance
|
Ila
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @Ila | Stardance
|
1792486115.5311885
|
1793090915.5311885
|
|
940
|
Spacetex by @stemdood44 | Stardance
|
stemdood44
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Spacetex by @stemdood44 | Stardance
|
1792788639.4259224
|
1793393439.4259224
|
|
939
|
LUNAR-HAL by @INiNiDS | Stardance
|
INiNiDS
|
1
|
78.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-29T18:18:07Z", "hours": 78.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Finally shipping this! It honestly took forever and I burned out twice along the way, but I pushed through to get it over the finish line. Try out the live demo or grab the local build. Heads up: the web demo might feel super sluggish since the models are running on Heroku, so expect some delay. Also, all demo sessions share the same persistent worlds! Have Fun!", "repo": "https://github.com/ininids/lunar-hal", "demo": "https://lnhal.ininids.in.rs"}]...
|
[{"post_id": 75310, "ts": "202 [{"post_id": 75310, "ts": "2026-09-29T18:16:50Z", "hours": 5.1756, "text": "Alright, final devlog! Went all-in on bug squashing for this one—crushed a ton of issues, finally got CI completely green and stable, cleared out all the CodeQL alerts, and pushed the demo build. So yeah… I’m officially shipping now!"}, {"post_id": 68044, "ts": "2026-09-14T12:49:45Z", "hours": 12.1378, "text": "DevLog #9: Checkpoint Hardening & Stage 5 GNN Kinematics Convergence * This session was focused on a deep technical milestone: diagnosing a critical engine staging bug in LUNAR-HAL and driving the Stellar GNN-kinematics pipeline through the completion of Stage 5. 1. 🛠️ Staging Architecture & Atomic Checkpoint RCA (Rust) Diagnosed and resolved a critical issue in the --resume workflow where staging logic triggered a self-copy ( src == dst ), truncating output checkpoint weights upon restart. Implemented robust canonical path checking ( std::fs: :canonicalize ) to ensure fully atomic weight persistence across interruption signals ( SIGINT / SIGTERM ). Hardened checkpoint state serialization, eliminating filesystem race conditions during runtime hot-reloads. 2. Stage 5: GNN-Kinematics Training Executed the 200-epoch training run for the galactic velocity prediction model ($v_x, v_y, v_z$ derived from positions + photometry). Validated host telemetry: stable VRAM footprint on local NVIDIA GeForce RTX 5070 (~3.1 GB / 12 GB allocated) with optimal throughput (~30s / epoch). 3. Loss & Convergence Verification Train Loss: Decreased to ~0.7660 . Validation Loss: Reached a clean, stable quasi-stationary plateau at ~0.7694 . Physics Constraint: Invariant equilibrium maintained throughout ( phys_loss ≈ 0.7700 ), demonstrating high generalization without overfitting."}, {"post_id": 45625, "ts": "2026-08-12T07:29:27Z", "hours": 3.5756, "text": "* 🚀 DevLog #8: The Great Pivot — From Game to Technical Stellar Platform * The mission has changed. Following the deployment of the WebOS in DevLog #7, we realized that the “game” mechanics were holding back the true potential of the engine. This update marks our transition from a simulation with combat elements to a high-fidelity technical platform for stellar generation, research, and visualization. We have officially executed the transition plan, gutting the “game” and hardening the “platform.” The Great Purge: lunar-stellar-core The era of lunar-game-backend is over. We have performed a git mv on the heart of the engine to establish a strict architectural boundary. Logic Extraction: We have completely removed all traces of Enemies, Projectiles, HP, Attacks, and the “Attention Map.” The simulation no longer cares if you are “watching” a star; it only cares about the physics. The Core: The new lunar-stellar-core crate is now framework-agnostic. It handles only the technical state: camera math, sector caching, and the pipeline results. Terminology Shift: “World” is now “StarScene.” It’s no longer a level; it’s a coordinate-stable dataset. Unified Multi-Platform Deployment We’ve consolidated our frontend logic. Instead of separate builds, we now have a single Managed Frontend Service with a unified builder. Target Switching: Through the lns utility, we can now hot-swap between web , desktop , and android targets. Android Integration: The platform now supports Android NDK/SDK. We’ve replaced mouse-only logic with Pointer Events , enabling touch-based pan/zoom/selection. Runtime Config: The backend now dynamically injects the correct URL (handling the 10.0.2.2 emulator trap) based on the active platform. Sandbox 2.0: The Admin Overlay The Sandbox is no longer a separate copy of the simulation. It has evolved into a Meta-Management Shell for the real frontend. The Iframe Bridge: The Sandbox now embeds the live lunar-frontend via an iframe. Communication Protocol: We implemented a versioned postMessage protocol in lunar-structures . The Sandbox sends Admin Commands (CreateStar, SetCamera) and receives Scene Events (StarSelected). Permanent SIREN Gallery & Drag-and-Drop We’ve moved from “latest renders” to a persistent filesystem-based catalog . Atomic Persistence: Stars created via AI or manual tools are now saved as GalleryStar DTOs. Each star gets its own directory with metadata, SIREN textures, and thumbnails. True Drag-and-Drop: We’ve implemented a custom drag-session in the WebOS. You can now drag a star from the Gallery into the Sandbox to insert it into the live scene, and vice versa. Found Issues The transition hasn’t been without its casualties. Two “boss-level” bugs have appeared during the implementation of the new WebOS logic: Sandbox Handshake & OS Crash: Currently, the Sandbox is failing to “see” the Frontend service through the iframe bridge. Even worse, attempting to initialize the connection often results in a total OS-level hang , crashing the Testbench entirely. We are currently investigating if this is a circular dependency in the backend or a massive memory leak during the handshake. The “Minimize” Trap: While we implemented WindowLifecycle to keep applications alive in the background using display: none , we hit a critical logic error. Once an app is minimized, the “un-minimize” (maximize) function fails to trigger . The app remains in a state of digital limbo, perfectly preserved but completely inaccessible."}, {"post_id": 41159, "ts": "2026-08-05T06:03:25Z", "hours": 3.4289, "text": "DevLog #7: WebOS Evolution, The Black Room, and “lns” Orchestration This update marks a fundamental shift in how we interact with the simulation ecosystem. We have moved away from static dashboards to a fully dynamic WebOS environment within lunar-testbench , alongside a complete overhaul of our launching utility. Lunar-Testbench: The WebOS Overhaul The Testbench has been reimagined as a “Black Room” —a dark, immersive workspace where everything begins with three spotlights. The Spotlight Mechanic The interface features three dormant flashlights. Service Ignition: Clicking a spotlight “turns it on” and launches its corresponding backend service. Dynamic App Injection: Once a service is active, the specific applications depending on that service manifest below the spotlight. The Sandbox: Our most complex tool, the Sandbox , now requires all three services to be active simultaneously, setting the stage for deep-system integration in future updates. The Dock To manage the chaos of multiple windows, we’ve implemented a Bottom Dock . Every running application is pinned here, allowing for seamless switching between training, validation, and live simulation environments. Orchestration: From “lunar-start” to “lns” The way we boot the engine has been streamlined. We’ve stripped the heavy lifting out of the primary entry point to create a more modular startup flow. lns Utility: lunar-start has been evolved into lns —a lightweight micro-utility. Its sole purpose is to initialize the Testbench and trigger the backend. lunar-start-backend: This is a new, dedicated service that acts as the primary launcher. It monitors and manages the lifecycle of all other applications within the suite, ensuring that when you click a service in the UI, the backend is ready to deploy it."}, {"post_id": 31372, "ts": "2026-07-19T18:15:40Z", "hours": 8.1406, "text": "🚀 DevLog #6: Hyper-Optimization, Core Threat Integration, and New Swarm Archetypes ⚙️ Optimization: The Fight for Nanoseconds With the transition to a full 3D environment and manual entity manipulation, the load on the CPU and memory bus grew exponentially. So we tried to optimize as much as possible. 👾 Integration: Enemies in the Core Loop Previously, hostile entities existed only as isolated test units (testbench). Now, enemy fleets are officially hardcoded into the base simulation loop. Autonomous Background AI: Enemy behavior is no longer bound to the player’s viewport. Strategic fleets live their own lives in the background—conquering systems and harvesting resources—even if you are editing a galaxy millions of light-years away. Dynamic Pathfinding: The toughest challenge was stabilizing AI during manual manipulation. If you grab a planet and toss it in front of an enemy dreadnought, the pathfinding algorithm instantly recalculates a safe bypass vector based on the newly altered gravitational signature of that sector. 🛸 New Threat Archetypes: The Utility-Driven AI Each enemy now operates on a Utility AI system, calculating its next move based on distance, health ratios, and—most importantly—the Player’s Attention . We have categorized the hostile forces into six distinct tactical archetypes: Archetype Role Logic Highlight The Tank Heavy Juggernaut Berserk Logic: Its utility increases as its health drops. It becomes more aggressive the harder you try to kill it. The Thief Rapid Raider Attention-Aware: Only strikes stars when the player is looking away ( t_neglect > 15.0 ). High speed (20.0) allows for quick hit-and-run ops. The Invisible Stealth Saboteur Adaptive Camouflage: Maintains $0.05$ visibility. Only reveals itself when the player’s cursor “scans” over it or during brief power-grid flickers. The Scavenger Opportunistic Parasite Pack Mentality: Heavily prioritizes stars that are already under attack by other units to “steal” the resources. The Backstabber Chaos Agent Infighting: If it detects a fellow enemy with $<35 % $ HP, it will betray its own kind to secure the kill for itself. The Coward Skittish Scout Self-Preservation: Immediately generates an escape vector if the player’s “God-Hand” (cursor) gets too close or a Tank enters its vicinity. 🧠 The “Attention Map” Integration The most advanced part of this integration is how these entities interact with the Lunar-Frontend . We don’t just track positions; we track the player’s focus: d_mouse Factor: Enemies calculate their distance to your cursor. Thieves and Cowards use this to decide when to flee or stay in the shadows. t_neglect Metric: The simulation tracks how long it’s been since you last interacted with a specific star. The longer a sector is neglected, the higher the “utility” for an invasion force to move in. ⚔️ Combat Mechanics: Physical Projectiles vs. Direct Damage To keep the simulation performant while maintaining visual fidelity: Star Assaults: Enemies fire physical Projectile entities. Each has its own speed, radius, and damage value, allowing players to potentially intercept them or warp them with gravitational anomalies. Internal Infighting: When enemies like the Backstabber turn on their allies, the damage is processed via an optimized EnemyDamage buffer, bypassing heavy projectile physics for internal “swarm” calculations. Note: ISP issues and local routing to the Hack Club site still make uploading updates feel like sending signals through a dense asteroid belt."}, {"post_id": 12966, "ts": "2026-06-21T06:54:53Z", "hours": 18.7053, "text": "DevLog #5: God-Mode Editor, Crate Separation, and Stealth Features Following the development of “Mission Control,” the project has transitioned into a full 3D environment. The cosmos is no longer just being generated; it can now be manipulated in real-time. Project “Lunar-Hal”: God-Mode Editor The new 3D editor allows for direct manipulation of the simulation rather than just monitoring metrics through the TestBench. Free-Fly Mode: A fully functional in-engine 3D editor. Users can toggle Creator Mode to navigate through stellar clusters at high speeds. Real-Time Manipulation: Selecting a star allows for immediate overrides of mass, spectral class, and luminosity. The SIREN engine recalculates astrophysics on the fly, updating the frontend visuals without performance drops. Architecture: The Great Crate Separation To manage codebase complexity, the backend has undergone a significant architectural refactor. All core gameplay logic has been isolated into a dedicated, independent Rust crate. Modular Design: Rendering overhead and editor scaffolding are now separated from pure game rules, physics, and state machines. Improved Compilation: Logic changes no longer require recompiling the entire project. Crates now compile in isolation, allowing for faster iteration and cleaner incremental builds. Inventory System and Stealth Mechanics Work has begun on a functional inventory system designed to hold “Creator Tools.” This system moves beyond traditional item management into world manipulation. Drag-and-Drop Reality: Mechanics are being implemented to allow users to grab celestial bodies directly from the viewport to rearrange solar systems manually. Entity Interaction: These telekinetic mechanics are also being tested on combat entities. This allows for manual interaction with hostile fleets, such as testing physics logic by moving units into gravitational anomalies like black hole event horizons. Lunar-Frontend: Enhanced UI The UI has been updated to accommodate the new editor and inventory capabilities: Creator Widgets: The modular sidebar now includes inspection panels for editor controls and inventory management. Optimized Streaming: The frontend provides a seamless bridge between TestBench metrics and the heavy 3D viewport, maintaining high performance during active manipulation. Roadmap The next phase of development will focus on: Running heavy simulations of billions of stars in background threads while maintaining editor stability. Stabilizing enemy pathfinding during manual entity manipulation. Preparing the architecture for multiplayer synchronization. Note: DevLog updates may be sporadic due to local ISP and network routing issues affecting access to the Hack Club site. Space logistics are complex, but terrestrial routing remains a significant challenge."}, {"post_id": 7982, "ts": "2026-06-13T09:54:00Z", "hours": 10.8433, "text": "🚀 DevLog #4: The God Mode Dashboard & Stellar Genesis! If Day 3 was about plugging the matrix straight into the engine’s spine, today we built the ultimate command center around it. No more chaos, no more manual config-wrangling via terminal. We just deployed a full-scale infrastructure for total cosmic control! Here is the tactical breakdown of what just dropped in the engineering bay: ⚙️ Project “TestBench”: Total Control & Validation We got tired of guessing what’s actually happening inside our AI’s digital brains, so we built TestBench—the ultimate proving ground for complete testing, training, and validation of every single AI model in the project. Backend Fusion: The whole thing is hardwired straight into our reactive Rust backend. God-Tier UX: Now, benchmarking a dataset, checking loss curves, validating weights, or fine-tuning a model is a matter of a few clicks without ever leaving the ecosystem. Real-time telemetry monitoring. Honestly? It’s clean, it’s seamless, and it just works. 🌟 Meet SIREN: The Star Architect Our AI fleet just got a massive reinforcement. Say hello to our newest model—SIREN. Her sole, monumental objective is the procedural generation of the stars themselves. No more random glowing spheres. SIREN calculates physics, luminosity, spectral classes, and spawns unique, structured astrophysical objects. The cosmos isn’t just procedural anymore; it’s beautifully complex and scientifically backed. 🎛️ Lunar-Frontend: The Creator’s Control Panel A cosmic backend deserves a killer visual interface. We gave lunar-frontend a massive upgrade to make managing this madness an absolute breeze: The Sidebar: We coded a modular, highly responsive sidebar. All your tools, model toggles, and data streams are now neatly organized and right at your fingertips. Next Stop: Unleashing SIREN onto the global map, syncing its generation directly with TestBench metrics, and forcing the frontend to smoothly render billions of new star systems without dropping a single frame! 🚀"}, {"post_id": 4775, "ts": "2026-06-08T08:22:17Z", "hours": 9.8683, "text": "🚀 DevLog #3: The Neural Awakening & Backend Fusion! 🪐 Day 2 was chaos, but Day 3? We just plugged the matrix straight into the spine of the engine! 🧠✨ Remember that “confused toaster” from the last devlog? Yeah, well, it just evolved into a full-blown stellar intellect. The pipeline is locked, loaded, and absolutely cooking. Here is the tactical breakdown of what just dropped in the engineering bay: 🌌 The Big Brain Upgrade (Model & Data): We didn’t just tweak the model; we completely rebuilt its reality. We scraped, cleaned, and injected a massive new dataset, pushing our local parameter model to the absolute limit. No more hallucinating dead stars — lnai now actually understands the cosmic data it’s processing. 🔗 The Great Backend Fusion: The neural net is officially out of the sandbox and merged with the core Rust backend! We wired the prediction pipelines directly into our engine architecture. It’s fast, it’s memory-safe, and it operates with zero friction. Data is flowing from the neural layers to the backend loops in real-time. 🏎️ Zero Meltdown, Pure Performance: Training and running local models usually turns your rig into a literal space heater, but we optimized the living hell out of the inference pipelines. The memory footprint is clean, the tokens are flying, and your GPU can actually breathe while rendering the cosmos. The foundation is solid, the telemetry is clean, and the local universe finally has a brain that doesn’t just work — it thinks . Next stop: weaponizing this intelligence for procedural generation and forcing that flight physics engine to respect the laws of space! 🛰️🔥"}, {"post_id": 1972, "ts": "2026-06-04T07:13:17Z", "hours": 2.9592, "text": "🚀 DevLog #2: Neural Overdrive & Brainstorming LUNAR-AI! 🪐 Day 1 is in the books, and we are officially cooking! We’re pushing the boundaries of our infinite, local-first universe, and things are getting wild in the engineering bay. Here is the lowdown on what just dropped: 🧠 Project LUNAR-AI (lnai) is ALIVE: We officially laid down the first lines of code for our core AI driver! The mission? Giving your local universe a brain. No external API calls, no corporate clouds—just raw, local intelligence. 📉 Reality Check (The Results): Okay, look… right now, the results are, let’s say, highly questionable . It’s giving “confused toaster” more than “galactic supercomputer,” but hey, Rome wasn’t built in a day, and an infinite universe needs a little chaos first. 🛠️ Absolute Grind Mode: The output might be mid right now, but the workflow is at an all-time high. We are working 25/7, refactoring the neural pipelines, and optimizing the backend to make sure this local LLM integration doesn’t melt your PC. The brain is wired, the bugs are being hunted, and the grind never stops. Next stop: making lnai actually smart and finally getting that flight physics engine to behave! 🛰️✨"}, {"post_id": 717, "ts": "2026-06-02T09:35:55Z", "hours": 3.0953, "text": "🚀 DevLog #1: Ignition & Cosmic Foundations for LUNAR-HAL! 🪐 Day 0 is officially complete. We are building an infinite, AI-driven space sandbox powered completely by your local hardware, and the base is locked down: 🌌 Mission Control: Prepared the repository, set up community standards, and went full open-source under the AGPL v3 license to keep our local engine free forever. 💻 Frontend Setup: Fired up the project using Rust + Dioxus! Built the core architecture and launched the first three foundational viewports: Home, About, and Contact. 🛠️ The Manifesto: Designed a killer glassmorphic UI layout and integrated our “Broke-Tech” framework—proudly rendering procedural worlds directly on your GPU. Zero server costs, zero latency, infinite universe. Next stop: implementing the flight physics and interactive star canvas! 🛰️✨"}]...
|
Title: LUNAR-HAL by @INiNiDS | Stardance
Devlogs: Title: LUNAR-HAL by @INiNiDS | Stardance
Devlogs:
🚀 DevLog #1: Ignition & Cosmic Foundations for LUNAR-HAL! 🪐 Day 0 is officially complete. We are building an infinite, AI-driven space sandbox powered completely by your local hardware, and the base is locked down: 🌌 Mission Control: Prepared the repository, set up community standards, and went full open-source under the AGPL v3 license to keep our local engine free forever. 💻 Frontend Setup: Fired up the project using Rust + Dioxus! Built the core architecture and launched the first three foundational viewports: Home, About, and Contact. 🛠️ The Manifesto: Designed a killer glassmorphic UI layout and integrated our “Broke-Tech” framework—proudly rendering procedural worlds directly on your GPU. Zero server costs, zero latency, infinite universe. Next stop: implementing the flight physics and interactive star canvas! 🛰️✨
🚀 DevLog #2: Neural Overdrive & Brainstorming LUNAR-AI! 🪐 Day 1 is in the books, and we are officially cooking! We’re pushing the boundaries of our infinite, local-first universe, and things are getting wild in the engineering bay. Here is the lowdown on what just dropped: 🧠 Project LUNAR-AI (lnai) is ALIVE: We officially laid down the first lines of code for our core AI driver! The mission? Giving your local universe a brain. No external API calls, no corporate clouds—just raw, local intelligence. 📉 Reality Check (The Results): Okay, look… right now, the results are, let’s say, highly questionable . It’s giving “confused toaster” more than “galactic supercomputer,” but hey, Rome wasn’t built in a day, and an infinite universe needs a little chaos first. 🛠️ Absolute Grind Mode: The output might be mid right now, but the workflow is at an all-time high. We are working 25/7, refactoring the neural pipelines, and optimizing the backend to make sure this local LLM integration doesn’t melt your PC. The brain is wired, the bugs are being hunted, and the grind never stops. Next stop: making lnai actually smart and finally getting that flight physics engine to behave! 🛰️✨
🚀 DevLog #3: The Neural Awakening & Backend Fusion! 🪐 Day 2 was chaos, but Day 3? We just plugged the matrix straight into the spine of the engine! 🧠✨ Remember that “confused toaster” from the last devlog? Yeah, well, it just evolved into a full-blown stellar intellect. The pipeline is locked, loaded, and absolutely cooking. Here is the tactical breakdown of what just dropped in the engineering bay: 🌌 The Big Brain Upgrade (Model & Data): We didn’t just tweak the model; we completely rebuilt its reality. We scraped, cleaned, and injected a massive new dataset, pushing our local parameter model to the absolute limit. No more hallucinating dead stars — lnai now actually understands the cosmic data it’s processing. 🔗 The Great Backend Fusion: The neural net is officially out of the sandbox and merged with the core Rust backend! We wired the prediction pipelines directly into our engine architecture. It’s fast, it’s memory-safe, and it operates with zero friction. Data is flowing from the neural layers to the backend loops in real-time. 🏎️ Zero Meltdown, Pure Performance: Training and running local models usually turns your rig into a literal space heater, but we optimized the living hell out of the inference pipelines. The memory footprint is clean, the tokens are flying, and your GPU can actually breathe while rendering the cosmos. The foundation is solid, the telemetry is clean, and the local universe finally has a brain that doesn’t just work — it thinks . Next stop: weaponizing this intelligence for procedural generation and forcing that flight physics engine to respect the laws of space! 🛰️🔥
🚀 DevLog #4: The God Mode Dashboard & Stellar Genesis! If Day 3 was about plugging the matrix straight into the engine’s spine, today we built the ultimate command center around it. No more chaos, no more manual config-wrangling via terminal. We just deployed a full-scale infrastructure for total cosmic control! Here is the tactical breakdown of what just dropped in the engineering bay: ⚙️ Project “TestBench”: Total Control & Validation We got tired of guessing what’s actually happening inside our AI’s digital brains, so we built TestBench—the ultimate proving ground for complete testing, training, and validation of every single AI model in the project. Backend Fusion: The whole thing is hardwired straight into our reactive Rust backend. God-Tier UX: Now, benchmarking a dataset, checking loss curves, validating weights, or fine-tuning a model is a matter of a few clicks without ever leaving the ecosystem. Real-time telemetry monitoring. Honestly? It’s clean, it’s seamless, and it just works. 🌟 Meet SIREN: The Star Architect Our AI fleet just got a massive reinforcement. Say hello to our newest model—SIREN. Her sole, monumental objective is the procedural generation of the stars themselves. No more random glowing spheres. SIREN calculates physics, luminosity, spectral classes, and spawns unique, structured astrophysical objects. The cosmos isn’t just procedural anymore; it’s beautifully complex and scientifically backed. 🎛️ Lunar-Frontend: The Creator’s Control Panel A cosmic backend deserves a killer visual interface. We gave lunar-frontend a massive upgrade to make managing this madness an absolute breeze: The Sidebar: We coded a modular, highly responsive sidebar. All your tools, model toggles, and data streams are now neatly organized and right at your fingertips. Next Stop: Unleashing SIREN onto the global map, syncing its generation directly with TestBench metrics, and forcing the frontend to smoothly render billions of new star systems without dropping a single frame! 🚀
DevLog #5: God-Mode Editor, Crate Separation, and Stealth Features Following the development of “Mission Control,” the project has transitioned into a full 3D environment. The cosmos is no longer just being generated; it can now be manipulated in real-time. Project “Lunar-Hal”: God-Mode Editor The new 3D editor allows for direct manipulation of the simulation rather than just monitoring metrics through the TestBench. Free-Fly Mode: A fully functional in-engine 3D editor. Users can toggle Creator Mode to navigate through stellar clusters at high speeds. Real-Time Manipulation: Selecting a star allows for immediate overrides of mass, spectral class, and luminosity. The SIREN engine recalculates astrophysics on the fly, updating the frontend visuals without performance drops. Architecture: The Great Crate Separation To manage codebase complexity, the backend has undergone a significant architectural refactor. All core gameplay logic has been isolated into a dedicated, independent Rust crate. Modular Design: Rendering overhead and editor scaffolding are now separated from pure game rules, physics, and state machines. Improved Compilation: Logic changes no longer require recompiling the entire project. Crates now compile in isolation, allowing for faster iteration and cleaner incremental builds. Inventory System and Stealth Mechanics Work has begun on a functional inventory system designed to hold “Creator Tools.” This system moves beyond traditional item management into world manipulation. Drag-and-Drop Reality: Mechanics are being implemented to allow users to grab celestial bodies directly from the viewport to rearrange solar systems manually. Entity Interaction: These telekinetic mechanics are also being tested on combat entities. This allows for manual interaction with hostile fleets, such as testing physics logic by moving units into gravitational anomalies like black hole event horizons. Lunar-Frontend: Enhanced UI The UI has been updated to accommodate the new editor and inventory capabilities: Creator Widgets: The modular sidebar now includes inspection panels for editor controls and inventory management. Optimized Streaming: The frontend provides a seamless bridge between TestBench metrics and the heavy 3D viewport, maintaining high performance during active manipulation. Roadmap The next phase of development will focus on: Running heavy simulations of billions of stars in background threads while maintaining editor stability. Stabilizing enemy pathfinding during manual entity manipulation. Preparing the architecture for multiplayer synchronization. Note: DevLog updates may be sporadic due to local ISP and network routing issues affecting access to the Hack Club site. Space logistics are complex, but terrestrial routing remains a significant challenge.
🚀 DevLog #6: Hyper-Optimization, Core Threat Integration, and New Swarm Archetypes ⚙️ Optimization: The Fight for Nanoseconds With the transition to a full 3D environment and manual entity manipulation, the load on the CPU and memory bus grew exponentially. So we tried to optimize as much as possible. 👾 Integration: Enemies in the Core Loop Previously, hostile entities existed only as isolated test units (testbench). Now, enemy fleets are officially hardcoded into the base simulation loop. Autonomous Background AI: Enemy behavior is no longer bound to the player’s viewport. Strategic fleets live their own lives in the background—conquering systems and harvesting resources—even if you are editing a galaxy millions of light-years away. Dynamic Pathfinding: The toughest challenge was stabilizing AI during manual manipulation. If you grab a planet and toss it in front of an enemy dreadnought, the pathfinding algorithm instantly recalculates a safe bypass vector based on the newly altered gravitational signature of that sector. 🛸 New Threat Archetypes: The Utility-Driven AI Each enemy now operates on a Utility AI system, calculating its next move based on distance, health ratios, and—most importantly—the Player’s Attention . We have categorized the hostile forces into six distinct tactical archetypes: Archetype Role Logic Highlight The Tank Heavy Juggernaut Berserk Logic: Its utility increases as its health drops. It becomes more aggressive the harder you try to kill it. The Thief Rapid Raider Attention-Aware: Only strikes stars when the player is looking away ( t_neglect > 15.0 ). High speed (20.0) allows for quick hit-and-run ops. The Invisible Stealth Saboteur Adaptive Camouflage: Maintains $0.05$ visibility. Only reveals itself when the player’s cursor “scans” over it or during brief power-grid flickers. The Scavenger Opportunistic Parasite Pack Mentality: Heavily prioritizes stars that are already under attack by other units to “steal” the resources. The Backstabber Chaos Agent Infighting: If it detects a fellow enemy with $<35 % $ HP, it will betray its own kind to secure the kill for itself. The Coward Skittish Scout Self-Preservation: Immediately generates an escape vector if the player’s “God-Hand” (cursor) gets too close or a Tank enters its vicinity. 🧠 The “Attention Map” Integration The most advanced part of this integration is how these entities interact with the Lunar-Frontend . We don’t just track positions; we track the player’s focus: d_mouse Factor: Enemies calculate their distance to your cursor. Thieves and Cowards use this to decide when to flee or stay in the shadows. t_neglect Metric: The simulation tracks how long it’s been since you last interacted with a specific star. The longer a sector is neglected, the higher the “utility” for an invasion force to move in. ⚔️ Combat Mechanics: Physical Projectiles vs. Direct Damage To keep the simulation performant while maintaining visual fidelity: Star Assaults: Enemies fire physical Projectile entities. Each has its own speed, radius, and damage value, allowing players to potentially intercept them or warp them with gravitational anomalies. Internal Infighting: When enemies like the Backstabber turn on their allies, the damage is processed via an optimized EnemyDamage buffer, bypassing heavy projectile physics for internal “swarm” calculations. Note: ISP issues and local routing to the Hack Club site still make uploading updates feel like sending signals through a dense asteroid belt.
DevLog #7: WebOS Evolution, The Black Room, and “lns” Orchestration This update marks a fundamental shift in how we interact with the simulation ecosystem. We have moved away from static dashboards to a fully dynamic WebOS environment within lunar-testbench , alongside a complete overhaul of our launching utility. Lunar-Testbench: The WebOS Overhaul The Testbench has been reimagined as a “Black Room” —a dark, immersive workspace where everything begins with three spotlights. The Spotlight Mechanic The interface features three dormant flashlights. Service Ignition: Clicking a spotlight “turns it on” and launches its corresponding backend service. Dynamic App Injection: Once a service is active, the specific applications depending on that service manifest below the spotlight. The Sandbox: Our most complex tool, the Sandbox , now requires all three services to be active simultaneously, setting the stage for deep-system integration in future updates. The Dock To manage the chaos of multiple windows, we’ve implemented a Bottom Dock . Every running application is pinned here, allowing for seamless switching between training, validation, and live simulation environments. Orchestration: From “lunar-start” to “lns” The way we boot the engine has been streamlined. We’ve stripped the heavy lifting out of the primary entry point to create a more modular startup flow. lns Utility: lunar-start has been evolved into lns —a lightweight micro-utility. Its sole purpose is to initialize the Testbench and trigger the backend. lunar-start-backend: This is a new, dedicated service that acts as the primary launcher. It monitors and manages the lifecycle of all other applications within the suite, ensuring that when you click a service in the UI, the backend is ready to deploy it.
* 🚀 DevLog #8: The Great Pivot — From Game to Technical Stellar Platform * The mission has changed. Following the deployment of the WebOS in DevLog #7, we realized that the “game” mechanics were holding back the true potential of the engine. This update marks our transition from a simulation with combat elements to a high-fidelity technical platform for stellar generation, research, and visualization. We have officially executed the transition plan, gutting the “game” and hardening the “platform.” The Great Purge: lunar-stellar-core The era of lunar-game-backend is over. We have performed a git mv on the heart of the engine to establish a strict architectural boundary. Logic Extraction: We have completely removed all traces of Enemies, Projectiles, HP, Attacks, and the “Attention Map.” The simulation no longer cares if you are “watching” a star; it only cares about the physics. The Core: The new lunar-stellar-core crate is now framework-agnostic. It handles only the technical state: camera math, sector caching, and the pipeline results. Terminology Shift: “World” is now “StarScene.” It’s no longer a level; it’s a coordinate-stable dataset. Unified Multi-Platform Deployment We’ve consolidated our frontend logic. Instead of separate builds, we now have a single Managed Frontend Service with a unified builder. Target Switching: Through the lns utility, we can now hot-swap between web , desktop , and android targets. Android Integration: The platform now supports Android NDK/SDK. We’ve replaced mouse-only logic with Pointer Events , enabling touch-based pan/zoom/selection. Runtime Config: The backend now dynamically injects the correct URL (handling the 10.0.2.2 emulator trap) based on the active platform. Sandbox 2.0: The Admin Overlay The Sandbox is no longer a separate copy of the simulation. It has evolved into a Meta-Management Shell for the real frontend. The Iframe Bridge: The Sandbox now embeds the live lunar-frontend via an iframe. Communication Protocol: We implemented a versioned postMessage protocol in lunar-structures . The Sandbox sends Admin Commands (CreateStar, SetCamera) and receives Scene Events (StarSelected). Permanent SIREN Gallery & Drag-and-Drop We’ve moved from “latest renders” to a persistent filesystem-based catalog . Atomic Persistence: Stars created via AI or manual tools are now saved as GalleryStar DTOs. Each star gets its own directory with metadata, SIREN textures, and thumbnails. True Drag-and-Drop: We’ve implemented a custom drag-session in the WebOS. You can now drag a star from the Gallery into the Sandbox to insert it into the live scene, and vice versa. Found Issues The transition hasn’t been without its casualties. Two “boss-level” bugs have appeared during the implementation of the new WebOS logic: Sandbox Handshake & OS Crash: Currently, the Sandbox is failing to “see” the Frontend service through the iframe bridge. Even worse, attempting to initialize the connection often results in a total OS-level hang , crashing the Testbench entirely. We are currently investigating if this is a circular dependency in the backend or a massive memory leak during the handshake. The “Minimize” Trap: While we implemented WindowLifecycle to keep applications alive in the background using display: none , we hit a critical logic error. Once an app is minimized, the “un-minimize” (maximize) function fails to trigger . The app remains in a state of digital limbo, perfectly preserved but completely inaccessible.
DevLog #9: Checkpoint Hardening & Stage 5 GNN Kinematics Convergence * This session was focused on a deep technical milestone: diagnosing a critical engine staging bug in LUNAR-HAL and driving the Stellar GNN-kinematics pipeline through the completion of Stage 5. 1. 🛠️ Staging Architecture & Atomic Checkpoint RCA (Rust) Diagnosed and resolved a critical issue in the --resume workflow where staging logic triggered a self-copy ( src == dst ), truncating output checkpoint weights upon restart. Implemented robust canonical path checking ( std::fs: :canonicalize ) to ensure fully atomic weight persistence across interruption signals ( SIGINT / SIGTERM ). Hardened checkpoint state serialization, eliminating filesystem race conditions during runtime hot-reloads. 2. Stage 5: GNN-Kinematics Training Executed the 200-epoch training run for the galactic velocity prediction model ($v_x, v_y, v_z$ derived from positions + photometry). Validated host telemetry: stable VRAM footprint on local NVIDIA GeForce RTX 5070 (~3.1 GB / 12 GB allocated) with optimal throughput (~30s / epoch). 3. Loss & Convergence Verification Train Loss: Decreased to ~0.7660 . Validation Loss: Reached a clean, stable quasi-stationary plateau at ~0.7694 . Physics Constraint: Invariant equilibrium maintained throughout ( phys_loss ≈ 0.7700 ), demonstrating high generalization without overfitting.
Alright, final devlog! Went all-in on bug squashing for this one—crushed a ton of issues, finally got CI completely green and stable, cleared out all the CodeQL alerts, and pushed the demo build. So yeah… I’m officially shipping now!
Ships:
Finally shipping this! It honestly took forever and I burned out twice along the way, but I pushed through to get it over the finish line. Try out the live demo or grab the local build. Heads up: the web demo might feel super sluggish since the models are running on Heroku, so expect some delay. Also, all demo sessions share the same persistent worlds! Have Fun!...
|
1793004967.5732112
|
1793091367.5732112
|
|
938
|
My awesome macropad! by @kanchankumari1992214 | St My awesome macropad! by @kanchankumari1992214 | Stardance...
|
kanchankumari1992214
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @kanchankumari19922 Title: My awesome macropad! by @kanchankumari1992214 | Stardance...
|
1792547485.432366
|
1793152285.432366
|
|
937
|
My first slack bot! by @kanchankumari1992214 | Sta My first slack bot! by @kanchankumari1992214 | Stardance...
|
kanchankumari1992214
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @kanchankumari199221 Title: My first slack bot! by @kanchankumari1992214 | Stardance...
|
1792551166.7537868
|
1793155966.7537868
|