SDS Link   Far Reaches Campaign

Divider

Rules Modifications, Clarifications, And Additions
to Starfire and Imperial Starfire
for the

Far Reaches Campaign

This write up prepared by David Ternes
Version 2.07, 14 November 2000
Space Master: Ken Buchs


Table Of Contents

Introduction
    Description
    Updates
    Core Rules
    Support Software
    Game Communications
    Submission Deadlines
    Battles
    Problems, Space Master Errors, Etc.
    Space Master Precedence
Startup And General Information
    Startup Rule
    Startup Rule Modification
    Startup Data Required
    Permitted Technologies
    Home System Protection
    NPR Occurrence
    NPR Controllers
    Optional Rules Used
    Data Files Required
    File Naming Conventions
    E-Mail Message Conventions
Rules Modifications - Starfire, 3rd Ed., Revised
    Spare Drive Rooms
    Ramming
    Simultaneous Written Movement
    Weapons Fire Allocation
    Asteroid Fortresses - Pre Fabrication
    Asteroid Fortresses - Tractors Beams Required
    Missile Cost And Usage
    Crew Grade
    Tug Rooms
    Crew Quarters / Crew Size
    Construction Restrictions - Work Per Module
    Construction Restrictions - Tasks Per Module
    Construction Restrictions - Module Build Rate Limits
    Guns As Weapons
    Spaceport (SP) In PDC
    Spaceport (SP), Purpose
    Cargo Handling Systems (CHS & CHS2)
    Courier Drones - In Refits
  Rules Modifications - Sky Marshal #2
    Tech Tree Prerequisites
    New Mass Production Rule
    Orbital Motions
    Duration Of A Probe
    CFN Startup For Ind-2 / HT 1 Race
    Contested Systems
    In-System CFN
    PTU Placement
    One Method Of How To Handle The CFN
    Industrial Expansion Units
    Strategic Movement System Body Survey
    Surveying Non-HT Populated Systems
       (Strategic Movement System Body Survey)
    NPR Strategies
    Basic Determinants (NPR Strategies)
    Political States
    Data Tables
    Tech Systems Codes And Information
    Starfire Sequence Of Play
Rules Modifications - Imperial Starfire
    Planet / Moon System Movement
    Presence Of NPR Civilizations
    Ships Sharing Maintenance
Rules Modifications - General
    NPR Creation
    Locations Of Newly Built Units
    Abilities Of Commanders
    Learning Racial Characteristics
Working With SA And The SM
    General
    Changing Unit Names
    Ship Names
    Systems Removed During Refits
    Reusing Stored Systems
    Pre Fab Construction
    Assigning Small Craft
    Ship Maintenance
    Exceeding CFN Or Monetary Limits
    Economic Level Research
    Assisted R&D
    Treaties
    Limitations On Populating Asteroids
    Building Small Craft Automatically
Appendix I - Sky Marshal #2 Rules In Use
Appendix II - Optional Rules In Use
    Pulsed Movement
    Simultaneous Transit
    Break-Off And Surrender
    Break-Off And Surrender
    HTL NPR Governments
    Interstellar Expansion

Copyright © 1999-2000, David H. Ternes, Fort Wayne, Indiana.
Starfire and Imperial Starfire are Copyright © by Starfire Design Studios.


Introduction
TOC

Description
This is an Imperial Starfire campaign. These Rules Modifications, Clarifications, And Additions (MCA), document specific rules and conditions for use in this campaign.

Updates
This write up will be updated throughout the campaign. New versions will be released as needed. Each new version will supersede all previous releases.

Core Rules
The rules used in the campaign will be, in order of precedence:

  1. These Rules Modifications, Clarifications, And Additions
  2. Starfire Assistant program
  3. Starfire, 3rd Edition, Revised
  4. Sky Marshal #2
  5. Imperial Starfire

The following Starfire related products also contain information (notably system descriptions) which will be used during the campaign.

  1. Alkelda Dawn
  2. Crusade
  3. ISW-4

It shall be the responsibility of each player to learn the rules, and it shall be assumed that players have access to these rules.

Support Software
The Space Master (SM) will use the Starfire Assistant (SA) program by Steve Walmsley to control those aspects of the campaign supported by the program. In cases where the program may be at odds with the above listed rules, the program shall take precedence, unless exempted herein. Players are not required to have SA, and SA data files will not be distributed to players. Players will need the ability to access Microsoft Excel files (version 5.0 or later).

Game Communications
All players must have e-mail capability.
    All players will be required to send and receive turn information electronically. A Turn Information File will be sent to each player each turn to document each race under that player's control. A Player Log File will be required from each player for each race under the player's control to record and communicate the player's orders for each race. These files will be in Microsoft Excel 5.0 format.
    Other campaign related information will be sent to players by e-mail, communicated in person or via telephone, and, when appropriate, will be documented on the campaign's web site at http://www2.fwi.com/~dht/starfire/.

Submission Deadlines
The Space Master shall set a submission deadline for each turn's Log Files. This deadline shall be communicated to the player with the transmission of the Turn Information File. Failure to submit turn orders will result in no new orders being entered for the player's race(s).
    Players may submit future turn orders (i.e., orders for turns beyond the current turn). If this is done, failure to provide an update to the submitted orders by the deadline will result in the original orders being used. The Space Master reserves the right to limit the submission of future turns should it become too difficult to track.
    Any player who fails to submit turns or fails to confirm previously submitted turns for a period of four consecutive turns will be dropped from the campaign. In this case, the player's race will become an NPR. Players will not be allowed to resume control of their race as a Player Race.

Battles
Unless otherwise agreed by the involved players and the Space Master, all battles will be played at The Keep (4720 Parnell Avenue, Fort Wayne, Indiana). The Space Master need not be present for a battle to be executed.

Problems, Space Master Errors, Etc.
Problems with turns, misunderstandings in communications, and errors by the Space Master are inevitable. Any errors which are the specific fault of the Space Master will be corrected if possible. However, the Space Master reserves the right to declare a situation "an act of God" if it cannot be readily corrected or to convert an honest mistake into a permanent part of the campaign.

Space Master Precedence
All players are reminded that one rule shall override all others.


Startup And General Information
TOC

