Frontend rework

[aurarius1]

As said in #295 here the draft request for the frontend updates.

I did include a revised version of the Dockerfile and tested building an image with it for the Pi Zero (then copied it on the Pi Zero, since building on it directly will not work anymore due to the issues with the updated frontend I already outlined in the discussions). The resulting image is less than half in size. Nevertheless since raspberrypi.com suggests using a 16GB SD Card for Raspberry Pi OS Lite I updated the requirements a little bit, to ensure it works smoothly for everybody (since technically we cannot do much if the remaining storage is too low for the image to run).

I also included the PSA that docker dropped support for the Pi Zero.

This is opened as a draft, because it might still need some work and I think it is easier to checkout a pull request than fork a different repo.

[DarthArnettJr]

Okay, now. Let’s hope that this method won’t be heck to set up now, eh?

[aurarius1]

Okay, now. Let’s hope that this method won’t be heck to set up now, eh?

I don’t think that’s a fair assessment. Most of the issues you’ve run into stem from the very constrained storage environment. I’ve set this up on several Raspberry Pi models during testing, and it worked fine in each case.

[DarthArnettJr]

Well I hope I can get my hands on a 32 GB micro SD card from Target, their same day pickup is a GODSEND.

[aurarius1]

Well I hope I can get my hands on a 32 GB micro SD card from Target, their same day pickup is a GODSEND.

Don't rush it for now though, this is not yet finished! 😊

[aurarius1]

I did test with Ubuntu 22.04 on how to create the USB gadget in a VM and if the container would run. I could not check though if a connection to the game is possible. Therefore I did not provide any instructions for VM setup in the docs right now.

I did not have any problems with the new frontend, but I still will leave this as draft for a few days, to allow others to test!

[DarthArnettJr]

BTW, the bash part of the commands should be removed. The Pi tries to run the command as a binary file and fails.

[aurarius1]

Don't know if anybody else had time to test the branch as well. Should i change base of the pull request such that it will be merged into dev first?

[Berny23]

Did you test the rework with color puzzles in-game?

[aurarius1]

No, I haven't encountered a color puzzle yet, I am still on my playthrough, but sadly time is limited as well. You can leave the pull request open though until I get to one (or if you prefer me to convert it back to a draft that's fine as well).

[Berny23]

Great work! Some small things I noticed.

[Berny23]

No, I haven't encountered a color puzzle yet, I am still on my playthrough, but sadly time is limited as well. You can leave the pull request open though until I get to one (or if you prefer me to convert it back to a draft that's fine as well).

I don't have the game installed right now, but these puzzles are pretty frequent. It is important that colors are clearly visible and pulsing still works with the new design.

I'll just wait, no problem.

[aurarius1]

Ah can the part where you need to place Wyldstyle on each pad (in Vorton) be considered a color puzzle then? Since, if I am not mistaken, this also uses pulsing.

I'll play a bit more and report back here as soon as I get to it. A lot to do with university and work. :)

[Berny23]

Blinking is good. A real color puzzle is where placing a character on a colored toypad space changes things in-game with the same color. The keystone is called Chroma: https://lego-dimensions.fandom.com/wiki/Chroma

This should appear in the main story and is a pretty frequent puzzle in about every story pack.

[aurarius1]

Okay, so I think (or more guess, the first time I could recreate this issue was right now with Trixie), this has something to do with the USB gadget working a bit differently under newer RPi OS versions. I will need to test this more. I just set up a Bookworm SD card. Maybe also Bullseye is needed, then it would be probably necessary to revise the gadget mode setup. This also makes sense with the solution #301, which also seems to point towards Trixie. Though it could also be that Bookworm faces this problem as well, since it reports a similar kernel version. So maybe I need to further test it with Bullseye (since the original USB gadget setup was also done with this OS version), and I was just "lucky" that it worked for me without any issues, though being "lucky" isn't really a satisfying explanation either ...

So you cannot move the tags on desktop if you click, hold, and then drag. Are there any logs in the browser console?

[Dave247]

Good to know it wasn't just me doing something wrong. 😅

