Finally got around to spending some time moving forward on this! Some quick updates!!

I've gone through the code, formatting the files properly after I wrongly began placing code in header files. Things are done properly now, with code in .c files, prototypes and equates in .h files.

I also revamped the GUI slightly. The part of the GUI that is meant to be the interior of the ship is now a silvery greyish blue, the viewscreen remains black, and the LCARS tabs are now a deeper grey (screenshots to follow). Additionally, navigating the LCARS system is a bit different now. There is no tab for the viewscreen... that's default. There's a tab for Tactical (Shields and Weapons), Status (Core systems), Transport (subject to change), Power (all systems except Warp Core), and Map (which will display sensor range). You may switch tabs freely but to return to the viewscreen (see into space), simply tap on the key for the tab you have open again and it will close.





Some Features:
I'll also be changing the way the power system works. The warp core is now the sole source of power on the ship. Each module has a reserve power battery. A module draws power from its reserve battery. Some only drain when used, some drain constantly. Each power cycle, a module will request its default power from the Core. For example, a module that drains constantly will drain AND gain 5 power units per cycle, leaving its power at 100%. Once all modules are powered, any remaining power is wasted (you may install a reserve power module to save any leftover power, in the event of a warp core being destroyed)

As you know, modules may be given additional power. This can be done during combat to enhance your weapons and shields, or to enhance your Warp Drive speed to help you escape a battle you are losing. However, when a module is set to higher than default power levels, it will continue to refill at its default power draw. As a consequence, eventually, an overloaded module will run out of power and fail. This is called a burnout. This is designed to counterbalance the effect of overusing this feature to indefinitely give yourself an advantage. A module that "burns out" will not work again until its power level rises above 25%.

A few other things (long term): It will be possible to mine asteroids and loot destroyed ships for resources, like titanium and deuterium and other Trek-ish things. During battle, or after battle, you may expend resources to repair damaged systems. If you get disabled with no resources, you'll have to wait for a friend to deliver you some. Destroyed ships will also give you, rarely, a damaged tech module (like a weapon, shield, or core system) that you can install and repair or sell at a starbase.

This project sounds really cool. I can't believe this is the first time I stumbled across this thread.

Thanks! And yea, I alternate between periods of progress and stagnation due to my work schedule changing.

New screenshot: Icons rather than flashing word bars for alerts. Current alerts are shield status, ship status, power, and torpedo. For the two on the left, shield and ship, they monitor your ship systems. The default for a system in good health is green. If a system is damaged (below 50%), the indicator will become red. For the shield icon, the green outline of the ship represents the shield. For the ship icon, the whole ship is the icon.

The power icon will turn red with EITHER the reserve battery of any module OR the reserve power module (if installed) drops below 50%. The torpedo icon will turn red when a torpedo module runs out of a torpedo type that it is configured to fire.

So, been brainstorming ideas for how to work the numbers for damage in the game (since I haven't had much coding time the past week or so) and came upon a solution. I didn't want to treat the Hull Integrity module as another shield system, but in some regards, the hull *can* absorb damage from reaching the inside of the ship. A ship with weak integrity allows full damage through.

The solution:
Shields impart a damage resistance value to your ship, which controls how much damage is let through. For example, a weapon with a payload of 2 kJ impacting a shield with a DRV of 5 kJ is completely deflected, meanwhile a weapon with a payload of 7 kJ impacting this same shield inflicts 2 kJ bleedthrough damage.

Hull integrity will impart an additional DRV to your ship. Starting modules will offer 1 kJ, upgraded ones will offer higher levels of protection. Note that shield deflection will always occur first. While the hull integrity is above 50%, it imparts its DRV worth of additional protection. When your hull integrity drops below 50%, it stops adding DRV to your ship. When the module drops to 0%, the hull integrity module adds its DRV to the incoming damage, thus causing your ship to take more damage from impacts. Hull integrity is "damaged" before its DRV is applied to calculate system damage.

** Bear in mind that shields will always absorb the full damage of a weapon, and decrease in health by its power. **

To sum it up:
1. Weapon impacts shields. Shields take damage equal to weapon power.
2. Shield DRV (equal to DRV * percent health) subtracted from weapon power. If excess, proceed. If not, stop.
3. Excess damage is dealt to hull integrity.
4. If hull integrity is >=50%, subtract module DRV from excess damage. If excess damage, proceed to 7
5. If hull integrity is <50%, do no subtraction. If excess damage, proceed to 7
6. If hull integrity is =0%, add DRV to excess damage. Proceed.
7. Remaining damage is dealt to (random*) system module.

* In early releases this will be random. In later releases, i hope to have the ability to target systems based on point of impact. *

GUI Stuff
Soon, I'll be starting work on a new raycasting/rendering system. Still a bit un-experienced with doing this, but I'll try we'll see how it goes. Anyone who has more experience with this sort of graphics (3d, raycasted) and is willing to lend some time and help, please let me know.

Perhaps, and this is just a minor suggestion, the greater the hull (in terms of its DRV), the less the maximum speed (or potential maximum speed) of the ship. This would help balence things as a heavily armored ship with a maxed out speed value, seems incredibly unfair. You could even go as far as to increase the max speed again when the damage or module power falls. This would be reminiscent of losing plates of hull armour off of the ship, thus, dramatically reducing its weight.

Well the maximum speed of the ship depends on the installed Warp Drive module. I could apply your suggestion to the impulse drive, which is generally the speed a battle would occur at. This would mean a heavily armored ship moves slower in battle. It wouldn't make much sense for warp speeds, as "warp" is a curvature in space itself, in which your ship is stationary (meaning ship weight wouldn't have much effect).

