This game is a highly complicated and feature-rich game, and as such the interface is quite hefty. That being said, it does have a few key elements that you can see when you look at it. The biggest area of the screen is the "Viewscreen". It is a black window-looking area of the screen where the majority of the visuals and information you will see in this game are shown. The second main part of the screen is the "Overview Tabs". This section of the screen provides five basic informational categories that can be used to view more information about your ship. From left to right: Sensors, Tactical, Mains, Repair, and Cargo. Also, with none of the menu options selected, you can see an unobstructed view of space in front of you.

This data screen shows abridged information about the main systems on your ship--those systems that control the basic functions of your ship. This includes engines--orbital thrusters, sublight engines, and FTL engines--as well as life support, transportation, sensors and more. On this screen, you will see: (1) A small icon representing the type of module, (2) A health bar indicating the current health of the module [this health bar will change color to indicate health danger zones], (3) And the overall background color of the module will change to indicate if the module is online or offline [green indicating online, red indicating offline].

This data screen shows abridged information about the tactical (combat) systems on your ship. Much like the main system interface, these module backgrounds will change color to indicate online/offline state. Typically, only one weapon module can be "online" at a time, although that status will be referred to as "armed". Off to the left part of the screen, you will see some information about your overall ship status: (1) Two icons, showing the current design of your ship as seen from the side and top, with circles around them indicating shield integrity. (2) Under that you will see the current hull integrity, represented as a gray bar. (2) Underneath that, you will see a blue bar indicating overall shield stability (which is a cumulative health among all your active shield modules) if you have one or more shields installed. If you are in battle, you will likely want to spend a lot of time on this screen to monitor the status of your defensive and offensive systems.

This data screen presents information about all of the propulsion systems on your ship. These systems are: Thrusters, Sub-light Engines, and Warp/FTL Drives, respectively. The information you are given is: current speed, maximum speed, and maximum acceleration possible. From here, you can toggle between the three drives using the Up and Down Arrow keys and use the Left and Right ones to move the sliders to adjust the speed of the specific engine. Bear in mind that what you see is purely visual until you "engage" your alterations by pressing the Store key. Doing so will disable all the other engines, enable the selected one, and set the new speed if possible. If something prevents that, a speed of 0 will be returned for the selected engine (which will effect no change).

Project TI-Trek gives end users the ability to alter the style of the interface they see when using the game. To do this, simply replace the appvar TrekGFX with one of your own, built using your own sprites. While this is for the most part an uninvolved process, it is important to keep the order of the sprites and their encodings entact. To assist with this, I have enclosed a template YAML, with the correct settings encoding options specified. The sprite list is commented out, with each commented line indicating which sprite goes where. Do not go out of order. You can download that file here.

Once you have edited your YAML file appropriately, and have all the sprites you need, you will need to build the graphics. Doing so will require that you have the CE toolchain on your computer, and the latest version of convimg. Run convimg by opening a Terminal window, navigating to the folder in which your YAML is stored, and then run convimg.

            cd path/to/convimg.yaml
            convimg

This assumes that you have followed the toolchain's directions for adding its binaries to your system PATH. If you didn't, then you should be doing this:

            cd path/to/convimg.yaml
            path/to/convimg/convimg

If run without error, you should see the following in your Terminal window. If you do NOT see this, contact the Project devs.

            [info] Generating output for convert 'customgfx'
            [info]  - Writing 'TrekGFX.h'
            [info]  - Writing 'TrekGFX.c'
            [info]  - Writing 'TrekGFX.8xv'

Your custom graphics pack has been successfully built. Congratulations!

If you have built a custom graphics pack, or have downloaded someone else's and want to install it in place of the defaults, you can do so by navigating to the folder where the TrekGFX.8xv file you just built or downloaded is located. You can then send it to your calculator (or emulator) by following the procedures for transfering files laid out by the software of your choice (TI-Connect, TiLp, etc). If you have followed the procedures laid out here properly, everything should work smoothly. However, if the calculator returns a graphics error or your sprites appear mismatched, consult the Troubleshooting section.

To customize certain portions of the server, you will want to locate and open the file config.json with your favorite style of text editor. You will see a JSON file that looks something like this:

            {
            "port":51701,
            "debug":true,
            "packet-size":4096,
            "min-client":[0, 0, 98],
            "max-players":100,
            "idle-timeout":600,
            "enable-discord-link":true,
            "log":"logs/server.log",
            "gamedata": { "path":"data/" },
            "player": { "path":"data/players/" },
            "space": { "path":"data/space/" }
            }

