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:

portion before the : is the hostname
portion after is the port number

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.

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

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.

play.titrek.us   ==> non-SSL, default port (51701)
play:titrek.us:PORT   ===> non-SSL, port specified (PORT)
s:play.titrek.us   ===> SSL enabled, default port (51701)
s:play.titrek.us:PORT   ===> SSL enabled, port specified (PORT)

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

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

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

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...
TIny_Hacker wrote:
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.

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?
ACagliano wrote:
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.

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:
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.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10
» View previous topic :: View next topic  
Page 10 of 10
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum