Starship Module and Interface

This page is a discussion of the Starship Module and Interface.

The Starship Module is designed to handle the basic data structures related to starships in general as well as the Starship Interface. The Starship Interface in particular is one of the key aspects of the game, as it is the primary interface through which the player will play the game. As such, it will be the largest and most complex Interface in the game, and will be required to heavily interact with other game modules. The basic architecture of the module is similar to other modules within the game that handle basic data types (such as integers and strings) and dictionaries. All code for the starship_interface object as well as the required child classes is located in the ship_interface.py file; starship objects, their classes and methods are located in the starship.py file.

Summary Description

An instance of the Ship_Interface object is created upon call to its initializer, which occurs the first time a player enters the Docking Bay at Starport, exits the Starmap, leaves an encounter, or re-enters their ship from a planet's surface (provided an instance of the object does not already exist). The interface is activated at that point. When activated, the module's internal libraries are called and the user-defined menu functions are defined. The user may use the Interface to perform most in-flight game functions, with the module remaining active but yielding overall game control as needed to other modules. The object deactivates when game control is passed back to another Interface, but the object itself is not destroyed until th2e game is exited. Functions that are available in the interface are defined outside of the program itself via an XML file, which dictates what items will appear in the menus and what in-game effects those menu items will have.

Data Structure of the Ship_Interface Object

The following list is an indication of the various variables and methods that will be included in a Ship_Interface object. This list contains suggested variables only. Ship_Interface objects are meant to be used as child objects of the InterfaceHandler object, used to activate various menu functions in-game. Ship_Interface objects have no child objects. Only one Ship_Interface Object is meant to be used in the game at any one time. They are meant to be loaded and activated by either the Hyperspace sub-module, the Starport Module, the Planetary Exploration Module, or the Encounter Module when their respective interfaces go out of scope if a Ship_Interface Object does not exist at the time. Their data structure is as follows:

• Class: Ship_Interface_Handler
  • Dictionary: Main_Menu_Functions
    • Keys: Menu Option Names
    • Values: Activation_Flags
  • Dictionary: Sub_Menu_Functions
    • Keys: Sub-Menu Option Names
    • Values: Activation_Flags
• Method: _init_(XML)

Data Structure of the Starship Object

The following list is an indication of the various variables and methods that will be included in a Starship object. This list contains suggested variables only. Starship objects are meant to be used as children of Fleet objects, and are used to contain all data pertaining to a particular ship. Starship objects have several child objects (including Shield objects, Armor objects, Weapon objects) that are mainly used as a means of keeping all the data stored in their organized in some fashion. Numerous starship objects may be used in the game (though in general its recommended the actual number of ships in play be kept to a relative minimum, considering all the data they contain), and are meant to be loaded by the Encounter Module (when ships in an encounter are created), the Starport Module (for escorts and new craft), and the Main_Menu module (for preliminary data on the player's ship). Their data structure is as follows:

Starship objects are direct children of Fleet objects. Their data structure is as follows:

• Class: Starship
  • Class: Vehicle (data structure for vehicles will be pretty much the same as that for starships. When not in operation, there will be no crew, of course.)
  • Class: Combatant (for details on the Combatant object, see the discussion under the Basic Combat Module). I think this got deprecated; I'll have to check the Combat Module to be certain.
  • Class: Shield
    • Integer: Shield_Class
    • Float(2 decimals): Shield_Status_Percentage (per combat arc; used for status display)
    • Integer: Shield_Recharge_Rate (SHP per round if below maximum)
    • Flag: Shield_Status (Raised/Dropped)
    • Flag: Nebula_Shield (Nebula/Normal)
    • Integer: Shield_Mass
    • Method: toggleShield() (used to change the shield status)
  • Class: Armor
    • Float(2 decimals): Armor_Status_Percentage (per combat arc; used for status display)
    • Flag: Reflective (Reflective/Normal)
    • Integer: Armor_Mass
  • Class: Weaponry
    • Class: Projectile_Weapons
      • Class: Projectile_Weapon_Racks (per combat arc)
        • Flag: Projectile_Weapon_Recharging (2 sec)
      • Class: Projectile_Weapon_Turrets
        • Flag: Projectile_Weapon_Recharging (2 sec)
    • Class: Beam_Weapons
      • Class: Beam_Weapon_Racks (per combat arc)
        • Flag: Beam_Weapon_Recharging (2 sec)
      • Class: Beam_Weapon_Turrets
        • Flag: Beam_Weapon_Recharging (2 sec)
    • Class: Special_Weapons
    • Flag: Weapons_Armed (Armed/Disarmed; 6 sec delay from arming command to armed status)
  • Class: Pods
    • Class: Permanent_Pod_Mounts
      • Integer: Maximum_Permanent_Pod_Mounts
      • Vector/List: Attached_Permanent_Pods (Cargo)
        • Vector/List: Pod_Contents (minerals, lifeforms, trade goods, etc.)
          • String: Item_Name
          • Float (1 decimal): Item_Amount
          • Integer: Permanent_Pod_Mass
    • Class: Expendable_Pod_Mounts
      • Integer: Maximum_Expendable_Pod_Mounts
      • Vector/List: Attached_Expendable_Pods (Blastopods, Jump Pods, Colony Pods)
      • Integer: Expendable_Pod_Mass
  • Class: Attributes
    • Float (2 decimals)": Bio (average health of the ship's crew)
    • String: Comm_Officer_Race
    • Hash/Dictionary: Cargo_Contents
    • Float(2 decimals): Cargo_In_Use
    • Float(2 decimals): Max_Cargo_Size
    • Float(2 decimals): Size (times an Intrepid-II-class Scout)
    • Integer: Total_Mass (in metric hectotonnes; range to be determined)
    • Float(2 decimals): Acceleration (in gees, from 1-25; based on mass/engine class)
    • Float(2 decimals): Turning Rate (in degrees per second, from 3-75; based on mass/engine class. Turning is always equal to 3 dps/gee of acceleration.)
    • Vector/List: Systems (Damage Levels)
      • Integer: Hull_Damage
      • Integer: Engines_Damage
      • Integer: Sensors_Damage
      • Integer: Communications_Damage
      • Integer: Shields_Damage
      • Integer: Beam Weaponry_Damage
      • Integer: Projectile Weaponry_Damage
      • Float (2 decimals): Energy (sum of all damage levels, divided by 7)
    • Vector/List: Systems (Functional)
      • Flag: Hull_Malfunctioning
      • Flag: Engines_Malfunctioning
      • Flag: Sensors_Malfunctioning
      • Flag: Communications_Malfunctioning
      • Flag: Shields_Malfunctioning
      • Flag: Beam Weaponry_Malfunctioning
      • Flag: Projectile Weaponry_Malfunctioning
    • Vector/List: Systems (Being Repaired)
      • Flag: Hull_Repair
      • Flag: Engines_Repair
      • Flag: Sensors_Repair
      • Flag: Communications_Repair
      • Flag: Shields_Repair
      • Flag: Beam Weaponry_Repair
      • Flag: Projectile Weaponry_Repair
    • Float (1 decimal): Fuel_Status (this will need to be concurrent with the Pod_Contents Vectors/Lists)
  • Vector/List: Vehicles
    • Class: Vehicle
  • Vector/List: Crew
    • Class: Character
      • String: Name
      • String: Species
      • String: Billet (i.e. their on-board job; captain, sci.off., navigator, engineer, comm.off., doctor, tactical, redshirt.)
      • Integer: Durability
      • Integer: Learning_Rate
      • Integer: Hit_Points
      • Float(2 decimals): Vitality (HP/maximum HP, as a percentage)
      • Vector/List: Disciplines
        • String: Discipline_Name
        • Integer: Discipline_Value
        • Integer: Maximum_Discipline_Value
        • Vector/List: Sub_Disciplines
          • String: Sub_Discipline_Name
          • Integer: Sub_Discipline_Score
      • Flag: Being_Treated (Treated/Not Treated)
      • Flag: Dead (Alive/Dead)
  • Flag: Flagship (Flagship/Escort)
  • Flag: Temporary? (Hired Escort/Permanent Ship)
  • Flag: Landed? (Landed/Star-borne)
  • String: Ships_Log
  • Enum: Location (HYPERSPACE/IN_SYSTEM/IN_ORBIT/LANDED/STARPORT/ENCOUNTER)
  • Enum: AlertStatus ("GREEN", "YELLOW", "ORANGE", "RED")
  • Integer: Hull_Temperature
  • Float: Fuel_Drainage_Rate
  • Integer: Base_Ship_Mass

Interface

Starship Interface (Example)

The main starship interface consists of six separate areas, as demonstrated in the graphic below:

• Main View Screen (MVS)
• Auxiliary View Screen 1 (AVS1)
• Auxiliary View Screen 2 (AVS2)
• Message Box
• Interface Buttons
• Menu Box

The largest of the six interface areas is the Main View Screen, or MVS, which is located in the large area on the upper-left-hand side of the screen. It is meant to give the player a feel for what is actually going on with their fleet/ship. This area is used to display the fleet icon while the ship is in space, as well as star/nebulae/flux icons in hyperspace (including flux transit animations) and planet/star icons within star systems. When the ship is in orbit of a planet, this area will display a graphic of the planet being orbited, and will show an animation when the ship is launching from and landing on planets. During communications, this area will display an image of the alien in which the player is in contact. Finally, it will show an animation of the docking bay doors closing when arriving at Starport, and opening when leaving Starport. While the ship interface is active, the present coordinates of the player's fleet are displayed in a small area at the top of the MVS. Finally, at the bottom of the MVS is an area that displays the Interstel logo and either the name of the fleet flagship or one of her officers, depending on whether or not there is an active menu open (a crewman's name will be displayed if their menu is active).

The two Auxiliary View Screens, or AVS, are located in the upper-right-hand side of the screen, with AVS1 located directly above AVS2. These displays are designed to give the player information about the current status of their ship/fleet and information on any objects the player encounters during the course of their travels. AVS1 constantly displays the ship's status. AVS2 displays one of several items, depending upon the action selected by the player. When the ship is landing on a planet, AVS2 will display the planet's Mercator map. The results of all Sensor Scans are displayed in this window (see the Science Officer's Menu discussion below). The ship's Damage Report can be called up for display in this window at the player's request via the Engineer's Menu. Similarly, a graphical representation of the results of a character examination can be called up for display in this window at the player's request via the Doctor's Menu. When in interplanetary space, it will show a system map (with some radar-like functions). Finally, if no active conditions are available, AVS2 will show a graphic representation of the ship's "alert status", which is dependent upon the condition of the ship's defensive systems, as outline below:

• Condition Green: Shields and Weaponry inactive.
• Condition Yellow: Shields active, Weaponry inactive.
• Condition Orange: Shields inactive, Weaponry active.
• Condition Red: Shields and Weaponry active.

Immediately below the MVS is the Message Box. This is where the game displays all text information being sent to the player, including comm messages, analyses, and "error" messages. The Message Box area also acts as a scratchpad when the Ship's Log option is active (selected by the player via the Captain's Menu). Text sent to the message box remains visible to the player unless an action occurs that clears out the box (such as making an Analysis), or until enough text has been sent to the message box to require it to "scroll down". If a message sent to the message box is long enough that it would scroll down before the player has had an opportunity to read it, the message can be set to "pause" mid-way through its display.

Below AVS2 are the graphical interface controls, also known as the Crew Interface Controls. These consist of seven "buttons" which can be activated one at a time in one of three ways: either by clicking on them with the mouse, by using an appropriate hotkey for the desired menu (default hotkeys for the Crew Interface Controls are F1 to F7 inclusive on the keyboard, with F1 corresponding to the Captain and each successive key to the right corresponding to the next button to the right), or by selecting the corresponding menu option in the Menu Box. When none of the buttons are selected, the Menu Box will display the Crew Interface Control Menu by default, listing the seven main crew positions (Captain, Science Officer, Navigator, Engineer, Communications Officer, Doctor, Tactical Officer) in order from top to bottom; the area at the bottom of the MVS will display the ship's name. When a button is been selected, it will turn red, the area at the bottom of the MVS will display the name of the crewman occupying the selected position (along with the title of that position), the appropriate menu will activate in the Menu Box, and the ACKNOWLEDGED tone will sound. Only one crew interface may be open at once; activating a new menu when a menu is already active will automatically deactivate the active menu.

The final area is the Menu Box, located just below the Crew Interface Controls, where further game options are displayed as associated with the currently active Crew Interface Control. By default, the Menu Box displays a maximum of seven options (this may change if it's deemed necessary at some point in the future). Each option in the Menu Box can be selected using hotkeys (default hotkeys for the Menu Box are the numbers 1-7 on the keyboard, with 1 corresponding to the topmost option of the Menu Box and each successive key to the right corresponding to the next option down) or via a click of the mouse. In most situations while the Interface is active, menu options can also be scrolled through by pressing the up and down arrow keys on the keyboard and activated with the <Enter> key, similarly to how the interface functioned in the original games (likewise, the <Space Bar> may be used to back out of most menu options. Options in the Menu Box will be displayed in White text on a Dark background. Whenever a Crew Interface Control is active, the #7 option will always display the word "Bridge"; this option will be a Blue-White color (as opposed to the other Menu Box options). This command will always deactivate the current Crew Interface Control and return the menu to the Crew Interface Control Menu. Attempting to activate a menu option that does not correspond to a valid function causes the NEGATIVE tone to sound, but otherwise has no other effect.

While the Starship Interface is active, game-time will be running at the normal rate (10 seconds of real-time per game hour), unless an active scan is taking place or the game must pause to display an abnormally long message.

Procedures and Notes

Chain of Command

As long as there is one character aboard the ship, there is always a Captain (Commanding Officer). Launching from Starport cannot be accomplished without at least one character aboard, hence the player registration routine at the very beginning of the game. The character in the Captain position sets the overall Command Discipline and associated sub-disciplines for the ship. Should the Captain of the ship be killed, the next available officer in the chain of command automatically assumes the role. The chain of command is as follows:

• Captain (Commanding Officer)
• Science Officer (Chief Science Officer/Executive Officer)
• Navigator (Chief Navigational Officer)
• Engineer (Chief Engineering Officer)
• Tactical Officer (Chief Tactical Officer)
• Communications Officer (Chief Communications Officer)
• Doctor (Chief Medical Officer)

All other Senior Officers are assigned by the player at Starport and set the overall Discipline score and associated sub-disciplines for the ship. Should any other crewmember be killed off during the course of the game, the game routine will automatically check to find the available character with the highest overall Discipline score in the affected associated Discipline and set them to "moonlight" that position (unless that character is a redshirt, in which case they are simply assigned the position). The associated disciplines for each Senior Officer position is as follows:

• Science Officer: Science
• Navigator: Navigation
• Engineer: Engineering
• Tactical Officer: Tactical
• Communications Officer: Communications
• Doctor: Medicine

Interface Options

This section of this page will go in detail over the default crew menu options planned to be made available in the Crew Interface Controls for SF3, categorizing the various options by their location within the Crew Interface Control Menu of the Starship Interface. This will serve as an indication of what methods will be necessary in order for the module to function as intended, and as a way of seeing what data will be necessary for the interface's XML.

Intended Starship Interface Menu Options for SF3:

1. Captain
   1. Launch/Land
   2. Disembark/Launch Vehicle
   3. Cargo
   4. Log Planet
   5. Ship's Log
   6. Bridge
2. Science Officer
   1. Sensors
   2. Analysis
   3. Culture
   4. Bridge
3. Navigator
   1. Maneuver
   2. Starmap
   3. Bridge
4. Engineer
   1. Damage Report
   2. Repair
   3. Jump Pod
   4. Bridge
5. Communications Officer
   1. Distress
   2. Playback
   3. Bridge
6. Doctor
   1. Examine
   2. Treat
   3. Bridge
7. Tactical Officer
   1. Raise/Drop Shields
   2. Arm/Disarm Weapons
   3. Bridge

Captain Menu Options

Launch/Land

This option allows a player to select a planetary landing site (or at least an atmospheric entry zone) for their flagship; it's generally assumed that the rest of the player's fleet remains in orbit while the flagship goes down to the planet's surface. It is also used to launch back into space while on a planetary surface, and to launch from Starports. How this option appears in the Menu Box is a function of the fleet's location; it will show as LAUNCH if the ship is LANDED or at STARPORT, and will show as LAND anywhere else.

When this option is selected, the position of the fleet is checked; if the position is HYPERSPACE or IN_SYSTEM, the NEGATIVE tone sounds and the message "THERE'S NOWHERE NEARBY TO LAND, MORON." will appear in the Message Box. If the position is LANDED or STARPORT, the QUESTION tone will sound and the message "READY TO LAUNCH, CAPTAIN?" will appear, with a YES or NO dialogue box appearing. Selecting NO will cancel the launch request and return game control to the Captain's sub-menu. Otherwise, a countdown animation will play, followed by an animated sequence dependent on where the ship is launching from. Launching from a planet's surface will simply place the ship about half-way between the top of the planet's atmosphere and the planet's surface, relative to the launch position. Flying out of the planet's atmosphere will be done by the player, at which point another animation will be shown making the transition to orbit. If the launch occurs at Starport, a "launch tube" animation (similar to the launch tube effect from the original Battlestar Galactica will play, at which point the player's ship will transition to orbit.)