Startup Rule
The New Empires Campaign - Balanced Starting Forces rule (24.05b, Sky Marshal #2, page 57) shall govern the setup of players in the campaign, with some modification.

Startup Rule Modification
The following modifications have been made to the Startup Rule.

  1. All player race home systems will have two habitable worlds (T worlds).
  2. All player race home systems will have at least one and at most three asteroid belts.
  3. There is no guarantee on the number of warp points in the systems immediately adjacent to a player race's home system.
  4. Player races will not start on ST worlds.
  5. No NPR will be present in a system next to a player race's home system.
  6. All player races start at High Tech Level 1 (HT1), with all of the systems for HT1 and earlier.

Startup Data Required
Players will be responsible for providing the complete startup information from the Startup Rule (above). The specific information required may be found in Sky Marshal #2 and also on the campaign's web site. The web site also has additional help information for the startup.
    Players may provide the Space Master with general suggestions as to what they would like to see for the racial attributes (RC, RM, RD, and RO) for their player race. The Space Master is under no commitment to honor such requests, but may adjust racial attributes where appropriate.

Permitted Technologies
AlkA list of all technologies and systems permitted to player and non-player races will be compiled and maintained separate from this document. Only those technologies and systems specifically included on that list may be used in the campaign.
    Technologies and systems on this list may include those listed in Starfire (3rd Edition, Revised), Imperial Starfire, Alkelda Dawn, Crusade, and ISW-4.

Home System Protection
No closed warp points will be allowed to access a player race's home system.

NPR Occurrence
The Space Master desires that this campaign focus on the interactions of the player races, not on Non-Player Races (NPRs). Therefore, the odds for the occurrence of NPRs will be reduced by the Space Master as exploration occurs. The exact level of NPR reduction and the method of implementing the reduction will be known only to the Space Master.

NPR Controllers
Players are required to help with the running of NPRs. Each player must, when requested by the Space Master, agree to control at least one NPR. Players may be asked to control additional NPRs, but they are required to control only one NPR. Persons not actively part of the campaign may also be brought in to control NPRs.

Optional Rules Used
The optional rules used by the campaign will be listed in Appendix II. The specific rules used are subject to change.

Data Files Required
Information will be transmitted between the Space Master and the individual players via three data files. Each of these files has a specific function. Use of two of these files is mandatory, the third is optional.

  1. Turn Information File - This file is sent by the Space Master to a player. It documents the current status of one race (PR or NPR). A player may receive more than one Turn Information File per turn (one per race controlled). The format of this file is set by the Space Master and is not subject to change by the players. This is a mandatory file.
  2. Log File - This file is sent by the player to the Space Master. It contains the player's orders for one race. A player may send more than one Log File per turn (one per race controlled). The format of this file is set by the Space Master and may not be changed by the players. The use of this file is mandatory.
  3. Fleet File - This file is used to document the current status of the forces controlled by one race. It includes information about the race's military organizations, ships, armies, commanders, etc. The format and organization of this file may be set up by the individual player, or the file available on the web site may be used. The file is sent to the Space Master as needed to verify that the Space Master's recorded information about a race's forces agrees with that of the player.

File Naming Conventions
Specific naming conventions have been adopted for the naming of the files used to communicate between the Space Master and the players. These conventions are based on the lowest common limits and requirements for Microsoft Windows (Yuck! Macs rule!). The conventions allow for the easy sorting and storage of files, and for the quick identification of the contents of each file. The use of these conventions is mandatory.

E-Mail Message Conventions
All e-mail messages sent to the SM for or about the Far Reaches Campaign must begin with five specific characters. These are; "[SF2] " (note space after the closing bracket). Messages which do not begin with these exact characters may be incorrectly routed by his mail utility. The SM shall not be responsible for anything contained within an improperly marked message.


Rules Modifications - Starfire, 3rd Ed., Revised
TOC

Spare Drive Rooms
Reference:   03.01.02
Page:   11
Change:   1) Ships mounting spare drive rooms, other than tug engine rooms, must use engine rooms consistent with those required for the ship's hull type. This means, for example, that a heavy cruiser, which normally carries two engines per engine room, may only have spare engine rooms which have two engines per room (ships with uneven engine counts per room, such as light cruisers, must alternate the sizes of their spare engine rooms).
    2) A ship may never benefit from more than the maximum number of engines for its hull type, and may never benefit from two different types of engines at the same time (tug rooms are not included in this prohibition, see 08.02.02.5 below). When a ship takes damage, the effects of spare engine rooms may come into play immediately (ex. a ship with one extra engine room, which has an engine room destroyed, need not reduce speed). A ship must still follow the rule as written to switch between different types of engines.
    A ship which does not have a "tug room" (see 08.02.02.5 below) may not activate spare engine rooms above the normal number allowed for its hull type when towing (i.e., even when towing, a non-tug may not activate extra engine rooms).
Rationale:   As written, the rule makes spare engine rooms effectively useless, except in very special circumstances.
    One also wonders what happens when a ship with a spare engine room tractors another ship, and is allowed (under the tractored movement rules) to activate the extra engines. If that ship later turns the tractor off, what happens to its extra active engines? Is it required to stop and deactivate them (unfair and unreasonable at the least), or does it continue with them active but giving no benefit (contrary to the rule as written)?

Ramming
Reference:   03.07
Page:   15
Change:   This rule will not be used. There will be no ramming.
Rationale:   The SM doesn't like the concept, and doesn't want it in the campaign.

Simultaneous Written Movement
Reference:   03.08
Page:   17
Change:   This rule will not be used.
Rationale:   Standard movement rules will suffice.

Weapons Fire Allocation
Reference:   04.02.02
Page:   20
Change:   All non-interceptable weapons (typically beam weapons) fired by one unit or a datalinked group of units at one other unit must be fired together as a single volley. Damage from such weapons will be treated as a combined group, rather than applied individually.
Rationale:   The rules do not require all non-interceptable weapons to fire as a group. Firing these weapons individually is a method which maximizes damage by using rounding to the firing unit's advantage. However, such a practice would notably slow the tactical game, and so will not be permitted.

Asteroid Fortresses - Pre Fabrication
Reference:   04.09.07
Page:   29
Change:   Asteroid Fortresses cannot be Pre Fabricated.
Rationale:   The contents of an Asteroid Fortress are built into the asteroid uniquely as part of its construction. Therefore, the contents cannot be prepared before the asteroid has been selected.

