Author Topic: Project TI-Trek for the CE nears first demo release  (Read 19237 times)

0 Members and 1 Guest are viewing this topic.

Offline ACagliano

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 919
  • Rating: +32/-2
    • View Profile
    • ClrHome Productions
Re: Project TI-Trek for the CE nears first demo release
« Reply #15 on: December 03, 2020, 01:11:11 pm »
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


Offline ACagliano

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 919
  • Rating: +32/-2
    • View Profile
    • ClrHome Productions
Re: Project TI-Trek for the CE nears first demo release
« Reply #16 on: February 01, 2021, 12:25:31 am »
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. commandblockguy assisted me in testing throwing some invalid packets at it. It's not 100% bullet-proof, but it does a darn good job, being the first project in Python I did solo, as well as the first ever firewall-type thing I've made.
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.

Also, for anyone interested in testing out existing features, please note that in order to access the Web Deck, you must register first with the server using your calculator. This is a feature meant to prevent stray accounts from people who do not intend to play. I may ease that in the future for certain extenuating circumstances, but as of now it stands.

Also also, anyone who previously made an account on the system will need to do so again... during a config change, I deleted the accounts directories. Sorry.

Also also also, 3d frame compositing is planned to happen server side, with the server implementing opengl or pyglet to generate a frame for each client, a compressed RLET sprite, that is then rendered to the client through the standard graphx calls. As of right now that, as well as collision, are the main things that needs to be done before we are ready to start putting out actual playable releases rather than feature showcases.

Also also also also, for those unaware, the client-server will implement an auto-update functionality allowing clients to be served, and then subsequently install and reload, newer versions of the game upon connecting to the server without dealing with the hasstle of doing it manually.

Offline ACagliano

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 919
  • Rating: +32/-2
    • View Profile
    • ClrHome Productions
Re: Project TI-Trek for the CE nears first demo release
« Reply #17 on: July 22, 2022, 10:32:39 pm »
Update 0.0.112
This update is still under development.

I have recently undertaken a complete rewrite of the core of this project. This was done for a number of purposes. Firstly, the game was already coming it at ~37kb in size, and with much of the functionality still to go, that was quite large. Secondly, I wanted to reorganize some of the code. I also wanted to respond to some of Mateo's criticisms of my exorbitant use of global variables in the code by removing them where possible. There are a few other changes as well.

(0) The current size of the build, with much of the old functionality re-written, is at ~16.5k, which is currently half the old size.
(1) Fontlibc is now utilized, as well as a custom font.
(2) Better console implementation. It's a chunk of memory that writes in and cycles out as needed rather than an array of static "slots" for console entries as it was previously. This also means that there is no character limit per log line apart from what the buffer can hold.
(3) Network fallthrough initialization. There are constructors for TCP (currently a null placeholder), Serial, and CEmu pipe mode. The network devices are tried in that order, defaulting to the first successful initialization, or erroring out if all of them fail.
(4) Code uses the latest serial and usb drivers, meaning things should work on Windows.
(5) The progress indicator for client updates is now a loadbar, not some text.
(6) The splash screen and server selection is completely revamped. Splash screen network-up icon indicates the device that is connected, be it an Ethernet cable for TCP, a USB icon for serial, or a pipe for pipes. The server selection screen no longer requires the user to input server IP's... that information is now metadata within the keyfile generated by the server.
(7) Module icons are now part of the ship metadata that is transferred with the "load ship" packet, not part of the assets pack that is sent separately.

Feast your eyes on some screenshots:




And lastly, courtesy of beckadamtheinventor:


The rewrite branch of TI-Trek can be found here: https://github.com/acagliano/titrek-calc/tree/rewrite