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);
}
Then you can wait for the function to finish by using async/await:
async function doStuff() {
//...
await updateLIves();
// should wait for updateLives to finish
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
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.
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.
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.
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.
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.
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.
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)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 theupdateLives
function to finish before doing the next thing. I see that this function does not return anything, that may cause the issue?Then you can wait for the function to finish by using async/await:
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
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.
If I could look at the code somehow I can help debugging. Can you put it online somewhere like a codesandbox?
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.
Oh, it was easier than I thought.
I defined the
interval
variable at the top of the io.js module. Everytime you calltype()
it will overwrite the interval. I use setInterval to process the queue of characters one by one. So iftype()
is called while another is still running, only the last one will finish.Moving the
interval
variable inside thetype()
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.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.
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.
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!
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.
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)