Asteroid Fortresses - Tractors Beams Required
Reference:   04.09.07
Page:   29
Change:   Asteroid Fortresses cannot be built or moved outside of an asteroid belt until a race has developed the Tractor Beam (T).
Rationale:   Tractor beams are required to move asteroids and Asteroid Fortresses..

Missile Cost And Usage
Reference:   06.04.02
Page:   40
Change:   An additional method for describing magazine loadouts is allowed. This will be termed a Specific Missile Loadout. A player may, specify that a unit (ship, base, PDC, etc.) has a specific load of missiles in its magazine(s). This information must be recorded for the unit and must state the number of each type of missile loaded, which magazine(s) the missiles are in, and the total cost for the missiles. This value is not deducted from the Missile Fund. When this unit enters battle, it enters with the specified missile loadout in its magazine(s).
    When it is necessary to determine a loadout for a magazine which does not use a Specific Missile Loadout, the total value of all Specific Missile Loadouts in the entire empire is first deducted from the Missile Fund. Any remaining amount in the Missile Fund is handled normally, except all magazines with Specific Missile Loadouts are not counted when determining the value of Missile Fund loadouts.
    The total of the Specific Missile Loadouts for an empire may never exceed the total of the Missile Fund. Should this ever be found to have occurred, the Space Master will levy a severe penalty against the offending empire (the minimum penalty is the elimination of all missiles in the magazines of any units about to enter battle). It is the responsibility of each player to see that this condition does not occur for any race under the player's control.
    Units with two or more magazines may have one or more magazines which use Specific Missile Loadouts and one or more magazines which use the Missile Fund normally. However, no individual magazine may do both.
    Note that this rule may also be used to place missiles in a Hold (H) on a ship.
    The Specific Magazine Loadout for a unit may be changed during any turn as part of the orders on a race's Log file. A Specific Magazine
    Loadout may not be modified when doing a loadout of missiles for battle.
Rationale:   The basic system for the Missile Fund works well enough (well, sorta), but there are some units which simply need a specific, fixed number of missiles, not a percentage of a magazine load out.

Crew Grade
Reference:   07.00
Page:   42
Change:   Base stations and space stations are considered normal ships for purposes of Crew Grade. These units may advance above Average.
Rationale:   There has been discussion on the Starfire Mailing List which indicated that these units could not advance like regular space ships for Crew Grade. None of the arguments against these ships having typical crews were convincing. Therefore, their crews may become more experienced like any other crew.
    Despite This also appears to be what is supported by the Starfire Assistant program.

