February: 11

Notes

2025

Migrations Nx SubFolders

• 12:37AM

  The shell command to start moving the discord software into the subfolder.

pnpm nx g move --project pydiscordsh --destination apps/discord/pydiscordsh --skipFormat=true

For Atlas and Fudster, I am thinking that we need to rework those as well? We could place them into their own category for now too, hmm.

• 02:14AM

  Next up will be the herbmail subfolder, which will just hold the astro files for now.

pnpm nx g move --project herbmail.com --destination apps/herbmail/herbmail.com --skipFormat=true

Okay needed to adjust the tailwindcss because its pulling from the shadcn package that we had.

That leaves the atlas and the fudster project, both we can keep in the apps for now and come back around with those later on. Okay! Migrations are complete , let me close that ticket out for now. Opps, forgot to update the cargo.toml for the workspace changes.

Clock Extension for GoDot

• 02:33AM

  Clocks aka Timers are a bit of an issue right now with our godot extension? I am thinking that there might be a race condition, where the timer is not yet added into the scene before it gets triggered.

Markets

• 03:27PM

  Good to see Nvida come back up to the $130 mark and very nice to see $TSLA back down to the $330 mark. I am hoping that tesla goes back under the $300 mark, making it a great time to pick up a couple more shares. Yet I really want to offload my nvidia at around $150, so maybe getting a point inbetween both of them would be great.

GoDot WSL Test After Migration

• 05:25PM

  Parts of the monorepo are a bit broken since we did the subfolder migrations, mainly because the paths have changed. Some of the locations are still hard coded, so just need to scope them all out and make the adjustments.

ClockMaster + Timer Extension Merge

• 07:24PM

  I made a mistake by splitting these into two different files, we will merge the clockmaster_extension.rs into the timer_extension.rs. Then from the timer_extension.rs, we can just import the Clockmaster. Dropping the ensure function from the TimerExt and removing the whole ClockMasterEx!

  To keep track of this change, inside of the pub trait TimerExt, we are removing this function:

  fn ensure_timer(base: &mut Gd<Node>, key: &GString, wait_time: f64) -> Gd<Timer>;

  // Which References this impl TimerExt

  fn ensure_timer(base: &mut Gd<Node>, key: &GString, wait_time: f64) -> Gd<Timer> {
    let timer_key = format!("Timer_{}", key);

    let mut timer = if let Some(mut existing_timer) = base.try_get_node_as::<Timer>(timer_key.as_str()) {
      existing_timer.stop();
      existing_timer.set_wait_time(wait_time);
      existing_timer
    } else {
      let mut new_timer = Timer::new_alloc()
        .with_name(&timer_key)
        .with_one_shot(true)
        .with_wait_time(wait_time)
        .with_autostart(true);

      base.add_child(&new_timer.clone().upcast::<Node>());
      godot_print!("[TimerExt] Added new timer: {}", timer_key);
      new_timer
    };

    if !timer.is_connected("timeout", &base.callable("hide_avatar_message")) {
      timer.connect("timeout", &base.callable("hide_avatar_message").bind(&[key.to_variant()]));
    }

    godot_print!("[TimerExt] Timer '{}' started with wait_time: {}", timer_key, wait_time);

    timer
  }

Then, we are going to remove the ClockMasterExt trait, as we will shift the focus towards the ClockMaster. One of the things that will make this a bit different than a ClockManager, will be that it has a bit more scope creep than a traditional manager. The biggest challenge will be to maintain both async and sync with the timers, while avoiding race conditions and mutex guard issues.

pub trait ClockMasterExt {
  fn get_or_create_timer(&mut self, key: &str, wait_time: f64) -> Gd<Timer>;
  fn remove_timer(&mut self, key: &str);
}

impl ClockMasterExt for Gd<Node> {
  fn get_or_create_timer(&mut self, key: &str, wait_time: f64) -> Gd<Timer> {
    let timer_key = GString::from(key);

    if let Some(timer) = self.try_get_node_as::<Timer>(timer_key.as_str()) {
      let mut existing_timer = timer.clone();
      existing_timer.stop();
      existing_timer.set_wait_time(wait_time);
      existing_timer.call_deferred("start", &[]);
      return existing_timer;
    }

    let mut new_timer = Timer::new_alloc();
    new_timer.set_name(timer_key.as_str());
    new_timer.set_wait_time(wait_time);
    new_timer.set_one_shot(true);

    self.add_child(new_timer.clone().upcast::<Node>());

    new_timer.call_deferred("start", &[]);

    godot_print!("[ClockMasterExt] Timer '{}' created with wait_time: {}", key, wait_time);

    new_timer
  }

