Omnimaga

Calculator Community => Other Calc-Related Projects and Ideas => Topic started by: ACagliano on November 19, 2017, 09:32:31 am

Title: Project TI-Trek for the CE nears first demo release
Post by: ACagliano on November 19, 2017, 09:32:31 am
I've been talking about it for a while. Asking questions about how to do this or that. But without any real progress.

Scroll down for a question I have about ship/terrain assets.

Well as of the past week or so, that has changed. I sat down, turned off my Minecraft (with great internal suffering) and got to work. Over the past week, I succeeded in creating the shields, the major non-combat systems, damage reception, power control, and more.

At this point in time, there is no networking implemented and the file is quite large (~15kb). Much of this is due to graphics and AI calculations which, when networking is implemented will no longer be present. The intent is also to hold graphics server-side and send the relevant sprites to the calc during runtime, which will be saved in a temporary assets file. Also, as Kerm told me that CALCnet will likely not be a thing for the CE due to differences in network protocol, I'll probably use the existing USB protocol on the CE with a computer side program to send data to the hub, which would have the ability to interact with connected CE's and CALCnet, allowing the color and monochromes to play on one server. I'll also open source this when done to allow it to be ported to the CSE.

But more on that later. I have very little left to do before I can release a demo. Basically just AI ship control, player ship control, rendering the viewscreen, and firing. In the scope of what I've done already, that shouldn't take too long.