See the lists below for a description of what each option in the file does.

Settings

port

Port on which the server will listen.
Accepted: Any valid port number

debug

Whether or not packet debug info will be printed to the log and console. It can get lengthy.
Accepted: true | false

packet-size

The size of the send() and recv() buffers the server works with.
The default (4096) mirrors the buffer size on the calculator.
Accepted: Any valid size in bytes

min-client

Bytearray containing 3-byte version ID of the earliest client version that will be allowed to connect.
Accepted: [<major>, <minor>, <revision>]

max-players

Maximum number of simultaneous connections allowed.
Accepted: Any, within reason

idle-timeout

How long .recv() should block before triggering an exception and closing the connection.
Accepted: Number, indicating time (in seconds)

enable-discord-link

Whether or not the server sends chat and status messages to the server's Discord.
Accepted: true | false

log

Specifies the path to the server's logfile.
Accepted: A string representing a file path. The file does not need to be manually created.

player

A dictionary of configuration options for handling of player data (see below).

space

A dictionary of configuration options for handling of map data (see below).

Now you need to make sure you have the dependencies needed for the server software to run. Many of these are system libs, but nonetheless, the full list of dependencies is below. If you do not have them, use pip or pip3 to install them:

            socket, threading, ctypes, hashlib, json, os, sys, time, math, ssl,
            traceback, subprocess, logging, gzip, re, pycryptodomex

Now it is time to launch the server. To do so, open a Terminal window:

            cd <path_to_server.py>
            python3 server.py

If it runs without issue, congratulations! You have gotten the game server up and running! Now there is one further optional setup procedure. This is if you want to run the server as a daemonized process, accessible through a screen session. It uses systemctl (if your server environment uses something else, you will have to figure out the equivalent scripting).

            [Service]
                WorkingDirectory=<path to the server root>
                User=<user you want to run as>
                Group=<group you want to run as>
                ExecStart=/bin/sh -c '/usr/bin/screen -DmS trek /usr/bin/python3 <path to runserver.py>'
                ExecStop=/usr/bin/screen -p 0 -S trek -X eval 'stuff "stop"\\015'
                ExecStop=/bin/sleep 10
                
            [Install]
                WantedBy=multi-user.target

You will likely need to adjust some of the paths from what is shown above. Once you enable the systemd file, working with the service should be as simple as systemctl stop|start|status.

Overview

TrekFilter is an internal, custom packet filter service firewall I wrote to protect the service from some of the stray (or more focused) attacks I saw in the server logs earlier in the server's life. TrekFilter used to be more configurable, but I have taken away the ability to interface with it and turned it into a rigid security structure that performs three (3) important checks on each incoming packet. If a packet fails any one of the three integrity checks, a firewall event is triggered.

1. Packet Size: Some packets have static sizes, and others are mappable over some function (Ex: 8 bytes per module requested). For these packets, an expected size is listed in the Firewall's metadata. Should an incoming packet of a type with a specified size or mapped size not match what is expected, a firewall event is triggered.


