Introduction

Thank you for your interest in Project TI-Trek, the first massively-multiplayer online game for the Texas Instruments TI-84+ CE graphing calculator. This project has been a long time coming, and seen a lot of ups and downs, pauses and restarts, start overs, and many painstaking hours of figuring out what I did so wrong that my calculator achieved nuclear fusion while attempting to test it. I owe a debt of gratitude to fellow members of the calculator programming community, particularly Cemetech, whose encouragement and assistance has made this project possible. In particular, I owe an even larger debt of gratitude to a smaller subset of the community who have been actively involved in the development of this project, who will be named later in this document. And last but not least, I would like to acknowledge the inspiration from the genre of space-based sci-fi including Star Trek, Star Wars, Orville, Stargate, and others; My love of this genre was a major factor driving this project.

This project is one of, if not the first of its kind. It is an MMO, in which you can create and customize a virtual spaceship styled after the ones in Star Trek and its spinoffs. The game is set within a randomly generated map, with bodies that move through the sky, stars that experience their life cycle, and more. Not only is the map custom and fluid (although based on a set of pre-computed paths), but we also implement some aspects of real-world physics. Distances mirror those in real space, gravity is accurate, the sizes of objects are accurate. Gravity will affect all non-static entities, and of course stars and black holes and other celestial objects will pose a threat to players in the game, as well as other players.

Dependencies and Installation

Client-Side (Calculator)

There are quite a few things required on your calculator in order to make this game work properly, but rest assured...if you have used CE programs in the past, chances are you already have several of them. Without further ado, here's the list of on-calc dependencies:

Your Computer

As of right now, the game still requires a USB connection to your computer, with some software running to read the incoming serial data and convert it to Internet packets. Below you will find the list of requisite software and hardware you will need:

If you do not have Python3 or pyserial installed on your computer, follow the procedure outlined in the next section, Bridge Setup and Usage.

Bridge Setup and Usage

Dependencies

The Bridge is a Python script written to allow the TI-84+ CE graphing calculator running the USB Serial library to connect to the Internet. Once you have the requisite software and dependencies, using the Bridge is fairly easy.

First, you will need to make sure you have a working installation of python3. Python versions before 3 will NOT work. If you do not already have python3 installed, you can install it by running apt-get install python3 python3-pip, or a similar command on whatever operating software your computer is running. "python3-pip" installs Python's module installer, which makes it easier to add libraries and modules to Python.

Once you've gotten that set up, next you will need to grab the dependencies. For now, the only one is pyserial, a module that adds methods for interfacing with serial devices (like the calculator). If you don't already have it, you can install it using pip3 install pyserial or pip install pyserial...which of the two commands you use depends on how your system installed and aliased python3-pip.

Configuration

The bridge comes with a configuration file, called config.json. This file contains some default settings for the bridge. I'll briefly explain them below:

port
Default port on which to attempt TCP connection. This can be overriden by Client (see Server List)
debug
Determines whether or not the bridge should print detailed packet relay information to the Terminal. Can be true or false.
mode
Determines whether the bridge is seeking an open pipe or an open serial device. Pipes are used for CEmu, serial device for a physical calculator. Can be pipe, cemu, default, or serial.
pipe files (pipe_in, pipe_out)
Paths to files that will be used in Pipe mode to communicate with CEmu. These are ignored for serial mode.

Usage - Pipe Mode

To run the bridge, simply type in Terminal python3 bridge.py, from the directory where the bridge files are located.

            Running in debug mode.
            Out pipe: /tmp/cemu-tocalc
            In pipe: /tmp/cemu-fromcalc

Once you see this, you are ready to launch CEmu (for maximum stability, run CEmu once to initialize the Pipes, then close it again. Also, this requires the USB branch of CEmu by commandblockguy.). Let CEmu open. Run the Client program on CEmu. As it initializes the serial device, the following will show up underneath the existing lines:

            Pipes opened
            ^C to exit.
            Serial listening.

If you see these lines AND ONLY THESE LINES, then you are ready to go. Simply play the game, and everything should work nicely. However, sometimes it may not go so smoothly. As the bridge can be a bit finnicky still, it may bug out, especially if CEmu had still written data to the pipes from the last instance. If the bridge is attempting to send packets at this point, simply exit out of the Client program completely, then close CEmu. This will trigger an exception on the bridge. That's what you want. Start the bridge again and things should be fixed.

