Updates

Currently unreleased client updates:
1) Client can now specify what port number it wants the bridge to connect to, using standard hostname with port string syntax. For those who may not know what this means:

Code:

If you do not specify a port number, the default is used (51701). The default port can be changed in the bridge config.

2) For server broadcast messages, the log line on the calculator shows up with a globe icon to indicate server message. Thanks to beckadamtheinventor for creating that particular sprite.


Currently live server updates:
1) For registration, email verification (via a regex) is added... invalid emails trigger registration failure.
2) An automated karma system for users is implemented as a form of bad-practice barring from the service. It works as such:
- User joins, initial karma is set to 10.
- Every packet the server receives from that user increments the karma by 1 (capped at 100)
- Every packet that fails one of two checks causes your karma to decrease by 2:
--- Attempting to send packet types you should only be able to send while logged in when not logged in
--- Sending a text field with special characters)
- A user (or IP) that hits 0 karma receives an IP ban.

Question

What is the simplest, most portable way, in Python, to detect if a service you are attempting to connect to is using SSL or not?

I'd sidestep the issue by one of the following solutions:
* using a protocol which starts as plain binary, and quickly negotiates features before switching to (D)TLS mode if the client supports (D)TLS. That's a STARTTLS approach, used by e.g. FTPS and SMTPS. This mostly protects privacy, but leaves the door open to interference: a MITM attack could make the server believe that a client does not support (D)TLS;
* better: simply deprecating plain binary communication and mandating (D)TLS support
If you want to provide an upgrade path, you could provide two different services on two separate TCP / UDP ports for plain binary connections and (D)TLS-only connections - just like HTTP and HTTPS. This leaves the old protocol subject to the same privacy and integrity issues as before, and clients which support only it will eventually disappear when upgraded for functionality or security reasons.

Hmm. Well this is for TI-Trek.
The custom service can run with or without an SSL context, and I'm trying to have the clients (and by extension the bridge) have a "prefer SSL" config option whereby the bridge tries an SSL connection, and if that fails, falls back to normal.

I suppose the easiest method is to reserve 2 ports for the service, one set by default as the SSL-wrapped context and another as the non-SSL.
The SSL context could run on `port` and the non-SSL on `port+1`.
The service first tries an SSL connection to `port`. If no active service is detected it attempts a non-SSL connection to `port+1`. It would just have to be documented that the service requires 2 sequential ports available, but will only use one of them.

Update

We have only a few more things to implement before the combat beta is ready for testing:
1) Chunk-wise server loading
2) Entity movement
3) Collision
4) Physics related to the above 3
5) Wrapping up lose ends that need to implemented to ensure all legs of the project handle the above fully and properly.

While progress on server-side stuff has slowed, I have been hard at work on documentation and on improving the user interface.
Firstly, the default ship configuration modules have been settled upon (some stats have yet to be added). All players will start with the following systems:
(1) Life Support, (2) Energy Core, (3) Orbital Thrusters, (4) Sublight Engines, (5) Phaser Type Weapon

Secondly, I have added some additional hostname configuration options:
Prepend the entire hostname string with s: to enabled SSL for this specific entry.
Append a custom port number to the hostname :PORT to specify a non-standard port.
Default port is 51701.
The default option for SSL is specified in the Settings menu. If you set Prefer SSL to true, the bridge will always attempt an SSL connection first, falling back to non-SSL if it fails. If Prefer SSL is false, SSL will only be used if the prefix is used. See below.

Code:


And last but not least, the WIP documentation for the game: http://titrek.us/components/downloads/usersguide.php

Update

Small, relatively insignificant feature addition, but two-way communication is now a thing.
Players can talk in the chat from their calcs by pressing the [Prgm] key. See demo below.
As of right now, only single lines are supported (adding more will wrap to the next pixel down and make things look awful. I plan to implement support for wrapping in the log (and perhaps add more log-lines that can be saved).

AWESOME!!!
That is my favorite feature yet: keep up the good work!

Update

Log Updated. Support for text-wrap now a thing. Each log-line has a hard limit of 99 characters (100 including null terminator).
Credit to commandblockguy for routines to wrap text between words, and for routine to count number of lines.
I do also plan to have the act of pressing the [Prgm] key to bring up the chat input UI send a packet to the server, causing all incoming damage to be reduced. We will use some manner of scaled damage reduction to prevent abuse.
Option 1: Enabling the chat input UI sets initial damage reduction to 100% for 30 seconds. Once you hit 30 seconds, it drops from 100% to 0% over the course of the next 30s, meaning that after 1 full minute, you have no more protection. Also, if you cancel the chat prematurely, you get a cooldown (canceled if another player talks in chat).
Option 2: We track how often users use the Chat UI, and if it is used so often (or consistently in combat), the damage reduction you get out of it begins to drop.

Hmm, it appears that chat text wrap isn't quite done...

Well in the input routine is uses a different mechanism. That's an adjustment beck is going to have to make in his input routine.

Update

I recently added a "particles" system to the client, where certain client-side effects can be rendered onto the screen to show certain things, like damage to the ship. The one particle that is currently implemented is a "cracked screen" effect that appears as a form of sprite mask on top of everything else.

That ship reminds me of one from HailStorm...

Nice work, keep it up!

Wait, who made Hailstorm?

I did, and I also submitted the ship to the icon making contest some time back.

Update: Version 0.0.98 is out

Version 0.0.98 brings a few new, experimental features:
1) The multi-line log and chatting system are now in a public beta.
2) There is a "particles" system added to the client. One particle has already been added-- a "cracked screen" effect that appears when your ship integrity is low.
3) There is now a battery icon added to the main status screens. That's a WIP and may be revised... it doesn't show up well--redesigns welcome