Now, feast your eyes on some screenshots:
(http://clrhome.org/startrek/gallery/startrek_0.0.16alpha.gif)

(http://clrhome.org/startrek/gallery/startrek_0.0.16_mains.gif)

(http://clrhome.org/startrek/gallery/startrek_0.0.16_power.gif)

(http://clrhome.org/startrek/gallery/startrek_0.0.16_shields.gif)


The Question:

This game is played in a virtual 3D world. The map objects and ships are technically 3D. My question is, would it be better, both in terms of rendering speed and data size, to create several versions of each sprite, to view the object from different angles, or to create full 3D models for the ships and the spherical map objects (the irregular objects will be rendered differently). For full 3D, I could make 16x16x16 models for each item, leading to an overhead of 4096 bytes per object, which if it's in an external assets file on the CE isn't a major issue. When this game eventually gets backwards-ported to the monochrome calcs, we'd be talking about 512 bytes per object.

If the common consensus is the latter (3d models), is there someone here who has experience making them?
Title: Re: Star Trek Multiplayer for the CE nears first demo release
Post by: ACagliano on November 23, 2017, 10:27:50 am
Update

An alpha demo is almost here. Got pretty much all the basic combat systems complete. Just have to add in phaser/torpedo sprites, rendering, and target tracking. Then work out any bugs in the firing/movement/rendering system. Here's an image with the demo opponent, a Borg sphere, rendered on screen.
(http://clrhome.org/startrek/gallery/startrek_0.0.21.png)
Title: Re: Star Trek Multiplayer for the CE nears first demo release
Post by: ACagliano on August 18, 2018, 01:18:53 pm
UPDATE -- 0.53 alpha-ish

Ok, update time!!
This game took a bit of a hiatus, as many of my projects do from time to time because of real life, skill building, and other stuff.
However, I did some code reorganization at the start of the summer, then set out on an endeavor to have a working demo of basic combat (single player) by the end of the summer.

Attached is the current pre-demo release. This version is functional but has no AI or rendering engine yet. That is what I'm working on now... 3d rendering, weapons and targeting, then wrapping everything up, optimizing, and releasing. That being said, I'll talk about some of the cool features already implemented:

1. Ship Status Icon
At the lower, left side of the screen there is an icon that shows your ship and your shields. As your ship takes damage, you'll notice the shields first. They start off electric blue, then degrade to yellow, then to red. Additionally, within the ship itself, which is normally grey, sections of the ship will turn red as systems are damaged. Hull integrity causes a small filled red circle when it reaches <50% in the saucer that gets larger when hull integrity fails. In addition to that, the nacelles turn red when the warp drive is below 50%, the aft of the ship turns red when impulse, life support, or the warp core fall below 50%. As of now, this icon is locked to an Enterprise-ish shape, as are the indicators. If/when I allow icons to be customized, I'll have to modify this to match.

2. Warp Core Failure
When the warp core system is damaged to less than 25% health, the program begins attempting to trigger a warp core breach. The odds of a core breach are 1 / system health * 10. So, for a warp core at 24% health, the odds of a breach occurring are 1/240. If the warp core is at 10% health, the odds become 1/100. Once a breach is successfully trigged, a timer begins. You get 1000 game cycles to avert the breach or your ship is destroyed. I have yet to clock how long that actually is. You can avert the breach by (1) Repairing the warp core to above 50% health (see Repair), or (2) Pressing the [Del] key to eject the warp core. The ejection occurs and spawns a critical warp core behind your ship, on a slow trajectory moving backwards (relative to you). Doing so immediately stops all power flow to your ship, meaning if you have no auxiliary power module installed or no warp core to refill the slot with, you'll lose power fast! The counter continues from whatever it was at when you ejected it, and then explodes in a MASSIVE detonation that can significantly damage your ship if you're too close.

3. Power, Inventory, Core Breach, Life Support Alerts
When any one of these four things need attention, there is an alert dedicated to them. The power icon appears when any module is unable to fulfill its power requirements, meaning that your power generation is no longer effective enough to keep your ship powered. This means that it is time to (1) Bring unessential systems offline, (2) Repair your warp core (the health of your core determines your ship's power output), or (3) Switch to an auxiliary power module (if installed).
The Inventory status alert appears when an active torpedo module has exhausted it's supply of selected torpedoes (unimplemented).
The core breach alert appears when a warp core breach has been triggered, and will disappear if the core is repaired or ejected.
The life support alert appears when the life support system hits 0% health or is turned offline. If life support is not repaired and brought back online within 2000 game cycles, your crew dies and you lose.

4. Repairing Your Ship
Any module may be repaired, including shields and hull integrity. Repairing a module stops it from being supplied power, stops it from functioning, and expends a lot of power to repair it. Every 5 game cycles, the module draws its current power default and gives itself 1 unit of health. For a starting ship, this means that it takes a module 250 game cycles to fully repair to 50 health, and costs 250 power to do so.
* A repairing module is treated as OFFLINE. This means that if you are repairing your shields, they will not function. If you're repairing your hull integrity, it will not give you extra damage protection. If you are repairing your warp core, it will stop generating power. The only modules that will function while being repaired are your engines (warp drive/impulse) and your weapon systems.*

5. Damage Calculation
Damage in game occurs as two factors: shield damage and hull damage. Phasers or other energy weapons deal more damage to your shields than to your hull, while torpedoes will deal more damage to your hull than your shields. Notable exceptions will be the Narada torpedoes that will deal staggering damage regardless and disruptor phasers, which will be somewhat balanced against both.
First, the current health and current power configuration of your shields are calculated and multiplied by the shield's damage resistance value. This is the amount of damage that your shield is capable of repelling at 100% health and 100% power. To start, this number is 5. Most weapons you'll encounter at first will deal 1-3 damage. If your shields are at, for example, 60% health, they will be capable of blocking only 3 damage. If you were to then set your shields to use 200% power, they would become able to block 6 damage. In this way, you can boost your systems to help you out in combat, but at a cost (see Boosting).
The shield damage value of the weapon is subtracted from the shield's health, resulting in shield damage. The calculated damage resistance value is subtracted from the weapon's hull damage. If this value becomes 0 or less at any time, we stop calculating damage.
We then read out the damage resistance value of your hull integrity module. If hull integrity is 50% or higher, that number is subtracted from the weapon damage. If hull integrity is <50% but above 0%, the damage resistance becomes 0. If hull integrity is 0%, the module's damage resistance is added to the incoming damage. This emulates a damaged hull becoming less effective at protecting the interior from damage. Any remaining damage is applied to a system currently chosen at random, but eventually to be chosen based on the direction of the incoming weapon compared to the direction of your ship, allowing you to target specific areas.

6. Boosting Systems
Any system, except the warp core, may be boosted to allow it to perform more effectively. Here's a list of what boosting a generic system will do:
Shields: Increase damage resistance
Hull integrity: increase damage resistance
Life Support: unable to be altered
Warp Core: unable to be altered
Warp Drive: Increases maximum attainable warp speed (to a max of +5 speed)
Impulse Drive: Increases maximum attainable impulse speed (to a max of +2 speed)
Sensors: Increases maximum sensor range/targeting range
Phasers: Increases phaser damage
Torpedoes: Increases torpedo speed
Transporters: Increases transporter range
* A boosted system will use power at a faster rate than it is being recharged, and eventually run out of power and stop working. Use boosting sparingly. *

7. Warp/Impulse Speeds
The ship has 4 average impulse speeds:
1 field / cycle = 1/4 impulse
2 fields / cycle = half impulse
3 fields / cycle = 3/4 impulse
4 fields / cycle = full impulse
certain ship types and a boosted impulse module will allow additional speeds < 10.
A damaged impulse module reduces the maximum impulse speed.
The ship has warp factors 1-9, with speeds in between the major warp factors. Each warp factor increases the speed by it's factor.
Warp 1 = 10 fields / cycle
Warp 2 = 12 fields / cycle
Warp 3 = 15 fields / cycle
Warp 4 = 19 fields / cycle
Warp 5 = 24 fields / cycle
Warp 6 = 30 fields / cycle
Warp 7 = 37 fields / cycle
Warp 8 = 45 fields / cycle
Warp 9 = 54 fields / cycle
boosted warp core max = 59 fields / cycle
Intermediary warp factors supported, for example, 16 fields / cycle equals Warp 3.5.
A damaged Warp Drive module decreases the maximum speed to a minimum of 10 (warp 1) unless the module is completely destroyed.

(http://clrhome.org/startrek/gallery/0.50_statusicon.png)
(http://clrhome.org/startrek/gallery/0.53_tactical.png?1)
Title: Re: Star Trek Multiplayer for the CE nears first demo release
Post by: ACagliano on August 27, 2019, 10:27:22 am
Hey all. It's been a while. I haven't posted much in terms of this project here, but it's been ongoing.

1) The project page at http://clrhome.org/startrek now has a sister: http://titrek.us. This is mostly due to me wanting to host the site for it on the same server as the game itself.
2) There is a web frontend for the game server: http://srv.titrek.us. This lets players log in to their game account to change their in-game names, email, password, sub to notifications about the game, alter the appearance of their ships/etc. The frontend is in the very early stages, but it's coming along.
3) I'm no longer working solo on this project. A number of people are assisting (or involved somehow) in this project. I am tackling the client side and web frontend of this thing pretty much solo (with beckadam and whoever else is good with raycasting helping with the rendering aspect). For calc=>computer=>server communication, we are awaiting the functionality of the TI USB Device lib. For the server itself, me, GregsAStar, and beckadam are working on the Python. The save files are JSON, the server will be running on UDP 1701 (for the registry number of the Enterprise). I am also hosting this entire project... git for the projects, the websites, and the game server itself, on a Raspberry Pi 4.
4) Additional help has come from EaghanScarlette and Pieman in the form of sprite work, and Eaghan has agreed to assist me with formulae for the behavior of certain celestial entities, to make the behavior of space, and forces like gravity, as accurate as possible.

Screenshots available at: http://titrek.us/gallery.php
Pre-alpha (GUI test, no real functionality yet) available at: http://titrek.us/downloads.php
Title: Re: Star Trek Multiplayer for the CE nears first demo release
Post by: Xeda112358 on August 27, 2019, 10:30:31 am
This is sounding quite cool!
Title: Re: Star Trek Multiplayer for the CE nears first demo release
Post by: ACagliano on October 01, 2019, 05:39:01 pm
UPDATE

Progress has been made on the User Interface for TI-Trek. Here are some screenshots:
The Main Systems module overview screen
(http://titrek.us/gallery/0.86_mainsscreen.png)

The Tactical Systems module overview screen
(http://titrek.us/gallery/0.86_tacticaloverview.png)

The module configuration/info popup, accessible by pressing [Enter] on chosen module
(http://titrek.us/gallery/0.86_moduleinfo.png)

Some changes to the power system setup also. Module efficiency (how well it performs its task) will be a function of module battery charge (current power level * 100 / max power storage) multiplied by power draw setting (set power draw / base power draw). Power draw meaning how much power a module will take from its source (core, auxiliary, or internal reserve) every power cycle. Each module will also have a maximum draw, which is the maximum amount of power a module may be set to draw before the module incurs a damage penalty every power cycle. For instance, if the module's max draw is 8 and you have it set to 10, the module will take 2 points of damage every time it draws power. This means you can set a module to use as much power as you want, to super-boost it, but keep in mind the higher you set this, the faster the module takes damage.
Title: Re: Star Trek Multiplayer for the CE nears first demo release
Post by: Jonson26 on October 23, 2019, 04:43:46 am
This looks really nice! I especially like, how you use graphics, to make what's essentially a simplistic interface look fancy. These screenshots remind me of some Amiga games. BTW, do you plan on doing a 68k port?
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano on June 08, 2020, 05:43:56 pm
UPDATE

Project TI-Trek has now been successfully compiled with full USB support... using srldrvce. Due to wonkiness in CEmu's usb support, it is no longer possible to test networking on the emulator (the lib cannot initialize the driver properly). I will need to move to on-unit testing for the remainder of client-side development of this project. I have gotten written the ntwk_Login(), ntwk_Register(), and ntwk_Disconnect routines, which are the first aspects of gameplay that will be tested. While I have been hard at work on client-side things, commandblockguy has been working on a USB=>IP bridge similar to the one Kerm devised for gCn over DirectUSB. And last but not least, beckadamtheinventor has been hard at work developing the server side of things... from map generation to control codes and saving/loading data. For those interested, the server is written in Python, runs on port TCP 1701 (the registry number of the Enterprise), and uses json for long-term storage. It stores connection descriptors to an array of Client objects, which also contain the IP address, username, and some more information about the connected user.

The game will implement semi-accurate space physics. When the map generates, the server pre-generates some paths for celestial bodies using formulas for things like gravity and inertia. Those objects will follow those paths every tick, scaled to the time-rate of the game. In addition to fluidity in space (meaning planets, starbases, etc will not be in exactly the same spot every time you look for them), other objects will pose a threat... black holes will exist and end your journey very fast. Stars will tick their life cycle and then die in a manner determined by their size. Major celestial events, such as star death or planet destruction will result in a path-adjustment for entities within gravitational range of the changed section.

Also, after discussion with beck, another feature will be added to the game, called a synthesizer. This component will allow you to interact with materials you own on a molecular level to enhance them in certain ways. For example, say you place a piece of tempered steel into the synthesizer. You can then select from reserves of any type of element, and the properties they enhance/detract from will most reflect their actual chemical properties (toughness, deflection, malliability, heat resistance, etc). Say you choose to combine the tempered steel with a type of element that increases toughness but decreases heat resistance. You would wind up with steel (hull plating, for instance) that provides a boost against projectiles and physical impact, but is damaged more by heat sources, phasers, and the like. You could also, for instance, infuse your hull plating with a mineral that enhances magnetism, which in turn enhances your shield deflection. And if you attempt to combine unstable materials, you could, for example, wind up inflicting feedback damage to an attacking enemy, but also winding up with vastly increased damage to your own ship.

For anyone wishing to have a look at the code-base so far (yes, it will need some optimization), here it is. I will say, in my opinion, at least the network handling is remarkably well-organized... for what I usually do.
https://github.com/acagliano/titrek-calc
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano on September 10, 2020, 12:23:21 am
A few teasers from the upcoming 0.0.94 release.

1) Custom graphics packs supported. To indicate that the graphics pack is custom made (so the client doesn't do a normal version check), you use the following settings in convimg, in addition to the normal ones.
Code: [Select]
lut-entries: true
header-string: "\xff\xff"
Special thanks goes to MateoC for implementing the `lut-entries` option in convimg... it simply moves the offsets LUT into the appvar itself, rather than leaving it defined in the program. This allows the program to load any array of sprites as assets. You will still have to keep the same sprite order, however. Refer to the link I posted previously for details.

2) The splash screen has been completely reworked.
(http://titrek.us/gallery/stills/0.0.94_splash.png)
The menu interface is cleaner, and the networking status is indicated by icon now, instead of by text. A green USB icon indicates that the serial device is ready, a red icon indicates some error. If we implement nanotube, or internetce support, an icon will indicate if the program is preferring that connection.

3) The program now alerts you on the splash screen if your graphics version is incompatible.
(http://titrek.us/gallery/stills/0.0.94_splashwitherror.png)
The incompatible graphics is triggered in one of two ways:
 a) You are using a default sprite pack and the version header does not match the one set within the program's `reqd_version` array.
 b) You are using a custom sprite pack (version string 0xff, 0xff), and the number of sprites in the LUT does not match the number of sprites in the program build.
Either of these being the case causes the above alert to show up, and the "Play Game" menu option to just return you to the main menu.

All splash screen and error/alert icons are built directly into the program to ensure they are available... the asset pack only supplies stuff used for the game.
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: Xeda112358 on September 10, 2020, 06:39:34 am
Nice work :O
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: Eeems on September 14, 2020, 12:19:56 pm
Looking good :)
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano on September 27, 2020, 10:33:01 pm
Thanks guys!

Update - v0.0.95
Planned to make this the full combat beta, but some security enhancements to the server and the whole setup make it necessary to release a client and bridge update before then.


NEW FEATURE - Client-Side Server List
As of right now, the server to connect to (through the bridge) is no longer controlled by the bridge's config file... it's controlled by the calculator itself.
(http://titrek.us/gallery/stills/0.0.95_serverlist.png)
Slot 1 is set by default and cannot be edited. Slots 2-10 are blank and can be edited (so that the game can connect to other hosted instances of the server).

The client adds 2 new packets, CONNECT and DISCONNECT.
Connect: Instructs the bridge to open a tcp socket to the server or host name following the control code in the serial packet.
Disconnect: Instructs the bridge to close the current socket.
* So long as the calculator does not unplug or disconnect from the bridge, you can connect/disconnect/reconnect without needing to restart the bridge. *
* Special thanks to commandblockguy for implementing this change. *

NEW FEATURE - On-Calc Mini-Log
The calculator has a 4-line mini-log, with each log-line buffered to 50 characters. This log can display errors, info, debug messages, and server broadcasts. The widget has variable height based on how many of the 4 lines it needs to display, and also remains on the screen for a configurable time. Default is 100 ticks. Any time a new message is written to the log, the clock resets.
(http://titrek.us/gallery/demo-vids/0.0.95_showvariablelen.png?1)
And here is the new Settings interface to change the log timeout:
(http://titrek.us/gallery/stills/0.0.95_settingsupd.png)

NEW FEATURE - Server Supports SSL
This may have been posted in this thread earlier, but the server is written with an optional SSL context. This can be enabled in the server config. The actual handling of certificates and renewal is not something the server does, so anyone hosting an SSL instance will need to handle ensuring their SSL config is up to date. The SSL path is also configurable, it just needs to be readable by whatever user is running this service.
*As of right now, the bridge does not support SSL, so any SSL servers will be unable to be connected to.*

NEW FEATURE - Verification-Based Authentication
As an attempt to dissuade connections to this service that are not from the calculator, such as random port probes or script kiddies, the server now implements a code-based verification system. When a user registers an account, an 8-digit code is generated and written to the user's account file, as well as sent to the calculator for display. You will be required to log into the web deck and input your verification code before you will be able to log in to the game server. This will allow us to filter unsolicited connections, as well as remove any anomalous user accounts created.
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: Eeems on November 17, 2020, 09:06:38 am
Thanks guys!

Update - v0.0.95
Planned to make this the full combat beta, but some security enhancements to the server and the whole setup make it necessary to release a client and bridge update before then.


NEW FEATURE - Client-Side Server List
As of right now, the server to connect to (through the bridge) is no longer controlled by the bridge's config file... it's controlled by the calculator itself.
(http://titrek.us/gallery/stills/0.0.95_serverlist.png)
Slot 1 is set by default and cannot be edited. Slots 2-10 are blank and can be edited (so that the game can connect to other hosted instances of the server).

The client adds 2 new packets, CONNECT and DISCONNECT.
Connect: Instructs the bridge to open a tcp socket to the server or host name following the control code in the serial packet.
Disconnect: Instructs the bridge to close the current socket.
* So long as the calculator does not unplug or disconnect from the bridge, you can connect/disconnect/reconnect without needing to restart the bridge. *
* Special thanks to commandblockguy for implementing this change. *

NEW FEATURE - On-Calc Mini-Log
The calculator has a 4-line mini-log, with each log-line buffered to 50 characters. This log can display errors, info, debug messages, and server broadcasts. The widget has variable height based on how many of the 4 lines it needs to display, and also remains on the screen for a configurable time. Default is 100 ticks. Any time a new message is written to the log, the clock resets.
(http://titrek.us/gallery/demo-vids/0.0.95_showvariablelen.png?1)
And here is the new Settings interface to change the log timeout:
(http://titrek.us/gallery/stills/0.0.95_settingsupd.png)
That's pretty cool :) Security is important, I'm glad you're thinking it through now.

NEW FEATURE - Server Supports SSL
This may have been posted in this thread earlier, but the server is written with an optional SSL context. This can be enabled in the server config. The actual handling of certificates and renewal is not something the server does, so anyone hosting an SSL instance will need to handle ensuring their SSL config is up to date. The SSL path is also configurable, it just needs to be readable by whatever user is running this service.
*As of right now, the bridge does not support SSL, so any SSL servers will be unable to be connected to.*
Will there be a way to reload the certificate without restarting the service?

NEW FEATURE - Verification-Based Authentication
As an attempt to dissuade connections to this service that are not from the calculator, such as random port probes or script kiddies, the server now implements a code-based verification system. When a user registers an account, an 8-digit code is generated and written to the user's account file, as well as sent to the calculator for display. You will be required to log into the web deck and input your verification code before you will be able to log in to the game server. This will allow us to filter unsolicited connections, as well as remove any anomalous user accounts created.
I'm assuming there is a way to recover this as well in the back-end if the user forgets it?
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano on November 23, 2020, 11:16:45 pm
That's pretty cool :) Security is important, I'm glad you're thinking it through now.
You think that's cool wait till you see what I scrapped the older security mechanisms in favor of...

Will there be a way to reload the certificate without restarting the service?
Possibly? I'm not 100% sure how to do that... and restarting the service is simple enough.

I'm assuming there is a way to recover this as well in the back-end if the user forgets it?
Nope, because this security system has been (at least for now) removed. See the Update notes.


UPDATE: Version 0.0.98 released

- First Public Release with the Multi-Line log/chat widget, and 2-way chat ability.
- Battery icons on the module stats overview tabs now indicate POWER_OK or POWER_WARN
- "Particles" system implemented... displays some effects on the screen if certain conditions are true.
- ---- First particle implemented - "Cracked screen" effect appears when the ship integrity is low.
- And last but not least:
Self-Contained, Custom, Service-Level Packet Filter
This particular bit of the server is not yet implemented, as it's still under development, but when complete, will wrap the packet receive portions of the server in a packet filter specifically designed to "speak" the TI-Trek protocol. The filter receives the connection descriptor, the `addr` info of the packet, and the data, as well as a format string, indicating the lengths and types of specific packet segments. First the filter checks the blacklist, immediately closing the connection to an IP that is on it. Then the filter performs a sanity check, looking for data that should not belong in certain parts of the packet (such as special characters in the usernames), and last but not least, it performs a threshold check, seeking how many times an offender has triggered the filter. If that number is over a specified hitcount, the offender is blacklisted. Blacklisted users are written to a fail2ban-compatible logfile every time they try to connect, post-blacklist. The filter also has the ability to search for extra modules and actions written by end users. Modules (checks) go in the `filter/modules/` directory; Actions go in `filter/actions/`. The "method" and "failaction" keys specify the check name and the response to a True response from the check. For a custom check/action, the value of that key is the name of the file to look for, and the code should be in `main():`. To see the current progress on that, check out the link below. Code for finding and loading the module provided by beckadamtheinventor.
https://github.com/acagliano/titrek-server/blob/master/trek_filter.py
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano on November 30, 2020, 11:44:41 pm
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.
(http://titrek.us/gallery/anims/0.0.98_showall.png)
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano 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

Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano 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.
Title: Re: Project TI-Trek for the CE nears first demo release
Post by: ACagliano 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:
(http://titrek.us/gallery/stills/0.0.112_about.png)
(http://titrek.us/gallery/stills/0.0.112_tcpicon.png)
(http://titrek.us/gallery/stills/0.0.112_srlicon.png)
(http://titrek.us/gallery/stills/0.0.112_pipeicon.png)
And lastly, courtesy of beckadamtheinventor:
(http://titrek.us/gallery/stills/0.0.112_titrekuidemo.gif)

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