For the purposes of continuing to test the new frontend I can switch to Bookworm if that has less issues, and if I encounter it again then I'll go back even further.
I don't recall encountering the error in the last stable build. Or if I did, at least nowhere near as consistently, as I appear to be able to trigger it every time when I would go to load a game. At least that hopefully makes it easier to narrow down the cause.

I should also add that I haven't been using a USB splitter cable like I know I am supposed to be, so it could very well be the same issue that you were having with with your Zero W not getting enough power. I guess I really do need to get one to test out if that fixes it issue first.

As for the tags I apologise I meant on desktop the click, hold and drag does work. It's more that is that the required hold delay when using a mouse is not intuitive to do so, as I didn't realise that's what I needed to do until I tried it on my phone.

[aurarius1]

So I am currently trying it with Bullseye; I just have to finish the setup. I'll report if it works with Bullseye. Yes, for me, the same, up until today, I have never encountered this error. It could technically also be related to the use of node22, but this needs more testing to be done.

Well, I also never did bother to use such a splitter, and just had this issue for the first time, but yeah, all of those things could very well play into the reproducibility/weirdness of the issue as well.

Ah, yes, I can see that. I'll check if I can remove the click delay on desktop 👍

[aurarius1]

Please try it with Bullseye, on Trixie and Bookworm it resulted in the same error for me now, Bullseye does work. I used the latest version of Bullseye found here: https://downloads.raspberrypi.org/raspios_lite_arm64/images/ (from 2023-05-03).

Maybe this was also just lucky now, hard to tell for me now.

[aurarius1]

I also quickly checked the delay-on-touch-only option in Vue Draggable, which seems not to accept the shorthand form, as I originally had it. Now, the desktop should not have a delay anymore. Sorry for the inconvenience! 🙂

Edit: will update the Readme/Docs with instructions to use Bullseye today or tomorrow evening. Probably will then also start inspecting how to fix it for newer Kernel versions 🙂

[Dave247]

Please try it with Bullseye, on Trixie and Bookworm it resulted in the same error for me now, Bullseye does work. I used the latest version of Bullseye found here: https://downloads.raspberrypi.org/raspios_lite_arm64/images/ (from 2023-05-03).

Maybe this was also just lucky now, hard to tell for me now.

I used that same image and also even made sure to use the pi-setup.sh script from your frontend branch and using podman and not docker to try and get a close as possible reproduction steps to as to what you would be doing yourself (within reason), and I can report back that on Bullseye when loading a game it does work and no error is thrown. So it looks like you were correct in your assumption and perhaps just have been overly doubting yourself from all of the mixed results when testing. Which I know what that's like and how important it is to have a working config that you can start from otherwise you start to go a bit crazy. 😅

I've also discovered some other frontend specific problems that you might already know about.

The first is when moving a tag from the middle pad position back to the toybox the scaling of the tag gets all messed up and becomes massive when hovering hover the toybox, but goes back to it's normal size when letting go/placing in the toybox. This happens both on mobile and PC.

I have two more but are yet to be able to consistently reproduce the problem. Both are only on PC in Edge and Firefox though, while I can't trigger either at all on mobile.

The first is sometimes when creating more then one character it can lead to the below Syntaxerror which results in a crash. The error message is always the same.

<anonymous_script>:1


SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at /app/index.js:513:25
    at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read/context:68:3)

Node.js v22.22.1

The second is when creating a new character sometimes all of the images will disappear, where refreshing the page is required to fix it. There's nothing unexpected in the logs when this happens.
See the below screenshot for reference. Also though I didn't manage to catch it in time before it disappeared, the blue box at the bottom with the text status that "X tag was successfully created" does still appear.

Screenshot

[aurarius1]

I used that same image and also even made sure to use the pi-setup.sh script from your frontend branch and using podman and not docker to try and get a close as possible reproduction steps to as to what you would be doing yourself (within reason), and I can report back that on Bullseye when loading a game it does work and no error is thrown. So it looks like you were correct in your assumption and perhaps just have been overly doubting yourself from all of the mixed results when testing. Which I know what that's like and how important it is to have a working config that you can start from otherwise you start to go a bit crazy. 😅

