SG Dial Sim Preview 2

After more than a year and a half, I’m pleased to announce that the second preview of SG Dial Sim is finally ready for download!

What’s New

Preview 2 involved a lot of technical changes that aren’t visible to users (more on those below). In addition to fixing the outstanding issues with Preview 1, the new release has one major new capability: destination sources.

It’s now possible to create sets of additional destinations on top of the default collection of addresses from Stargate SG-1 that come with the sim. This is a big deal for anyone who wants to use the sim for roleplaying, as it lets you add any address you like to the address book, after which it becomes a dialable destination just like the default ones. Sources stack as well, so you can essentially override default addresses with custom destination details.

Tech Updates

This update was so long in the making because (in part) I decided to undertake a significant refactor of the Angular code base. Preview 1 used an intricate system of observables to pre-assemble dialing sequences. This mechanism would have become unwieldly further down the roadmap, so the new release features an entirely new architecture behind gate functionality. Preview 2 makes use of the reactive Angular state library NgRx to manage the state of the dialing computer, which obviates the need to build entire dialing sequences in advance, and makes it easier to tie distant parts of the interface to the gate’s state changes.

In fact, it occurred to me while working on this refactor that the new system is much more to how the dialing computer would have worked in the TV show. It’s mentioned in at least a few episodes of Stargate SG-1 that the dialing computer works by sending and receiving a large variety of distinct signals from the Stargate itself. While a particularly detailed explanation is never given—and likely would have been wasted on virtually all viewers given the inscrutable and esoteric nature of real-life computer software at the turn of the century—it stands to reason that these signals represent instructions, for the gate to perform individual actions such as spinning the inner ring to a specific position, and from the gate to confirm when a chevron is engaged, when the gate is active, whether a wormhole is incoming or outgoing, et cetera. As such, a system that works by dispatching actions for individual components of the dialing sequence at the appropriate points in time, and listening to actions fired by the code that’s controlling the timing of the visual changes of the on-screen gate, is likely far more in keeping with the source material than the previous approach.

/geekout

I also updated Angular, TypeScript, GreenSock, and Electron to their latest versions as of now. This included bumping GreenSock from 2.x to 3.x, which required some substantial changes to the animation code to make use of GreenSock’s new API, and new capabilities in the 3.x line will pay dividends down the road.

This update has been a long time coming, but the overhaul has created a much more stable foundation for iterating on new features going forward.