Twitter Freesound.org Ludum Dare One Game a Month github npm Youtube

Welcome to brianmacintosh.com. I'm Brian MacIntosh, and I am a game programmer in the Orange County area of Southern California. This site serves to host and distribute some of my games and my blog, below.

I have developed games and apps for the XBox 360, Windows PC, iPad, Amazon Alexa, and Windows 7 Phone. I'm particularly interesting in procedural generation, pixel art, and emergent gameplay, and I'm looking forward to developing more games with these technologies.

Blog RSS E-Mail

You are filtering on tag 'nodejs'. Remove Filters
Previous Page | 2 total posts | page 1 of 1 | Next Page

Persistent data in the Alexa Skills nodejs SDK


February 05th, 2017 @ 0:59
Tags: alexa, nodejs, random

I recently started use the Alexa Skills Kit SDK for nodejs to write an Amazon Alexa skill. I ran into one rather silly roadblock, which I will now share so others can avoid.

This SDK handles persisent data (with the same session and across sessions) by providing an attributes property on the skill handler (accessed by this.attributes). My problem was that sometimes properties I set on this object were apparently completely ignored by the next request (even if I kept the session open with an this.emit(":ask", ...) response). It is perhaps obvious in hindsight, but you must make all your changes to this.attributes before calling emit, as emit will immediately and synchronously prepare and send the response to Alexa, including the attributes you're trying to persist into the next session. But it took me quite some time to figure this out.


Permalink

Keeping cmd windows open with /K


January 29th, 2014 @ 13:28
Tags: cmd, nodejs, random

I like using .BAT files to run common tasks like compiling Java code or starting my NodeJS server. It's very convenient to just execute a .BAT where you've already written out all the proper parameters rather than typing out an entire call every time you need it. This does cause a problem, though - if any of the programs that execute from the .BAT returns an error code, the command window will immediately close. This makes it impossible to debug those programs.

I tried adding the pause command at the end of each file, but to no avail - the command window exits immediately when a program returns an error and doesn't execute the rest of the file (which is responsible of it, admittedly).

The solution was to use a parameter to the cmd program itself:

cmd /K bat/mybat.bat

The /K parameter keeps the window open even if the .BAT stops executing. I simply copied all my .BATs to a subdirectory and created wrapper bats using this line.


Permalink


Previous Page | 2 total posts | page 1 of 1 | Next Page