Tug Rooms
Reference:   08.02.02.5
Page:   48
Change:   A ship with a "tug room" (i.e., a single extra engine room with all the ship's excess engines in that room) follows the revised rules for spare engine rooms (see 0.3.01.02 above), with one exception. When towing (i.e., having a tractor beam attached to another ship or unit), the tug may use all of the engines in its tug room, even if they are of a different type than those in the other engine rooms on the ship. No transition turn is required to activate these engines.
    Regardless of the number or type of engines on the tug, the tug and/or a tractored chain may never exceed the maximum speed for the ship's type or the size of the tractored chain, whichever is more restrictive.
    In the case of a tug with different engines in its tug room than its primary engine rooms, one turn with the engines shut down is still required to switch between the types of engines for primary motive power (ex. a ship with military engines wishing to switch over to the commercial engines in its tug room for strategic movement must shut its engines down for one turn to make the change). Unless otherwise stated, a tug is always assumed to be moving according to the rules for the engines in its main engine rooms.
Rationale:   The rule, as written, is inconsistent with rule 03.01.02, Spare Drive Rooms. This modification provides a reason to have a "tug room" as distinct from "spare engine rooms".

Crew Quarters / Crew Size
Reference:   09.06.02.2
Page:   53
Change:   The size of freighter crews will be set as one-third (FRD, minimum 1) of the hull space of the ship. Requirements for quarters will be based on this crew size (this will result in quarter requirements which are the same as in the basic rules).
    For example, an FT6 with 60 hull spaces will be treated as having 20 crew (RCP). One Qs would be required to support this crew size.
Rationale:   The rules clearly state (09.03, page 52, and 09.06.02, page 53) that "Commercial freighters ... use smaller crews than warships". However, examples of ship design layouts from Insurrection and ISW-4 show that freighter crews are treated as being the full size of the ship' hull spaces. Only the Shipyard program specifies freighter crew sizes consistent with the stated conditions of the rules. The practice of the Shipyard program will, therefore, be used in the campaign.

Construction Restrictions - Work Per Module
Reference:   09.07.04 Restrictions
Page:   54
Change:   The limitation of "Each unit may only be worked on by one module," will be modified. The revised rule shall be "Each unit may only receive the amount of work provided by one module." Although a seemingly minor modification, this is quite significant. The limitation is that the work equivalent of one module (shipyard, mobile shipyard, or machine shop) may be applied to one ship or base station per turn. Thus the number of separate tasks a shipyard complex may handle is greater than the total number of shipyards present.
    For example, a Tech Level 4 shipyard complex with 10 shipyards (18 HS/module) could, under the original rule, apply 16 HS of work to 10 corvettes (CT) in one turn, with each shipyard having an excess capacity of 2 HS. If another corvette was added to the complex, it would receive only 2 HS of work in the turn. Under the new rule, since the complex has an excess of 20 HS, it would be possible to build an eleventh corvette in the same turn, with 4 HS of work capacity spare.
Rationale:   This is the work method supported by the Starfire Assistant program. While this implementation does not follow the rules exactly, it is a far simpler way of tracking shipyard work.
    Despite claims in the rules to have simplified the construction process, it was still necessary to track the activities of individual shipyards, to insure that each yard did not provide work to units on which it was not permitted to work.

Construction Restrictions - Tasks Per Module
Reference:   09.07.04 Restrictions &
09.08.02 "Work in Progress" Limits
Page:   54 & 55
Change:   Shipyard modules are limited to one task at a time. Any module may work on more than one task per strategic turn, but only starts a new task when the previous one is complete.
    This will not apply in the campaign. Shipyards may work on tasks in any order which the player wishes, so long as each task in a shipyard complex receives some (minimum 1 HS) work each turn.
Rationale:   This limitation is not implemented in the Starfire Assistant program and the SM doesn't pay attention to it. While the rule is reasonable, it will never be implemented consistently in the campaign, so it is excluded.

Construction Restrictions - Module Build Rate Limits
Reference:   09.07.04 Restrictions &
09.07.05 Capacity Usage
Page:   54
Change:   The previous modification for this rule has been deleted. The maximum work rate which may be applied to any one segment / system of a space station, asteroid fort, or planetary defense center is (2*HT)+5 for shipyards or HT+5 for planetary industry.
    A work-around for the inability of the Starfire Assistant program to handle this situation has been created so the basic rule can be used.
Rationale:   A work-around for the inability of the Starfire Assistant program to handle this situation has been created so the basic rule can be used.

Guns As Weapons
Reference:   26.03, Tech Level 2
Page:   62
Change:   The Gun (G) is an offensive weapon system for purposes of activation and carrier hulls.
Rationale:   The Gun (G) is not identified as a Weapon System for activation and carrier hulls (note "w"). It should be.

Spaceport (SP) Requires PDC
Reference:   27.02.11
Page:   67
Change:   Spaceports must be built as part of a PDC. Spaceports cannot be built as free standing units.
Rationale:   This is not supported by the wording of the rule as written, but is the interpretation which the authors of the rules have put on Spaceports, and is what is supported by the Starfire Assistant program. It is documented here to prevent misunderstandings.

Spaceport (SP), Purpose
Reference:   27.02.11
Page:   67
Change:   Spaceports specifically built by a race (as opposed to those created by a CFN) have two, and only two functions.
    The primary function of a spaceport is to allow the construction of spacecraft by a world, with a Medium or large population, using its planetary industry. For a world to build any type of spacecraft either on the ground (with Atmospheric Capability) or in space, that world must have at least one Spaceport. Any number or size of ships may be built, as long as there is at least one Spaceport (within the limitations of planetary industry). Note that the often discussed limitation of 40 hull spaces of construction per Spaceport does not exist.
    The secondary function of a Spaceport is to allow a race to hold space ships on the ground, either in mothballs or with their drives deactivated. In this case, the 40 hull space per Spaceport does apply.
    The new rules for the CFN in Sky Marshal #2 indicate that the CFN builds Spaceports on all inhabited worlds. Such Spaceports explain why the CFN is willing to service such worlds, and why CFN ships do not require cargo handling equipment. However, for campaign purposes, the use of such Spaceports is for a race's CFN, not its military vessels. Military vessels, including Imperial Freighters (i.e., freighters directly under the race's control, rather than part of its CFN), need military Spaceports, which the race must specifically build.
Rationale:   There has been much confused talk among some of the players about Spaceports and their usage. This summarizes the current rules from the various rule books, and hopefully makes the function of Space ports clear.

Cargo Handling Systems (CHS & CHS2)
Reference:   27.03.03 & 27.07.04
Page:   67 & 72
Change:   A ship equipped with a Cargo Handling System (CHS or CHS2) may use its Cargo Handling System to move cargo internally. To do this, the ship must meet all normal conditions for cargo handling; most notable is the requirement that the ship be stopped with its drive field turned off. This does not, however, modify the time required to load small craft (see Starfire, 3rd Edition, Revised, 03.04.04, page 13), whose loading requirements are expressed in "turns" rather than cargo storage points.
Rationale:   Discussions on the Starfire Mailing List led to a negative ruling by Oerjan Ohlson of the SDS regarding the use of Cargo Handling Systems for the internal movement of cargo on a space craft. That ruling was, incorrect, based on the realities of past and current cargo handling systems on ships (actually about the only ships in existence which cannot handle their own cargoes are container ships).

Courier Drones - In Refits
Reference:   27.04.01.1
Page:   68
Change:   Note that it is no longer necessary to purchase Courier Drones when refitting ships not originally equipped with Courier Drones.
Rationale:   This is not a change to the rule, but it is a change to the way many players understand the rule. Therefore it is specifically noted here to remind players of the situation.


Rules Modifications - Sky Marshal #2
TOC

Tech Tree Prerequisites
Reference:   15.09.04
Page:   13
Change:   This rule will be used.
Rationale:   This is noted here only because this non-Alkelda Dawn specific rule is buried in the Alkelda Dawn section of Sky Marshal #2.

New Mass Production Rule
Reference:   15.09.03.4b
Page:   17
Change:   This rule shall not apply to space stations.
Rationale:   It is clear from the construction and refit rules for space stations that they are not like other units. Uniqueness of design is implicit within their "free form" construction. If the rule were required for space stations it would mean that almost every change to every space station would be a "new class".

Orbital Motions
Reference:   13.07
Page:   20
Change:   Although relative system motion will not be used in the campaign, the optional rules to not generate radians until opposing units are present will not be used.
Rationale:   The Starfire Assistant program does not support the delayed generation of radians, and the specific location of system bodies is needed for communications and movement as part of general campaign play (i.e., the original rule, as written, doesn't work).

Duration Of A Probe
Reference:   18.00b & 19.02b
Page:   41 & 53
Change:   All probing movement through a warp point will expend 1 StMP, regardless of the type of probe performed. Further, to gather any information on the target system, the ship must remain in the system for the duration of the StMP. Normally this will be the equivalent of one week.
Rationale:   The rules do not specify the amount of time required to gather information on any probe other than a "Deep Probe" (SM2, 19.02b, page 53). This rectifies the problem by defining all probes to required one week.

CFN Startup For Ind-2 / HT 1 Race
Reference:   15.04B
Page:   43
Change:   An Ind-2 race which achieves High Tech Economic Level 1 develops an in-system CFN starting in the turn after that race completes research on the Shuttle (st). It develops a general CFN in the turn after it has completed research on the Commercial Engine (Ic), and either Atmospheric Capability (AC), or Boat Bays (BbS) and Shuttle (st).
Rationale:   A race which has just acquired the capability of space travel cannot be assumed to immediately have a CFN. This rule establishes a simple set of conditions which must be met before a race can use its CFN capacity.

Contested Systems
Reference:   15.04.08.11b
Page:   46
Change:   The CFN will supply units normally in a system in which a warp point defense situation exists. The CFN will continue to service such a system and units at the warp point until such time as the warp point defense is defeated (i.e., the system will not be considered as "contested" simply because the enemy executes a failed assault).
Rationale:   The existing rules do not make this situation clear, and some information from the Starfire Mailing List suggests that this situation should be considered as creating a contested system. Such suggestions are rejected here as illogical. As long as the enemy is contained on the other side of the warp point, the system is safe and not contested.

In-System CFN
Reference:   15.04.09b
Page:   46
Change:   The restriction on a system having a minimum income of 200 Mc to use the in-system CFN will not apply. There will be no minimum income requirement for the use of the in-system CFN.
Rationale:   This rule is not supported by the Starfire Assistant program, and so cannot be readily enforced.

PTU Placement
Reference:   15.04.09.1b
Page:   46
Change:   The limitation of a maximum of 1 PTU per 100 Mc of income in the system for free transport of in-system colonization will not apply. There will be no income based limitation on the use of the in-system CFN.
Rationale:   This rule is not supported by the Starfire Assistant program, and so cannot be readily enforced.

One Method Of How To Handle The CFN
Reference:   No number
Page:   47
Change:   The basic method of handling the CFN in this rule will be used, with one exception. All shipments will be treated as having a duration of 1 strategic turn. To ship something a distance which requires more than one strategic turn of movement, the shipment starts each turn where ever it ended the previous turn. A form to handle this method is included in the player's Log file. The version in the Log file will be used in the campaign.
Rationale:   This places the responsibility of tracking an extended shipment on the player rather than the Space Master. It is also easier to document in the Log file.

Industrial Expansion Units
Reference:   15.03.03b
Page:   49
Change:   Industrial Units (IU) may only be sold during a turn which has a turn number that is a multiple of ten (10).
Rationale:   The rules, as written, allow the selling of IU "on any growth turn." When the Starfire Assistant program is used in a campaign, population grows on every turn. This insures there is no confusion that the original limitation on when IU may be sold is still in place.

Strategic Movement System Body Survey
Reference:   19.03b
Page:   53
Change:   A few aspects of this rule need clarification.
1)  In accordance with normal strategic movement rules, a survey unit must expend 1 StMP moving through a warp point and into a system in which it will perform a System Body Survey. Units moving to perform this System Body Survey may be counted as part of a Rough or Detailed Survey during this movement.
2)  No time is required to shift between System Body Surveys in the same system. But 1 StMP is required to shift between System Body Surveys in separate parts (primary / secondary) of a Binary Star System.
3)  No time is required to shift between a Rough Survey and a Detailed Survey. A Detailed Survey may begin in the StMP following the completion of the Rough Survey.
4)  No time is required to shift between a Rough or Detailed Survey and a System Body Survey, or vice versa.
5)  Portion #4 (Weird Worlds) is not performed in this campaign.
Rationale:   These are minor details which were found to be unclear while using this rule.