Usage - Serial Mode

If you are running in Serial mode, the process is pretty much the same, but the procedure varies slightly. Start the bridge like before, to ensure everything will work properly. When you do so, you should see the following in Terminal.

            Running in debug mode.
            No device detected.

Now plug your TI-84+ CE graphing calculator into your computer. Start the Client program (see Client Setup and Usage for instructions if needed). You should be on the Splash screen (see below) and the USB indicator should be green (if it is red, see the Troubleshooting section). Now run the bridge again. You should see the following:

            Running in debug mode.
            ^C to exit.
            Serial listening.

If you do not see the above lines, again see the Troubleshooting section. If you do, congratulations. You are now ready to play the game.

Client Setup and Usage

Splash Screen

The first thing you will see whenever you run this program is the Splash Screen. This is your gateway to all the features of the program. You will see a screenshot of the splash screen to the right. The screen will consist of 2 main parts, a menu and some indicators. First, the indicators: At the very bottom of the screen you will see a USB indicator. This icon will be green to indicate that the serial interface is successfully set up and will be red to indicate that the serial device failed to initialize. Just above that, is the graphics error indicator, a text error that appears when the version of the graphics you have installed on your calculator is incompatible with the current program version. If you do not see this alert, you can rest assured your graphics are properly loaded.

Program Settings

Running the program for the first time will initialize a settings queue with default options for some of the key functions of the program. This will occur again whenever the settings save file is missing, or its size does not match that of the built settings queue. This also means that program updates that change the size of the queue will cause your settings to be reset. You can see the editable settings in the image to the left.

There are a few aspects of your gameplay experience that can be altered from the Settings page, accessed by hovering the selector bar over the Settings menu option and pressing Enter. In order, they are:

Debug Mode
Causes internal program debug messages to be displayed in the log widget
Prefer SSL
A currently unimplemented setting that causes the bridge to always prefer an SSL connection to a server, if able
Save Login Info
Saves your username and password so you don't have to keep re-typing them
Frame Refresh Rate
A combination of Entity and Chunk refresh rate, specifies how many ticks should pass between requests for new framedata
Packet Limit
A maximum number of packets to process each tick
Network Timeout Limit
A time period of inactivity that triggers a server ping; the server failing to respond to that ping causes the client to assume the network is down and exit the game
Log Display Length
How long individual log-lines stay on screen before they disappear

Server List

Selecting the Play Game option from the main menu brings up the server list, which allows you to choose from a selection of servers to connect to. Any valid form of server identification is acceptable here; hostname or IP address. You may also choose to add an optional port number using the :port notation. For example play.titrek.us or play.titrek.us:51701 are both valid. In subsequent releases, the entire hostname and port string would be prepended with a "s:" to open an SSL connection (eg: s:play.titrek.us:51701 or s:play.titrek.us). This is not necessary if the "Prefer SSL" setting is enabled. The default server, play.titrek.us, is filled in to the first slot by default and cannot be edited or removed; However, the other nine (9) slots may be filled with whatever server hostname, IP, and port you choose. As indicated to the right of the interface, the Enter key selects a server, and the Del key Edits (or Deletes) an existing server (to remove, simply press Enter without entering text when prompted for the server name).

Gameplay

Keybindings
(Menus)
KEYACTION
move option selector up
move option selector down
Enterselect option
Clearexit menu
(Server List)
in addition to Menus (above)
KEYACTION
Deledit selected server
Keybindings
(General)
KEYACTION
Y=enable/disable sensors interface
Windowenable/disable tactical systems interface
Zoomenable/disable main systems interface
Traceenable/disable repair system interface
Graphenable/disable ship inventory interface
Varsenable/disable client debug mode
Clearexit secondary menu, disconnect from server
Prgmbring up message input
2ndfire armed weapon module
Logbring up engines max, speed config
steer ship down
steer ship left
steer ship up
steer ship right
Keybindings
(Main Systems Overview)
* Overwrites the normal keybind when on this screen
KEYACTION
Statshow module details
Clearhide module details
Modetoggle selected module online/offline
???this is a placeholder
* scroll up through modules
* scroll down through modules
Keybindings
(Tactical Systems Overview)
* Overwrites the normal keybind when on this screen
KEYACTION
Statshow module details
Clearhide module details
Modetoggle shield module/arm weapon module
* scroll up through modules
* scroll down through modules
Keybindings
(Speed Configuration)
* Overwrites the normal keybind when on this screen
KEYACTION
Storeconfirm change
* scroll up through engines
* scroll down through engines
* adjust speed slider left
* adjust speed slider right