2. Unpriviledged Client Sending Priviledged Packet: Certain packets types should only be used by logged in clients. If a client that is not logged in is sending a packet they should not, either they are using an outdated, modified, or bugged client (the server's enforced minimum client supported should prevent this in most cases) or the client has no idea about the service's protocol and is thus likely an attacker. If a client that is not logged in sends a packet that it should not be sending, a firewall event is triggered.


3. Special Characters in Text Fields: Certain packets, such as the message packet, should have printable characters in them. In this case, if those packets contain special characters in that part of the packet, a firewall event is triggered.

A Firewall Event

A firewall event is a response from the filter to any of the above three packet integrity checks failing. When one occurs the following actions are taken to ensure that the offense is promptly dealt with and the (possible) attack is interrupted:

1. The offending user is immediately disconnected.


2. The offense is logged by the server using loglevel [FILTER].


3. A message is sent to the #security channel of the Project TI-Trek discord.


4. * A fail2ban jail monitors the server log for offenses. Too many hits in a period of time causes the offender to be banned.

PGRM: TITREK

The Client Program
File Size: 34614 bytes
* You will need enough RAM free to accomodate the listed size.

APPVAR: TrekGFX

Default Assets Pack
File Size: 30729 bytes
*This remains in archive, and so RAM space is not needed.

APPVAR: TrekSett

Settings Save File
File Size: 585 bytes
* This is moved to RAM when saving settings, so listed size in RAM is needed.

pixelShadow
userMem
Stack

Serial Buffer: 8192 bytes
Server-Side Assets Cache: variable
Splash Screen sprite: 13818 bytes
USB status sprites: ~750 bytes
Log indicator sprites: ~400 bytes
Game State saves: ~650 bytes
Assorted RAM for functions: ~1000 bytes

At long last we have arrived at the fun section -- the part where I turn into an alarmist and spend way too long freaking you out over worst-case usage scenarios that will likely never happen, but that I need to in order to cover arbitrary legal grounds.

This is a compiled C program, which means that on your calculator it is effectively assembly and is thus capable of breaking in quite spectacular and oftentimes amusing ways. For instance, how cool would it be to have your own personal firework-emitter, flamethrower, or nuclear reactor in your pocket, accessible by simply running our program. Unfortunately, however, should the FBI come calling, we will be forced to disavow all knowledge.

Dark humor aside, all official releases of this project are relatively stable, or stable enough that we can guarantee they will NOT trigger a nuclear meltdown of your calculator's circuitry. However, do be aware that improper usage of this software (in a manner inconsistent with the procedures laid out in this document) may cause some adverse effects. This includes but is not limited to: RAM clears, program and appvar corruption, and memory corruption. While we at Project TI-Trek have taken great care to ensure that all components of this project are stable, by using this software you assume any and all risk associated with it and agree to save harmless Project TI-Trek and its affilates.

General EULA for Project Components

All major components of this project--server, client, and bridge--are the property of Project TI-Trek and of their respective developer(s) and are under intellectual copyright as laid out in Section 102 of the Copyright Act of 1976. The software components of this project are all distributed under the terms of the GNU General Public License Agreement v3 (GPLv3), and we assert that any distribution of our software must provide the same license agreement.

By common consent, we also assert that any assets, sprites, artwork, or publications released by us are also the property of Project TI-Trek and their respective designers or creators and that they are also distributed under the terms of GPLv3, with the same requirement that all subsequent redistributions/alterations be governed by the same license agreement.

The default game server provided by us for initial testing, and later sustainable gameplay, is governed by the same license as indicated in the first paragraph (GPLv3). However, be advised that the data files retained by our instance of the server are not. They are closed source, and viewable only by the individual account-holder to which they belong and, in abridged format, by Project staff on the Admin page of the "Web Deck". Be aware that gaining access to files on our server that you should not have access to is data theft, a cyber crime, and will result in prompt legal action.

EULA for Our Hosted Server Instance

As an end user of Project TI-Trek, you are given the privilege of using our server to play the game. In the initial stages, this server is used as a deployment environment to test new feature additions. However, it is also available for sustainable gameplay for project users. We will provide the ability to use our server free-of-charge for the foreseeable future. This means that not only is having an account and playing the game free of charge, but you will also not be asked to buy any special packages to unlock additional features or get more currency, access special areas of the map, or any of the other pay-to-win garbage that has become commonplace on almost every other MMO.

This being said, let me reiterate--the use of our server is a privilege, not a right. We can and will terminate your ability to use our service for violating our Terms of Service. The Terms are quite simple: don't be an asshole. If you are unclear as to what constitutes being an asshole, you probably need to re-evaluate yourself. But in the event you need a more specific breakdown, read on.

Modified Clients: Do not connect to our service with modified clients. We cannot guarantee that the server will support them, and we do not know what kind of advantage using it will give you over other players. Don't do it. It will get you IP banned.

Online Conduct: We expect a level of maturity from users. The server will at some point support a global chat. This means it will likely come with its share of trolls and flamers. Let's have no pretense here: trolling and flaming will result in being IP banned at the very least. Treat others with kindness. All chat messages are logged. A bit of in-game-context trash talking is one thing. Turning our platform into a medium to bully others will result in punitive action, from banning your IP address to contacting appropriate authorities. Simple as that. Don't test us. I work with children for at least part of my living and as a result I take bullying and harassment very seriously.

Now that we have passed the Terms of Service, let's finish the last topic of the EULA--information use. Our server does have moderate forms of data capture, particularly during the registration phase. We collect the following information from users: a username, a password, and an email address. The latter can be omitted should a user wish not to share it; If you do provide it, it will be used to send automated emails for major project updates only, unless you subscribe to other things. This is the only information we collect, as a result, our server is COPPA-compliant, as we collect no personally identifiable information from anyone, let alone a minor. You may upload assets to the "Web Deck" to control different aspects of your LARP experience within this game, but again...this information is cosmetic and cannot be used to identify you in any way. If you are a parent whose child is interested in playing this game and you would like to know more, feel free to contact the Project devs using one of the three options provided in the footer at our Official Website.