Surveying Non-HT Populated Systems (Strategic Movement System Body Survey)
Reference:   19.03b
Page:   53
Change:   When a high tech race enters the system of a non-high tech NPR, there is a desire to survey the system, since the NPR is both unable to stop the survey and is generally unaware it is occurring. However, the NPR does have some limited sensing capability which will prevent the surveying race from completing the surveys without being detected. The following conditions determine how much of a system may be surveyed without the NPR detecting the survey efforts.
1)  Rough or Detailed Surveys. In systems with Pre-Ind and Ind-2 NPRs, Rough and Detailed Surveys may be completed without detection. In systems with an Ind-2 NPR, there are 37 hexes sensible by the NPR. Of these, 33 cannot be surveyed without the NPR observing the activity. Therefore, no more than 190 points of a Rough Survey may be completed without the NPR becoming aware of the survey.
2)  Habitable Worlds Surveys (HWS). The home world of any NPR cannot be surveyed without the knowledge of the NPR. Further, no other T or ST world may be surveyed if it is within 3 system hexes of the NPR's home planet without the knowledge of the NPR. The number of HWS points which may be completed is equal to 50 times the percentage of Habitable Worlds which may be accessed without the knowledge of the NPR.
3)  Non-Habitable Worlds Survey (NHWS). The NPR will be able to detect survey work at any Non-Habitable World which is within three system hexes of the NPR's home planet. The number of NHWS points which may be completed is equal to 50 times the percentage of Non-Habitable Worlds which may be accessed without the knowledge of the NPR. When determining the numbers of Non-Habitable Worlds, include all Desolate and Extreme environment worlds other than asteroids.
4)  Asteroid Belt Survey (ABS). The NPR will be able to detect survey work in any Asteroid Belt hex which is within three system hexes of the NPR's home planet. The number of ABS points which may be completed is equal to 50 times the percentage of Asteroid Belt Hexes which may be accessed without the knowledge of the NPR.
Rationale:   This situation has come up in two separate campaigns, and been resolved differently in each case. Now there is a standard ruling which is based on a more careful reading of the rules.

NPR Strategies
Reference:   16.00b
Page:   59
Change:   Two additional sets of rules will govern NPRs. The ship design policies generated by the Starfire Assistant program will apply, as will the locally created NPR Ships & Systems Policies rules. The NPR Ships & Systems Policies rules are contained in a separate document which may be found on the web site.
Rationale:   These additional rules serve to make NPRs more unique, and to prevent players from using NPRs as experiments for policies and new ship designs. Each NPR will have its own unique way of creating ships and using those ships in battle. Some of these methods may not be the best military options, but then, that's reality.