Viewscreen & Ship Interior

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.

Main Systems Overview

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].

Tactical Systems Overview

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.

Speed Configuration

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).

Custom Graphics Packs

Making Your Own Graphics Pack

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!

Importing a Custom Graphics Pack

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.

Hosting a Server Instance

Want to run your own TI-Trek server? The reasons are plenty. Want liberty to modify the server to a different play-style, have your own missions, or just build your own community there? It is possible to do so.

First things first, just clone the repository for the server!

            git clone https://github.com/acagliano/titrek-server

Now that you have the current build of the server, now comes the time to give it a /home! No pun intended; That is precisely what you must do. You must create a directory in which the files for the server will go. Of course, if you clone the repository, you will have one. You can proceed to move that directory to the place where you want the server to be on your computer. Or you can...you know... clone it there to begin with.

Configuring the Server

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",
            "ssl":{ "enable":true, "path":"ssl/" },
            "firewall":{ "enable":true, "path":"filter/", "security-level":"default" },
            "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.
ssl
A dictionary of configuration options for SSL (see below).
firewall
A dictionary of configuration options for the TrekFilter service firewall (see below).
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).

SSL

enable
Specifies if the server should run with or without SSL.
*For now, SSL is not supported, and a flag in the code itself will force this option to False*
Accepted: true | false
path
Specifies the directory in which SSL files (certificates and keys) can be found.
Accepted: A string representing a folder path. Trailing slash required. The folder need not exist.

Firewall

enable
Specifies if the TrekFilter service firewall should be enabled or disabled.
Accepted: true | false
path
Specifies the directory in which the firewall's files are located.
Accepted: A string representing a folder path. Trailing slash required. The folder need not exist.
security-level
An option that controls what modes and packets the firewall checks. (See Configuring TrekFilter)
Accepted: "low" | "medium" | "high" | "default" (default is an alias of medium)

Player

path
Specifies the directory where the server stores user directories.
Accepted: A string representing a folder path. Trailing slash required. The folder need not exist.

Space

path
Specifies the directory where the server stores map data.
Accepted: A string representing a folder path. Trailing slash required. The folder need not exist.

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

Running the Server

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=/home/trek/server/
                User=trek
                Group=trek
                ExecStart=/bin/sh -c '/usr/bin/screen -DmS trek /usr/bin/python3 /home/trek/server/server.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.

Customizing TrekFilter

- Overview -

For those of you familiar with iptables, pf, or other similar style of firewall, the setup of TrekFilter will be somewhat familiar to you. However, instead of a series of command line flags and options, you are utilizing a json dictionary. This dictionary contains: (1) the name of the check to perform, (2) the method to call to conduct the check, and (3) the method to call should the check fail. Think of this as similar to the iptables conntrack module and chains. TrekFilter can check both connections and packets. Some of the checks determine if a user is trusted, untrustworthy, or blacklisted; Others check the sanity of packets. The filter also contains a jump table of actions that can be the result of triggering one of TrekFilter's state checks. These actions are: (1) drop packet but inform user that packet is invalid, (2) drop packet silently, (3) refuse connection, (4) add connection to greylist, (5) blacklist connection. The filter also writes repeat offenses to a logfile that is set up to be readable by fail2ban. More on that later.

- Built-In Checks and Responses -

TrekFilter has a few built-in packet check functions that already get loaded as a default ruleset. If you leave TrekFilter enabled in your configuration file, this ruleset will be loaded the first time you start the server and you won't really have to worry about it. Below, I will elaborate on some of the built-in packet checks and responses to those checks.

Packet Checks
blacklist
This check simply makes sure that the connecting IP is not on the blacklist
Default Fail Responses: drop_packet, refuse_connection, fail2ban
order
This check makes sure that a user who is not logged in is not attempting to send packets that only logged in users should. This indicates the sender is not following the Trek protocol and thus may be a malicious or stray connection.
Default Fail Responses: set_offender, drop_packet
sanity
This check makes sure that packets that would result in directory traversal or file creation are sane. For the most part, this means no special characters. *This requires a packet specs file*
Default Fail Responses: set_offender, inform_user, drop_packet
threshhold
This check looks to see if the current IP's trigger count has passed a hitcount.
The hitcount is 3 in High-Security mode, 5 in Medium-Security mode, and 10 in Low-Security mode
Default Fail Responses: drop_packet, blacklist_ip
Filter Actions
drop_packet
Clears the data segment of the packet.
set_offender
Logs the IP address and hitcount to a list of firewall events. If the IP already exists in the list, the hitcount is incremented.
inform_user
Sends the user (calculator) a packet of type [Message] (chat message) that reads: "Packet dropped by server: Invalid"
refuse_connection
Calls the .close() method on the connection descriptor immediately.
blacklist_ip
Adds the current IP to the blacklist. At this point, the IP is barred from the service (note the blacklist check).
fail2ban
Logs an attempt by a blacklisted user to connect to a logfile that is monitored by fail2ban. (This requires user-end configuration).

- Filter Security Level -

TrekFilter has three possible security modes: Low, Medium, and High. It also has a fourth "Default" option but that is an alias of Medium. These determine how the filter processes incoming packets.

Filter Security Levels
Low
The filter will not inspect any incoming packets except the ones you list in a JSON array in a file called: packet_whitelist.json. In addition, the filter will stop inspecting packets from a client once the client logs in. Also, it takes 10 hits against the firewall for an IP to become blacklisted.
Medium | Default
The filter will inspect every incoming packet except the ones you list in a JSON array in a file called: packet_excludelist.json. In addition, the filter will stop inspecting packets from a client once the client logs in. Also, it takes 5 hits against the firewall for an IP to become blacklisted.
High
The filter will inspect every incoming packet except the ones you list in a JSON array in a file called packet_excludelist.json. In addition, the filter will continue inspecting packets from a client, even after they log in. Also, it takes 3 hits against the firewall for an IP to become blacklisted.

If the files listed above do not exist, they will not be created; However an empty array will be generated, causing the filter to either ignore everything or inspect everything, depending on the security level. In this way, setting the filter to a Low security level, and not specifying a packet whitelist effectively disables the filter.

- Packet Specs -

Packet specs are an essential part of the "Sanity" check because they tell the filter what constitutes a sane packet. The specs are imported by dropping a file called "packet_specs.json" into the filter's root directory. The filter does not require it to run; In its absence, it will simply disable the sanity check. This file defines the contents of specific packets so that the sanity check can work with them. **Note: This section of the Firewall is still under development and the protocols are subject to change.** Below, you will see the file implemented within the instance of the Server running here. You may simply copy the text below, and paste it into the aforementioned file in the correct place.

            {
            "2":{"segments":["special_chars", false, false]},
            "3":{"segments":["special_chars", false]}
            }

Note that you need only define packets with components that require checking. In this case, we check the contents of the [Login] and [Register] packet (types 3 and 2, respectively), making sure the usernames contain no special characters. The other segments correspond to the other portions of the packet ([Register] has three packet segments, [Login] has two). A packet segment with a value of false is skipped. Also any packet that is not listed here is also skipped. In this case, the username segment of the packet is checked using the built-in "special_chars" method.

- Console Control -

You can view information about the Firewall in its current state by using the following command in the server Console:

            fw info     # view version, status, mode, ruleset, and hit-lists

For security, it is not allowed to permanently disable the filter, or change its mode from the Console; This requires editing the config file for the server and restarting.

- Importing Custom Checks and Responses -

The TrekFilter directory will have two directories created inside it: (1) actions, and (2) modules. These directories are for new behaviors you would like to add to the filter. Please follow the procedure listed below...failing to do so will result in TrekFilter throwing an exception and possibly crashing.

  1. Download the template file provided here. Edit the "main()" function to do the actions you want, and rename the file if you desire.
  2. Place the file you just edited into one of the two folders created in the root directory of TrekFilter. If you are importing a packet check, the file goes into the "modules" folder. If you are importing a failaction, the file goes into the "actions" directory.
  3. The file name of the file you have created (minus the .py extension) defines the method you are importing. For example, if the filename is "mycheck.py", then the name of the new method you can use in the firewall is "mycheck". This is the case for both packet checks and failactions.