Perfect, so it should be included in the docs to still use Bullseye, until we can figure out what to change for the USB setup.

The first is when moving a tag from the middle pad position back to the toybox the scaling of the tag gets all messed up and becomes massive when hovering hover the toybox, but goes back to it's normal size when letting go/placing in the toybox. This happens both on mobile and PC.

Yes, I have seen it already, though I am still unsure on how to fix this, as the draggable element will take the parent size. As I said, I am also not a frontend pro, but I'll check if I can fix this.

The first is sometimes when creating more then one character it can lead to the below Syntaxerror which results in a crash. The error message is always the same.

After a quick inspection, my best guess: This error could actually happen without the new frontend as well. The problem here is that the fs.readFile is asynchronous, so the backend might send the response that the tag was created before even having written everything to the disk. I don't know if this is in scope of this pull request, as I wanted to avoid changing the backend too much. However, it should be fixed, and there should be a route for batch creation of tags as well (as hinted by my TODO).

The second is when creating a new character sometimes all of the images will disappear, where refreshing the page is required to fix it. There's nothing unexpected in the logs when this happens. See the below screenshot for reference. Also though I didn't manage to catch it in time before it disappeared, the blue box at the bottom with the text status that "X tag was successfully created" does still appear.

I have not encountered this before, but I'll try to reproduce & fix it. If you manage to trigger this bug again, could you check if the browser console logs anything?

[aurarius1]

After some experimenting, this should fix the huge toybox items, though I am pretty sure my CSS and DOM structure can still be further improved ...

[Dave247]

I used that same image and also even made sure to use the pi-setup.sh script from your frontend branch and using podman and not docker to try and get a close as possible reproduction steps to as to what you would be doing yourself (within reason), and I can report back that on Bullseye when loading a game it does work and no error is thrown. So it looks like you were correct in your assumption and perhaps just have been overly doubting yourself from all of the mixed results when testing. Which I know what that's like and how important it is to have a working config that you can start from otherwise you start to go a bit crazy. 😅

Perfect, so it should be included in the docs to still use Bullseye, until we can figure out what to change for the USB setup.

I'll try and see if I can get your build working in a Trixie VM, as well as also seek to source a splitter cable as a way to try and further narrow down if it is a hardware/power issue.

The first is sometimes when creating more then one character it can lead to the below Syntaxerror which results in a crash. The error message is always the same.

After a quick inspection, my best guess: This error could actually happen without the new frontend as well. The problem here is that the fs.readFile is asynchronous, so the backend might send the response that the tag was created before even having written everything to the disk. I don't know if this is in scope of this pull request, as I wanted to avoid changing the backend too much. However, it should be fixed, and there should be a route for batch creation of tags as well (as hinted by my TODO).

Yeah that's a good point. The original frontend doesn't allow for creating more then one tag at a time, so it could be a holdover issue that has just never surfaced until now. Probably as you continue to tweak things and add stuff like this to a list, said list will continue to get longer and longer, eventually justifying a greater need to do some more major changes to the banckend as well.

The second is when creating a new character sometimes all of the images will disappear, where refreshing the page is required to fix it. There's nothing unexpected in the logs when this happens. See the below screenshot for reference. Also though I didn't manage to catch it in time before it disappeared, the blue box at the bottom with the text status that "X tag was successfully created" does still appear.

I have not encountered this before, but I'll try to reproduce & fix it. If you manage to trigger this bug again, could you check if the browser console logs anything?

I managed to capture the browser console logs when the problem happened. There's very much something there that should hopefully be enough for you to work with.
I've attached the full output starting from opening the page before launching the game in case it may be of some use. The issue occurs at line 347.
Also I should note I am using Firefox Nightly, in case you are confused by some other messages in the log. But as mentioned I was able to recreate the issue in Edge stable as well. Oh and I was still using the build prior to the b41f541 commit.
console-export-2026-3-10_15-51-27.log

[Dave247]

Hey @aurarius1 I was thinking more about power... do you also have a Pi 4(B) or just a Zero W? I know the 4 can be powered using the GPIO pins, as while that comes with it's own set of complications, I can't help thinking it would still be a more ideal way then using a Y splitter cable that who knows what the quality of it may be like, where I am not sure if we could trust whatever result we would get when using one.

