FreeSpace Wiki - User contributions [en]

Backgrounds

2006-01-10T23:03:44Z

81.182.83.170:

'''Backgrounds''' are extremely important when designing a mission. In addition to breaking up the constant blackness of space, backgrounds set the mood for the mission. If you are creating a standalone (non-campaign) mission, you can use whatever colors you like, regardless the colors don't clash. If the mission takes place in a system featured in the single-player campaign, it is ok to base your nebula backgrounds based on that particular mission. 
If you are creating a campaign, be sure to create templates before starting work on ANY missions. It would also be a good idea to write down the number of planets, the bitmap associated with them along with their orbit. This will come in handy if you have a mission taking place closer to the star, and therefore the closer planets will be larger or only be seen. Make each system unique to give the player more than just the same color backgrounds over different systems. Some ways to vary systems include different numbers, colors and sizes for suns; different nebula patterns and planet systems. 
Whatever you do, make sure to create your backgrounds first so you won't have to worry about getting killed while admiring your nebular handiwork. 

There are three main ways to create backrounds for missions you create in FRED:

==Creating backgrounds from scratch==
Wether you are using flashy custom nebulas or the stock nebulas, placing nebulas is rather hit-or-miss. For each background bitmap, you must line up the nebulas using the pitch/heading/bank edit boxes. After each significant change, you must test the mission to make sure your tweaks have worked to your desire. You must also make sure each nebula bitmap isn't too streched to make it distorted. Keeping the bitmap's scale values nearly equal will avoid this. Additionally, bitmaps that have really large scales look too streched even when the scale values are nearly square. As with any other topic in FRED, you will get good at this once you have experience.

==Using a background generation program==
A few background generation programs can be downloaded that will randomly place background bitmaps for you. After running the program, it would spit out a mission file that contains the background. Some tweaks are necessary to get a realistic background, since you may need to change the background's bitmp, pitch, bank and/or heading. This method is much faster than creating backgrounds from scratch. Documentation for each generator varies and it would be a good idea to read it before using.

==Skyboxes==
A recent addition to the Source code project, skyboxes allow users to create a skybox model and place it around the field of play much like the background bitmaps. They are rendered in addition to the [[nebula background|background nebulas]], so be sure to include either a skybox or nebula bitmaps, but not both. To create a skybox, read the [[Skybox|Skybox Option]] page.

Galactic Terran Alliance

2006-01-10T23:03:24Z

81.182.83.170:

The '''Galactic Terran Alliance''' was an alliance formed by the human race after the unification of the peoples at [[Earth]]. Abbreviated as '''GTA'''. The space-based military wing of the GTA is known as the Galactic Terran Navy (GTN) but referenced as such only in the Freespace Reference Bible. The intelligence branch of the GTA is [[Galactic Terran Intelligence]] (GTI).

==Speculation==
Any info read here is not canon. The following section needs to be cleaned up to separate the facts from the interpretation.
----

===The beginning===
The Galactic Terran Alliance was formed in the first years of the age of space exploration, when the nations of the Earth have unified and formed an alliance. In the beginning, there were linguistic difficulties, but later, the English language later became a common language all through Terran space, even though not all GTA citizens spoke it as if it were their mothertongue, or did not speak it in a way that could be understood.

Initially, the alliance was focusing on economic and research factors, but later, with the discovery of Subspace, building, maintaining and developing a space navy was at hand.
----
===Expansion===
The Alliance spread their empire all through the [[Sol]] system, building shipyards, repair yards and other kind of factories or supply depots. By the end of the 23rd centaury, the GTA had already taken up the whole [[Sol]] system and also spread to [[Delta Serpentis]] and [[Beta Aquilae]].
----
===Wars===
In 2320, the GTA first encountered the [[Vasudans]]. At the beginning, there was no armed conflict, the war only erupted in the year of 2321, when a Vasudan representative was murdered. Both sides mutually declared war on each other and the [[The 14-Year War|14-Year War]] began.

After forteen year of seemingly endless war, when the [[Shivans]] destroyed both Vasudan and Terran targets, the two sides signed an armistice and turned against the cosmic destroyers. The most important war in the history of both species began.