To use a new module or action you have placed into the approprate folder, you will want to edit the file filter_rules.json in the firewall's root directory. You will want to add a new line of json to the place in the firewall's processing where you would like your new rule to resolve. The existing ruleset is:

            [
                {"check":"blacklist","method":"blacklisted","failaction":["refuse_connection","fail2ban"]},
                {"check":"order","method":"packet_order","failaction":["set_offender","drop_packet"]},
                {"check":"sanity","method":"sanity","failaction":["set_offender","inform_user","drop_packet"]},
                {"check":"threshold","method":"threshhold","failaction":["blacklist_ip"]}
            ]

As you can see, "method" is the function to call (or file to load) to analyze the packet. By contrast, "failaction" is an ARRAY of functions to call (or files to load) in response to a FAILED packet check.

Let us assume, for example, that you have added 1 new check, check1.py, and 1 new action action1.py and placed them into the "modules" and "actions" directories, respectively. Let us also assume that you want to add a new packet check, called customs that uses your custom packet check, and responds to a fail by calling the built-in refuse_connection method as well as your custom action. Let us also assume you want to place this rule after the existing order check. Here is what your new ruleset should look like:

            [
                {"check":"blacklist","method":"blacklisted","failaction":["refuse_connection","fail2ban"]},
                {"check":"order","method":"packet_order","failaction":["set_offender","drop_packet"]},
                {"check":"customs","method":"check1","failaction":["refuse_connection","action1"]},
                {"check":"sanity","method":"sanity","failaction":["set_offender","inform_user","drop_packet"]},
                {"check":"threshold","method":"threshhold","failaction":["blacklist_ip"]}
            ]

This is important! Follow these directions precisely or you may break your firewall instance. Do not do these things if you do not know what you are doing. If you are having difficulty, ask for help!

- Fail2Ban -

This firewall outputs repeated attempts to connect by blacklisted users to a log file, trek-f2b.log in the firewall's root directory. It is possible to create a custom regex for use with Fail2Ban to interpret these loglines. This documentation will not provide instructions on how to create a Fail2Ban jail--please consult the appropriate wikis and man pages for that. However, I am making available a configuration file that may be placed into the fail2ban/filter.d directory, defining the regex that can read TrekFilter's logfile. That configuration file can be obtained here. Please be advised that this regex is currently untested in deployment; Please report back on any issues or successes you encounter.

Troubleshooting

Having a problem with one of the parts of this project? Chances are we encountered some of the same issues during testing already. Before you resign yourself to failure, have a gander at this list of issues we encountered, and suggestions to resolve them based on how we fixed it. Some of the information here might help you out.

Bridge Fails to Detect Physical Calc
  1. Is your calculator's USB port malfunctioning?
  2. Is your SRLDRVCE and USBDRVCE up to date?
  3. Is your settings savefile outdated? This can cause problems.
    Delete the appvar TREKSETT and try again.
  4. Is your computer running Windows? The serial/usb drivers don't play well with Windows. Wait for a fix.
Bridge Fails to Detect CEmu Pipes
  1. This is a known issue with CEmu support. The best solution at present is to keep starting CEmu, running the Client program, then quiting and closing CEmu with the bridge running until it detects the pipe files. After that, follow the directions for using the bridge normally.
Custom GFX Version Error
  1. You have built custom graphics with an outdated custom YAML file, or the pack you are using is outdated. Custom graphics verify version number using image counts. Download the template YAML linked in the "Custom Graphics" section and add the missing sprite(s).
Custom GFX Image Mismatch
  1. This is related to the previous issue, and it is another manifestation of a version error. Since custom graphics check for version using sprite count, two graphics versions with the same number but different orders won't be detected, and sprites will show up where they don't belong. To fix, follow the procedure in the previous issue.

Technical Info

In this section we will review some under-the-hood information about this game, including memory requirements, file creation, and more. It should go without saying that this game requires a lot of memory to run.

Files Used or Created

PGRM: TITREK
The Client Program
File Size: 24366 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.

RAM Areas Used

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

Credits

I would like to thank the following individuals for their significant contributions to this project:

Client-Side Programming
(Lead) Anthony Cagliano
Adam "beck" Beckingham
commandblockguy
Server-Side Programming
(Lead) Adam "beck" Beckingham
commandblockguy
Anthony Cagliano
Bridge Programming
commandblockguy
Sprite Designers
Bailey Conrad
Ampersand
Pieman
TurquoiseDrag0n
Donators
Adam "beck" Beckingham
Pieman
ACagliano
Zeda

Legal Notices

Disclaimer

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.

Software Licenses

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.