Basic Determinants (NPR Strategies)
Reference:   16.01b
Page:   59
Change:   The starting cash which an IND-2 NPR shall receive will be 3*GPV, not 4*GPV. No more than 80% of this starting cash may be used to construct space stations. Up to 20% of the starting cash must be used to construct one or more PDCs. Excess funds are lost.
Rationale:   Under the original rule, this starting cash can be used only for building space stations. The systems available to an NPR force it to spend most of the startup money for weaponry on its space station(s), leading to massively armed structures. There is no reason for such heavily fortified space stations to exist (they didn't know anyone was out there). The only way to limit this is to reduce the amount of starting cash.
    The requirement for putting some of the starting cash into PDCs reflects the realization that races may build PDC equivalents without expecting an attack from outer space (ex. NORAD).

Political States
Reference:   17.02b
Page:   71
Change:   Although everyone seems to know, it is never explicitly stated in the rules how the Trade Intercourse, Military Alliance, and Trade & Military Alliance relate to each other.
    If a race has a Trade Intercourse treaty with another race, and adds a Military Alliance, then the new political state is Trade & Military Alliance. The Trade Intercourse treaty is not replaced by a Military Alliance, but rather is enhanced by it.
Rationale:   This relationship is not stated in the rules, and is not obvious from the way table 17.02.00.3b, (Political Offers Modifier Table) is structured. From the table, it appears that the next step up from a Trade Intercourse treaty is to a Military Alliance, in which case the benefits of the Trade Intercourse treaty would be lost. This is neither logical nor desirable.

Data Tables
Reference:   various
Page:   84-88
Change:   Ignore all of these pages. Use the tables in Starfire, 3rd Edition, Revised.
Rationale:   These are superseded in Starfire, 3rd Ed.

Tech Systems Codes And Information
Reference:   26.02b
Page:   89-91
Change:   Ignore all of these pages. Use the tables in Starfire, 3rd Edition, Revised.
Rationale:   These are superseded in Starfire, 3rd Ed.

Starfire Sequence Of Play
Reference:   No number
Page:   92-93
Change:   Ignore these pages. Use the Sequence of Play in Starfire, 3rd Edition, Revised.
Rationale:   This is superseded in Starfire, 3rd Ed.


Rules Modifications - Imperial Starfire
TOC

Planet / Moon System Movement
Reference:   13.07.06
Page:   16
Change:   All relative motion within a system will be ignored.
Rationale:   Although paragraph 13.07.07 specifically recommends against ignoring this movement, the rules, generally, already ignore all moon and planet movements for most aspects of the game, except fleet maneuvering. As the constant determination of system body positions is time consuming, and as this should be an all or nothing rule, it will be nothing since it cannot be all.
Change:   The rules for the relative motion of planets will be used. Although there are clear problems with implementing this, the Starfire Assistant program does this automatically, and the SM is not able to run the campaign without using relative motion.

Presence Of NPR Civilizations
Reference:   14.01
Page:   17
Change:   The Space Master will not include all NPRs generated by the Starfire Assistant program. The method for making the determination as to which NPR is kept and which is discarded will be random, and will not be known to the players.
Rationale:   The Space Master wants this to be a campaign based primarily on player interaction, not NPR interaction. NPRs should be a spice in the game, not the main course.

Ships Sharing Maintenance
Reference:   15.10.03.1
Page:   33
Change:   The restriction on warships of different sizes sharing maintenance carried in their Holds will not apply. Ships may freely share maintenance.
Rationale:   The logic by which maintenance carried by a freighter is general, but the same maintenance placed on a warship becomes ship specific seems very weak and creates notable difficulties in tracking. Further, the Starfire Assistant program is not designed or equipped to handle this situation.


Rules Modifications - General
TOC

NPR Creation
Change:   The creation of an NPR, and the assignment of its attributes, population, and other characteristics will be handled by the Space Master and the Starfire Assistant program.
Rationale:   The Space Master intends to let the program do all the work possible.

Locations Of Newly Built Units
Change:   An Immobile unit built and deployed in a system which is not under threat of attack or which does not require less than the strategic level of play, will not have to account for how the unit is moved into its final location within the system. In the case of systems which require lower level play, newly built units appear at the shipyard or in orbit around the planet which built the unit.
    For example, a base station intended to defend a warp point and built at a shipyard orbiting a planet will effectively appear at the warp point when completed, if there is no need for tactical or interception level play in the system in the turn the base station is completed.
Rationale:   Keeping track of the exact build location of immobile units in non-threatened systems, and how they get moved to their final locations, is just too much unnecessary work.

Abilities Of Commanders
Change:   In order to minimize the need for huge Standard Operating Procedures and highly detailed messages to fleets, the SM will assume that all local commanders are reasonably intelligent and competent at their jobs. This will be taken to mean that local commanders may react to local threats in a manner consistent with their existing orders and common sense. Specifically, a local, non-graded, commander (whether an admiral or not) may react to the enemy in generally one of three ways.
1)  Advance and possibly attack.
2)  Evade within the system.
3)  Withdraw from the system.
    Note that withdrawals from a system may not be used as a method for shifting a force to a more desirable location. This must be a logical response to the situation in the initial system.
    The SM reserves the right to refuse to accept any action which is not consistent with a logical response to situation.
Rationale:   No one, especially the SM wants to see huge SOPs. Also, knowing the SM, he wouldn't read them anyway. So, this allows modest SOPs and reasonable player control of local forces.

Learning Racial Characteristics
Change:   When a race establishes a Military or higher level treaty with another race, both races will learn limited information about the other race's racial characteristics. The race will know the other race's Habitability Index. It will also have a general idea about the other race's Chauvinism (RC), Militancy (RM), and Determination (RD). This will be reported as either; Low (01-33), Medium (34-66), High (67+). If modifications apply to the other race's characteristics, then the values reported shall be for the Modified RC, RM, or RD.
Rationale:   The rules do not provide for a race learning anything about the racial characteristics of another race until the race either is partnered with the other race or has conquered it. A race should have some idea about another race's characteristics if it has regular dealings with the other race in the form of treaties.


Working With SA And The SM
TOC

General
The Starfire Assistant program has a number of quirks and oddities in its operation which are not intuitively obvious, especially to the players in this campaign, who will be one step removed from the program itself. Similarly, the Space Master has a lot of quirks and oddities in his operations.
    A few comments are also necessary about working with the Space Master who is working with Starfire Assistant.

Changing Unit Names
Once a unit is under construction or being refitted, do not attempt to change the name of the unit. Either change the name in the turn before starting the work, or in the turn after the work is done. Name changes made during these times are not handled properly by SA, and great confusion will result when the original name of the unit appears in the Events report. As the SM will almost certainly not remember that he should not change the name of the unit, it will be the responsibility of the player to not make such a change. Any problems or confusion which results from such a change will be considered to be the fault of the player and the SM will be under no requirement to correct the situation.