[[Ross 128]] had already been lost, [[Betelgeuse]], [[Beta Cygni]] and [[Ribos]] also fell to the [[Shivans]]' superiority. When the [[Shivans]] took Antares, it became clear for the GTA that if the [[Vasuda]] system falls, they lost the [[Vasudans]]. In the effort to defend Vasuda from the mighty Shivan fleet, innumerable Terran pilots fell. Even after all the sacrifice both sides have taken, the [[SD Lucifer]] bombarded Vasuda Prime, killing billions of innocent [[Vasudans]] after only fourteen hours of ceaseless bombardment.

[[Sol]] was the next target of a Shivan attack. If it had not been for the Vasudan refugees who found the [[Ancients|Ancient]] records, the Earth would have also been debilitated. Thankfully to the successful extraction of the Ancient data, the [[SD Lucifer]] was destroyed in the Subspace tunnel between [[Sol]] and [[Delta Serpentis]], causing the jump node to collapse.

Although the [[Shivans]] were defeated and the [[The Great War|Great War]] has come to an end, putting the dissolution of the long-living alliance was at hand.
----
===Dissolution===
In the year of 2345, the [[Terrans]] and [[Vasudans]] officially formed an alliance, called the [[Galactic Terran-Vasudan Alliance]], causing the end of the Galactic Terran Alliance.

[[Category:Organizations]]

Mission Chatter

2006-01-10T23:00:05Z

81.182.83.170: more wiki-like

'''Mission chatter''', or '''Pilot chatter''' is essential to the feel of a good mission. It gives a mission a sense of reality that even some [V] missions lacked, and immerses the player more completely in the action. Pilot chatter can be used to fill in space between dogfights, give the player subtle hints about the universe the mission/campaign designer has decided on, recall information from earlier in a campaign so that its fresh in the players mind for later reference, and plenty more. It's a hugely important plot and mood element for any mission, and yet is one of the most neglected. So, without further ado, here are some basic guidelines for producing decent pilot chatter in your mission.

==Step 1 - Build the Mission==

It's generally not a good idea to do your chatter during the formative stages of a missionâ€™s development. You often don't have a full grasp on where you want to see the mission go, and even rarer is to know how you want it to get there. Pilot chatter has to be relevant to the events of the mission and campaign, otherwise it sounds disjointed and artificial. Also, before the mission is completed, it's unlikely you'll be able to determine the best time to put the chatter in. Placing it over the top of a dogfight would be silly, and chances are it wouldn't get read anyway. So, before you start your pilot chatter, it's a good idea to have at least a reasonably complete mission, so that you can be sure the timing is good, and the content relevant

NB - As with any rule, there are exceptions. If your mission begins several minutes before the action so you could fill this space with pilot chatter, of course this can be done before the mission is complete. This will undoubtedly be essential to set the scene of the mission, and quite possibly relevant to later events. Besides - if you mission is set two or three minutes before the start of any action, you're going to need something to occupy your time during testing.

==Step 2 - Define your content==

This is a quick, but essential step towards good pilot chatter. As mentioned above, pilot chatter can perform multiple roles in a mission, and is more than just a space-filler. Here you need to define what it is that you want mentioned. Is there an event from a previous mission the player should be recalling? Is there another operation going on at the same time as the players mission that may become relevant later? If you're guarding a convoy, does the player need to know what's aboard the freighters? It's much easier to know what you want said at this point in the process, as it gives you definable goals towards which you can work, and makes deciding on what specifically to say much easier.

==Step 3 â€“ Script your Messages==

So, by now, you've built a mission, and you've decided what's going to be spoken about. Now all you have to do is create the specific messages. This is the most important part of the pilot chatter process, as the specific messages are the things that the player will be seeing, and without them, you obviously have no chatter. So clearly, you'll need to take a lot of care to ensure that this part is done right. Though that might sound daunting and time consuming, it really is only as hard as you make it. First, play through the mission two or three times. Find out where the quiet parts are, how many wingmen you typically lose along the way, choose the events you want to comment on, etc. (NB - if you do this during testing, you can save yourself some time). Along with the content you defined earlier, this will form the framework for the messages. Now you're more than ready to begin your scripting.

==Tips==