Edit: Screenshot of power cycle in effect

At the start, all modules are inactive (default for testing). Once they hit 50%, they become active, but are automatically set to 50% of their default draw (40% because 5 cannot be split in half evenly). Once the module hits 100% power, then it's power draw is set back to 100%, automatically.

Update:

Removed a lot of the automated stuff from the power cycle. You'll be now able to manually bring systems online/offline. You will also be able to (from the Status screen) select 1 system for repair (adds 1 point of health every 5 ticks).

Now, having either your life support system or warp core at 0% health (and offline) causes a game over (Warp core breach for latter, which might at some point give you a *chance of* a breach, but not always). Repairing the core module to above 25% stops the breach if you can do it in time.



Once I code the ability to select modules for repair and online/offline (arrow keys), i will release the standing alpha for testing while moving forward.

How is this game played atm? My understaning is it is an online multiplayer game. Have you done the proper USB intergration or did I miss something and it is a player vs. AI?

EDIT: Ah okay, just glad that I did not miss (or skew) what I read in the thread.

It's somewhere earlier in the thread. Early releases will be against an AI to test, however, for VERY early releases it will be to test the screens/maths using like trigger keys that serve as a substitute for actual combat events. I'm working mainly on ship administration now... controlling your systems, managing your health and power, repairing... and the response of the ship to damage.

It will go multiplayer when people who are more skilled than me release USB drivers/protocols for me to use.


Edit: 0.0.39 alpha is available for people to screw around with
http://clrhome.org/startrek/downloads.php

Ok, a few updates... Still have to do raycasting, then create a stationary AI to test some combat features with, then ill release that for testing. Right now I need some advice. Have a look at the two screenshots. Do we prefer the smaller icons, where one was for shields and the other for ship integrity, or do we prefer the larger, joint icon, where shields were outside and hull integrity on the inside.

Two icons


Single, larger icon

MOAR UPDATEZ

So I have added a Warp Core Breach mechanic to the game as a sub-function of having your Warp Core damaged. Now, once your Core hits 25% or less health, it begins attempting to "trigger" a breach. The odds of a breach are 1 out of the health of your Core * 10. So, for example, at 25%, your Core has a 1/250 chance of a breach occurring. At 10%, that's a 1/100 chance. And so on.

