## NOTE: This project does not represent good development practices. It exists for archival reasons only.


Integrated Communications Experience (ICE) is a project that prioritizes security, followed by integrated access to all online communication mediums. ICE is intended to replace a complicated communications toolchain (Discord, Google Drive, Email, WikiDot, etc.) with a single secure application.

This is the repository for ICE, and associated modules.
Do not distribute files contained within or save copies of credentials. These will be re-secured before the final version of the project, but it is wise to 
practice security as we develop this project.

[ICE Project Board](https://github.com/Smoke3785/ICE/projects/1)

### 7/15/2020 - Update

I have linked a registration system to the database and added a first name requirement to sign up. I initially wanted to include a first-name and last-name requirement, but that was apparantly too good for Jonathan \[REDACTED]. I've made progress in learning SQL Query Syntax, and I've figured out how to create and link fields in the database. The registration page, for the time being, is not styled or fleshed out. It looks like Dug, and I'll need to somehow make the registration itself password protected or time-locked. Security features for the registration page are upcoming. I'm incredibly grateful for the amount of tutorials to copy and paste from.

This is the current Registration Page: 

![ICE REGISTRATION](https://cdn.discordapp.com/attachments/659180705556856846/733066489598574783/unknown.png)

Upcoming work includes expanding the database to include wiki posts, creating a front-end for the wiki database to allow easy creation of articles, and a script to index, style, and display articles in a menu heirarchy. I made progress on this earlier before decided to make my life more difficult and decided to do most of it in JavaScript (which I don't know). In the future, I will also be creating an interactive page to outline basic opsec (@Noah) and list the dos and don'ts of secure communincations. 

Here is a preview of the upcoming Home Page that will be more-or-less live within the next few weeks:

![ICE HOME PREVIEW](https://cdn.discordapp.com/attachments/716030512518529105/732716018388041798/unknown.png)

### 7/13/2020 - Update

Since the very beginning of this project my ambition has far exceeded my ability in web design. I'm pleased to say, however, that I'm making steady progress. More importantly, I'm learning a lot as I develop. Currently, ICE has a **functioning user database back-end**. This means that, in theory, anybody who is invited to the site can create a user account and it will be encrypted and stored on the server. In practice, this setup is severely fragmented and needs to be re-ordered. I plan to create two branches of ICE, in the future. One will be a working copy, and the other will be the live copy. This means that all the code that is published will be clean and functioning and pretty so I can continue to inflate my Ego. 

The HTML-CSS aesthetic login page for the website has been retro-fitted with the functioning PHP script to handle input (and sanitize n'at), so it looks good and functions well. On the To-Do list is to remove the ability to highlight label text (as suggested by the honorable Mr. Foulke). Once this is handled the login page should be up to snuff when it comes to quality control. In future, I want to add more semantic animations to reflect authentication success/failure. This is a frill, though, so is something I'll be putting off for a rainy day.

The current iteration of the site closely reflects the visual mockup, which I'm very pleased about. I rewrote the page using CSS Bootstrap, but I figured it would be more work to do it that way and not worth the time. I may use Bootstrap for future iterations or mobile-optimized versions of the site, but for now I'm sticking with Vanilla CSS. In the future, I may end up using SCSS, depending on whether or not I figure out what SCSS actually is.

This is the current login page:

![ICE LOGIN](https://cdn.discordapp.com/attachments/636262965032648745/732371959500767332/unknown.png)

And the visual mockup:

![ICE LOGIN VISUAL MOCKUP](https://cdn.discordapp.com/attachments/636262965032648745/732398393279774801/unknown.png)

I hope that creating this GitHub will aid in streamlining collaboration. The only concern is that only I can do work on PHP (which makes up the majority of the code, at this point - Over 60%) because of the way I am interfacing with the server. I will consider investing time into configuring remote access in the future if there is enough interest in collaboration.

Integrated Communications Experience

*This was a proposal for an early project I hoped to complete for school. Unfortunately, I was never able to follow through for two reasons:*

*1) My proposal was legitimately horrendous and would not have worked in a million years and*

*2) I didn't feel like it*

*I do intend to revisit this project in the future, but my approach will be substantially different from what I proposed in the beginning of 2021.*








Over the next two and a half months, I intend to devote my time entirely to the development of a project in the field of computer science. This project takes the form of a mobile game, and incorporates meta-scale concepts like front-end mobile/web development, server development, networking and communication, as well as general coding concepts and development principals. The project is based on a personal passion of mine, an existing mobile game called Launch! Launch’s development is being shortly terminated. I hope to rebuild the game and offer it to the community as not only a replacement for Launch! but an upgrade, created with the perspective of a long-time player. I will be developing using the following technologies:

* HTML
* CSS
* * Bootstrap
 * Material UI
* Javascript
* * React JS
 * React Native
 * Expo
* Google Cloud Computing
* * Firebase
 * Storage
 * Functions

All technologies used are done so under official licensing and are being paid for in full, at my own expense. All assets, files, and intellectual properties used in the development of this project are done so under official licensing or express permission from their creators. 

# PROJECT OVERVIEW

Launch II is a GPS game that has players building infrastructure around the world to support a missile-based combat system. The central gameplay-loop revolves around the player generating wealth via a combination of a basic hourly income, war-time bounties, and infrastructure yields. The player can then choose to invest that wealth in weapons, defenses, or further economic infrastructure. Longer gameplay loops include incentives to form large factions, negotiate global treaties, and protect your empire from legitimate threats.

The game will be released for Android, with a potential for a limited iOS release for select players. The game is a mobile app, but will also have a game-integrated website that will provide the following: 

1. A way to easily observe and visualize server metrics. Data could include average player wealth, a faction’s overall military power, or a number of other collected data-points.
2. A public face for the game and its community. While Launch has historically had heavy Discord integration, the website can serve as a further gathering point. It will have the ability to promote community events, important in-game phenomenon, and detailed update and development patch notes.
3. A web-based game monitor. Players will now be able to view the world map on the web without access to their phones. This will allow for more robust coordination between members, and has the theoretical possibility to become a robust way of communicating and planning with other players. 
4. An administrator panel for server owners. This will act as a simple way to manage the Launch II server that you own. It will replace the need for a local console, and let you manage server-rules, game assets, and a slew of other data points. This will also ensure the security of users, as it insulates them from exposing encrypted and sensitive data points to server owners with ill intent. 
5. A groundwork for a desktop application for dedicated players, faction managers, and server owners. Building this web app with electron-deployment in mind means that this website could become a powerful tool for Launch! hotshots. 

All data and game functions will be executed via Google’s Firebase ecosystem, a cloud-computing solution that offers everything Launch II needs to ensure performance, stability, and a modern presentation. Firebase was chosen over a more traditional approach to game server development due to its proximity to my existing skill set, as well as its dedication to security and user safety. 

# TECHNICAL OVERVIEW

The front-end for Launch II (that being the app that the user installs on their phone and interacts with) will be developed using React-Native in combination with Expo. React Native is a cross-platform mobile development framework created by Facebook as an extension of React. Operating within the React environment will allow me to cultivate an existing skill-set, as well as ensure future compatibility with operating systems across Android and iOS. The client will use Firebase Authentication to handle initial user login. It will also be used in conjunction with certain proprietary technologies to enforce bans, eliminate GPS spoofing, and decrease the prevalence of cheating within Launch II.

![](https://lh5.googleusercontent.com/rI5fmQUR2vYISJY2btwhmj5wUK0X7bVmL5UZa6kew1m87PzMPLMXdNhyUkkEqW0F0eD43ScXDwuI_mApnVnEaIiZe_bUd2FicY6p7YLBVxTc7P_w7kE4CFiaPUe8dpQo_oLVzPvd)

Launch II’s front-end has four basic components: The user interface, the game renderer, the communications service, and the internal database. The UI simply acts as an interface by which to send requests to the server. It will immediately request that the server execute a function with given parameters. The game renderer is how the client interprets the majority of relevant data. When the client receives positional data for other players, for instance, the game renderer will move that player’s avatar to its corresponding position on the map. The communications component of Launch II has two jobs: Send certain data to the server (such as the player’s location and time) and receive certain data from the server (such as other players’ positions). Its job is simply to pass data to the internal database from the server, or transmit data from the internal server to the data. These communication events (both sending and receiving) will happen cyclically, meaning that communication of data will always occur within a certain period of time (likely under 500ms) so that the player’s experience of the game appears un-interrupted. The fourth component of the game is the internal database. The internal database holds a cached copy of all data relevant to the game’s operation. Some of this data will be refreshed from the server every tick. Some of this data is stored once upon request and not updated again until subsequent requests. A portion of this data is stored only temporarily until it is passed to the server from the device. This internal database is what will allow the client and the server to communicate efficiently, only attempting to send or receive data when necessary, and relying on local storage when not.

A fifth-pseudo component exists, and that is the interpolation logic. Because Launch II does not require ultra low-latency between the server and the client, and because of its platform-inherent connection instability, the game must be able to interpolate game events between instances of server connection. For example: If a missile is fired while the client is connected to the internet, and then the client becomes disconnected, the client user should be able to observe that missile's trajectory up until the point of impact (at which point the server is required to handle an impact event) without communicating with the server. This means that whatever function the server uses to determine missile trajectory (as well as other metrics) must also exist on the client. Some logic must also exist to efficiently prefer one over the other. This advanced interpolation mechanic has the highest potential to make Launch II highly performance efficient, but also carries the highest risk of producing the opposite effect.

![](https://lh3.googleusercontent.com/AlPcgcl7YFFBNG4j4r7Z8f1Q3BMRX8le8e56naH7Y8oAkEjDOHTlmCagClI_jFA6_3zhF0EMJX8QIdtCNzUI1TJCkHbRGI1zUQ2_7A5X_FEQZCrAqdIEFCThicjpgNXmwfrocu7I)

The server has four primary components, divided between two functions. The Database and Storage components will handle the storage of data and files, respectively. The Cyclical and Reactive are functional components that handle the game's logic, whether on a schedule (Cyclical) or at a user’s request (Reactive). The Database component is the backbone of Launch II. It will hold all relevant data about players, the game, user accounts, and more. It will also hold the rules that dictate the game in a dynamic way such that they can be easily balanced and adapted. The database doesn’t do anything on its own, but relies on the two functional components to read and write data to and from it. The Storage component holds larger data, those that don’t need to be read and written frequently. These could be game backups (in JSON format), user profile pictures, or meta-data about the game. The game could theoretically function without this component, but the division of labor between the database and the storage component will make development more straightforward in the long run, and clean up the database for server owners to manage easily. 

The Cyclical component of the server handles events on a schedule. These timescales vary - the most important being the Cyclical function that runs every tick (as mentioned before, likely under 500ms). This will handle everything from missile movement to player positions in the world to the game’s chat function. Other Cyclical functions will handle things like the game’s hourly allowance, and even weekly challenges and awards. 

The Reactive Component authenticated then handles user requests. To ensure that normal users aren’t simply pretending to be admins or faction leaders, it is important to cross reference the claim that user is making with a handful of other metrics. If a user who is not an administrator somehow calls an administrator action, the Reactive function will reference the database to ensure that the user is authenticated. In the large majority of cases, the user will pass this authentication check, and the Reactive function will handle the request that the user made. For example: User 1 clicks buy, requesting that the server purchase several missiles on his behalf. The server checks if the user is who they say they are, then checks if the user has the money required to make that purchase. Assuming all is well, the server will then subtract the correct amount of money from that user’s metadata, then add the missiles he requested to his missile site. The reactive function will then terminate, leaving the Cyclical function to pass that data back to the client. 

# REPORTING

Reporting will occur in three formats. Firstly, oral or short written reports can be given daily, explaining progress made, concepts learned, and hurdles being faced. Secondly, weekly written reports will be written, detailing the technical achievements of the week, as well as the plans and hopes for the coming week. Finally, GitHub and Discord will be consistently updated with developer notes, giving an overview of progress at any significant milestone, as well as communicating with potential end users / testers to gain insight into future progression. 

.

# MILESTONES

These milestones are tentative, and contain only a rough outline of development. The order of these milestones are subject to change as development occurs, as milestones may reveal themselves to be prerequisites of each other in an unexpected way. What is written below is based on my understanding of the features essential to gameplay, security, and social networking. Before release, additional work will be required, but the game should be essentially functional if these milestones are complete.

## Absolute Basics

These milestones are what are required for the game to be developed any further. Many of these will be reworked, but serve as proofs of concepts or placeholders for impending features.

* Basic communication between two devices via a Firebase intermediary
* Firebase authentication and basic security protocols
* Develop a logical flow for authentication, as well as integrate data caching to avoid repeated logins. 
* Tick-based basic communication components, both for server and client. Demonstrable with simple iterable value.
* Create basic multi-player GPS renderer, passing locational data to server and retrieving that data from the server
* Client based value-exclusion for GPS. (i.e. Launch I privacy zones). Could do this via server but why bother?
* Create a game config file that provides parameters for functions to execute based on. 
* Create a simple hourly loop for allowance distribution that references frequency and value from the config.

NOTE: Two values must be passed to the server: Real GPS coords and Privacy-Excluded values. Only privacy excluded values are passed back to other users. DotNCarry.

## Beginnings of Gameplay

This is where the game starts to resemble Launch I. This takes the basics from the first category and applies them to essential game functions. No missiles yet, but the groundwork for communications has been created in a way that makes most things possible with simple adaptations of other code.

* Begin to develop reactive functions for simple structure generation.

NOTE: Keep track of all functions in a Google Doc or other format!

* Expand structure metadata and data-linkage. 
* Create ability for the user to create an ore mine. This requires a Reactive function to create it and a cyclical function to handle ore-mine logic and ore-creation.
* Optimize server requests so static objects are updated only as frequently as possible.
* Develop player files linked to user accounts. Create a simple Reactive function to handle authentication then purchases. 
* Develop server functions to handle missile inventory additions and subtractions.
* Develop a system to add missiles to a fired-missiles list and subtract them from a launcher’s inventory. 

NOTE: Static objects exist as their own objects, not as meta-data of a player.

* Develop client side missile trajectory rendering system based on server-provided values of position and target. Missiles mustn’t move at this point, but their trajectories should be rendered.

NOTE: Client should always interpolate based on cached values, NEVER based on server values UNLESS authentication or calculation is required to return accurate value.

* Integrate missile movement into the tick-based cyclical function of the game.
* Develop interceptor capabilities and logic. Add Cyclical loop to calculate interceptor hit percentage in the event of object-target collision.
* Polish missile firing system. Allow for advanced interpolation to occur on client-side devices to mitigate effects of intermittent server disconnections.
* Create advanced ore generation objects, as well as ore objects. Develop cyclical function to generate ore, as well as recalculate ore-generation-diminishments upon ore-mine creation. Store ore generation level as object data.

## End of Basic Development

Now that many of the basic loops and functions are hashed out, it is time to add the rest of our features that utilize these functions. At this point, the game should resemble Launch at its most basic. It is important at this point not to attempt to develop more frills than are necessary before finishing the important parts, as many components in this category will eventually have advanced capabilities. 

* Create ability to Reactively request player data and store it to cache upon clicking the player on map.
* Create roles such as moderator and administrator. Create authentication procedures for both.
* Create server feed, player-specific alert feed, and curated game announcement feed.
* Begin to develop a social system, but only to the extent that is required to display simple data upon request, as outlined above.

## User Interface Polishing and Social Features

Launch is built on its community, and it is what makes the game special. This is an important part of Launch II - increasing the players’ ability to network, make personal connections, and coordinate with players who join the game. This is where the menus developed in the last section start to be filled out: with rich user-data and advanced faction capabilities. This is the least exhaustive of the list, because by this point the things that need finished will have revealed themselves clearly. 

* Integrate factions into the game, as well as the basic faction page. Create authentication procedures for faction leaders.
* Develop firing rules, such as friendly fire rules and warnings upon firing on weak players.
* Develop rich faction pages and data.
* NOTE: This data will be reactively requisitioned from the database and then read from cache. No reason to update this data every tick.
* Develop rich player pages and data. This includes some graphic design - development merits and the like to commemorate player achievements. 
* Develop direct discord integration for reputable factions.
* Create a cyclical gameplay loop to handle weekly wars, awards, etc. War and Peace will be awarded.

# DEVELOPMENT TIMELINE AND FINAL DELIVERABLE

By the end of my first development-period, my goal is for Launch II to be at the end-stages of its basic development. At this point, the game will not be finished, nor necessarily deployable, but it will be a matter of filling in the gaps from this point forward. This first development period will take place from January 11th (the date of writing) until April first. At this time, I will have a significant amount of documentation on the process and concepts relevant to Launch II’s development. On top of that, I will be able to deliver not only a basically-functional version of the game, but a presentation on the development journey, the road ahead, and the product as it exists as of April 1st.

I’m excited to begin development on Launch II. It has been an important part of my life and I hope that it can continue to be, albeit in an advanced capacity. The developer and community of Launch have given a lot to me over the years. Being able to give back is an incredible opportunity, and an opportunity I feel obligated to capitalize on.

Launch II Development Project Proposal

This entire piece concerns the role of the government in the personal lives of its citizens. I don’t think my libertarian beliefs will come as a huge surprise to anybody, but this piece certainly made me seriously consider some of my initial thoughts on the subject. There are three primary things that caught my interest: The government’s role in intimacy and religion, the government being shady, and the Mormon wars (which I wasn’t previously aware of).

A central principle of mine is that when it comes to personal matters, the government should mind its own so long as no rights are being infringed. The government exists, ultimately, to protect the citizens’ rights from infringements by others. When it comes to polygamy and polyamory (which are effectively the same in the context of this article), the government has no responsibility to step in. The court’s claims of “combating ‘stationary despotism’” strike me as a justification for a war on Mormon influence. The pyramidic power structure that the government described as problematic exists, to variable extents, in every piece of life. The nuclear family, corporations, and the Christian church are all examples of this sort of power structure. Why aren’t these despotic structures as problematic in the modern day as the courts prophesied? Because we restrict these power structures from infringing on the rights of their constituents. The US Department of Labor, for example, protects my job from forcing me to do things that are dangerous. Things like Whistleblower protections are designed to protect me from retribution by the companies (or, allegedly, governments) in the event that I exposed wrongdoing. I suspect that if the government had been more understanding at the outset and respected (disregarding the morality) the Mormon’s tradition of polygamy, they could have used that as a bargaining chip to gain more power over the church and Utah. 

Which brings me to my second point: The government is shady as hell. This fiasco that happened ~200 years ago patently exposes the government’s tendency to conflate legal rulings with long-term political interests. If this was happening to such a degree 200 years ago, it makes me wonder how frequently things like that happen today. It certainly brings to mind contemporary cases like Edward Snowden’s charges of treason. Are these actually warranted? Or are they another grasp at power by the government? Do the actions of America in its infancy have any bearing on its behavior today? Or have we grown past this sort of conspiracy.

Finally, I never knew about the Mormon Wars. This is a fascinating piece of history that I’d never heard of. I want to do more research into this - the whole thing reminds me of the plot of Far Cry 5.

Reflective - Reynolds v. United States

# smoke-machine-js 

A collection of helpful functions, polyfills, and definitions I frequently use in my projects.

Contains general content, as well as project-specific code snippets which is implemented in multiple contexts.

This package is intended primarily for personal use, but please feel free to use/improve any of the functions provided here.

[NPM](https://www.npmjs.com/package/smoke-machine-js) **|** [GitHub](https://github.com/Smoke3785/smoke-machine-js)



# Installation

`npm install smoke-machine-js`

# Usage

```js
// For ES6 imports
import { helperFunctions } from 'smoke-machine-js';

// For commonJS
const { helperFunctions } = require('smoke-machine-js');
```

# Documentation

Documentation for all modules.

[JSdocs](#) **|** [View on Website](https://owenrossikeen.com/docs/smoke-machine-js)

### **Helper Functions**

A collection of functions for processing and formatting data.

Some of these may be redundant, depending on their runtime (e.g. [helperFunctions.getTime()](#helperFunctions.getTime) in a browser with the Internationalization API). These functions are mostly meant to act as polyfills for runtimes where they are not natively supported.

Many of these functions are extremely simple (e.g. [helperFunctions.arrayRandom(arr)](#helperFunctions.arrayRandom)), and you may ask yourself why they require a function. The reason is that I do not feel like writing it 200,000 times, or the underlying code isn't nearly as semantic as a named function.

---

- [helperFunctions](#helperFunctions) : <code>object</code>
 - [.stringToSHA256(str)](#helperFunctions.stringToSHA256) ⇒
 - [.stringToByteBuffer(str)](#helperFunctions.stringToByteBuffer) ⇒
 - [.intFromBytes(bytearray)](#helperFunctions.intFromBytes) ⇒
 - [.roundFloat(float)](#helperFunctions.roundFloat) ⇒
 - [.getTime(full)](#helperFunctions.getTime) ⇒
 - [.projectAudit()](#helperFunctions.projectAudit)
 - [.crc32(str)](#helperFunctions.crc32) ⇒
 - [.parsedJsonStringsToInt(object)](#helperFunctions.parsedJsonStringsToInt) ⇒
 - [.degreesToRadians(deg)](#helperFunctions.degreesToRadians)
 - [.radiansToDegrees(rad)](#helperFunctions.radiansToDegrees)
 - [.milesToKilometers(miles)](#helperFunctions.milesToKilometers)
 - [.kilometersToMiles(kilometers)](#helperFunctions.kilometersToMiles)
 - [.bytesToHexString(data, length)](#helperFunctions.bytesToHexString)
 - [.arrayRandom(arr)](#helperFunctions.arrayRandom)
 - [.capitalizeString(str)](#helperFunctions.capitalizeString)
 - [.generateOrdinal(i)](#helperFunctions.generateOrdinal) ⇒

<a name="helperFunctions.stringToSHA256"></a>

### helperFunctions.stringToSHA256(str) ⇒

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: ByteBuffer containing SHA256 encoded str

| Param | Type |
| ----- | ------------------- |
| str | <code>string</code> |

<a name="helperFunctions.stringToByteBuffer"></a>

### helperFunctions.stringToByteBuffer(str) ⇒

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: Byte Array containing encoded str

| Param | Type |
| ----- | ------------------- |
| str | <code>string</code> |

<a name="helperFunctions.intFromBytes"></a>

### helperFunctions.intFromBytes(bytearray) ⇒

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: Decoded 64-bit Floating Point number

| Param | Type |
| --------- | ---------------------- |
| bytearray | <code>bytearray</code> |

<a name="helperFunctions.roundFloat"></a>

### helperFunctions.roundFloat(float) ⇒

Useful for rounding single-precision floats (such as those encoded in a Java application)

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: Number rounded to the 100ths place.

| Param | Type |
| ----- | ------------------- |
| float | <code>number</code> |

<a name="helperFunctions.getTime"></a>

### helperFunctions.getTime(full) ⇒

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: Formatted string time

| Param | Type | Default | Description |
| ----- | -------------------- | ------------------ | -------------------------------------------------------- |
| full | <code>boolean</code> | <code>false</code> | Whether or not function returns seconds. default: false. |

<a name="helperFunctions.projectAudit"></a>

### helperFunctions.projectAudit()

Iterates over all files (excluding node_modules and the like) to determine the (roughly estimated) number of lines of code in a given project

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
<a name="helperFunctions.crc32"></a>

### helperFunctions.crc32(str) ⇒

Generates a crc32 checksum from a string

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: crc32 checksum number

| Param | Type | Description |
| ----- | ------------------- | ------------------------------------- |
| str | <code>string</code> | The stringified data to be converted. |

<a name="helperFunctions.parsedJsonStringsToInt"></a>

### helperFunctions.parsedJsonStringsToInt(object) ⇒

Takes a parsed JSON object which contains numbers read as strings and converts those strings to numbers.
e.g. userID: "1234" would become userID: 1234.
Also has the nasty tendency to turn empty arrays into zeroes.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: Object with numbers, rather than strings.

| Param | Type | Description |
| ------ | ------------------- | ------------------------------------- |
| object | <code>object</code> | The stringified data to be converted. |

<a name="helperFunctions.degreesToRadians"></a>

### helperFunctions.degreesToRadians(deg)

Converts degrees to radians. Simple as.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions)

| Param | Type |
| ----- | ------------------- |
| deg | <code>number</code> |

<a name="helperFunctions.radiansToDegrees"></a>

### helperFunctions.radiansToDegrees(rad)

Converts radians to degrees. Simple as.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions)

| Param | Type |
| ----- | ------------------- |
| rad | <code>number</code> |

<a name="helperFunctions.milesToKilometers"></a>

### helperFunctions.milesToKilometers(miles)

Converts miles to kilometers. Simple as.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions)

| Param | Type |
| ----- | ------------------- |
| miles | <code>number</code> |

<a name="helperFunctions.kilometersToMiles"></a>

### helperFunctions.kilometersToMiles(kilometers)

Converts kilometers to miles. Simple as.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions)

| Param | Type |
| ---------- | ------------------- |
| kilometers | <code>number</code> |

<a name="helperFunctions.bytesToHexString"></a>

### helperFunctions.bytesToHexString(data, length)

Converts a byte array into a hexadecimal string.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions)

| Param | Type | Default | Description |
| ------ | ---------------------- | --------------- | ----------------------------------------------------------------------------- |
| data | <code>bytearray</code> | | Data to be encoded |
| length | <code>number</code> | <code>32</code> | The maximum number of bytes which will be read (left justified). Default: 32. |

<a name="helperFunctions.arrayRandom"></a>

### helperFunctions.arrayRandom(arr)

Selects a pseudorandom value from the provided array.
Because I was sick of typing 'Math.' 200 times.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions)

| Param | Type | Description |
| ----- | ------------------ | -------------------------- |
| arr | <code>array</code> | Array to be selected from. |

<a name="helperFunctions.capitalizeString"></a>

### helperFunctions.capitalizeString(str)

Capitalizes a given string.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions)

| Param | Type | Description |
| ----- | ------------------- | ------------------------ |
| str | <code>string</code> | String to be capitalized |

<a name="helperFunctions.generateOrdinal"></a>

### helperFunctions.generateOrdinal(i) ⇒

Generates an ordinal suffix for a number.
e.g. 1 becomes 1st, 9 becomes 9th.

**Kind**: static method of [<code>helperFunctions</code>](#helperFunctions) 
**Returns**: The number concatenated with its ordinal.

| Param | Type | Description |
| ----- | ------------------- | -------------------------------------------------- |
| i | <code>number</code> | The number for which an ordinal will be generated. |

### **Launch Functions**

A collection of functions specific to Launch-related projects:

- Launch
- Launch II
- Launch: Experimental
- Counterforce
- Counterforce II
- smokeSignal

---

- [launchFunctions](#launchFunctions) : <code>object</code>
 - [.stringFromData(bb)](#launchFunctions.stringFromData) ⇒
 - [.getStringData(str)](#launchFunctions.getStringData) ⇒
 - [.getStringDataSize(str)](#launchFunctions.getStringDataSize) ⇒
 - [.sanitizeName(str)](#launchFunctions.sanitizeName) ⇒
 - [.cleanJSONGameSave(json)](#launchFunctions.cleanJSONGameSave) ⇒

<a name="launchFunctions.stringFromData"></a>

### launchFunctions.stringFromData(bb) ⇒

Reads a Short at the provided ByteBuffer's offset, reads a string of the length denoted by the read short.
This DOES iterate the ByteBuffer in the namespace where the function is called.

**Kind**: static method of [<code>launchFunctions</code>](#launchFunctions) 
**Returns**: The string which was read.

| Param | Type | Description |
| ----- | ----------------------- | -------------------------------------------------- |
| bb | <code>ByteBuffer</code> | The ByteBuffer from which the string will be read. |

<a name="launchFunctions.getStringData"></a>

### launchFunctions.getStringData(str) ⇒

Converts a string to a ByteBuffer containing a short (representing the length of the converted string), followed by the converted string.

**Kind**: static method of [<code>launchFunctions</code>](#launchFunctions) 
**Returns**: ByteArray

| Param | Type | Description |
| ----- | ------------------- | ----------------------------------- |
| str | <code>string</code> | The string which will be converted. |

<a name="launchFunctions.getStringDataSize"></a>

### launchFunctions.getStringDataSize(str) ⇒

Returns the byte-size of a short (representing the length of the string), followed by a byte-encoded string

**Kind**: static method of [<code>launchFunctions</code>](#launchFunctions) 
**Returns**: Number

| Param | Type | Description |
| ----- | ------------------- | ---------------------------------- |
| str | <code>string</code> | The string which will be measured. |

<a name="launchFunctions.sanitizeName"></a>

### launchFunctions.sanitizeName(str) ⇒

Sanitized the given name for profanity, as well as dangerous characters. Not currently functional.

**Kind**: static method of [<code>launchFunctions</code>](#launchFunctions) 
**Returns**: The sanitized string.

| Param | Type | Description |
| ----- | ------------------- | ----------------------------------- |
| str | <code>string</code> | The string which will be sanitized. |

<a name="launchFunctions.cleanJSONGameSave"></a>

### launchFunctions.cleanJSONGameSave(json) ⇒

Cleans coarsely converted JSON game save (from XML) for use in Counterforce.
This is an ultra-specific function for Counterforce.

**Kind**: static method of [<code>launchFunctions</code>](#launchFunctions) 
**Returns**: Cleaned object.

| Param | Type | Description |
| ----- | ------------------- | ----------------------- |
| json | <code>object</code> | The parsed JSON object. |

# Dependencies

- [bytebuffer.js](https://www.npmjs.com/package/bytebuffer)
- [crypto-js](https://www.npmjs.com/package/crypto-js)
- [readline](https://www.npmjs.com/package/readline)
- [recursive-readdir](https://www.npmjs.com/package/recursive-readdir)

Huge shout-out to bytebuffer.js. This package powers several of my projects and is phenomenal.

smoke-machine-js

# smoke-signal-js

A JavaScript port of Tobster's communication library, TobComm. Be aware - this implementation is functional, not class-based! This is because I am not Bri\*ish.

# Installation

`npm install smoke-signal-js`

# Usage

```js
// For ES6 imports
import { smokeSignal } from 'smoke-signal-js';

// For commonJS
const { smokeSignal } = require('smoke-signal-js');
```

# Documentation

[JSdocs](#) **|** [View on Website](https://owenrossikeen.com/docs/smoke-signal-js)

## Functions

<dl>
<dt><a href="#getSendObjectData">getSendObjectData({)</a> ⇒ <code>bytebuffer</code></dt>
<dd>Encodes an object into a Tobject ( a bytebuffer prepended with metadata) to send data to a LaunchLike server.
</dd>
<dt><a href="#getSendCommandData">getSendCommandData({lCommand,)</a> ⇒ <code>bytebuffer</code></dt>
<dd>Encodes data required to send a command to a LaunchLike server.
</dd>
<dt><a href="#getRequestObjectData">getRequestObjectData({lObject,)</a> ⇒ <code>bytebuffer</code></dt>
<dd>Encodes data required to make an object request to a LaunchLike server.
</dd>
<dt><a href="#sendCommand">sendCommand({lObject,)</a> ⇒</dt>
<dd>Requests a command from a LaunchLike server with the given code.
</dd>
<dt><a href="#sendObject">sendObject({lObject,)</a> ⇒</dt>
<dd>Sends an object from a LaunchLike server with the given code and data.
</dd>
<dt><a href="#requestObject">requestObject({cData})</a> ⇒</dt>
<dd>Requests an object from a LaunchLike server with the given code.
</dd>
<dt><a href="#processBytes">processBytes(cData, context)</a> ⇒</dt>
<dd>Takes a Tobject and parses out a message type definition and length for the data.
The function then calls a handler method of the context which was provided to it with the transcribed data.
</dd>
</dl>

<a name="getSendObjectData"></a>

## getSendObjectData({) ⇒ <code>bytebuffer</code>

Encodes an object into a Tobject ( a bytebuffer prepended with metadata) to send data to a LaunchLike server.

**Kind**: global function

| Param | Type | Description |
| ----- | ------------------- | ----------------------------------------- |
| { | <code>object</code> | lObject, lInstanceNumber, lStart, cData } |

<a name="getSendCommandData"></a>

## getSendCommandData({lCommand,) ⇒ <code>bytebuffer</code>

Encodes data required to send a command to a LaunchLike server.

**Kind**: global function

| Param | Type | Description |
| ---------- | ------------------- | ---------------- |
| {lCommand, | <code>object</code> | lInstanceNumber} |

<a name="getRequestObjectData"></a>

## getRequestObjectData({lObject,) ⇒ <code>bytebuffer</code>

Encodes data required to make an object request to a LaunchLike server.

**Kind**: global function

| Param | Type | Description |
| --------- | ------------------- | --------------------------------- |
| {lObject, | <code>object</code> | lInstanceNumber, lStart, lLength} |

<a name="sendCommand"></a>

## sendCommand({lObject,) ⇒

Requests a command from a LaunchLike server with the given code.

**Kind**: global function 
**Returns**: Nothing. This calls a function within the class context provided to it.

| Param | Type | Description |
| --------- | ------------------- | ---------------- |
| {lObject, | <code>object</code> | lInstanceNumber} |

<a name="sendObject"></a>

## sendObject({lObject,) ⇒

Sends an object from a LaunchLike server with the given code and data.

**Kind**: global function 
**Returns**: Nothing. This calls a function within the class context provided to it.

| Param | Type | Description |
| --------- | ------------------- | ------------------------------- |
| {lObject, | <code>object</code> | lInstanceNumber, lStart, cData} |

<a name="requestObject"></a>

## requestObject({cData}) ⇒

Requests an object from a LaunchLike server with the given code.

**Kind**: global function 
**Returns**: Nothing. This calls a function within the class context provided to it.

| Param | Type | Description |
| ------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| {cData} | <code>object</code> | An object containing the request code, the instance number, the starting position, and the length. Generally only the data is provided. |

<a name="processBytes"></a>

## processBytes(cData, context) ⇒

Takes a Tobject and parses out a message type definition and length for the data.
The function then calls a handler method of the context which was provided to it with the transcribed data.

**Kind**: global function 
**Returns**: Nothing. This calls a function within the class context provided to it.

| Param | Type | Description |
| ------- | ----------------------- | ---------------------------------------------------------- |
| cData | <code>bytebuffer</code> | The data which you wish to decode |
| context | <code>class</code> | The class context from which you're calling this function. |

# Dependencies

- [bytebuffer.js](https://www.npmjs.com/package/bytebuffer)
- [smoke-machine-js](https://www.npmjs.com/package/smoke-machine-js)

Huge shout-out to bytebuffer.js. This package powers several of my projects and is phenomenal. The developer of smoke-machine-js is remarkably handsome.

Congrats on the ultrawide 😉

DOCUMENTS

smoke-signal-js

smoke-machine-js

Launch II Development Project Proposal

Reflective - Reynolds v. United States

Integrated Communications Experience