If the player is IN_ORBIT, the internal game clock is stopped and a call is made to the Planetary Exploration Module for the generation of a planetary Mercator map (for details, see the discussion under the Planetary Exploration Module). A dialogue box will appear in AVS2 with the generated Mercator along with a set of crosshairs, as well as textual indicators of the position of the crosshairs on the Mercator (the default position is at the intersection of the planet's Equator and Prime Meridian). A new menu will appear in the Menu Box, with the options of SELECT SITE, DESCEND and ABORT appearing. The player will be able to access these controls as with the other Menu options for the Starship Interface. Selecting ABORT will return game control to the Captain's Sub-Menu, restarting the gameClock in the process. Selecting SELECT SITE will allow the player to move the crosshairs in order to select their landing site. The player will be able to use the WASD and arrow keys to move the crosshairs across the surface of the Mercator, with the textual indicators updating to the new position of the crosshairs instantaneously. The mouse may also be used to move the crosshairs around. Final landing coordinates are entered by pressing the <Space Bar>, the <Enter> key, or by clicking the mouse (note that there is no true abortion of this procedure; the player may back out of the menu selection but the coordinates of the crosshairs at the time will be entered as planetary landing coordinates). Finally, selecting DESCEND will start the descent sequence; the Planetary Exploration Module will generate a detailed surface map at the coordinates selected as well as the neighboring coordinates while an atmospheric entry animation plays. A check is made of the planet's gravity at this point, with a "burn up" animation playing if the gravity is too high. When the animation is complete, the player's ship will be in atmosphere approximately halfway between the top of the planet's atmosphere and the surface; the Planetary Exploration Interface takes control of the game at this point.

Disembark/Launch Vehicle

This option allows the player to take control over a vehicle, using it for exploratory duties. Which menu option is visible depends on the player's location; in space, its listed as LAUNCH VEHICLE, while it is DISEMBARK at Starport. Whether or not the player may use a vehicle in a given situation depends on the situation and what vehicles are available to the player. While the player is in space, ATVs and ITVs may not be deployed; if these are the only vehicles available to the player when they select LAUNCH VEHICLE, the NEGATIVE tone will sound and the message "WE CANNOT DEPLOY LAND VEHICLES WHILE WE'RE IN SPACE, MORON." will be displayed, with game control remaining with the Captain's sub-menu. Likewise, if the ship is in hyperspace, the NEGATIVE tone will sound and the message "WE CANNOT DEPLOY VEHICLES IN HYPERSPACE, SIR." will be displayed, with game control remaining with the Captain's sub-menu.

If the ship is at Starport, the menu option DISEMBARK will be displayed. Selecting this menu option will engage the Starport Interface for that Starport; this will be accompanied by the TELEPORTATION tone and the teleportation animation while the Starport Interface engages. Historically, DISEMBARK was also used to deploy the ITV once the ship has landed. That functionality is now discussed under the Planetary Exploration Module.

If the ship is at a position where it can launch the indicated vehicle, the QUESTION tone will sound and the message "WHICH CREWMEMBERS WILL CREW THE (vehicle name)" will appear, along with a selection dialogue. The player may select which crewmembers they want to crew the vehicle, up to the maximum compliment for the vehicle involved (1 for a Daystar, 2 for a Viper, 5 for an Avenger and 6 for an MC Shuttle). A LAUNCH and NEVER MIND option button will also be available; selecting NEVER MIND sounds the ACKNOWLEDGE tone and closes out the dialogue without launching a vehicle. When LAUNCH is selected, the game checks to see if at least one crewmember has been chosen to launch the vehicle; if not, the NEGATIVE tone sounds and the message "AT LEAST ONE CREWMEMBER MUST BE ASSIGNED TO THE VEHICLE, SIR." will appear, with the selection dialogue remaining open. The game will then check to make sure at least one crewmember has remained with the ship. If not, the NEGATIVE tone will sound and the message "AT LEAST ONE CREWMEMBER MUST STAY BEHIND WITH THE SHIP, SIR." will be displayed, with the selection dialogue remaining open.

When a valid crew has been selected for the vehicle, the LAUNCH VEHICLE tone will sound and control will pass over to the vehicle. The position of the player's fleet is logged as a nearby encounter, which will remain visible on the player's in-system radar. The control interface for the vehicle will utilize the same set of controls as the player's ship (though perhaps a different color or decorative schema will be used so the player can differentiate the vehicle in which they are in control. Control passes to the vehicle's Command sub-menu (which is equivalent in all ways to the Captain's sub-menu).

The game works the same way while the player is in control of a vehicle in space, except that the vehicle may not enter hyperspace. Attempting to do so will raise the message "THERE'S NO SUPERPHOTONIC ENGINE INSTALLED ON THIS CRAFT, SIR." and will sound the NEGATIVE tone. Encounters are still handled through the encounter engine. Should the vehicle be destroyed, game control will pass back to the ship, provided the player's Captain character wasn't killed in the process. If the vehicle encounters the player's fleet, docking is automatic, and game control returns to the Captain's sub-menu.

Cargo

This option allows the player to look at the cargo manifests of the ships in their fleet. When this option is selected, the ACKNOWLEDGED tone sounds and the gameClock is paused. A list of the cargo currently being stored aboard the player's ship is then brought up in the MVS, with Technologies and Artifacts listed first, followed by Minerals, Lifeforms, Specialty Trade Goods and Standard Trade Goods (in that order). Under each category, cargo is listed in alphabetical order. Each cargo entry lists the name of the cargo and the amount being carried. At the bottom of the MVS two rows of buttons will appear. The top row of buttons contains five options: SCAN, TRANSFER, TRANSFER ALL, DROP, and DROP ALL. Selecting these buttons requires a mouse click and requires that a specific item be previously selected from the cargo manifest. Scan gives an analysis of the cargo from the ship's Science Officer, Transfer allows the player to move the cargo to another ship in the fleet and allows them to specify how much of that cargo to transfer, Transfer All transfers all of that cargo to another ship in the fleet, Drop allows the player to decide how much of that cargo to jettison in the cargo text menu, and Drop All will jettison all of that cargo. Both transfer options and both drop options involve a sanity check. The botton row of buttons contains three options, which once again require a mouse click to operate. The options are NEXT, PREVIOUS and CLOSE. Next and Previous are used to scroll through the ships in the player's fleet. Selecting CLOSE will close the cargo manifest and return game control to the Captain's sub-menu, sounding the ACKNOWLEDGED tone and un-pausing the gameClock.

This is probably the least detailed procedure on this page. No doubt that's because I described it last...The procedure will probably still include a number of additional uses of the SELECT_SCROLL, ACKNOWLEDGED and NEGATIVE tones. An additional tone for cargo jettisoning will likely be added. Once cargo is jettisoned from the ship it cannot be picked up once again if the ship is in space. Traditionally, that also happened on a planet's surface; I might consider trying to override that rule for SF3.

Log Planet/Drop Colony Pod

This option allows a player to send a remote drone to the nearest Starport with information on a planet the ship is currently orbiting, for the purpose of making a colony recommendation. When this option is selected, the game routine will check to see if the ship is in orbit of a planet. If not, the message "YOU MUST BE IN ORBIT TO LOG OR COLONIZE A PLANET." is displayed in the message box and is accompanied by the NEGATIVE tone. If the ship is in orbit of a planet, the game routine will next check to see if the planet has been previously logged or colonized, displaying the message "THIS PLANET HAS ALREADY BEEN COLONIZED" and the NEGATIVE tone if it has been colonized. The last check made is for habitation; inhabited planets cannot be logged or colonized. The message "THIS PLANET IS ALREADY INHABITED" will be displayed and the NEGATIVE tone sounded if the planet is inhabited. If the ship is in orbit of a planet, it has not already been colonized and is not inhabited, the game will sound the QUESTION tone and display the message "DO YOU WISH TO COLONIZE THIS PLANET? YES/NO". The YES and NO options will be displayed in the Menu Box. The player must answer before the game proceeds. If the player answers "NO", the Menu Box will exit to the Captain's Sub-Menu, sounding the ACKNOWLEDGED tone. If the planet has not been logged, the question displayed is "DO YOU WISH TO LOG THIS PLANET FOR COLONIZATION?"; again, selecting NO will sound the ACKNOWLEDGED tone and return control to the Captain's Sub-Menu.

If the player selects YES when asked if they wish to log the planet, a check is made of the planet's record for the reward value of that planet. If the reward value is positive, the planet is indeed colonizable and the player will receive a reward for logging the planet. An event will be created to generate a Starport evaluation message rewarding the player; the reward will be applied to their bank account upon return to a Starport. If the reward value is negative, the planet is not colonizable and the player will have to pay a fine for a bad recommendation. An event will be created to generate a Starport eveluation message penalizing the player; the penalty will be applied to their bank account upon return to a Starport. In either case, the evaluation message generated will not be displayed to the player until they visit the Operations office at Starport.

Regardless of whether or not the planet is habitable or not, the routine will perform a further check of the planet's record. This will be used to determine why the planet is unsuitable, or (if it is colonizable) whether it is in fact an optimal world. Suitability for colonization will use the traditional set of criteria for the Starflight Universe:

• Temperature range including the Temperate and/or Tropical categories.
• Gravity less than two gees. Gravity from .7 to 1.3 is optimal (and should generate a slightly different message from a standard logging success message).
• Atmosphere must contain oxygen
• Water Must contain water
• Weather Must be None, Calm or Moderate
• Higher Bio-density and Mineral density are preferable, but they are NOT a criteria for logging a planet.

The game will sound the LAUNCH DRONE tone, the message "REMOTE FTL HOMING DRONE LAUNCHED, CAPTAIN" will display, and game control will return to the Captain's Sub-Menu.

If the player selects YES when asked if they wish to colonize the planet, a check is made of the ship's record to see if a Colony Pod is available. If not, then the message "WE DON'T HAVE ANY COLONY PODS AVAILABLE, CAPTAIN." will appear and the NEGATIVE tone will sound. Game control will return to the Captain's sub-menu at that point. Otherwise, the Mercator Map will appear, with the menu options SELECT SITE, DEPLOY and ABORT appearing in place of the Captain's sub-menu. The player may select a set of coordinates to set down the Colony Pod in the same manner they would select a landing site for their ship. Selecting ABORT sounds the ACKNOWLEDGED tone and returns the game to the Captain's sub-menu without launching a pod. Selecting DEPLOY will sound the LAUNCH VEHICLE tone, and the message "COLONY POD DEPLOYED, CAPTAIN. SENDING NOTIFICATION TO STARPORT." will be displayed, with game control returning to the Captain's sub-menu. The planet will be considered inhabited at this point; subsequent colony pods may not be launched at the same planet.

Note that for SF3, all inhabitable worlds in the Alpha and Delta Sectors are considered to have already been logged.

Colony Pods
Colony pods are a new feature introduced for SF3. Their purpose is to augment the traditional method of recommending worlds for colonization; logically, by the time SF3 begins, all the worlds that can be recommended in both the Alpha and Delta sectors have been recommended. Colony pods enable the player to actually carry out the colonization process. Note that worlds may still be logged for colonization in the Beta Sector.

Colony pods are a standard expendable pod available to the player at Starport. They cost 100,000 MU for the player to purchase. Once deployed, they are designed to give the player a steady, reliable flow of income. The challenge for the player will be to make enough money off of the growth of a colony to ultimately recuperate their initial investment.

Colony pods must be deployed by a starship in orbit of a planet. Upon launch, the pod's overall value is evaluated and an event is added to the game's calendar (for specifics of the game calendar, see the discussion under the Event and Plot Handler Module). Every week, the pod adds an amount of revenue to the player's coffers. The amount added is dependent upon the estimated value of the colony's growth potential as evaluated at the time of launch. A set of starfaring-age structures will be present at the coordinates of the pod's deployment, should the player land there (i.e. a player may visit their own colonies). There is a 25% chance that a player-established colony will have a trade depot present; these posts will be purveyors of fuel and standard trade goods only (to avoid making things overly complex).

Largely, the same criteria are used to evaluate the growth potential of a colony as are used to evaluate a planet for colonization, though the criteria are more strict. Two criteria set the colony's base value:

• Mineralogical Content: The colony has a base value equal to all mineral deposits present at its site, times the mineral density.
• Biological Content: The colony has a base value equal to the STV/m3 of all lifeforms present on the world, times the biodensity.

The total base value represented by these figures is modified by a multiplier, which is tallied up by the following criteria:

• Biological Content. A -.1 multiplier is added for each "star" of danger level in native lifeforms.
• Atmosphere: Oxygen must be present (1.0). A penalty will be involved if the atmosphere is Oxygen, Hydrogen Cyanide (.10).
• Atmospheric Density: Moderate atmospheres are worth the most (1.0). Thin and Thick atmos are worth less (.75), and Very Thin/Very Thick atmos are worth the least (.5).
• Hydrosphere: Must contain water. The closer the colony is to the hydrospheric elevation, the higher its value (1/(el - h)).
• Gravity: Colonies on planets with optimal gravity are worth more (using the formula y = -x^2 + 2x, where x=gravity).
• Temperature: A schema will be set to determine the temperature at the site, based on latitude and the temperature range. A planet with all six temperature categories will start with Inferno at the equator and go progressively colder every 15 degrees of latitude. A planet with five categories will start at the highest and cool every 18 degrees; four categories every 23 degrees, three categories every 30 degrees, and two categories every 45 degrees. A planet with only one temperature category will have a uniform value across its surface. Colonies falling in the Temperate to Tropical range will be worth the most (1.0), Arctic and Searing will be worth less (.75), and Subarctic/Inferno will be worth the least (.5).
• Weather: Calm Weather is worth the most (1.0), No weather or Moderate weather are worth less (.5).
• Planetary Type: Liquid world colonies are worth the most (1.0), followed by Rock (0.9), then Frozen (0.8), then Molten (0.7).

A colony set at the same elevation as the hydrosphere or below causes an automatic failure of that colony (a value equal to zero). This is done to avoid the potential division by zero error inherent in the formula used. A colony also automatically fails if the final multiplier is less than zero; colony pods will never cost the player any money over their initial investment.

Finally, once the base value has been modified by the total multiplier, the end value is subject to one last modifier:

• Prior Colony Pods: Subsequent colony pods may be launched on a world with another colony already deployed, but these subsequent colonies will be worth progressively less and less as more pods are deployed on the same planet. Deploying one at the same coordinate set as a pre-existing colony site will cause the new colony to fail completely (i.e. have no value). Each subsequent colony acts as a divisor to the colony's value, with the divisor equal to the total new number of colonies on the planet's surface (i.e. the second colony divides bt two, the third by three, and so on.).

So, the final overall formula is: ((( (base value * total multipliers)/number of colonies )))

Here are a couple of examples:

A player sets a colony down on Earth a good distance from the hydrosphere but close to the planet's equator. This is the first colony on the planet's surface. It is evaluated as follows:

• BASE VALUE
  • Lithosphere: Tungsten (340), Plutonium (420), Platinum (400) ==> value = 1160 * .05 (5% mineral density) = 58
  • Lifeforms: Giant Squid (500), Parascopal Plant (1000), Sabertoothed Mole (300), Apple Tree (560), White-Tailed Deer (280) ==> value = 2640 * .45 (45% biodensity) = 1188
  • Base Value: 1246
• MULTIPLIERS
  • Lifeform Danger: Giant Squid (5), Parascopal Plant (1), Sabertoothed Mole (1), Apple Tree (0), White-Tailed Deer (1) ==> value = 8 * -.1 = -0.8
  • Atmosphere: Nitrogen, Oxygen (1.0)
  • Hydrosphere: Water (for our example, a value of .02 will be used)
  • Type: Liquid (1.0)
  • Gravity: 1.00 G (1.0)
  • Atmo. Density: Very Thin (.5)
  • Temperature: Searing (.75)
  • Global Weather: None (.5)
  • Total Multipliers: 1+.02+1+1+.5+.75+.5-.8 = 3.97
• FINAL TALLY
  • Colony Number: 1 (1/1)
  • GRAND TOTAL VALUE: (1246 * 3.97) / 1 = 4946 MU/wk

A player sets a colony down on Koann III close to the hydrosphere in the mid-latitudes. This will be the sixteenth colony on the planet's surface. It is evaluated as follows:

• BASE VALUE
  • Lithosphere: Titanium (240), Antimony (280), Nickel (100) ==> value = 620 * .45 (45% Mineral Density) = 279
  • Lifeforms: Apple Tree (560), Brown Hopper (2065), Buzzing Duck (425), Common Bos Taurus (1000), Goofball Berry Plant (1865), Heaving Mass (850), Sky Screecher (1000), Tentacled Hexapod (525), White-Tailed Deer (280) ==> value = 8570 * .90 (90% biodensity) = 7713
• MULTIPLIERS
  • Lifeform Danger: Lifeforms: Apple Tree (0), Brown Hopper (1), Buzzing Duck (0), Common Bos Taurus (0), Goofball Berry Plant (0), Heaving Mass (1), Sky Screecher (3), Tentacled Hexapod (2), White-Tailed Deer (1) ==> value = 8 * -0.1 = -0.8
  • Atmosphere: Nitrogen, Oxygen (1.0)
  • Hydrosphere: Water (for this example, a value of .5 will be used)
  • Type: Liquid (1.0)
  • Gravity: 1.40 G (.84, using the formula)
  • Atmo. Density: Thin (.75)
  • Temperature: Temperate (1.0)
  • Global Weather: Moderate (.5)
  • Total Multipliers: 1+.5+1+.84+.75+1+.5-.8 = 4.79
• FINAL TALLY
  • Colony Number: 16 (1/16)
  • GRAND TOTAL VALUE: (7992 * 4.79)/16 = 2392 MU/wk

Ship's Log

This option allows the player to leave notes for themselves in-game. When this option is selected, the ACKNOWLEDGED tone will sound, the gameClock will stop, and a textbox-like area will open up in the MVS. The game will check the player data for the current game to see if there is any text already in the log, and will display any such text that exists. A cursor will be added to the end of any text that exists. A large "Close" button will overlay the Crew Interface Controls. Exiting from the Ship's Log function will require the player to click on this button; there will be no keyboard equivalent. While the interface is active, any key the player presses will be displayed as text. The player may use the arrow keys or mouse clicks to move the cursor to any desired point in the text. The text will default to "insert" mode (any new text is inserted at the point of the cursor), though the <Insert> key may be used to toggle "overlay" mode (where new text replaces what's already present). When the player clicks on the Close button, the ACKNOWLEDGED tone sounds, the text is saved, and game control returns to the Captain's Sub-Menu. It'd be neat if we could set something up where the text could be printed from in-game. Barring that, this could at least be changed so that plain text is saved and restored; this would allow the player to open up a text file outside the program and retrieve their information

Bridge

This option cancels the Captain's Menu and returns the Menu Box over to the Crew Interface Controls. At the same time, the ship's name is displayed in the Name Ship/Active Crew area at the bottom of the MVS and the ACKNOWLEDGED tone is sounded.

Science Officer Options

Sensors

This option allows the player to take a sensor reading. In the original games, this option was used to scan both starships and planets. In SF3, scanning starships had been made an automatic part of the targeting process under the Tactical Interface (for details, see the [Encounter_Module#Interface|Encounter Module]] discussion), which leaves planets (or other space objects, such as stars) as the only thing the player may scan using this menu option. If the player attempts to take a scan in hyperspace, the NEGATIVE tone sounds, the message "SHORT RANGE SCANNERS ARE OFFLINE WHILE WE'RE IN HYPERSPACE, SIR." will be displayed, and game control will remain with the Science Officer's sub-menu. Similarly, if the player attempts to take a scan in inter-planetary space, the NEGATIVE tone sounds, the message "SCANNERS REPORT NO CONTACTS, CAPTAIN." will be displayed, and game control will remain with the Science Officer's sub-menu.

When selected while in orbit of a planet, the SCANNING tone will sound; this is an elongated tone that sounds for approximately two to three seconds. While the tone is being sounded, an outline of the planet will appear in AVS2 and multi-colored "dots" representing lifeform, energy (occupied structures, used on inhabited worlds) and mineralogical readings will begin flashing inside this outline. While this is occurring, the Planetary Exploration Module will be in the process of selecting the initial disposition of objects on the planet's surface (for details, see the discussion under the Planetary Exploration Module); each dot will correspond to the type of object placed (by color) as well as the size of the object place (by size of the dot). Once present, these will continue flashing until the SCANNING tone has stopped, at which point the dots will freeze. Once that occurs, the following basic information on the planet is displayed in AVS2 along with the planet's outline:

• Mass: This will list the planet's mass, in kilograms.
• Bio: This is the planet's biodensity, listed as a a percentage from 0-100.
• Min: This is the planet's mineral density, listed as a percentage from 0-100.

The information presented by a scan will remain in AVS2 until another action takes place that requires the use of that display (such as displaying the Mercator).

Along with the information presented in AVS2, the following pieces of data will appear in the Message Box:

• Atmosphere: The planet's main atmospheric components
• Hydrosphere: The planet's major liquid component
• Lithosphere: The three most common minerals found on the planet's surface.

These data will remain on screen in the Message Box until something else is displayed in that area (such as a subsequent analysis of the sensor scan).

Analysis

This option allows the player to get more in-depth information on a recent sensor reading. The player may delay making an analysis of a sensor reading as long as the planet's outline remains on display in AVS2; doing anything that removes the basic data from view will require the player to take a fresh sensor reading before making an analysis. In the event that a fresh sensor reading is not available, the NEGATIVE tone will sound and the message "I NEED A CURRENT SENSOR READING, CAPTAIN." will display, with game control remaining with the Science Officer's sub-menu.

If a fresh sensor reading is available, the ACKNOWLEDGED tone will sound. At that time, a Planetology Check will be performed, the results of which will determine the specific information displayed (for details on how the check works, see the Technology skill discussion on the Player Data page). Data for display will then be presented; if the information is indicated as something that will be displayed, the necessary information is retrieved from the planet's record. Otherwise, the word "UNKNOWN" will be displayed instead. Once the game determines what data will be displayed, it will go ahead and display that data in the Message Box, returning control to the Science Officer's sub-menu.

The following pieces of data are presented when an analysis is performed, in this order:

• Object: The type of object being scanned; this should in this case always say PLANET..
• Orbit Number: The orbital lane the planet occupies around the star.
• Predominant Surface: The planet's type, either ROCK, LIQUID, MOLTEN, FROZEN or GAS GIANT
• Gravity: The planet's surface gravity. This is particularly crucial information; planets with high gravity are unsafe to visit.
• Atmospheric Density: The density of the planet's atmosphere. Used to help determine sky color.
• Temperature: The categorical planetary temperature range.
• Global Weather: The categorical severity of the overall planetary weather.

All analyses are proceeded with the header "ANALYSIS OF LAST SENSOR READING:", located on its own line. All entries are on their own line except for Object and Orbit Number, which share a line.

Culture

This option gives the player crucial data on any civilizations living on planets that the player visits during the course of the game. When the player enters orbit around a world where there is a culture living there, the message "DOWNLOADING CULTURAL DATA..." will appear in the Message Box (after the "INITIATING ORBITAL MANEUVER..." message appears; see the Interplanetary Travel Module discussion for details) and the DOWNLOADING DATA tone will sound. This is an elongated tone (similar to the SCANNING tone); once the tone has stopped playing, the message "...CULTURAL DATA RECEIVED." will appear in the Message Box.

If the player attempts to use this menu option at any location other than planetary orbit, the NEGATIVE tone sounds, the message "WE ARE NOT IN ORBIT AROUND A PLANET RIGHT NOW, YOU IDIOT." will display in the Message Box, and control remains with the Science Officer's sub-menu. If the player attempts to use this option in orbit of an uninhabited world, the NEGATIVE tone will sound, the message "NO CIVILIZATION DETECTED." will show in the Message Box, and control remains with the Science Officer's sub-menu.

When used while in orbit around an inhabited world, the following information is displayed in the Message Box:

• Inhabited by: The first line of a cultural report always includes the words "INHABITED BY (species)", where (species) is the name of the race inhabiting the planet.
• Tech Level: This indicates the level of technology the species has achieved, and is one of the four tech level categories (STONE AGE, METAL AGE, INDUSTRIAL AGE, STARFARING AGE).
• Population Density: This is a categorical indication of the population's density on the planet (SPARSE, MODERATE, DENSE). Higher densities generally mean it is more likely the player will encounter an inhabited area on the planet's surface.
• Economy: This is a categorical indication of the present global economic level (DEPRESSED, LEVEL, INFLATED). This gives the player an indication of whether the planet would be a better place to buy standard trade goods or to sell such goods instead.
• Trading Style: This is an indication of how eager the species is to haggle (NO TRADING, NO HAGGLING, HAGGLE A LITTLE, HAGGLE A LOT). The word "haggle" is a little more clear of the intent of this function of the game, as opposed to the word "barter", which was used in the original games. This lets the player know just how willing a species will be to change their prices during any transactions that take place.
• Cultural Analysis: This briefly talks about the species in general.
• Will Sell: This lists any specialty trade goods and technologies the species will sell. Technologies will be listed first, followed by specialty trade goods.
• Will Buy: This lists any specialty trade goods and technologies the species will buy. Specialty trade goods will be listed first, followed by lifeforms. Any specialty trade goods the species is particularly interested in will be appended by an asterisk.

Note that in most cases there will be sufficient data that needs to be reported to the player after requesting a cultural analysis that the Message Box will likely have to pause. In this case, the game clock will stop and allow the player to proceed upon a keypress, as is usual with long messages in the Message Box.

Status Because AVS1 constantly displays the ship's status, this option is obsolete as a selectable function of the Science Officer. However, a brief discussion of what will be displayed in AVS1 is warranted.

The Status display shows the following pieces of information:

1. The current stardate (listed as day.hour-month-year. A year is ten months long and a month is 28 days long.)
2. The ship's categorical damage status (listed as NOT DAMAGED, SLIGHTLY DAMAGED, MODERATELY DAMAGED, HEAVILY DAMAGED, SEVERELY DAMAGED, or CRITICALLY DAMAGED)
   1. The determination of the ship's categorical damage is status is determined by taking the damage levels of all systems and dividing them by the number of systems. 1% corresponds to SLIGHTLY DAMAGED, with each subsequent category beginning twenty percentage points higher (i.e. CRITICALLY DAMAGED corresponds to 81% systems damage or higher.)
3. The current amount of available cargo space being used (listed as a percentage; 100% means that the ship's cargo bays and pods are completely full).
4. The current amount of fuel/energy available (listed as a 2-decimal float, giving the actual amount of fuel still available)
5. The status of the ship's Shields (displayed graphically as a bar; a full bar indicates the shields are at full strength for their class rating.)
6. The status of the ship's Armor (also displayed graphically, in the same manner as the Shield Status Bar)
7. The ship's Shield status (Raised/Lowered)
8. The ship's Weapons status (Armed/Disarmed)
9. The ship's alert condition status (Green, Yellow, Orange or Red)

Bridge

This option cancels the Science Officer's Menu and returns the Menu Box over to the Crew Interface Controls. At the same time, the ship's name is displayed in the Name Ship/Active Crew area at the bottom of the MVS and the ACKNOWLEDGED tone is sounded.

Navigator Menu Options

Maneuver

This option allows the player to maneuver their fleet, and is the primary means by which the player can explore while in space. When selected, the game will first check the flagship's hLocation enumeration for its present location. If the location is LANDED, the NEGATIVE tone will sound and the message "WE ARE NOT IN SPACE, CAPTAIN." will be displayed in the Message Box. If the ship is at STARPORT, the NEGATIVE tone will sound and the message "WE MUST LAUNCH FIRST, CAPTAIN." will be displayed in the Message Box.

Otherwise, the game will pass control over to one of the Hyperspace Module or Interplanetary Travel Module, depending upon which one is indicated by the enumeration. If the enumeration indicates IN_ORBIT, the message "LEAVING ORBIT..." will be displayed in the Message Box, followed by the message "...OUTSIDE ORBITAL RANGE. WE ARE FREE AND CLEAR TO NAVIGATE, CAPTAIN." once the Interplanetary Travel Module engages. Otherwise, no message will be displayed.

While the fleet is Maneuver mode, the Maneuver option will remain highlighted on the Navigator's Sub-Menu; all Menu Box controls will be locked down and the mouse will be temporarily disabled. The player player may move their ship through space using WASD keys, the arrow keys, or the numeric keypad (with the 1, 3, 7, and 9 keys reserved for diagonal movement). Pressing the <Space Bar> or <Enter> keys will cancel Maneuver mode and allow the player to utilize the Menu Box controls and mouse once again. Entering planetary orbit cancels Maneuver mode involuntarily, while engaging the autopilot from the Starmap engages it involuntarily. For details on these in-game functions, see the discussions under the Inter-Planetary Travel Module and the Hyperspace Module.

Starmap

This option allows the player to see where they are in space and allows them to either plan a course or actually set one. When selected, control of the game will switch over to the Starmap Interface after the location has been checked (for details on the workings of the Starmap interface, see the discussion under the Hyperspace Module). The routine will return the game to the Starship Interface upon exiting the Starmap. If a set of destination coordinates has been entered into the ship's autopilot, the game routine will then check the flagship's hLocation enumeration for its present location. If the enumeration indicates the ship's position as anywhere besides HYPERSPACE or IN-SYSTEM, the NEGATIVE tone will sound and the message "WE'RE NOT IN SPACE, SIR. I CAN'T ENGAGE THE AUTOPILOT NOW." will appear in the Message Box. Otherwise, the autopilot engages; the fleet will calculate the direction that it needs to move in order to arrive at the ordered destination point along a straight-line course, and will begin to proceed to that location at the fleet's best possible speed. If the fleet is in-system, the direction of travel in hyperspace will be calculated, and the fleet will first head out-system along that directional course (again at the fleet's best possible speed). Engaging the autopilot automatically puts the ship in Maneuver mode; if it is not engaged, control returns to the Navigator's Sub-Menu upon leaving the Starmap Interface.

Bridge

This option cancels the Navigator's Sub-Menu and returns the Menu Box over to the Crew Interface Controls. At the same time, the ship's name is displayed in the Name Ship/Active Crew area at the bottom of the MVS and the ACKNOWLEDGED tone is sounded.

Engineer Menu Options

Damage Report

This option allows the player to learn more about the current status of their ship, to see which systems have become damaged, and to see how bad the damage actually is. This option manually displays the ship's Damage Control Status in AVS2; this is the same dialog that appears in the Tactical Interface's Fleet Status Display with the Status Pane active (for more information, see the discussion under the Encounter Module). When this option is selected, the game will check to see if the display is already up. If so, the message "THE DAMAGE CONTROL DISPLAY IS ALREADY UP, CAPTAIN" will be displayed in the Message Box and the NEGATIVE tone will sound. Otherwise, the ACKNOWLEDGED tone will sound and the display will be shown in ASV2, with game control passing back to the Engineer's Sub-Menu. Note that while the display is the same as that used in the Tactical Interface, the same level of functionality will not be available in the Starship Interface; it merely acts as a display in this case. Ordering a repair requires the use of the Repair option, directly below the Damage Report option on the Engineer's Sub-Menu.

The Damage Report display has a display for each ship system: Shield, Armor, Hull, Engine, Beams, Projectiles, Sensors, Communications and Life-Support. Each display shows the condition of that system via a percentage indicator. Additionally, the indicators are colored to indicate the level of severity of damage to the system. Undamaged systems display in green. Systems damaged up to 20% (lightly damaged) are shown in sky blue, up to 40% (moderate damage) in yellow, up to 60% (heavily damaged) in orange, up to 80% (severely damaged) in red, and up to 100% (critically damaged) in magenta. Destroyed systems are in dark grey.

Damaged systems will affect the ship's performance in many ways. Damaged shields and armor will be less efficient in protecting the ship from further damage. Damaged engines will be slower and less fuel efficient. Damaged weaponry will fire intermittently, have a higher chance of missing (for tracking weapons) and will take more energy. Sensors and communications system damage will affect the accuracy of scans and the success rate of translation and distress call issuance. Life support damage will result in crew damage when the player utilizes their thrusters; the amount of damage will be contingent upon the amount of acceleration available to the ship, with higher accelerations equating to more damage.

Repair

This option allows the player to order the Engineer to begin repairs on a specific damaged system. When this option is selected, the game routine will check to see if any systems are damaged. If not, the NEGATIVE tone will sound and the message "ALL SYSTEMS ARE FULLY OPERATIONAL, SIR." will appear in the Message Box. Otherwise, the ACKNOLWEDGED tone will sound and the game will replace the Engineer's Sub-Menu in the Menu Box with a listing of currently damaged systems. At the same time, the game will check to see if the Damage Report is up in AVS2 and display it if it isn't. The player will be allowed to scroll through the list of damaged systems sing the same set of controls as the rest of the Interface. When the player selects the system they'd like to have repaired, the QUESTION tone will sound and a dialogue will pop up giving the player information on the estimated time to complete repairs and whether or not they wish to proceed. Picking NO closes the dialog, and nothing else happens at that point. Otherwise, the game will check to see if another system is currently being repaired. If there is, the QUESTION tone will sound and a dialogue saying "I AM STILL REPAIRING THE (system name), CAPTAIN. SHALL I DISCONTINUE AND WORK ON THIS INSTEAD?". Selecting NO sounds the ACKNOWLEDGED tone and closes out the dialogue, with repairs continuing on the original system. Selecting YES sounds the ACKNOWLEDGED TONE, closes the dialogue, and switches repairs over to the new system. In either case, when repairs commence on a new system, the message "BEGINNING REPAIRS ON THE (system name), CAPTAIN." will appear in the Message Box. When the system is fully repaired, the message "REPAIRS ON THE (system name) ARE ALL COMPLETED, SIR." will appear in the Message Box, sounding the NOTICE tone at the same time. The Engineer will then pick up repairs on the next most heavily damaged system.

When repairs on a system begin, the game will perform a Skill check for the Engineer. The skill to be Checked depends on the system selected: Shields, Beams and Projectiles will require a Defenses Check, while all other systems will require an Internal Systems Check instead. Note that neither the Hull nor Armor may be repaired while the ship is in flight; both require repairs at Starport. The target number for the Check is equal to the percentage of damage done to the system. If the Check is successful, a percentage of damage is repaired that hour equal to this formula:

((( (Base Repair Percentage) / round up (6 - Engineer's Engineering Discipline Score/50) )))

The base repair percentage is 10% for all systems requiring a Defenses Check and 15% for all systems requiring an Internal Systems Check. For every ten points in the Engineer's skill score, an additional 1% of damage is repaired during hourly repairs to the damaged systems. Also, for every ten points (rounded down) in the degree of success of the Check, an additional 1% systems damage is repaired.

Should the Check fail, then repair minerals will be required to continue repairs on the system. The game will select one of the repair minerals at random and select an amount between one and ten cubic meters of that material. The game will then reduce the indicated amount by .1 cubic meter for every point in the involved repair skill. If the amount required drops to zero or less as a result of this action, then the mineral requirement is automatically resolved as a success. Otherwise, the NOTIFICATION tone will sound and the message "THIS IS ENGINEER (engineer's name). I NEED (amount) CUBIC METERS OF (repair mineral) TO CONTINUE REPAIRS ON THE (system), CAPTAIN." The game will then check to see if the mineral is present in the cargo bay in a sufficient quantity to cover the requirement. It it is, the message "SHALL I TAKE THIS FROM CARGO?" will appear immediately after the initial message, with a YES and NO dialogue also appearing. Gameplay is paused while the player decides. Either selection sounds the ACKNOWLEDGED tone and closes the dialogue. If the player selects YES, the minerals are removed from the ship's cargo stores and the situation is resolved as a success. If the player selects NO, or if there isn't a sufficient amount of the correct mineral available, the message "I AM CEASING REPAIRS AT THIS TIME." will appear, and repairs will stop on the indicated system. The indicated amount of the indicated mineral must be gathered before the player may resume repairs on that particular system, though the Engineer is free to work on other systems as necessary. A successful mineral Check will allow the repair of one-half the normal amount, and no bonuses are given for the Engineer's skill levels.

The player may never repair destroyed systems except at Starport; any attempt to do so will sound the NEGATIVE tone and display the message "THE (system name) SYSTEM HAS BEEN COMPLETELY DESTROYED, SIR. WE'LL NEED TO RETURN TO STARPORT TO REPLACE IT.". A starship is destroyed when it sustains 100% hull damage; if the player's flagship reaches 100% hull damage, the player's character is killed when their ship is destroyed and the game is over.

Jump Pod

This option allows the player to use a jump pod in an attempt to move their fleet instantaneously to a set of desired coordinates. When this option is selected, the game will first check to see if any ship in the fleet is equipped with a jump pod. If not, the message "WE DON'T HAVE ANY JUMP PODS, CAPTAIN" will be displayed in the Message Box and the NEGATIVE tone will sound. Next, the game will check the flagship's location enum to see if the fleet is currently in hyperspace. If it isn't, the message "WE ARE NOT CURRENTLY IN HYPERSPACE, CAPTAIN" will be displayed in the Message Box and the NEGATIVE TONE will sound. Finally, the game will check the flagship's current fuel status. If the flagship does not currently have at least 15 cubic meters of fuel aboard, the message "WE DO NOT HAVE ENOUGH FUEL TO USE A JUMP POD, CAPTAIN" will be displayed in the Message Box and the NEGATIVE tone will sound.

Otherwise, the message "ACTIVATING STARMAP" will be displayed in the Message Box, the ACKNOWLEDGED tone will sound and control of the game will switch over to the Starmap Interface after a brief delay (for details, see the discussion of the Starmap under the Hyperspace Module). A flag within the Starmap's routine will note that the jump pod routine called it, and will return the entered coordinates to the jump pod routine. At that point, the game will return control to the Starship Interface. If no coordinates are returned, the game will automatically assume the player changed their mind about using the jump pod. Otherwise, the message "JUMP PODS CONSUME 15 CUBIC METERS OF FUEL. OK TO PROCEED?" will be displayed in the Message Box, with the options of YES and NO appearing in the MENU BOX. If the player selects "NO", the ACKNOWLEDGED tone sounds and control reverts back to the Engineer's Menu.

Otherwise, the game will calculate the likelihood of a successful jump. This will use the traditional method of calculating jump pods success as listed on www.starflt.com; the game will look for all stars within ±seven coordinates of the target coordinates and assign them a value based upon which axis they are closest to those coordinates (a star one coordinate away has an influence of 20, two away counts as 15, three as 10, four as 5, five as 2, and six and seven as 1). For purposes of this value assignment, the x= and y= axis are treated separately; the star's distance to the destination is the larger of either the x or y values. For example, a star is located 5 coordinates downspin and 2 coordinates coreward of the destination. For purposes of using a jump pod, that star is five coordinates away from the destination, and thus has an influence value of 2.

If there is a star at the target coordinates, an automatic failure occurs; the player may target a flux if they so choose, and will appear just outside the flux's event horizon if the jump is successful. The values are tallied together as they are assigned, and the final value becomes the probability of a successful jump. If the final probability is less than ten percent, the probability is set to ten percent; likewise, any probability over 95% becomes 95%.

Once the probability has been calculated, a Check is made of the Engineer's Quantum Mechanics Skill, with the DC set equal to a value equal to (100 minus the total calculated influence). If the Check is successful, the fleet will arrive on target. If not, the game will place the fleet some distance away, with the distance increasing based on the degree of failure of the Check. Regardless of whether the Check is successful or not, the final probability is shown in an animation in the MVS, flashing three times and sounding the NOTIFICATION tone each time, followed by the flux animation and a message stating whether the fleet arrived on target or not.

Bridge

This option cancels the Engineer's Sub-Menu and returns the Menu Box over to the Crew Interface Controls. At the same time, the ship's name is displayed in the Name Ship/Active Crew area at the bottom of the MVS and the ACKNOWLEDGED tone is sounded.

Communications Officer Menu Options

Hail Because hailing occurs during encounters only, it is a function that needs only to be covered by the Tactical Interface. As a bridge function, it would be redundant. For a discussion of how to hail targets during encounters, see the discussion under the Encounter Module. For details on the functions of communicating with alien races, see the discussion under the Communication Mechanics, Interface and Engine

Distress

A number conditions may leave the player stranded with no possibility of further actions. Examples include running out of fuel or having destroyed or inoperative engines which cannot be repaired. In this case the player has the option to put the crew into cryogenics (sleep pods) and sending a emergency distress call for rescue. From the player's point of view the transition from where they are to Starport is instantaneous. An animation may be played here for the return to Starport, either simply a fade to black and reappearance at Starport, or a high-speed travel animation, or a Fallout style moving animation of a cryogenics pod.

When the player selects the Distress option, the QUESTION tone will sound and the message "ARE YOU SURE YOU WANT TO SEND A DISTRESS SIGNAL, SIR?" will appear in the Message Box, along with a dialogue for selecting YES or NO. If the player selects NO, the dialogue closes and control returns to the Communications Officer's Sub-Menu.

Otherwise, the game will measure the current distance of the player's fleet to the closest Starport, which is where the player will appear if their distress call is successful. A Check is then made of the flagship's Communications Officer's Distress skill, with the DC of the Check starting at 50 and increasing by one point per hyperspace coordinate unit distance to Starport. Note that a player can issue this kind of distress call during an encounter as well, though if there are unfriendly combatants in the area, the DC of the Check will be much higher.

A successful Check will result in the player's fleet being towed back to Starport with the crew in stasis. This process will cost the player a stiff fine, which is determined as a factor of the the amount of time it takes to get back to port. This will be based on the slowest craft in the player's fleet; the normal travel time to the Starport along a straight-line course will be calculated and then multipled by three. Each full hour involved in the tow will cost the player 5000 MU. Towing charges are assessed at the Operations office at Starport, under Evaluations. The player is required to view the evaluation before they launch again. Towing charges may make a player's financial status negative.

Should the Check fail, the NEGATIVE tone will sound, and a message stating "I'M SORRY SIR, THERE SEEMS TO BE TOO MUCH INTERFERENCE. I CANNOT RAISE STARPORT AT THIS TIME". This may leave the player in a bad situation; some exceptions may be allowed for a bad check in this case, such as what may happen if the player has a destroyed engine.

Playback

This option enables the player to revisit a recent conversation they had with an alien species. When selected from the Communication's Officers sub-menu, the ACKNOWLEDGED tone sounds and the Menu Box will list the date and time of the last six conversations the player had, with a seventh option labeled "EXIT" also available. Selecting EXIT will sound the ACKNOWLEDGED tone and send the Menu Box back to the Communications Officer's Sub-Menu.

Selecting any other conversation will pause the game and begin displaying the message (with formatting) in the MVS. Scroll buttons and a slider will be provided to the player to allow them to access any point in the conversation with their mouse. Likewise, the up-and-down arrow keys will allow the player to move through the text. The <Page Up> and <Page Down> keys may also be utilized to move whole screen lengths at a time. Finally, the <Space Bar> will back out of the conversation, returning control to the message selection options in the Menu Box.

Bridge

This option cancels the Communications Officer's Sub-Menu and returns the Menu Box over to the Crew Interface Controls. At the same time, the ship's name is displayed in the Name Ship/Active Crew area at the bottom of the MVS and the ACKNOWLEDGED tone is sounded.

Doctor Menu Options

Examine

This option allows the player to learn more about the vitality status of the crew of their ship. When this option is selected, the game will check to see if the Doctor is currently treating anyone. If so, the message "I AM STILL TREATING A PATIENT, CAPTAIN. SHALL I STOP AND DO THIS INSTEAD? (YES/NO)". The YES and NO options will be displayed in the Menu Box. The player must answer before the game proceeds. If the player answers "NO", the Menu Box will exit to the Doctor's Menu, sounding the ACKNOWLEDGED tone.

Else, the message "WHO DO YOU WISH TO EXAMINE?" will be displayed and the ACKNOWLEDGED tone will sound. A list of the names of the ship's crew will be displayed in the Menu Box, along with a "NEVER MIND" option at the bottom. Selecting NEVER MIND aborts the action and returns the Menu Box to the Doctor's Menu, sounding the ACKNOWLEDGED tone.

On any other selection, the game will access the Starship's Crew dictionary and finds the Character object with the matching Name key, and will then get the information on that character's fVitality float, szDrainID string and nDrain integer. It will then report a categorical condition of the character, based on their present Vitality as follows:

Categorical Character Condition based on Vitality Score

Vitality Score Range	Categorical Condition
100%	NOT WOUNDED
80-99%	SLIGHTLY WOUNDED
60-79%	MODERATELY WOUNDED
40-59%	HEAVILY WOUNDED
20-39%	SERIOUSLY WOUNDED
01-19%	CRITICALLY WOUNDED

The game will assemble the following string: " (character_billet) (character_name) IS (character_vitality_status), WITH AN OVERALL VITALITY OF ((character_vitality) * 100)%". If the character's szDrainID string is not empty, that string will replace the (character_vitality_status) in the string, and the phrase ", DROPPING (nDrain/HP * 100)% HEALTH PER HOUR" will be appended to the end. Once assembled, the string will be displayed in the Message Box, the ACKNOWLEDGED tone will sound, and the Menu Box will return to the Doctor's Menu.

Treat

This option allows the player to actively single out and rapidly heal any one member of their crew. When this option is selected, the game will check to see if the Doctor is currently treating anyone. If so, the message "I AM STILL TREATING A PATIENT, CAPTAIN. SHALL I STOP AND DO THIS INSTEAD? (YES/NO)". The YES and NO options will be displayed in the Menu Box. The player must answer before the game proceeds. If the player answers "NO", the Menu Box will exit to the Doctor's Menu, sounding the ACKNOWLEDGED tone.

Else, the message "WHO DO YOU WISH TO TREAT?" will be displayed and the ACKNOWLEDGED tone will sound. A list of the names of the ship's crew will be displayed in the Menu Box, along with a "NEVER MIND" option at the bottom. Selecting NEVER MIND aborts the action and returns the Menu Box to the Doctor's Menu, sounding the ACKNOWLEDGED tone. On any other selection, the game will access the Starship's Crew dictionary and finds the Character object with the matching Name key, and will then get the information on that character's fVitality float, szDrainID string and nDrain integer. If the fVitality equals 1.00 (i.e. the character is not wounded at all), the szDrainID string is empty (i.e. the character has no afflictions) and nDrain equals zero, the message "THIS CREWMEMBER DOES NOT REQUIRE TREATMENT" will be displayed in the Message Box, the NEGATIVE tone will sound, and the Menu Box returns to the Doctor's Menu. Next, the game will check the character's Being_Treated flag. If the flag indicates the character is being treated, the message "THIS PATIENT IS ALREADY BEING TREATED" will be displayed in the Message Box, the NEGATIVE tone will sound, and the Menu Box will return to the Doctor's Menu.

If any of the above conditions are not fulfilled (i.e. if the float does not equal 1.00 or some kind of drain is indicated), the message "I AM BEGINNING TREATMENT ON (name)" is displayed in the Message Box, where "name" is the matching Name String of the indicated Character object. That character's Being_Treated Flag is switched to TRUE and the ACKNOWLEDGED tone will sound. Player control will return to the Doctor's Menu at that point.

Character Healing
Character healing is one of the functions that takes place during the game's hourly Check. When the game makes an hourly Check, all characters on the ship are checked for injuries; this involves checking their fVitality float, szDrain string and nDrain integer, using the same conditions as indicated above for Treatment to determine if the character needs to be healed. If the game determines that healing is required for a character, the internal healMe() method is called.

Wounded characters have a standardized natural healing rate, which depends both upon their current health and current location as outlined in the following table:

Character Natural Healing Rate Based on Health and Location

Location	Vitality <25%	Vitality 25-70%	Vitality >70%
Vehicle	-1 HP / 3 hrs	+1 HP / 12 hrs	+1 HP / 4hrs
Ship	±0 HP / hr	+ 1 HP / 6 hrs	+1 HP / 2hrs

In addition, a character has a chance of recovering without assistance from any draining condition any time they recover HP during the healing process. This chance is solely dependent upon the character's Durability (which is set based upon their species). A random number from 1-20 is generated by the game; if the result is less than or equal to their Durability, the draining condition is canceled out. A character cannot gain HP while a draining condition is still in effect; instead, they lose the amount of HP indicated by that condition.

When being treated by a doctor, the character's natural healing rate is augmented based upon their location, using the following formulas:

• Ship: (Doctor's Treatment Skill + Doctor's Medicine Discipline Score)/20
• Vehicle: (Doctor's Treatment Skill + Doctor's Medicine Discipline Score)/40

In both cases, the result of the formula is rounded down to the closest integer and added to the amount of the character's natural healing, along with the bonus from the doctor's Xenobiology Skill score (as outlined in the discussion of that skill on the Player page). Should the character have a draining condition (and thus be unable to regain HP), the Doctor's Specialized Treatment Skill replaces the Treatment Skill in the formula; the result of the formula is subtracted from the result of the random number Check for canceling out the condition instead.

While at Starport, the healing rate of characters depends entirely on whether or not the port has an Infirmary or not. If it does not, healing occurs at the starship rate. If it does, however, all wounded characters may be treated simultaneously, and gain bonus imparted from a Doctor with a 100 point Treatment and 250 point Medicine equivalency.

Note that in all cases of healing, the amounts healed are in HP, not in percentage Vitality. After any form of healing takes place, the internal checkMyVitality() method must be called to recalculate the character's fVitality float. Should a character's HP rise above their maximum as a result of healing, any additional healing points are lost. Temporary HP imparted to the character from the Doctor's Biofortification Skill should be included in all Vitality calculations.

This section may differ from what's on the Player page, where healing by a Doctor is treated as a Check. I kinda like this version better; if there is a substantial difference, go with this version.

Bridge

This option cancels the Doctor's Menu and returns the Menu Box over to the Crew Interface Controls. At the same time, the ship's name is displayed in the Name Ship/Active Crew area at the bottom of the MVS and the ACKNOWLEDGED tone is sounded.

Tactical Officer Menu Options

Raise/Drop Shields

This option toggles the shields on the player's flagship from active to inactive and vice versa. Shields add to the survivability of the player's ship, but have an associated energy drain when in use (when raised, they will have a constant power draw of 0.1 m^3 of fuel per hour). When the Tactical Officer's interface is selected, the game will check the status of the shields on the flagship. If there are no shields or if the shields are down, the option "RAISE SHIELDS" will be listed in the interface. Otherwise, the option "DROP SHIELDS" will be displayed instead.

When the RAISE SHIELD option is selected, the game will first check to see if there are any shields installed on the flagship. If there are no shields installed, the NEGATIVE tone will sound and the message "WE DO NOT HAVE ANY SHIELDS, CAPTAIN". will be displayed in the Message Box. Otherwise, the game will call the internal toggleShield() method of the ship's Shield object. The method will sound the SHIELDS UP tone, set the Shield object's Shield Hit Points equal to the Shield Current Maximum HP for each arc (these values are used instead of the Shield Maximum Hit Points value to prevent the player from regaining full shields in an encounter by simply toggling their shields off and on in rapid succession.), calculate the current shield status percentage for each arc, change the Shield status message in the ship's Status box in AVS1 from "DOWN" to "UP" and change the shield power icon bars from grey to blue, add 0.1 to the ship's FuelDrainageRate float, change the Shield_Status flag from False (dropped) to True (raised), and display the message "RAISING SHIELDS, CAPTAIN" in the Message Box. After the method has completed running, the ship's changeAlertStatus() method will be called, which will set the ship's status to Condition Yellow (if the weapons are not already armed) or Condition Red (if they are). Player control will return to the Tactical Officer's Menu at that point, with the interface updated to say DROP SHIELD instead of RAISE SHIELD.

For the DROP SHIELD option to be even be displayable, the ship must have shields installed and already raised; there is no need to check for these conditions again. When the DROP SHIELD option is selected, the game will call the internal toggleShield() method of the ship's Shield object. The method will sound the SHIELDS DOWN tone, set the Shield object's Shield Hit Points to zero in each arc, change the Shield status message in the ship's Status box in AVS1 from "UP" to "DOWN" and change the shield power icon bars from blue to grey, subtract 0.1 to the ship's FuelDrainageRate float, change the Shield_Status flag from True (raised) to False (lowered), and display the message "LOWERING SHIELDS, CAPTAIN" in the Message Box. After the method has completed running, the ship's changeAlertStatus() method will be called, which will set the ship's status either to Condition Green (if the weapons are not already armed) or Condition Orange (if they are). Player control will return to the Tactical Officer's Menu at that point, with the interface updated to say RAISE SHIELD instead of DROP SHIELD.

Arm/Disarm Weapons

This option toggles the weapons on the player's flagship from active to inactive and vice versa. Weapons allow the player to engage hostile targets; this is necessary for some of the intended game quests. Weapons have no outright power drain associated with keeping them armed; they only draw power when fired. When the Tactical Officer's interface is selected, the game will check the status of the weapons on the flagship. If there are no weapons or if weapons are disarmed, the option "ARM WEAPONS" will be listed in the interface. Otherwise, the option "DISARM" will be displayed instead.

When the ARM WEAPONS option is selected, the game will first check to see if there are any weapons installed on the flagship. If there are no weapons installed, the NEGATIVE tone will sound and the message "WE DO NOT HAVE ANY WEAPONS, CAPTAIN". will be displayed in the Message Box. Otherwise, the game will call the ship's toggleWeapons() method. The method will sound the ARM WEAPONS tone, change the internal Weapons_Armed flag from False to True, set the Weapon_Recharging flags for all weapons from False to True (increasing the rate of the ship's energy expenditure), change the Weapons status message in the ship's Status box in AVS1 from "UNARMED" to "ARM", and display the message "ARMING (weapon type) (weapon mount)" in the Message Box for all weapons in the ship's arsenal, where (weapon type) is the name string of all the types of weapons installed on the ship and (weapon mount) is either RACKS or TURRETS, depending on what the ship has available and if there is in fact a weapon system installed on that particular mount. Once all other messages have been shown in the Message Box, the message "ALL WEAPONS READY, CAPTAIN." will be displayed in the Message Box. After the method has completed running, the ship's changeAlertStatus() method will be called, which will set the ship's status to Condition Orange (if the shields are not already up) or Condition Red (if they are). Player control will return to the Tactical Officer's Menu at that point, with the interface updated to say DISARM instead of ARM WEAPONS. Weapons may only be fired while the Tactical Interface is active (for details, see the discussion under the Encounter Module); this gives the player the opportunity to prepare for combat when entering a known hostile area. Every time a weapon is fired a certain amount of energy is consumed.

For the DISARM option to be even be displayable, the ship must have weapons installed and already armed; there is no need to check for these conditions again. When the DISARM option is selected, the game will call the ship's toggleWeapons() method. The method will sound the DISARM WEAPONS tone, change the Weapons status message in the ship's Status box in AVS1 from "ARMED" to "UNARMED", change the Weapons_Armed flag from True (armed) to False (disarmed), set the Weapon_Recharging flags for all weapons to False regardless of their current status, and display the message "POWERING DOWN ALL WEAPONS, CAPTAIN" in the Message Box. After the method has completed running, the ship's changeAlertStatus() method will be called, which will set the ship's status either to Condition Green (if the shields are down) or Condition Yellow (if they are up). Player control will return to the Tactical Officer's Menu at that point, with the interface updated to say ARM WEAPONS instead of DISARM.

Bridge

This option cancels the Tactical Officer's Menu and returns the Menu Box over to the Crew Interface Controls. At the same time, the ship's name is displayed in the Name Ship/Active Crew area at the bottom of the MVS and the ACKNOWLEDGED tone is sounded.

Methods

Ship_Interface_Handler Class Methods

_init_(XML)

The argument flag is designed to be a way of indicating whether the game will be set to load data from XML files or from the saved toybox file. While the game is being tested, the flag should be set to True to load from XML. When the game is ready for public dissemination (including any public alpha tests), this flag should be set to False.

The method's initializer creates a list of menu options for the Starship Interface, either by drawing loading the list in from the Toybox object or by parsing the appropriate XML file. The names of all main level objects are stored as keys in the Main_Menu_Functions dictionary, and the names of all submenu-level object are stored in the Sub_Menu_Functions dictionary, also stored as keys. Each key is given a list for a value. The first value in the list is always FALSE when the list is generated. The second value in the list is the name of the method that is activated when the first value becomes TRUE (when the menu option is activated). Any additional values in the list deal with color, display method and position, in that order). Once the dictionaries have been seeded with the necessary information, the method goes out of scope.

Starship Class Methods

toggleShield()

This method's purpose is to change the status of the ship's shields, either to active from inactive or vice versa. When called, the status of the Shield_Status flag is checked. If it is FALSE, the flag is set to TRUE and a call is made to the Combatant component of the starship object to set the shield hit points for each defensive arc to the current shield hit point value for each arc (the values in the vnCurSHP list); this value is used instead of the nMaxSHP integer to prevent the player from being able to instantly recharge their shields up to full strength by simply switching them off and turning them back on immediately. If the Shield_Status flag is TRUE, the flag is set to FALSE and a call is made to the Combatant component of the starship object to set the shield hit points for each defensive arc to zero. The values of the vnCurSHP are kept, but are not used; they will continue to "recharge" towards the maximum value while inactive.

In either case, once the SHP values have been reset, a call is made to the changeAlertStatus() method.

toggleWeapons()

This method's purpose is to change the status of the ship's weaponry, either from disarmed to armed or vice versa. When called, the status of the Weapons_Armed flag is checked. If it is FALSE, the flag is set to TRUE. The recharging flags for the four weapons types (Beam Racks, Beam Turrets, Projectile Racks, and Projectile Turrets) are set to TRUE as well, reflecting the charging of the weapons systems. If the Weapons_Armed flag is TRUE, it is set to FALSE and the recharging flags are set to FALSE, regardless of their prior status (with the Weapons_Armed flag set to FALSE, weapons will not fire; it acts as the "master arm" switch for the ship). In either case, once the flags have been reset as necessary, a call is made to the changeAlertStatus() method.

changeAlertStatus()

This method's purpose is to set the ship's alert condition color, a function used mainly for the player's ship. When called, it goes to the AlertStatus enumerator dictionary and sets the flags of all four values (GREEN, YELLOW, ORANGE and RED) to FALSE. It then checks the status of the Shield_Status flag and the Weapons_Armed flag, and sets the value of one of those flags to TRUE. If the Shield_Status and Weapons_Armed flags are both FALSE, GREEN is set to TRUE. If Shield_Status is TRUE but Weapons_Armed is FALSE, YELLOW is set to TRUE. If Shield_Status is FALSE but Weapons_Armed is TRUE, ORANGE is set to TRUE. Finally, if both Shield_Status and Weapons_Armed are both TRUE, RED is set to TRUE.

The method then checks to see if a status window is open where the ship's alert status would be displayed. If such a window is open, the method updates the graphic to reflect the ship's current alert status.

XML

The Ship_Interface and Starship objects, like most of the other objects in the game, are largely XML driven; this will help keep them flexible up until SF3's design is finalized (i.e. starship classes and menu options for the Starship Interface can be added and removed from the game freely, based upon what data is available in the XML files). Starship objects are reliant on two XML files for their data, one for their specific record (the file "craft_records.xml") and one for details on the equipment indicated in their record (the file "equipment.xml"). Both of these files are discussed in detail under the Fleet Configuration Module). The Ship_Interface object is dependent upon one file, which contains information on the names of the specific options in the the menus as well as information on which methods those options will activate (the file "ship_interface.xml"). This file is one of the (interface_name).xml files described in detail in the Core Module.

Module Status

This is current as of August 1, 2011

This module is currently in the final design phases; while specific descriptions of the intended functions of modules have yet to be written, the remainder of the module's basic description is complete at this point. Further design work on this module has been frozen for the time being, and will remain so until I'm ready to begin method descriptions for all remaining extant modules. This module will require a good deal of work with method descriptions, and will likely need substantial tweaking before it works the way its intended to. Still what's here should be sufficient for the design team to proceed with coding of the module.

---

NEXT: Hyperspace Module / Inter-Stellar Travel
PREVIOUS: Casino Interface and Module
TOP

---