You may repair a breach by healing your Warp Core system to above 50% (healing sets the module offline and drains power). However, doing so causes power to stop flowing to the rest of your ship until you stop the repair and turn the Core back online. If your Core is drained entirely of power, it will become difficult to re-engage it, which will leave your ship disabled and vulnerable to any subsequent Core breaches. Your Core can power itself, which is why it's best to not allow the module to drain entirely when healing, else you'll have some problems. (if you have a reserve power module installed, your systems will draw power from that instead if the Core goes offline, so you'll have less to worry about with losing power.)

This mechanic is showcased below, wherein a breach in progress is indicated by a red radiation warning symbol appearing to the left of the torpedo inventory and power warning alerts.


** Any module can be repaired similarly to the warp core, but with the same drawbacks. **

UPDATE

Very Early Access Alpha version 0.44 available for testing @ http://clrhome.org/startrek/downloads.php .

- Shield healthy indicator within ship status icon is now blue... for a forcefield.
- Intent to make individual sections of ship within status icon "transparent" to showcase damage *location* based on system location and system health.
- Speed indicator added (and preliminary speed). Speeds are below:

Full Stop: 0 fields/tick
Impulse: 1 - 4 fields/tick ( 1 = 1/4 impulse, 4 = full impulse)
Warp: Starts at 10 fields/tick for Warp 1. Speed increases by the warp factor. Thus, Warp 2 represents an increase of 2 fields/tick from Warp 1, Warp 3 is an increase of 3 fields, and so on. The speed indicator properly handles the transition between warp and impulse speeds in both directions, and can show fractional warp factors. For instance: Speed 17 is 2 fields faster than the Warp 3 speed of 15, but 2 fields slower than the Warp 4 speed of 19, making the actual speed Warp 3.5.

EDIT: Warp speeds now limited by the top speed of your warp core. Power consumption of your warp DRIVE will be equal to the number of fields you are moving per tick. The power draw of the module will be equal to the number of fields per tick moved at the drive's top speed, meaning that you'll always meet the power requirements to keep your drive charged, unless you: 1. Overpower the drive to increase your speed (by ~25%), or 2. Do not have a warp CORE with enough of a power output to handle it.

EDIT 2: The power alert indicator now is invisible when power levels are OK, only appearing red (and flashing) when power is beginning to run out. I intend to flash all of the warning lights.

UPDATE -- v 0.47 alpha

- The flashing power indicator removed, as it was causing the remaining graphics to slow down, as well as vastly increasing program size. Indicator now steady when alert active.

- The un-implemented torpedo indicator (which is orange when torpedo supply is low and red when supply empty) has been removed temporarily until the inventory system is implemented as well as weapons.

- As an alternative to repairing a warp core, it may now be EJECTED. This option is silent (for now) and becomes available once the warp core breach countdown begins on your active warp core. The active warp core is immediately removed from your ship, averting the destruction of your ship, but also stopping the supply of power to your ship. This means that without an auxiliary power reserve module as a backup, your ship will be dead in the water quite quickly. After ejecting your warp core, the text "core ejected" replaces the health bar of your warp core and the text "ejected" replaces the power usage bar on the power menu. You will eventually be able to install a new warp core module into this slot if you have one in your inventory.

- When you eject the core it will be spawned behind the ship, with a slow trajectory moving away from you. It will continue to count down from whatever it was at when you ejected it and detonate in a massive explosion that will damage any ship in range. This means simply ejecting the core is not enough to save you. You have to get away as well.

UPDATE --- v 0.50 alpha . (still pre-demo)

Status icon (lower left) now indicates damage to systems, based on location. Every module except for shields and hull integrity will have a location flag. When the module is damaged, if the health of the module is below 50%, the section of the ship the module is located in will be shown in red. The icon will alert you to damage to the system usually earlier than said damage will have effects on your ship, giving you ample time to repair.
Also, the two red dots that appear on the saucer are the state of the hull integrity. One dot appears at 50% and a second at 0%. Unimplemented is a third, slightly larger dot to indicate damage to systems located in the saucer.

This may be a silly question, but on the dependencies tab, it lists, Doors CS7, which is not compatible with the CE, while it also says there is a CE, version? What am I missing?

This was a monochrome project at its roots. It was then "ported" to the CE (I say ported but iirc, the monochrome version was never completed). It is very likely that this is left-over from that time (In fact, I think this is the case). It is also possible that ACagliano plans to port the project to the monochrome cals and is planning on using the DCS7 networking libraries.

LAX is correct for the first part. This started out as a project for the TI-83+/84+ calculators. Then, my TI-84+ SE broke and I bought a CE and began coding C. This project was then transitioned to the CE.

When it was a monochrome project, networking would have required DoorsCS7/CALCnet. Now, all that is needed is a USB driver. Once the CE version becomes multiplayer either myself or someone who still codes assembly/Axe can make a version for the monochromes that can connect to the CE servers. The game would be identical, except use greyscale graphics rather than color ones.


Edit: In C, what is the fastest way to go from X, Y, and Z vectors (represented as distance from an origin (your ship)) to angles (XZ, Y) representing rotation, based on the X axis and Y axis respectively? Am I correct in the assumption that if you have 2 3-d points, you can use distance to find the angles of rotation?

What angles are you looking for? Distance doesn't really effect the angle. You can have an object go forward in a straight line, the distance will increase but the angle will stay the same.
Anyways, if XZ is the "ground" plane, and Y is "up" then the "pitch", the angle "above" the ground plane, would equal the arcosine of Y ( acos(Y) in c ), and the "heading", the angle AROUND the the Y axis, would equal the arctangent of Y/X ( atan2(Y,X) in c )

Well yea, distance is a constant and is irrelevant. Also are you sure? I could have sworn Z went in the formulas somewhere!

Edit:
In 2d trig, isn’t the angle represented by arctan(y/x)? In my model, both Z and Y are relative to X. Unless I’m way off the mark, shouldn’t the angles be arctan(z / x) and arctan(y/x), respectively?

Ahh yea, I meant to type "arctangent of Z/X", not " arctangent of Y/X". One thing to note though is that even though mathematically, the heading is equal to "atan(Z/X) ", you should instead use the function "atan2(Z,X)" because it takes care of arctangent's limited domain and won't crash if X is 0. (And you may have to swap Z and X depending on which axis points "north").
As for "pitch" you only need the Y component of the vector, as the "heading" doesn't effect the "pitch", so arccos(Y) is correct. However the caveat here is that the direction vector should be be normalized before being used to calculate the angles. I think you can skip normalising the Z and X coordinates, but the Y coordinate should be decided by the length of the vector before being used to calculate the pitch, meaning that Pitch = acos(Y/R), where R = sqrt(X*X + Y*Y + Z*Z).
Reading Wikipedia's page on spherical coordinates would be helpful, especially the " Cartesian coordinates " section, although do note that the examples use the Z, not the Y, axis as the "up" axis. https://en.wikipedia.org/wiki/Spherical_coordinate_system