[aurarius1]

Thanks for the log, I'll try and trace the bug.

Regarding the power splitter: yes I do have a Pi 4B, but even if you used the GPIO Pins to power the Pi you would still need to have a power blocker, to protect your console/pc from backfeed. I can test this soon, since I should have a power blocker somewhere, although at the moment I suspect it's how the creation of the usb gadget is done, since newer guides I found seem to differ a bit - but I still need to read more into it, I have never dealt with this on a Pi before! ☺️

[Dave247]

Thanks for the log, I'll try and trace the bug.

Regarding the power splitter: yes I do have a Pi 4B, but even if you used the GPIO Pins to power the Pi you would still need to have a power blocker, to protect your console/pc from backfeed. I can test this soon, since I should have a power blocker somewhere, although at the moment I suspect it's how the creation of the usb gadget is done, since newer guides I found seem to differ a bit - but I still need to read more into it, I have never dealt with this on a Pi before! ☺️

I'll leave this one to you then, as I don't the required hardware and would have to purchase it which would be a bit of a waste as I don't think I would use it ever again. 😄

[aurarius1]

I just wanted to give a quick update: I think I found the issue with the "vanishing" frontend. It is most likely also related to the asynchronous file writing in the backend. I will add proper redirections to error pages, such that the frontend won't disappear due to this. I think the backend should not be touched by this pull request, but those issues should be fixed afterwards as well.

I'll test a bit with the error page, etc., before pushing the code!

[Berny23]

Please note, there has been lots of code cleanup in #326.
You may have to rebase or merge.

[aurarius1]

Thanks for the heads up. Sorry that it is taking so long to push the error handling stuff, I really couldn't test it yet, life is busy atm.

[Dave247]

I got distracted/busy with other things as well and haven't touched anything for a while. Decided to buy a Zero 2 to use exclusive for this project as I wanted to use my 4 for Steam Link, which was difficult given how many times I have been re-flashing the OS.

Trixie and Bookworm are still busted (as noted in #325) but that's no surprise, given that some time has passed I wanted to refresh myself on where things were.

I've spent a lot of hours recently trying (and failing) to get legacy GPU drivers working in Debian 13, which got me to think that if it's the USB gadget side that is failing then it's probably because whatever drivers and libraries the project was originally used aren't supported in newer kernel versions.
Like for example how RPI OS Trixie now has its own built in rpi-usb-gadget package that maybe the project should switch to using instead.

Given that this was meant to be for your purely frontend work @aurarius1 and it's kinda my fault for opening a can of can of worms and getting thigs off track. I agree it's best for you to just focus on just the frontend stuff which is what you already started, as the rest really needs to get collated and split off into its own thing.

[aurarius1]

I just merged everything back into the frontend branch and will test everything next week. After that it should be done! Sorry for taking so long, a lot is going on rn.

[aurarius1]

From what I've seen so far, everything still works except the issues with creating tokens. Is it okay if i change the methods to edit the toytags.json synchronously?

Also, what I just noticed, if the game writes update commands to a vehicle tag (tested when creating the Batmobile for the first time), the tags will have N/A stored as the name in the toytags.json, which also happens with the original frontend. However, the original frontend doesn't rely on the name stored in toytags.json, mine does. I found that the getAnyNameFromId function seems to have the ID check backwards, if looks up the name from the vehicle map if the ID is < 1000, else from the character map. From the IDs stored in the two maps, I think it should be the other way round, right? If so, is it also okay if I make this change with this pull request?

EDIT: just saw with the original frontend, names with N/A are filtered out on a page refresh. This might also be the reason for #280

[aurarius1]

Instead of further relying on toytags.json, the project could also implement a sqlite database for created toytags. However, if this is the way to go, refactoring this should definitely be a new PR.

[Berny23]

Thanks for looking into it. You can include the json fixes here too.

[aurarius1]

I've played the first level with the changes, seems to work fine for me. However, somebody else should test this as well.

I did not add the batch creation route, but the file reads are now synchronous.