  fn remove_timer(&mut self, key: &str) {
    let timer_key = GString::from(key);
    if let Some(timer) = self.try_get_node_as::<Timer>(timer_key.as_str()) {
      let mut timer = timer.clone();
      timer.queue_free();
      godot_print!("[ClockMasterExt] Timer '{}' removed.", key);
    }
  }
}

Now we can create the ClockMaster, which will be pased upon the GodotClass. Three issues that I see with the clockmaster, as of right now, are the timeouts, destruction and resuability. Timeouts should keep the timer in the cache but simply mark it as inactive; the timer should remain in the cache so it can be reused later. Destroying the timer should remove the timer from both the cache and the Godot scene when executed. Resuable timers should restart but there might be a part where the godot might remove it? Race condition for the timer was not an issue with the wasm but it was on the mac.

2024

The characters might have issues with multi-worlds and cause issues if they are being played oln multiple worlds/game sessions, so we need a way to lock them out to prevent this from occuring.

StartZone

Going to clone over the Scene1 and call it StartZone, here I want to test case a couple different concepts that I had in my mind, including a Game Manger and the combat engine. I am thinking that the GameManger and Combat both would be internal engines but with the combat engine extending out to a combat service, which would then be handling combat events? The game manager would just be incharge of loading and unloading the scene cameras for now? This is still a bit of a hazy area since I am trying to go for a SOA/Events style system but I need to remember that I am limited to just a single thread. We could have the game manager also push some of the messages to javascript via a post message, but offloading to javascript would mean that the game might have issues in an mobile build. Sometimes these things can be a pain to map out, because of the WASM limits, ugh. I am still going to think it through in small steps and maybe it will come together near the end, I guess that is part of the course.

The first step would be to clone the Scene1.unity to StartZone.unity and then add it into the build order.

Going back to the character scene, I would then adjust the buttons for the characters, one with an open sheet and another button to load the character into the StartZone.

For the sake of simplicty, I should work out the locations of the characters and make sure that they do not get loaded into multiple worlds?

Maybe make sure that once the character is done from the mission, there would be a timer that would prevent the character from going onto the same mission again?

I still need to work out the kinks of how I would approach this problem, but for now, I will just skip it and leave this as a note!

KBVE

While I am working on the Unity front, I also wanted to go over the website design, I am thinking of a black, grey, sky blue style for the KBVE website. It would mean leaving the orange, pink and purple color style but I think it might be a better move down the line? I am not an amazing ux designer but I am thinking the tri-color scheme that I had earlier was a bit too much for the website and I think going a bit back to a monotone would make it easier.

Namecheap

Need to setup time to migrate all my domains out of namecheap and to CloudFlare! I will start with the base domains that I currently am using and I will let some of them expire because the cost basis might be too high.

Weather

While working on the KBVE namespace and migrating some of the older code, I am looking into how to expand the code base to include some additional features. One of the features that I wanted to include was a weather system, including a way handle it globally but for now, I think a simple day and night cycle is enough. My concern would be about running the internal clock, which I should migrate into a tick system?

Here is the current clockbased weather formula:

  float angle = (currentTimeOfDay * 360f) - 90f; // Shift by -90 degrees to start at dawn
      directionalLight.transform.localRotation = Quaternion.Euler(angle, -30f, 0f);

      if (currentTimeOfDay <= 0.25f || currentTimeOfDay >= 0.75f)
      {
        //  ? Night Light
        directionalLight.color = Color.Lerp(
          Color.blue,
          Color.black,
          Mathf.Abs(currentTimeOfDay - 0.75f) * 4f
        );
        directionalLight.intensity = Mathf.Lerp(
          0.1f,
          0.5f,
          Mathf.Sin(currentTimeOfDay * 2 * Mathf.PI)
        );
      }
      else
      {
        //  ? Day Light
        directionalLight.color = Color.Lerp(
          Color.yellow,
          Color.white,
          Mathf.Abs(currentTimeOfDay - 0.5f) * 4f
        );
        directionalLight.intensity = Mathf.Lerp(
          0.5f,
          1f,
          Mathf.Sin(currentTimeOfDay * 2 * Mathf.PI)
        );
      }

However, I think for the performance of the game, we need to rewrite some of it to use the tick system instead.