July: 30

2024

Dialogue The dialogue flow is almost ready to be on the production branch, with some minor tweaks left in the option branch. We would have to add the different action ULID and action system for the dialogue but I think we can do that on a later date. The chaining of the dialogue will be important and then setting it up so that the messages do not get displayed twice. We could keep track of the dialogue that gets read by flagging the boolean read to true after its done typing it out, which should remove it from the chain pool.

HID At the same time I am working on the Cryptothrone project, I am also looking into the HID emulation and getting a deeper dive of hardware emulation. My goal would be to perform these emulations in both Rust and Python, with different goals in mind for both! The python based HID will go into Atlas, making it easier for future developers to call and utilize, we would probably wrap the ada fruit library into a custom restful api via fastapi. As for the rust based, I am going to aim at creating a powerful emulation program written in rust for private usage. We could place the changes to the HID library directly into the fudster library.

The next problem that we are facing with the HID is that the ability to grab the current screen and process what is going on! Getting the program to be reactive and fast enough is tough if its all based upon pixels and sounds.

NPCDB The sidebar for the KBVE Docs need to be updated to include a direct link to the NPCDatabase.

Action System I started to map out the action system that will trigger when certain dialogue objects are triggered via the chaining. My initial concept for the action system would be to keep it simple and have it be an ULID to a factory or singleton that would execute upon clicking the action. It is still a bit tough to write it out without actually placing the concept into production.

2023

• 3:15pm - Currently looking at the structure for the account setup under KBVE.com repo. I believe the next move would be to just migrate the different concepts into their own MDX file. The reason we want to do this right now is because in the future, we can make it easier to add i18n into the core source. The migration of the *.astro* files into their own MDX file should be isolated into their own issue? This way we could maintain a structure for future developers that might want to see how I would go about it.
• 3:37pm - The initial files would be structured so that majority of the content would be inside of the MDX file, so that when we go about doing the translations, we have a central location for all the text. This means that if there are any errors messages, we would have the default aka English ones ready and then if there are any other languages that we would want to adapt, then those would be added on as their own MDX file.
• 4:20pm - We will start with a new layout astro, which is currently named the account.astro and from that standpoint, we will prepare for the astro v3 upgrade for this upcoming year. As I will state in the issue ticket, I am thinking of migrating all of the .astro components that are related to account management and officially moving them into the mdx file format. Afterwards, I want to then embed the different widgets that would be required for each action, a bit of a modular approach but it might be a bit over engineered for what we are doing at this current time, but it will make going into i18n a bit easier down the line in the future. I will start this test case by… hmm. Okay let me first make the _account folder, where I will store all the older code / astro files. After moving those, I would have to define the zod type for the account collection and then create the files that I would want to call? I will keep the types that I would want in zod to a bare minimum and then extend them out as I would like.
• 5:00pm - After adding the zod for the account and getting the basics out of the way. This includes watching deathclaws rip apart @andsam, which would describe exactly how I am going about this programming move. Ah I am going into a terrible performance loop within the dev branch right now, every build is throwing a terrible crash loop, I might have to see where I went wrong because this is starting to become a bit of a pain.
• 7:43pm - Quickly wrapping up the basic chores, now I am going to run a quick League match and review some of the updated libraries.
• 9:02pm - My Adventures of Superman, in the 5th episode of Season 1, Superman as Clark Kent, breaks a file cabinet then it just gets magically repaired. Why did I write this? Well there is no reason.
• 9:05pm - I should start to refactor some of the really basic modules, hmm, I think the logout module aka react one, should be simplified. The next patch will be a bit bigger than I was thinking, a decent chunk to the general codebase, which I should have split into different pull requests, but for now I suppose it will be okay.

Quote

He has no enemies, but is intensely disliked by his friends. — Oscar Wilde

Tasks

• [ ]