Ship Names
One requirement and one prohibition apply to the naming of ships and other units.
Requirement   Players must specify the complete name of a ship, base station, or space station when the order to build the unit is given. The automatic numbering feature of SA will not be used by the SM. Failure to provide a name will be taken by the SM as a request to assign any name he feels like to the unit (and you will probably regret this).
Prohibition   Organization designations, their abbreviations, or words or groups of letters similar to organization designations may not be used as part of a ship name. Specifically excluded from being part of a ship name are the words: "subdivision," "division," "squadron," "fleet," "force," "group," "flotilla," and "company." Also, any terms used by a race to organize their ships or stations may not be used in ship names (ex. if a races uses army terms such as "regiment" to organize their ships, then the word "regiment" may not appear in a ship name).

Systems Removed During Refits
When a refit is performed on a unit, systems may be removed and either; 1) placed into storage in Holds (requires 25 csp of storage space per hull space of the system), 2) placed in storage on a planet, or 3) scrapped. It is the player's responsibility to list any such items removed during a refit and to specify what is to be done with the removed systems. If systems are scrapped, the player must explicitly list the costs of the items and the total scrap value. Systems not listed in the turn a refit begins will be assumed to have been scrapped with no benefit to the player's race (i.e., the race does not receive the 30% of the value of the system).

Reusing Stored Systems
Any system removed from a unit during a refit and placed in storage may be used in the construction or refit of another unit (ex., a Laser removed during a refit with Force Beams may later be mounted on another ship). SA does not make a provision for this situation. Therefore, in the turn the construction or refit starts, the player must list;

  1. What systems are being used from storage.
  2. From which storage location the systems are taken.
  3. The value of each of the reused systems.
  4. The total value of all the reused systems.
The SM will handle this by crediting the race with a Miscellaneous Income amount equal to the value of the reused systems.

Pre Fab Construction
The version of the Starfire Assistant program used in the campaign has a rather significant lack of ability to handle Pre Fabricated ("Pre Fab") items. Or, more exactly, it simply doesn't handle them. It is, therefore, necessary to use a work-around if Pre Fab construction is to be done.
    When ordering a Pre Fab unit, the player must clearly note it is Pre Fab, and must add "Pre Fab" to the name of the unit when it is ordered into construction (ex. to build a base station called "Defender 01", the build order must name the unit "Defender 01 Pre Fab"). Also note that all Pre Fab units must be assigned names just as if they were built normally (i.e., you can't build it Pre Fab, and then name it when it is assembled).
    When the Pre Fab item is complete, it must be put into storage. A special "fleet" is assigned at each race's home world which is identified as "Pre Fab Group". All Pre Fab units will be assigned to this group. Players will need to insure that the SM adds a note to each Pre Fab unit indicating where it is actually stored. The storage location must either be a planet or sufficient Holds available to contain it (150 csp per completed hull space). All parts of a Pre Fab units must be moved and stored together (ex., half a Pre Fab base cannot be stored on one world while the other half is in transit.
    Placing the Pre Fab unit in the Pre Fab Group will automatically mothball the unit. This is necessary to prevent SA from charging the owning race maintenance on the unit (remember, SA thinks it is regular construction -- a major oversight in the program). Players are warned to closely check their maintenance fees on the turn a Pre Fab unit is completed, as the SM has a consistent habit of forgetting to mothball Pre Fab units.
    To assemble a Pre Fab unit; ship it to its assembly point, and use a shipyard or machine shop complex to assembly the unit. When the unit is complete, the SM should rename it, removing the "Pre Fab" indicator, and take it out of mothballs. Players should double check that this is done correctly. Note that the failure of the player to insure the Pre Fab designator is removed and the unit taken out of mothballs may result in a ruling that the unit has not been assembled, regardless of how much work went into it.

Assigning Small Craft
At least one small craft must be assigned to any ship, station, or other unit which has a boat bay. A ship may not begin its shakedown cruise until it has its small craft.
    The Starfire Assistant program does not support this requirement from the rules. While it does allow the assignment of small craft to ships, it does not hold the ship back from service due to the lack of small craft.
    It shall be the responsibility of the players to insure that each of their ships has small craft assigned. Small craft should be assigned to a ship in the turn in which the ship's completion is recorded (i.e., when it is on its shakedown cruise).
    The Space Master will not check to determine that small craft have or have not been assigned to ships. However, should it be found that a vessel with a boat bay does not have at least one small craft assigned, then that unit will be declared to be non-operational, regardless of the current circumstances, and returned to a shipyard complex of the Space Master's choice (i.e., the fact that it is part of a fleet about to enter battle will not matter; the unit is treated as not being present).
    Players are advised to be very careful in the assignment of small craft. Only a verifiable Space Master error will prevent a ship from being penalized.

Ship Maintenance
Due to the use of the Starfire Assistant program, the standard method of placing maintenance in the hold of a ship cannot be used. SA does not support individual ships carrying maintenance. In SA, maintenance is assigned only at the fleet level.
    Players will be required to specify how much maintenance will be assigned to a fleet. When ships are transferred into or out of fleets for any reason, it will be the responsibility of the controlling player to specify how much maintenance is to be removed or added to those fleets.
    Players will also be responsible for indicating how the maintenance assigned to a fleet is carried. The Space Master will enter this as a note in SA with the fleet. There are three common methods for carrying maintenance. Players are free to devise other methods. These methods may be combined within one fleet.

  1. In the Holds of the fleet's ships.
  2. On supply ships which accompany the fleet.
  3. On CFN freighters hired specifically for this task.
    Players must insure that a fleet has the ability to carry the assigned maintenance in the manner specified (ex., if the player says all maintenance is in the Holds of the fleet's ships, then the player must be sure that the fleet has enough Holds to carry all the maintenance). Should it be found at any time that a fleet does not have sufficient capacity to carry the assigned maintenance in the manner specified, then all excess maintenance will immediately be lost to the player (not just lost to the fleet, but lost to the race).

Exceeding CFN Or Monetary Limits
Sooner or later every player will exceed the limits on CFN capacity (Holds or Quarters) or spending money.
    When transferring tasks for the CFN from the player's Log File to the Starfire Assistant program, the Space Master will first take CFN tasks from the CFN sheet. After these are assigned, orders from the Colonization sheet will be entered in the sequence listed on that sheet. If the capacity of the CFN is exceeded by a task, any task from that point on will be ignored.
    Deficit spending will not be permitted (OK, this isn't reality, but it will be the rule). The sheets of the player Log File will be processed from left to right in the file display, and from top to bottom on each sheet. At the point at which anything would cause a negative balance in the race's treasury, all spending requests will be halted (exception; continuing research will take precedence over any other spending request).

Economic Level Research
The Starfire Assistant program uses a number of specific terms for the various types of research which may be performed when working to advance a race's Economic Level. Players need to be familiar with these terms and need to use the correct term when ordering research to be done.
    Note: Players are advised to use the term "Economic Level Research" when referring to Economic advancement, not "Technical Level Research". The latter term is too close to the SA use of "Technical System Research", and may easily be confused with this by the Space Master.
  1)  Normal Research. This is the standard from of Economic Level Research. Startup cost is based either on Imperial Starfire, 15.07.03 Tech Level R&D Chart (page 26), or Sky Marshal #2, 15.07.03 (page 10), 30% of the race's monthly Total Production, whichever is greater. Monthly cost is based either on the Tech Level R&D Chart or 10% of the race's monthly Total Production, whichever is greater. This gives the race a D10 die roll towards the R&D Point Requirement.
  2)  Crash Research. This is as described in Imperial Starfire, 15.07.04.01, Crash R&D (page 26). Cost is three times the normal startup fee, and three times the normal monthly fee, whichever is greater. This gives 2D10 die rolls towards the R&D Point Requirement.
  3)  Assisted Research. This is as described in Imperial Starfire, 15.07.04.02, Assisted R&D (page 26) and Sky Marshal #2, 15.07 & 15.08, 15.07.03, and 15.07.04.2 (all on page 10). Cost is either nothing, if the races both have the right population sizes on one world, or an additional 50%, if the races do not share a world. This gives the assisted race a 150% multiplier on the monthly D10 roll for the R&D Point Requirement. Note that Assisted Research is only ordered by the race receiving the assistance, not by the race providing the assistance.
  4)  Observed Perceived Threat Research. This is described in Imperial Starfire, 15.07.04.03, Perceived Threat R&D (page 26). Cost is 1.5 times normal. This gives a 120% multiplier on the monthly D10 roll for the R&D Point Requirement.
  5)  Crash Observed Perceived Threat Research. This combines Crash Research and Observed Perceived Threat Research. Cost is 3 times normal. This gives a 340% multiplier on the monthly D10 roll for the R&D Point Requirement.
  6)  Sensor Perceived Threat Research. This is described in Imperial Starfire, 15.07.04.03, Perceived Threat R&D (page 26). Cost is 2 times normal. This gives a 140% multiplier on the monthly D10 roll for the R&D Point Requirement.
  7)  Crash Sensor Perceived Threat Research. This combines Crash Research and Sensor Perceived Threat Research. Cost is 3 times normal. This gives a 400% multiplier on the monthly D10 roll for the R&D Point Requirement.
  8)  Paused. This allows a race to temporarily stop research.

