This page is a discussion of the Operations Office Sub-Module.
The Operations Office Sub-Module is designed to handle the Operations office interface; more specifically it is designed to display and playback Starport Notices and Evaluations. 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 hash tables / dictionaries. This module is required by the Starport Module only. The Operations sub-module is important to the game because it acts as another means to divulge important clues to the player, help immerse them in the Starflight universe, and function as the means through which the player learns about the results of their colonization efforts. All code for the Operations sub-module is located in the sf3_starport_ops.py file.
Summary Description
An ofc_Ops object is created and stored during the initialization of a Starport office if a certain flag is set to True. When created, the ofc_Ops object will load in the current list of Starport Notices into a holder dictionary, checking the display status of those messages as it does so. It will then check to see if the player has made any evaluations or launched any colony pods since the last time they visited a Starport. If so, those efforts at colonization are evaluated and an appropriate message is seeded for display into a holder dictionary. Finally, if another flag is set to True, the interface will be set to have a Library access button available; another routine will load in library data to a third holder dictionary (again, checking for the display status of the data as it does so). The Operations interface comes up when the player enters the Operations office; when an option is selected from that menu, the appropriate data is displayed to the player. The object remains in memory until the player leaves the star system in which the office's Starport is located, at which point the object is destroyed (along with its parent Starport object).
Data Structure of the ofc_Ops Object
The following list is an indication of the various variables and methods that will be included in an ofc_Ops object. This list contains suggested methods and variables only; they should be updated as needed when finalized method and variable names are selected. Ofc_Ops objects are meant to be used as child objects of Starport objects, and have no child objects. Ofc_Ops objects are created during runtime when a player enters a star system and are subsequently destroyed when they leave that system. Thus, while there may be multiple ofc_Ops objects used in the game, only one will be in existence at a time (
per Starport located in a system; the Flornea system has two Starports in it and thus may have two ofc_Ops objects in it as well, one for each base). Their data structure is as follows:
- Class: ofc_Ops
- Hash/Dictionary: hNotices
- Key: Message ID
- Tuple: Message and Status
- Flag: Message Lock (True locks the message; it won't display)
- String: Message Text
- List/Vector: vEvals
- String: Evaluation Message
- Integer: Value
- Hash/Dictionary: hLibrary
- Key: Entry Name
- Tuple (String, Flag): Entry Info, Locked?
- Method: init(bLibLock)
- Method: unlockMsg(msg_ID)
Interface
Operations Interface (Sample)
The Operations Office interface consists only of two main areas, as demonstrated in the graphic:
- Message Box
- Interface Buttons
The
Message Box takes up the bulk of the screen and is by far and away the largest area on screen. As the name suggests, this area is used to show every message the player will receive while still in the Operations office. Immediately below the
Message Box along the bottom of the screen are the
Interface Buttons. There are four such buttons, one to call up Starport Notices, one for Evaluations, one for Library Access, and a fourth to Exit (
ignore the "Bank Balance" one in the graphic; apparently at one time the Bank would've been merged in with the Operations office. Instead, this is where the "Library Access", will be located). The Library Access button may or may not be accessible depending on whether or not the method is instructed to activate it or not; if not, the button may either be dimmed, or simply set not to appear in the interface (
this is going to depend on how we set it up). The Notices button is highlighted every time the player enters the Operations Office. Selecting an
Interface Button may either be done via a mouse click or by using the keyboard arrow keys followed by the <Return> key; once an option is selected, the player will have to use the arrow keys to continue to scroll through the various messages. The selection cursor will scroll, so pushing the left arrow key when the cursor is on the "Notices" button will move the cursor to "Quit" (and vice versa). When selected by the cursor, a specific button will turn red. The selection of a menu option will sound the ACKNOWLEDGED tone and activate a pre-programmed method (
as defined in the XML file). As with all Starport modules, no calls will be made to the gameClock object to advance the time while the interface is active.
General Procedures and Notes¶
Notices from Interstel given over time or given in response to major plot events. The purpose of these notices is to give the player hints to start off with, announce major events, give the player a sense of accomplishment and demonstrate consequences of actions, and of course humor. (notices - include initial mission briefing messages, clues and helpful info, and humorous company personals).
Evaluations are messages from Interstel to the player usually with a monetary reward or penalty. Examples include colony recommendation rewards and penalties, loss of a terrain vehicle and notice of its replacement, rewards for major plot events, etc. (evaluation - evaluations of player's recommendations of colonies; fine or bonus given for each recommendation. Was a major part of the original games.)
Library entries can be as big or as small as we want them. The samples I've got in the XML discussion are pretty basic; building the entries is going to be fairly time consuming and should probably be one of the last things we do with the game before its final completion. For reference, sapient race entries will probably have as much text data as in their profile.
Need to incorporate "dynamic messages" into Operations module (as per ICC plot discussion thread, 12/17/06). Main idea was to have messages show up that specifically indicate the ship's captain and ship's name. Should be doable through the event handler. Just need to have a few dynamic messages to add.
MNMinstrel Starport Notice post from ICC, 3/1/11 10:09 CST: "Earth History: Compelling new evidence about political unrest in the Afspamistan region during the early 21st century confirms that Veloxi spies were supplying the Talispam with spam bots. "
Note from the Casino Module page, 4/4/11: "What happens at Starport stays at Starport, baby." (Might be recyclable as a Starport Notice.)
4/13/11: quote from MNMinstrel: "Djaboon Foot fungus fetish!!!"5/9/11: Google has launched Google Earth because Android Burrey underpants
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TO: INTERSTEL OPERATIONS, STARPORT CENTRAL
FROM: ISS PATRIOT
STARDATE: 15.31-11-2006
RE: ALPHA SECTOR SURVEY
NNNNNNNNNNNNN
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
THIS MIGHT BE A BAD TIME TO BRING THIS UP, BUT I HAVE A BUNCH OF RECEIPTS FOR THE ENDURIUM I USED DURING THIS MISSION. WHO DO I NEED TO GIVE THESE TO, AND WHEN CAN I EXPECT COMPENSATION?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BREAKBREAK
BORNO, ALL YOUR BASE ARE BELONG TO US. XENON.
Methods
init(bLibLock)
unlockMsg(msg_ID)
XML
The ofc_Ops object, like most of the other objects in the game, is largely XML driven; this will help keep it flexible up until SF3's design is finalized (i.e. notices, evaluation messages and library data can be added and removed from the game freely, based upon what data is available in the XML files). The ofc_Ops object requires three different XML files, containing the game's list of notices (the file "starport_notices.xml"), the list of evaluation messages, (the file "colonization_evals.xml"), and the library access information (the file "LCARS.xml"). The following briefly goes over what data is located in these XML files.
starport_notices.xml
The file "starport_notices.xml" is designed as a listing of the possible messages a player may receive when visiting the Operations office at Starport; these messages are meant to immerse the player in the universe and to sometimes provide clues as to what they need to do to fulfill their mission. Under the root element, entries in the XML file are empty "notice" elements, each containing a mandatory "msg" attribute (which contains the message text). Notices may need to take up multiple messages; the routine that displays them on screen will look for the "escape" character of "/n" to denote new lines. The escape character of "/t" may also be used to add tab stops to the message.
Additional tags may be added later if it is decided they are needed; these would be tags to record a specific date, the names of specific ships and captains, and so forth.Sample structure of the starport_notices.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<root table-name="Starport Notices" version="0.1">
<notice msg="01-01-4620/n
/tYou are about to embark on your first mission. In your bank account you will find the amount of 12,000 monetary units (M.U.). This money
is to be spent training your crew, configuring your ship, and purchasing any necessary materials./n
/tOf course you may wish to leave some portion of this in the bank to earn interest. This is acceptable. At this stage of the operation our
primary goal is to gather information. Consequently, your objectives are -/n
1. Seek out and explore strange new worlds/n
2. Boldly go where no man has gone before/n
3. Establish contact with any sentients/n
4. Capture and bring back non-sentient lifeforms/n
5. Record alien lifeform data/n
6. Bring back alien artifacts/n
7. Bring back any valuable minerals (including Endurium)./n
8. Keep from getting brutally killed/n
/tWe have little information to offer concerning what you might find. We suggest however, that you avoid the area of space around the
coordinates 135,84 since that is where we lost contact with two of our earlier ships./n
/tScout reports indicate a high density of minerals in the mountainous regions of the innermost planet of our system./n
/tFurther, we have found information that leads us to believe that there may be some ruins of the old empire at coordinates 17N X 162E on
the second planet of the neighboring K-class system./n
/tWe have also received some indication of alien activity in the system 175,94./n
/tGood luck, and a safe return."/>
</root>
colonization_evals.xml
The file "colonization_evals.xml" is designed as a listing of the possible messages a player may receive if they submit a planet for colonization or launch a colony pod, designed to let them know the efforts of their colonization efforts (for more information on submitting evaluations and launching colony pods, see the discussion under the
Starship Module. Entries in the XML file are empty elements under the root element, and may either have the name "recommend" (used for evaluation of planetary colonization efforts, either through recommending a planet for colonization or by establishing a colony there using a colony pod) or "supplement" (used for other types of evaluation messages, such as fulfillment of victory conditions, applications of fines, and so forth; messages generated from the Lounge Module are of this type; see the discussion on
that page). Regardless of the element type, the inclusion of an "msg" attribute (used to hold the text of the evaluation message) and a "type" attribute (used to denote the message's purpose) is mandatory. Type attributes may have one (and only one) of the following values associated with them:
- optimal: the message is used whenever the player has established a colony on an optimally habitable world, or has located an optimally habitable planet to colonize.
- normal: the message is used whenever the player has successfully established a colony on a non-optimal world, or has located an non-optimal planet to colonize.
- firstFail: the message is used the first time the player fails to establish a colony, or recommends a non-habitable world. Usually includes the reasons for failure.
- fail: the message is used any subsequent time the player fails to establish a colony, or recommends a non-habitable world. Usually includes the reasons for failure.
- towed: the message is displayed at Starport after the player has issued a distress call and must be towed back to the closest Starport.
- victory: the message is displayed after the player has fulfilled a set of victory conditions. Can be used for the overall game victory conditions.
- defeat: the message is displayed after the player can no longer fulfill a set of victory conditions.
Both recommend and supplement messages types may be long, and so will utilize the same set of escape characters as the starport_notices.xml file. In addition, an escape character of "*" may be used to list reasons for a failed colonization result, and "$" may be used to list a specific monetary amount (with what that amount represents - a bonus or a fine - dependent upon the type involved).
Sample structure of the colonization_evals.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<root table-name="Evaluation Messages" version="0.1">
<recommend type="optimal" msg="Good Work! You have located an optimal planet. You have earned a bonus of $ MU for this recommendation./>
<recommend type="normal" msg="This planet proved to be suitable for colonization. You have earned a bonus of $ MU for this recommendation./>
<recommend type="firstFail" msg="Due to *, this planet proved unsuitable for colonization. You have been fined 100 MU. This is only a
warning; your next fine will be heavy. />
<recommend type="fail" msg="Due to *, this planet proved unsuitable for colonization. You are hereby fined $ MU. />
<supplement type="towed" msg="Supplemental Evaluation/n
RE: Towing Charges/n/n
Interstel Corporation Regulation 12A-7312 Emergency Distress Calls:/n/n
/tCaptain and crew of any vessel invoking an emergency distress call shall be liable for any costs incurred by Interstel Corproation./n
As a result of rescue operations initiated on behalf of said crew, you have been fined $ MU. />
<supplement type="victory" msg=Supplemental Evaluation/n
RE: Completion of Mission/n/n
Congratulations! As a result of your efforts, our sun is once again stable. All of Arth, and indeed the entire galaxy owes you a debt
which can never be fully repaid./n
Your heroic exploits will surely become intergalactic legend./n
Our token bonus of $ MU will allow you to live here on Arth in luxury for many years to come, although we suspect you may use it to
further your explorations. Once again, thank you! />
</root>
LCARS.xml
The file "LCARS.xml" is designed as a list of library access materials on species, lifeforms, artifacts, starships, and star systems; it's essentially meant as a reference for the player (
and potentially a means of providing clues in game). Under the root element, entries in the XML file are empty elements with the name "entry". These elements must contain exactly three attributes, one named "id" (which is used as the library access entry name), one called "lock" (which must either be set equal to true or false, and indicates whether the entry is "locked and shadowed" (i.e. not visible in the list of library access entries) at the game's onset), and one called "text" (which is used to contain the text of the library entry). Text attributes may be long and so will utilize the same set of escape characters as the starport_notices.xml file.
Sample structure of the LCARS.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<root table-name="library_access" version="0.1">
<entry id="Phlegmak Predator" lock="true"
text="Phlegmak Predator:/n
/n
*Mass: 500 hectotonnes/n
*Scale: 3x an Intrepid-II-class Scout/n
*Engine: Class 8/n
*Armor: Class 5/n
*Shield: Class 8/n
*Laser: Rivener Beam (6 Fore)/n
*Missile: Black Orb (1 Fore)/n
*Special: Stealth Cloak/n" />
<entry id="System Scanner" lock="false"
text="System Scanner: A technology sold by the Tandelou Eshvey (Eshvey) designed to scan an entire system for motion signatures
conducive with active space units in the vicinity. Can be useful for detecting/evading unwanted encounters within a star system./n
/n
*Volume: 1.5 m^3/n
*STV: 18,000 MU/n" />
<entry id="Poison Glider" lock="false"
text="Poison Glider: A cat sized, insect like carnivore. This creature's body is covered with a shiny yellow exoskeleton with a
black camoflaging pattern. It has two powerful rear legs for jumping, and extendable membranous flaps which allow it to glide
long distances. Its front claws are hooked for grasping and it has a small swivel head with one large compound eye. It also has a
retractable, needle like mouthpiece capable of injecting a potent poison./n
/n
*Volume: 2.0 m^3/n
*STV: 1500 MU/m^3 (3,000 MU)/n
*Purchased by: Nelsons (Home), Humna Humna (Supreme Market)/n" />
<entry id="Arth Star System" lock="false"
text="Arth (Star System)/n
/n
*Location: α125x100/n
*Number of Planets: 5/n
*Important Locations: Arth (p2); Starport Central (p2)/n" />
<entry id="Dweenle" lock="false"
text="Dweenle (Pedesolanum miseratio)/n/n
A pale race of short, hairless humanoids, the Dweenle have been in space longer than any other race, save perhaps the Uhlek.
Seemingly always depressed, they are universally unpopular due to their endless suicidal rambling. The oldest race in the
Delta Sector, they have survived the possession of the ancient Leghk, the wave of flaring stars caused by the Crystal Planet,
and more recently, the hostile attentions of the Umanu and G'Nunk- ironic, given their often repeated death wish. Notably,
they are the only extant race known to be native to the Delta Sector. However, despite all of their faults, the Dweenle do
buy and sell several valuable trade goods, and as such are an important commercial interest to the Sector./n
/n
*Type: Pathetic/n
*Durability: 4/n
*Learning Rate: 2/n
*Science: Average/n
*Navigation: Average/n
*Tactical: Average/n
*Engineering: Poor/n
*Communication: Excellent/n
*Medicine: Good/n
*Genders: 2/n
*Life Stages: Adolescent at 3 years. Adult at 7 years. Middle age at 12 yrs. Old Age at 20 years. Venerable Age at 26 years. /n
*Lifespan: 28 + 2d5 years. /n
*Height: 1.0 meters; 0.7 + 1d5 x 0.1 m /n
*Mass: 10 kilograms; 7.5 + (same 1d5 from height + 1d5 ) x 0.5 kg /n
/n
*Niche/Symmetry: Omnivorous Bilateral Consumer/n
*Speed/Transit: Biped, 4 m/rd (2 kph)/n
*Volume: 0.01 m^3/n
*HD: 51/45/51/n
*HP: 40/n
*Unarmed Damage: None/n
*STV: 1 MU (100 MU/m^3)/n" />
</root>
Module Status
This is current as of May 3, 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.
NEXT: Bank Module and InterfacePREVIOUS: StarportTOP