*To make your messages sound more natural and unified without voice acting, try to insert a sense of character into your wingmen. Is Alpha 2 a cocky hotshot? A battered, jaded old veteran? A green, over enthusiastic Ensign straight out of the academy?

*Say your messages out loud once you've written them down. The spoken word and the written word are not the same thing. If it sounds unnatural coming out of your mouth, it's probably not quite right, and needs changing. If English isnâ€™t your first language, you may consider asking a native English speaking friend or beta tester to perform these tests/changes for you.

*Watch out for spelling errors. Nothing looks more unprofessional than a poorly spelled message or briefing, except possibly a poorly spelled mission objective or ship name. Check all of your spelling twice, with a word processors spell checker if available.

*If you're building a single mission rather than a campaign, pilot chatter can sometimes be harder to think up. Some possibilities are

- Pilots responding to Commands orders, or relaying them more specifically to the rest of the wing.

- Pilots discussing current events, or life aboard whatever ship theyâ€™re stationed on

- Pilots communicating with vessels theyâ€™ve been assigned to escort, perhaps asking about cargo, or their destination.

- Pilots discussing the nature of the enemy, or their previous experiences with this enemy (This is great for introducing new enemies to the player as well)

- Pilots commenting on newly arrived ships in place or in addition to command. This can be mentioning their intentions, or their class, or even their affiliation to flesh out Commands famous â€œIncoming Jump Signature! Hostile Configuration!

*If, on the other hand, youâ€™re working on a campaign mission, remember to refer back to previous missions in that campaign. Not only does this enhance the sense of continuity missing from many fan campaigns, but it can also provide an easily accessible basis for a lot of pilot chatter in your mission, making the process of thinking it up that much simpler. If the missions directly previous to yours are being done by somebody else, remember to stay in close contact, and see if theyâ€™ll give you a beta or even some sort of mission outline or script. If these missions arenâ€™t done yet, or are being done by another staff member whom you canâ€™t contact, youâ€™ll have to try and improvise, and hope they follow the outline given to them. Alternately, remember you can always come back and edit details in or out of your chatter script.

*Use send-message-list sexps. Theyâ€™re easy to understand if you follow the rules down the bottom, keep down your sexp number, and theyâ€™re very convenient for long lists of messages, such as pilot conversations. Keep in mind though, that SML sexps fire as true from the start of the first message, not the end of the last, so if you want to base an event on the completion of one of these sexps, youâ€™ll need to know precisely how long the conversation lasts (easy to do by adding up the relevant time entries, which are in milliseconds, not seconds (1 sec = 1000 ms))

*Consider your chatter carefully. Your pilots should not toss off casual jokes when attacking a massive Shivan ship and holding the fate of humanity in their hands. Such jokes are also less funny when in orbit of a completely destroyed colony, or after the failure of your mission objectives that may have resulted in thousands of deaths. Pilot chatter is essential, however, in missions like convoy escorts, or quiet capship guards. Use common sense in defining your messages, and there shouldnâ€™t be any problems.

Right. If you read all that, then you should have no trouble in making interesting, chatter filled missions from this point on. Keep in mind though, itâ€™s only a guide. Other ways may turn out to be more efficient for your style of FREDding, or you might decide that what Iâ€™m saying is total rubbish, and you simply have a better way. (If so, chuck it up. Wikis are cool like that). And there are also missions where common rules and guidelines have to be suspended for realism or continuity or whatever. However, for most missions, the basic ideas presented here will adapt well, and hopefully thereâ€™ll never be an excuse to FRED a quiet mission again.

==Common problems==

How can I make the head anis on my messages match up with the head anis on the messages FS2 Sends?

The heads (and voices, and the messages themselves for that matter) that your wingmen send are defined by their persona. You can set the persona of various ships in the ship edit box. Then, all you need to do is to make sure you send your messages with the head ani used by that ships persona.

Wingman 1 is Head-TP1

Wingman 2 is Head-TP5

Wingman 3 is Head-TP6

Wingman 4 is Head-TP7

Wingman 5 is Head-TP8

Wingman 6 is Head-VP1

Wingman 7 is Head-VP2

Whenever my wingmen die, Command sends the messages I wanted them to send, making my conversations make no sense. What can I do?