Assisted R&D
Assisted R&D (Imperial Starfire, 15.07.04.2, page 26) enables a more advanced race to assist another race with research. If the two races have populations on the same planet the less advanced race may use Assisted R&D at no expense. Sky Marshall #2 (15.07, page 10) allows Assisted R&D to occur without a common world, but, at a 50% increase in the cost of the Assisted R&D.
    The Starfire Assistant program does not implement this situation properly. SA will charge the extra 50% whether or not there is a cohabited world. If a race is using Assisted R&D, and if there is a common planet with the assisting race as required in Imperial Starfire, then it shall be the responsibility of the player controlling the assisted race to request a refund (Miscellaneous Income) of the overcharge. This should be done each turn, requesting that the excess, which will be charged in the current fund, be credited to the race.

Treaties
Player races and NPR may enter into non-standard treaties with player races or NPRs. Such treaties must be negotiated between the controlling players, or if the controlling player is not known, through the SM. A written copy of any non-standard treaty must be prepared by the agreeing parties and submitted to the SM.

Limitations On Populating Asteroids
The Starfire Assistant program has an effective limitation on the number of sources from which an asteroid may be populated in the turn in which the asteroid is first colonized. Therefore, in the turn in which an asteroid is first colonized, all population moving to that asteroid must come from one, and only one, other world. If more than one source is ordered, all extra sources will be ignored.
    This is problem with the implementation of the Starfire Assistant program. The limitation is the only easy work around.

Building Small Craft Automatically
Version 3.90 of the Starfire Assistant program provides the ability to order the automatic construction of small craft when a ship is built. SA will schedule the building of a small craft in the final turn during which a ship will be under work. A player will have to provide the following information to have this done.
  1)  When providing the SM with a design, clearly indicate the standard type and number of small craft to be included on the ships with the design. This will be the type and number of small craft scheduled when the ship is built.
  2)  When ordering the construction of a ship, make an entry in the Notes column to indicate that you want a small craft to be built automatically.
    Anyone using this option should also be aware that if SA is unable to build the specified small craft due to the assigned shipyard complex already being filled to capacity, it will issue a warning, but will not reschedule the work for the following turn. The player will be responsible for ordering the construction of the small craft in this situation.


Appendix I - Sky Marshal #2 Rules In Use
TOC

The following rules and rules sections in Sky Marshal #2 shall specifically be included in the campaign. Some of these rules may be modified in the previous sections of this write up.


Appendix II - Optional Rules In Use
TOC

Players are warned that the Space Master tends to adopt optional rules without warning anyone. If players have any question regarding whether or not a rule is in use, ask immediately, and be sure to tell everyone the answer. Remember, if it isn't in this write up, it isn't in the campaign.

Pulsed Movement
Product:   Starfire, 3rd Edition Revised
Reference:   03.01.01.3
Page:   11
Comment:   Most of the players seem to think that this rule is the standard way to play the tactical game. Plus, it does make movement a bit more "realistic".

Simultaneous Transit
Product:   Starfire, 3rd Edition Revised
Reference:   03.06.02
Page:   14
Comment:   Paragraph 03.06.02.3, which is optional will also be used.

Break-Off And Surrender