Also, in the past few days, I have begun work on taking the "trustworthiness" system that the client uses to deal with "bad packets" and decided to write a self-contained custom packet filter designed specifically for the service. It contains catches for black-listed users, sanity checks for specific packet segments based on their type, and the ability to add your own checks and actions. As of right now, the filter is unimplemented, but when it is complete, it will be able to be enabled or disabled via the config file. (Also, to prevent spending a lot of time in packet filtering checks when a user is well into the game, I may have the filter only actually run on certain packets, like login, register, and other things with input fields.)
For anyone interested, here's the filter's code: https://github.com/acagliano/titrek-server/blob/master/trek_filter.py

Thanks to beck for the code to load external files.

Updates! Updates! Updates!

Version 0.0.99pre is still under development, but here is a few highlights for development so far.

1. Packets for MODULE_STATE_CHANGE, ENGINE_MAXIMUMS, and SETSPEED are now implemented at least in part. They don't check for certain statuses that might prevent the actions yet, but they do update, relay their responses to their calc, and have the effects propagate to your on-calc GUI.

2. The engine/speed configuration interface is now implemented. Accessed by pressing [Log]. You can scroll between your available engines, move sliders around to change your speed, then press [Sto] to engage your new speed.

3. With Debug Mode enabled in the client settings, the calculator now prints the Control Code and size of every packet it receives to the log widget.

4. Server-side, TrekFilter is now formally implemented into the service. TrekFilter is a custom firewall I made for the service, programmed to understand its protocol better than a system firewall could, and able to interact with your system firewall through the use of custom fail2ban jails.

Here a screenshot showing new (and some old) progress.

Updates

A few more 0.0.99-pre updates, and server updates:

1. Client now has support for unpacking assets sent by the server (aspects of terrain and player ship sprites will be sent to clients on the fly the first time they are needed, and cached on the calculator until the calc disconnects). The sprites will be zx7 compressed (but not RLET, since RLET sprites dont support Scaling and Clipping as of yet). When they arrive on the calculator, they will be decompressed to a malloc'd block of memory, then copied there, the pointer to which is stored in either a terrain cache or a player cache.

2. Client server-join procedure is streamlined and debugged. Client does not enter main loop until all parts of the join process succeed. First the client must see that the bridge is up, and that the request to connect to a server succeeded. Second the server must accept the client's version string (if your client is outdated but acceptable, you can still log in and an alert will print to log). Lastly, login must be successful. Once all of these succeed, you will enter the main game loop.

3. TrekFilter has seen some enhancements. It now runs in two modes, exclude mode and normal mode. In normal mode you must specify, in a JSON array within a file called "packet_whitelist.json", all the packet types you want the filter to inspect. In exclude mode, you are doing the same thing in a file called "packet_excludelist.json", except this time is a an array of all packets to exclude from inspection. The filter is distributed in exclude mode, for heightened security.

4. TrekFilter now logs repeat offenses to a file called "trek-f2b.log" in the filter's root directory. I have created a template file, "trek-f2b.conf" which is a Fail2Ban configuration file. I tested it with the command fail2ban-regex, and it appears to work properly. I welcome people to test it in deployment, as I am on the server currently.
Details on TrekFilter can be found here:
http://titrek.us/components/downloads/usersguide.php#Customizing%20TrekFilter

Update to Web Deck (Browser UI)

For logged in users, the Web Deck now has an Interface tab, the left side of which contains a utility for assisting users in creating custom assets packs for the game. (@Mateo, this is why I was trying to get convimg running on Raspbian). This is /s creatively called the "Custom GFX Pack Assistant". One you initialize the custom graphics, you will see 3 buttons: Browse for Sprite, Upload, and Set Default Sprite. The first two are used to upload a custom sprite, the second sets the sprite to the default. Be sure to select the sprite to be modified from the drop down menu on top before doing this.