This is undoubtedly the biggest and most common problem with sending any kind of message in FS2, and itâ€™s even more common with pilot chatter, since other pilots die so easily. There are ways around it, but it does require extra sexping. One of the more common ways is to make the pilots whom you want to send the messages survive is to use the ship-invulnerable sexp to make them invincible below a certain hull percentage. Keep in mind though, the longer they remain invulnerable, the more unbalanced the mission will get. Itâ€™s a good idea to change them back after theyâ€™ve sent their messages.

If you find this unbalances things too much, you can try back up messages. This involves much more sexping, but it does work. Say you want Alpha 2 to send a message thirty seconds after the mission has started. Create your message sexp referencing Alpha 2 and tell it to fire when time elapsed has reached thirty. Then, create another sexp that references Alpha 3, and only fire if time elapsed has reached 30 seconds and Alpha 2 is dead and Alpha 3 is not dead. Alpha 4 will send the message after thirty seconds when both Alpha's 2 and 3 are dead, and Alpha 4 is not. It's important to ensure the new wingman is alive, and all previous wingmen are dead, or you'll get multiple copies of messages being sent.

This process can be repeated as many times as there are friendly fighters in the mission, or as many times as you feel is necessary. Keep in mind, if youâ€™re worried about maintaining head ani continuity, youâ€™ll need several messages, each with a different Ani (I will generally only put two in, reasoning that, in theory at least, thereâ€™s a better than average chance that one of the first two will be alive, and after that, the message being sent is more important than head ani continuity being maintained.

Other ways around this problem are to use intense pilot chatter early in the mission (When pilots are more likely to be alive) and fill the latter half with chatter between capships, newly arrived pilots, or command. Also, keep in mind that messages that donâ€™t have to be sent can be given a priority of Normal or Low â€“ this will mean that they will not be sent at all if the ship charged with sending them dies. This is not, however, a viable option for conversations, or story important messages.

Skybox

2006-01-10T22:58:06Z

81.182.83.170:

A '''Skybox''' is an invisible sphere on which a texture can be applied, which will be the background of the actual mission.

To create a skybox you must create a [[*.POF]] that will represent the sky. The normals of the skybox must be pointing inwards so the player will be able to see the textures on the skybox. You can use as many textures as needed (2 to 6 are recommended). Additional textures will prevent streching of the map across the sky, but it will render slower. Recommended texture sizes for skyboxes are 512x512, 512x1024, 1024x512, or 1024x1024. It is possible to create animated textures that will display flickering stars or random comets.

==Creating a Scene to Render==

The first thing you want to do is to create a scene. Usually itâ€™s going to be space. Though You can download plugins that can generate terrain based on a bitmap. The good news is that you really donâ€™t need to do much point editing. You can make an interesting scene with simple primitives. You do not need to convert anything to pof. So splurge on your polycount as much as possible. When working with renders more is better. 
Truespace defaults the render backdrop to grey, to make it black (the normal color of space), right click on the render button and some options should pop up. Right click on color and set it to black. The background should follow suit. 
Now go to your primitiveâ€™s window and pull up the sphere icon. Right-Click on it and enter some high numbers into the boxes, for most planets 64x64 is ok. Click on it to create your sphere. For a texture you may use the axion planet shader. This creates random planet features and lets you define a planetâ€™s colors. Using this shader can save you lots of time. To gain acces to it right click on the paint object button, then click on the upper right sphere in the material editor, select axion planet shader from the list. Right click on the sphere to open the shader options. Click on various colors, a color selector will pop up. Defining different colors will create different looking planets. You can adjust the various sliders to alter the texture appearance. When you are satisfied you can hit the paint button. The only problem with the shader is that it seems you can only use one set of variables in a scene. 
If you want to add an atmosphere, hit control+c to copy your sphere then right click on the arrow button, then it the keyin box to slightly increase the size of the sphere. You can use the clouds shader along with filter transparency. Select the shader by clicking on the top left sphere then selecting clouds from the list. The upper right sphere controls transparency right click on it and select filter. set both the cloud back color and transparency filter color to black. cloud color can be changed for different effects. now paint the outer sphere. if you were to render the scene right now you would have a nice looking planet. 
To render nebulas, you want to use filter transparency (set the color to the same color you want to be transparent, usually black). i perfer to use texture map as my shader. you also want to change your reflectance (lower left sphere) to constant, otherwise you will see the edges of the primative you texture. You can apply the material to an object with the paint button, such as a plane or sphere. Then place it off in the distance somewhere. To create large wrap around nebulas you can make a really big sphere and flip the normals and apply your material. 
Play around with various stuff, you can add rings and background nebulas and distant asteroid belts, but im not going to go into that in too much detail. Realistically you will want to make an elaborate scene. There are plenty of filters to choose from. Play around with the material editor as much as posible, it is very easy to make cool stuff with it.

==Rendering the Textures==

Once your scene is complete pick a central location to render from. in that spot, create 6 cameras. It is critical that they have the same origin. rotate the cameras with the nemeric key-in window. Make it so that a camera points in each directin. Each camera must be perfectly paralell to whatever axis it is pointing down. Now the default camera angles are too narrow to render the box correctly. Changing the size value of the z axis of the camera essintially changes its zoom. setting that number to exactly 0.4 will make a seamless box (at least it did for me). 
go back into the render options. Set quality to high, visibility to raycast, anti-aliasing is optional, but i use adaptive. Make sure the ratrace toggle button is down. double check to make sure your background color is black. Select a camera and then click the view from object button in the view group. Click on render scene to file. In the Resolution section of the render dialog, select other and key-in whatever resolution you want to use. It should be square. give the image a name and choose a format. . If you use .tga be sure you render to a 24 bit, If you pick 32bit it will include an alpha channel that freespace probibly wont apriciate. repeat for each camera. Id advise the use of a naming convention to identify the set of bitmaps, such as skyname_front.

==Texturing the Box==

Start a new scene and create a plain cube with a resolution of 1. Now the first thing you must do is uv map the box. Click on UV Projection, select cubic uv projection. In order to eliminate the lines that apear at the edge of the texture, you must slightly scale up the projection cube. I find that increasing its size from 2.0 cubic meters to about 2.003 cubic meters is about enough to get rid of the lines without being able to detect the seams. When you are done, hit apply. Now get into the material editor and select texture map and pull up one of the images you just rendered. Using the paint face tool, paint the corasponding side on the cube. do that with each of your textures so that they line up. You may find that the top and/or bottom textures are not properly oriented. The best way to fix that is to open those textures in a paint program and rotate them so they line up with the others. once your box is seamless, scale it up to about 1400 cubic meters and flip the normals. glue it to a light and scve the scene. Run it through PCS with a conversion factor of 20 and save the mode. If nessisary, convert your textures to a format supported by freespace.

==Alternative to this process==

If you don't want to do all of the above, you can easily create your skybox textures in Photoshop, Paint Shop Pro, Gimp, MS Paint, or whatever floats your boat. You would then apply your maps in truespace and convert the COB into a POF. I'm not going to tell you how to make your skybox textures, since i can't really draw.

==Adding Skyboxes to Missions==

Put your skybox model into the models folder and your textures in the maps folder. In Fred, open up the background editor dialog. Near the bottom, there is an edit box where you can type in the name of your skybox. The file extension *.POF is optional. It is not recommended to use standard bitmap nebulas in addition to the skybox.

SF Scorpion

2006-01-10T22:56:30Z

81.182.83.170:

{{FS12_Ships}}
{{shipimage|image=http://www.descent-freespace.com/goodies/gallery/ships/tn_sfscorpion_tga.jpg|caption=The SF Scorpion}}

The '''SF Scorpion''' was a Shivan interceptor fighter used during the [[Great War]] in 2335 by the [[Shivan]]s.

==Description:==

===FS1 Tech Room Description===
We originally thought the Scorpion was the Shivans best fighter. However, we now believe that the Scorpion is nothing more than a Shivan scout ship. Their vast numbers and seeming unimportance to the Shivan war effort leads us to this belief. Regardless of its purpose, the Scorpion is highly maneuverable, fast, and difficult to destroy. It can also do damage equivalent to our space superiority fighters. 
In the event that you encounter Scorpions, regard them as a Class C threat.

===Developer Notes===
''None''

===Veteran Comments===
''The Scorpion is lighter and more agile then most Shivan craft, but not particularly fast. Armament is middle-of-the-road and neither impressive nor laughable, while protection is on the lightish side but still capable of standing up to enemy fire briefly. It does posess the unique abilty to move in three dimensions at once, something not often seen on lower difficulty levels but very annoying on higher ones.'' 
''All in all the Scorpion is quite comparable to the GTF Apollo. It does most of the same things with about the same level of competency as them.''

==Performance:==
===Statistics===
{|
|-
| style="width:200px" | '''[[Technical_Terms_and_Definitions#Type|Type]]'''
| style="width:200px" | Recon
|-
| '''[[Technical_Terms_and_Definitions#Manufacturer|Manufacturer]]'''
| Unknown
|-
| '''[[Technical_Terms_and_Definitions#Manuverablity|Manuverability]]'''
| N/A
|-
| '''[[Technical_Terms_and_Definitions#Max Velocity|Max Velocity]]'''
| 70.0 - 72.0 mps
|-
| '''[[Technical_Terms_and_Definitions#Max Afterburner Velocity|Max Afterburner Velocity]]'''
| 140.0 mps
|-
| '''[[Technical_Terms_and_Definitions#Armor|Armor]]'''
| N/A
|-
| [[Technical_Terms_and_Definitions#Hitpoints|Hitpoints]]
| 180
|-
| [[Technical_Terms_and_Definitions#Shields|Shields]]
| 600
|-
| '''[[Technical_Terms_and_Definitions#Length|Length]]'''
| 22 m
|}

===Armaments===

*'''[[Technical_Terms_and_Definitions#Gun Mounts|Gun Mounts]]'''
{| border=1 cellpadding=4 style="border-collapse: collapse"
|- align="center"
| colspan=3 style="background:#351515;"| '''Freespace 1'''
|- align="center"
| style="width:40px" |Bank
| style="width:60px" |Guns
| style="width:160px" |Standard Loadout
|- align="center"
| 1st
| 2
| Shivan Light Laser
|- align="center"
| 2nd
| 2
| Shivan Heavy Laser
|}
*'''[[Technical_Terms_and_Definitions#Missile Banks|Missile Banks]]'''
{| border=1 cellpadding=4 style="border-collapse: collapse"
|- align="center"
| colspan=3 style="background:#351515;"| '''Freespace 1'''
|- align="center"
| style="width:40px" |Bank
| style="width:60px" |Capacity
| style="width:160px" |Standard Loadout
|- align="center"
| 1st
| 40
| [[GTM MX-50|MX-50]]
|}

Starborn

2006-01-10T22:53:20Z

81.182.83.170:

{{non-canon}}

The '''Starborn''' (plural: ''Starborn'') are omnipotent and omnipresent creatures in the [[MindGames]] user-made campaign. They are able to manipulate human genes and influence their decisions. Only one third of humanity is immune to the influence of the Starborn.

==External links==
[http://www.3dactionplanet.com/hlp/hosted/mindgames/Starborn%20FAQ.html The Starborn FAQ]

{{stub}}

Species

2006-01-10T22:43:56Z

81.182.83.170: boldening

As of the end of Freespace 2, there are four canon '''species''' in the Freespace universe.

*[[Terrans]] - The Terrans, or Humans, are the most prominent race in the games, and the race of the player in all official Freespace Titles to date. 
*[[Vasudans]] - A race of philosphers and warriors from a desert world, the Vasudans are adversaries in the easrly stages of Freespace 1, but firm allies by Freespace 2 
*[[Shivans]] - A five limbed, xenophobic alien race, the Shivans are the primary adversary in both Freespace 1 and 2. 
*[[Ancients]] - A mysterious, extinct species known only from ruins, the Ancients provided the Terran Vasudan Alliance with the information that killed the Lucifer, and built the Knossos portal in Gamma Draconis. 
 
{{non-canon}}
 
==Non Canon Species==
 
*[[Aesir]] - A species in the user made [[Twisted Infinities]] campaign.
*[[Nightmares]] - A species originally created for the (now-cancelled) Reciprocity campaign.
*[[Starborn]] - Superior, omnipotent and omnipresent creatures from [[MindGames]].

[[Category:Lists]]

Shivan Manifesto

2006-01-10T22:43:12Z

81.182.83.170: boldening

{{non-canon}}
The '''Shivan Manifesto''' is a long, complex document, which describes (in detail) a theory on the origins and motivations of the Shivans during the events of the Freespace saga. Though the theory has gained some support, it has many detractors, and is not considered canon, nor is it generally accepted by the FS community.

== Summary of the Manifesto ==

The theory outlined in the Manifesto is based on the idea that the subspace travel performed by Terrans and Vasudans is harmful to subspace. It claims that the Shivans are energy beings from subspace, that use a kind of exoskeleton to maintain integrity in our own plane of existence, and their attacks against the two races are the Shivans aggressive defence of their home dimension whenever large levels of subspace activity occur in any given area of space.

The theory also explains the Shivans' motivation for destroying Capella as an act of fear, lest the GTVA deploy more Colossi in large numbers, as they were not able to understand how a civillization's technology could evolve so quickly. It also suggests that this retreat is due to the SOC mission where you are ordered to destroy a number of unknown Shivan devices, which the Manifesto states are responsible for Shivan life-support.

== Support for the Theory ==

The theory itself is based largely on conjecture from both the Ancients and Bosch monologues in Freespace 1, and Freespace 2, respectively, and a number of the ideas (such as the Shivans as energy beings) are not mentioned by any canon sources.

== Criticisms of the Theory ==

According to its detractors, the theory omits or ignores many significants pieces of information from the games, and overemphasizes the significance of others. It also makes several significant statements based almost entirely on guesswork, with no indication from either game to base these statements on.

Specifically, it makes major assumptions about the nature of the ETAK device, the Shivan Comm Nodes and the Shivans themselves without ingame evidence, and contradicts in game evidence on several points (for example, the beleif that the Shivans would be frightened of the possibility of multiple [[GTVA Colossus]] class vessels without any evidence that such vessels exist).

A more detailed list of the criticsms of the theory can be found on the [[Criticisms of the Shivan Manifesto]] page.

== Text of the Manifesto ==

The full text of the Manifesto can be found in [http://www.cyd.liu.se/users/~johbu692/The%20Shivan%20Manifesto.pdf PDF Form]

Node Inconsistencies

2006-01-10T22:41:58Z

81.182.83.170: intro added

Those continuation flaws that occur regarding jump nodes between FreeSpace: The Great War and FreeSpace 2 are called '''node inconsistencies'''.

There are a number of jump node connections that are used in [[Portal:Freespace_1|Freespace]] but are not illustrated on the [[Official Volition Node Map]]. They are listed below, along with their references and how valid you should consider them. [[Volition]] says that the [[Official Volition Node Map|node map]] should overrule other references.

==Pseudocanon Validity==

These connections are used in-game and would be considered canon if it weren't for the official map.

===[[Beta Cygni]] - [[Ikeya]]===
Used in First Strike (SM1-10). [[Famous Persons|Admiral Wolf]] says that the [[SC Taranis|Taranis]] has been chased from the [[Beta Cygni]] system back to the [[Ikeya]] system, and the [[SC Taranis|Taranis]] is fleeing to the [[Beta Cygni]] node during the mission itself. It is very likely, however, that this is a mistake. The cutscene immediately preceding this mission (not to mention the official node map itself) shows that the only subspace node out of [[Ikeya]] leads to [[Ribos]]. Additionally, during the mission, Freighter Halkins tows the cruiser to Tombaugh Installation, which is located in [[Ribos]]. It is probable that the mission designer just confused [[Ribos]] with [[Beta Cygni]].

===[[Beta Cygni]] - [[Ribos]]===
Used by the shield prototype convoy in The Hammer and the Anvil (SM1-08). The shield prototypes are escorted from the Cygni Installation in [[Beta Cygni]] to the [[Ribos]] node.

===[[Deneb]] - [[Altair]]===
Used by the player's squadron and Omega wing. The node is seen in Reaching the Zenith (SM3-04) and used in Running the Gauntlet (SM3-05) and Black Omega (SM3-06). Xenolinguists are transported to [[Altair]] to retrieve the ancient records and back to [[Deneb]] to rejoin the Terran fleet.

===[[Sirius]] - [[Delta Serpentis]]===
Used by the [[GTD Bastion]] in Clash of the Titans (SM3-07). The Bastion tries to intercept the [[SD Lucifer]] before it can reach [[Sol]]. Also seen in CB_starmap13 and CB_starmap14.

==Apocryphal Validity==

Although the [[Talania]] system is referenced in the FS1 ship database, no reference to it appears on the [[Official Volition Node Map]]. According to Eishtmo, however, Volition released a rudimentary node map around the time FS1 came out that had this system illustrated on it. This node map has unfortunately disappeared and has yet to resurface.

===[[Talania]] - [[Beta Aquilae]]===
===[[Talania]] - [[Vega]]===

===Comments===
Eishtmo: ''Further study into the topic has provided enough evidence that Talania was NEVER a canon star system. There is, at the very least, no evidence for it, the lack of a node map containing it being the biggest bit. At best, Talania as a star system is a concoction of various campaign builders and an overactive imagination. I apologize for making a big deal out of this.'' 
Goober 5000: ''There is indeed evidence for it - see the Leviathan FS1 tech entry: "...production was started up again after the defeat at the Talania system..." At the very least, we know it exists. Unfortunately we have no further information on what or where it is.''

==Command Briefing Animation Validity==

These connections are shown in the animations that accompany the FS1 command briefings. 

===Jump Nodes===

====[[Beta Aquilae]] - [[Sol]]====
Seen in CB_starmap06 and in CB_starmap08

====[[Ribos]] - [[Betelgeuse]]====
Seen in CB_starmap06, although Betelgeuse isn't labeled

====[[Ribos]] - [[Vega]]====
Seen in CB_starmap08, although the jump line isn't explicitly drawn

====[[Sol]] - [[Deneb]]====
Seen in CB_starmap08

====[[Vega]] - [[Antares]]====
Seen in CB_starmap04, although the jump line isn't explicitly drawn 

===Animation Usage===

====CB_starmap04====
Is seen in La Ruotta della Fortuna (SM2-03), showing ships being attacked in Vega and subsequently jumping to Deneb and Antares. Admiral Wolf says that the Vasudan fleet is retreating after having been decimated by the [[Hammer of Light]].

====CB_starmap06====
Is seen in Tenderizer (SM2-05), showing several possible jumps from Ribos through the surrounding systems. Admiral Wolf says that although there are dozens of star systems accessible from Ribos, the GTA can't afford to give up one more inch to the Shivans.

====CB_starmap08====
Is seen in Enter the Dragon (SM2-07) and in Playing Judas (SM2-08), showing the Lucifer jumping from Ribos to Vega and the Galatea jumping from Beta Aquilae to Sol to Deneb. In Enter the Dragon, Admiral Wolf says that fighter patrols have detected advance ships from the Lucifer fleet approaching Vasuda Prime. In Playing Judas, Admiral Wolf says that the Galatea has entered Deneb to guard the system against the Deneb prong of the Shivan attack on Vasuda. 

==Hearsay Validity==

These connections are mentioned in the FS1 briefings but are not shown visually.

===[[Betelgeuse]] - [[Antares]]===
Mentioned in The Field of Battle (SM1-02). Admiral Wolf says that Vasudans have been conducting strikes on Terran convoys en route to the Betelgeuse-Antares jump point. This jump corridor may also be alluded to in Paving the Way (SM1-06) when Admiral Wolf says that standard procedure would have the Galatea circumvent the Antares-Beta Cygni jump corridor and make two jumps. Jumping from Antares to Betelgeuse to Beta Cygni would satisfy this requirement. (But so would Antares to Ribos to Beta Cygni, through the pseudocanon Ribos-Beta Cygni corridor.)

==Implied Validity==

These connections are only implied, not described or illustrated.

===[[Beta Aquilae]] - [[Vasuda]]===
Implied in Tenderizer (SM2-05). Admiral Wolf says that the Galatea will be moving to Beta Aquilae in case the Shivans decide to attack Vasuda Prime through there. This implies that there is a jump corridor from Beta Aquilae to Vasuda. The shortest alternate route, starting from Beta Aquilae, involves three jumps: Vega to Deneb to Vasuda, or Sol to Deneb to Vasuda. (Of course, since they start in Antares, the Shivans could simply pulverize the Terran blockade and jump directly to Vasuda, but for whatever reason they don't decide to do that.)