DEV Community

Discussion on: Retro CRT terminal screen in CSS + JS

Collapse
 
ekeijl profile image
Edwin

Hey, thanks man! I'm really happy to hear that other people use my code for all kinds of stuff! I have not really thought about how to give credit, maybe just link to my dev.to profile for now. I was working on a portfolio site, this might be the motivation to actually finish it. :)

About the updateLives function, I assume you want to wait for the updateLives function to finish before doing the next thing. I see that this function does not return anything, that may cause the issue?

async function updateLives() {
    let span = document.querySelector(".lives");

    let blocks = Array(lives)
        .fill(0)
        .map(() => "■ ")
        .join("");

        // Added return here
    return await type("Text", { clearContainer: true }, span);
  }
Enter fullscreen mode Exit fullscreen mode

Then you can wait for the function to finish by using async/await:

async function doStuff() {

  //...
  await updateLIves();
  // should wait for updateLives to finish
Enter fullscreen mode Exit fullscreen mode
Collapse
 
maveric profile image
maveric • Edited

I've made that change, and the execution does not seem to change. I have a "console.log" immediately following the call to updateLives that in fact will not show until it completes. But if I move the mouse, the

wordSpan.addEventListener("mouseenter", handleWordHover);

gets called (as it's on all elements) and seems to interrupt the promise. If I move the mouse, I never get that console.log statement for that call. If that game ends with that interrupted, it won't show the game end typer properly.

I have not been able to find any resources on this type of interaction - an event listener popping off during an await that messes it up - and this whole async/await was not a paradigm when I was coding last. Trying to catch up.

Your help/suggestions would be greatly appreciated but I know this was just a side/learning project, not something you intended to support and won't be offended if you chose not to.

Thread Thread
 
ekeijl profile image
Edwin

If I could look at the code somehow I can help debugging. Can you put it online somewhere like a codesandbox?

Thread Thread
 
maveric profile image
maveric • Edited

The sandbox is at:
codesandbox.io/s/hungry-booth-wyl1...
It really is just your code that I've made some minor bug fixes and personal debug/figure out code to. The same thing happens on the sandbox from this write up as well if it's easier to look at code I haven't put any hack-it-to-figure-it-out code into.

Thread Thread
 
ekeijl profile image
Edwin • Edited

Oh, it was easier than I thought.

I defined the interval variable at the top of the io.js module. Everytime you call type() it will overwrite the interval. I use setInterval to process the queue of characters one by one. So if type() is called while another is still running, only the last one will finish.

Moving the interval variable inside the type() function ensures every promise will execute asynchronously like you expect. Not sure why I wrote it like this in the first place, probably because I thought I would only need 1 typer at the same time, lol.

Thread Thread
 
maveric profile image
maveric

That's fantastic. I'm very glad it was an easy find for you and greatly appreciate you looking into it for me. Works like a charm. That would have taken me ages to find, as I was going down the "how's the promise getting messed up" path.

I've got a lot to learn, but you've got great code for me to follow, so thanks again.

Collapse
 
maveric profile image
maveric

I'm not sure if you are still reading comments on this article but we had our airsoft event last month and these were a HIT. I loaded it up on some rPi's and battery packs with wifi that redirected all traffic to the pi.

I built a local backend API that took in the "command" and tested it against our list and sent back either brogue or fallout to run based on our new command names. Then hooked into the win/losses and sent that back to the api so we could have dynamic win/loss messages based on the game that was played. It added something completely new to the airsoft world and we will absolutely be bringing it back in future games.

Thread Thread
 
ekeijl profile image
Edwin

That's so cool! I picture this as a "retro arcade" that you use during the downtime of the airsoft event? Thanks for the update!

Thread Thread
 
maveric profile image
maveric

Nope. :P We've got the pi's people connect with with their phone and a few toughbooks they've got to be in front of. You've got to have people pull security (to keep enemies away) or play the game under fire in order to get the information out of it to complete your mission and keep things progressing. The "hacking terminal" is very much a part of the live fire scenario game.

Thread Thread
 
ekeijl profile image
Edwin

That is freakin' genius! Sort of "hacking" mini-games during the event, that's so creative! Reminds me of this "scavenger hunt" game that we used to play on my university campus.

I'm currently playing a game called "Control" which also has some terminal based mini-games, might add it to this project. (no promises tho)