Once you have either a custom or default sprite set for every sprite on the list, the Builder tools will show up, and you will be able to Build your graphics. Clicking the "Click Here to Build Assets" button populates a convimg.yaml file, then runs convimg to build your appvar, TrekGFX.8xv. Once this occurs, the Build button will dissappear, and be replaced by a "Download Assets" and a "Sync Assets" button. You can then download your appvar.

If you make a modification to your graphics settings, the appvar will be deleted, the Download button will disappear and be replaced by the Build button again. In addition, running "Sync Assets" will create a new custom gfx file (including any edits and reorders to the sprites), pull out the custom file urls from your old one, write them into the new one in the correct spots, then amend your interface as needed. In the future, the Sync button will only show up when there is a need to use it (updates to the assets). This will ensure that users have an easy way to make sure their custom packs remain compatible.

This mechanism is available for testing on the Web Deck to anyone who has already registered on the TI-Trek server. This is done by attempting to log in for the first time from your calculator, then following the directions to register. Anyone interested, this also gives us a good opportunity to stress-test login and registration.

Updates

CLIENT
A few mostly silent updates have pushed our latest version to 0.0.99. This latest version has a few small tweaks.

1) Firstly, the program now implements a minor change to the SRLDRVCE implementation that is believed to fix issues with Windows... The fix was actually within the SRL/USB driver packages, so you will need to update those as well.

2) The text input routine now wraps if you overflow the first line. It should do so without text shadow or graphical glitches but if any occur please report back.

SERVER
1) A few bugs in TrekFilter resolved... TrekFilter now properly handles packets with invalid characters.
2) Client disconnect is mostly stable now... Rather than having the client send a Disconnect packet to trigger the user to disconnect, we simply detect the bridge disconnecting, trigger a custom exception that clears the socket and deletes the client from the dict. This also allows TrekFilter to interact similarly without triggering exceptions. Let me tell ya'll, I have come to love the `raise` command :p.

WEB DECK
1) The User Info and Interface tabs are combined into one tab, "Info and UI". This page contains your user information and lets you edit it, but it also can display your player stats, ship stats, and provides links to two tools, the model uploader and the asset pack maker.
2) The asset pack maker tool deploys convimg to assist users in generating their own asset packs, using the procedures outlined by convimg. You can upload replacement sprites of the same size or direct the tool to use the default. When every sprite is assigned to either custom or default, you can then build your appvar. The Web Deck implements lib-yaml to generate a well-formed YAML, and then runs convimg. This feature has been lightly tested, but to all potential users, feel free to have at it.
3) The ship model uploader tool is similar to the asset helper, in that it allows you to upload your own custom model to define your ship appearance. For now, I will ask people to not use this tool, as there is no size limiter yet. That is part of the purpose of the new 3D Modeling Contest I started in the Graphics section of this forum--to ascertain a good limiting size. The page also implements WebGL to render any existing model you may have uploaded onto the page for quick viewing. That render IS actually the file upload button.

Updates - Textures Needed

Not much has been done on Trek, mostly due to a lull in my level of motivation and work on a few other things. Nonetheless, I/we have arrived at the next step of the development process...the implementation of the rendering logic. We have decided that the rendering will be done server-side through the use of OpenGL or Unity or some other engine, rendering a composite RLET image that will be streamed to the calculator for display. This means that we will be able to have a graphically decent-looking game without the speed loss of a full 3-D renderer on-calc. This will require a re-work of the internal mapping system, to generate map "objects" as collections of polygons for rendering, instead of as point-sprite data.

This also means we are in need of textures. Being that this is for the community, I am opening the floor to anyone who is good with designing textures and would like to have textures of their own design included in the project...
The texture sizes we will use will be 64x64.
we will need textures for:
1) Water
2) Clouds
3) Land (Desert, Green, Rocky, Hot (lava))
4) Types of gas -- Burning, Red Hot, Yellow Hot, Blue/White Hot
Any texture that isn't fulfilled by the community will be fulfilled by open source or public domain textures, or designed by me or an existing gfx dev.
If you have a texture to submit, you can PM me, or use the Project's discord (which can be found in the footer of http://titrek.us). With anything you submit, please also enclose whatever name or username you would like to receive credit under, as well as any usage license you wish to attribute to the contribution.

We also need 1 or 2 original ship models. As with the textures, I'll give anyone who wants to contribute the opportunity to do so, any assets still needed will be fulfilled by open source or public domain. For anyone wishing to submit a model for inclusion, I'll ask that it be in .OBJ format (if someone recommends a different format, lmk), and that aim for models that lean more on the simple side.