My OperaA small (ok, not so small) history of Modding in Bridge Commander, Part 1
Sunday, January 25, 2009 6:19:30 PM
Before I begin I should mention that while I've been "here" (in the BC scene) for longer than half it's lifetime, I haven't been here since the real early days, before mods. Foundation was already released, and the first Bridge mods were already in progress. So the early stuff is a bit incomplete at times, my appologies for that. And I also appologize if I mention my own mods a lot, I can be quite proud about them, and yes, that's a character flaw of mine. It should also be noted that I will mention scripting mods for the most part (this is a programming log afteral), I can't keep up with all the mods being released, not even all scripting mods! So I'll focus on the, to me anyway, most important ones. I hope you will not be insulted if your mod isn't mentioned.
Star Trek: Bridge Commander is a game from late Februari 2002 by Totally Games and published by Activision. It's also known as just Bridge Commander and is often abrevated to just "BC". It's set, as the name suggests, in the Star Trek universe, somewhere between the events of Star Trek: First Contact and Star Trek: Nemesis.
What made this game great at first was that it combined elements of Star Fleet Academy (bridge view and crew interaction) and Klingon Academy (third person ship interaction), you can chose to allow the crew to do things (AI) or take the helm yourself. Other things that also made it a succes was the fact that it was one of the first games to use more than a 1000 (I believe the average is 2500) polygons, per ship. At the time this was unheard of. It also ran at acceptable, playable, speeds on a Voodoo 2 card.
The game's life was greately expanded when people found out you could modify the game. Just some terminology, people creating modifications are called "modders", the modifications themself are called "mods" (short for modicafication, singular is mod), "stock" is the word for the original state of an asset in BC that was included with the CD.
First it was discovered that the textures were in the TGA image format. This resulted in simple retextures of the models used, for example, a black Sovereign, but also retextures that improved on the stock textures. It was also quite soon discovered that there were "scripts" in the form of Python modules, but they were all in pyc format, and a decompiler wasn't avaidable.
But quite soon after the European release in early March of 2002 Totally Games released a Software Development Kit (SDK for short) for BC. In it were tools, a "NIF" exporter (NIF is the model format) for 3DS MAX R3, the Model Property Editor (MPE) to create "hardpoints" (which define the statistics for a ship, such as where the phasers are, how strong the shields are, etc, etc), an AI tool, documentation for some of the things, and, most importantly (for me anyway) all the Python files, in their .py, uncompiled, form, ready for us to read and learn.
With the scripts, we learned that things like ships, projectiles, (star) systems were just scripts, just programming, no special syntax or anything, just Python code which followed some predefined interfaces (not Java like interfaces, more API/framework interfaces). Together with the existing stock ships and the NIF exporter people went to work to create their own ships. This let to some experimentation, but some problems were found with the stock way of doing things. For example, all ship references were hardcoded. So the Single Player wasn't easily changed. There is also the Quick Battle (QB) where you can setup simple matches between ships, it uses a simple menu structure of "species->ships". But this menu was also hardcoded, order and all. The main use-case for new ships was with this QB, so for each ship you wanted to add, you had to alter the QuickBattle script. This situation wasn't sustainable, since not everyone had enough experience with scripts/programming (yes, Python is a full blown Turing Complete language). And most people using mods are looking for convenience. So, some people included their modding QuickBattle as well, but you only need 2 mods that do this to get into problems.
There is also another problem, every ship in BC has a number, that is the "species" number (different from the species mentioned above, every type of ship is it's own species, even every type of projectile, but that's a whole other section (Multiplayer, yes, the ship species number is also used in multiplayer). In this case, it made sure the right icon was assigned to the ship for the interface (this was a common problem in those days).
To solve these problems a fellow named "Dasher42" (also of Homeworld fame with the mods Favour The Bold and Sacrifice of the Angles) created a Dynamic Ship Plugin (name unsure, it's old, and it was superceded before I even got BC, I only know of it because 2 persons came across it on 2 days with atleast a year across). With this system a person could write a plugin in a directory called scripts/Custom/Ships (the entire Custom directory was originally meant for extra missions, for example addons by Totally Games), and then you could add a single line to a file in that same directory, to "import" the ship into the game. These ShipPlugin files would then execute and ShipDef objects are created, one for each ship.
With this system, a person called "NanoByte" create a tool that could both create these ship plugin files from stock-like scripts, and it could update the import file as well. NanoByte eventually also created a "BCMod" format, a simple file that concatenated several files and could overwrite the files in your BC installation, it contained a bug where empty files were omitted, this caused a wave of problems with one of his major mods later on.
Even this system didn't entirely feel complete, since you still had to manually change files. This changed with the advent of one of the first "big" mods, QuickBattleReplacement.
QuickBattleReplacement (QBR) is a mod by a person called Banbury, it's intent is to, as the name suggests, be a replacement for the stock QB, it too was setup as a Mission (QB is just a mission with GUI), it just allowed more things to be done with it. Just a couple of examples, you could set the exact location of a ship, you could have more than 1 system to travel to (QB was, originally, limited to 1 system, in a way this still is, except that you can change a file to load more systems when you start QB), you could even have a neutral set of ships, instead of the stock Friendly/Enemy split. But one thing changed it, it could save a setup, and then later load it as well, this code dynamically loaded a set of files. I think the code was originally based on a section in the mainmenu, where it loads custom missions, or that Banbury already knew Python. It doesn't really matter I suppose, he created a small snippit of code that you could point to a directory, and it would attempt to load every module in it. This, combined with the advent of Bridge modding (I did mention the interaction with the crew? That too happens in full 3D), created a small revolution. Dasher42 incorporated the "load every file" snippit into a more advanced plugin framework for BC, which he called "Foundation".
Before we get to Foundation, there are 2 other mods Banbury made, together with Dasher on some aspects of it, before Foundation. They should be noted, not because of their popularity (which is somewhat of a mixed bag, loved by those that know, and have managed to run it, unknown to others), but because they started something.
They added completely new features to BC.
The mods were Shuttle Launching and Secondary Targetting. I have to admit, Starbases (AI-only "ships") could already target multiple ships and in the SinglePlayer there are shuttles being launched, but as far as I could determine, Banbury didn't look at the stock scripts. But still, this was new for the user. The Shuttle launching capabilities, which used the "load each module from a package" snippit, could be added to any ship, complete with configurable launchers for each shuttle, and the number of shuttles used. And could be launched through the Science menu (the distribution of tasks is a bit different from what is seen onscreen, Science is more like Ops here). One interesting ommision was retrieval of the Shuttles, which was added later as another mod by the scripter Defiant (post Foundation).
The second mod, Secondary Targetting, exploited the fact that while a ship instance has a target, it's weapons could be redirected to any other number of targets. It isn't well known these days, because it was hard to get it working correctly, and to use it in the first place. Because it exploited the above fact, it also meant that the camera would always point to the ship you were targetting, not the ship(s) the weapons were targetting. It also used buttons, instead of mosue clicks to target more enemies, and if memory serves me right, you also had to unselect an enemy before you could use that "slot" (10 slots maximum) again. But at the time, it was massive! It was this (type of) technique that someone else (called Sneaker, we shall meet him later on) used for another mod, Inaccurate Phasers. But this is, again, a post Foundation mod.
But then, the Prophecy unfolded, Foundation is born and unleashed to the world, no more changing stock files!
Hark! Hear those Angels sing!
It is this Foundation that is now the basis for all new mods, and it has been since early 2003 (and before?).
Aside for Ships and Bridges, Foundation also provides a couple of other functionalities. For example, "mutators", a way to turn any element included in Foundation (except other mutators) on or off. This, incidently, also was the first MainMenu mod. It also provided "Overrides", Python is a very open language, it allows you to change nearly everything, I even believe (tough can't find it right now) that the Python documentation read "Nothing is Sacred!" In short, this allowed Foundation to reach into a piece of code (modules), and replace functions and values (In Python, there isn't much different from the two). Aside from overides, Sounds, Systems (Maps) and TGLs were added as mutable resources, similar to ships and bridges. Some are more succesfull than others, sounds are very easy to create, just the "name" (to use internally), the file to play, the (optional) volume and (optional) the mutator to use, and others are just harder to do, such as Systems, one is now unused, TGLs, this is (mostlikely) because BC loads a couple of libraries from hardcoded locations, somewhere around last year (written early 2009) I wrote a small Python library that could write (and read) TGL files. I should mention that TGL stands for Totally Games Localization file, and provide a binding from keys to text and audio, so E1M1IntroLuiLine1 would be a key to the text (for example) "Congratulations on your promotion Captain". But by simply replacing this text you could get German (or French) game. At any rate, a lot of these files were loaded through hardcoded paths, and the Python in BC (version 1.5.2) has been modified, for example, we aren't allowed to read or write outside of scripts/Custom/ not even a listing is allowed, or loading modules from outside scripts/, altough are ways around the listing part (through the Load/Save dialog and programmatic access to the internal GUI structure). So I couldn't even replace the original TGLs with my new (and overridable) TGLs that were autogenerated for use. But I'm getting ahead of myself. Foundation was born! And the dawn of a new era in BC modding! (Yes, we do speak of a pre and post Foundation era in BC modding)
It seems pretty neat, doesn't it? The one modification that shall be the one on which all other mods are build, the one file change to end all file changes. It is 42. And yet, not all is quiet, but that is for another installment.
It is the time of Post Foundation.
Considering this article has grown rather long, I'm going split it here. It seems like a neat place to stop. Being a turning point in BC modding. I do appologize if the text has a rather abrupt ending because of it. You better come back for the next installment.
Also to come in later logposts, I shall be looking at some of the mods mentioned here and look at the details that made those mods briliant.
See you next time,
--MLeo
Star Trek: Bridge Commander is a game from late Februari 2002 by Totally Games and published by Activision. It's also known as just Bridge Commander and is often abrevated to just "BC". It's set, as the name suggests, in the Star Trek universe, somewhere between the events of Star Trek: First Contact and Star Trek: Nemesis.
What made this game great at first was that it combined elements of Star Fleet Academy (bridge view and crew interaction) and Klingon Academy (third person ship interaction), you can chose to allow the crew to do things (AI) or take the helm yourself. Other things that also made it a succes was the fact that it was one of the first games to use more than a 1000 (I believe the average is 2500) polygons, per ship. At the time this was unheard of. It also ran at acceptable, playable, speeds on a Voodoo 2 card.
The game's life was greately expanded when people found out you could modify the game. Just some terminology, people creating modifications are called "modders", the modifications themself are called "mods" (short for modicafication, singular is mod), "stock" is the word for the original state of an asset in BC that was included with the CD.
First it was discovered that the textures were in the TGA image format. This resulted in simple retextures of the models used, for example, a black Sovereign, but also retextures that improved on the stock textures. It was also quite soon discovered that there were "scripts" in the form of Python modules, but they were all in pyc format, and a decompiler wasn't avaidable.
But quite soon after the European release in early March of 2002 Totally Games released a Software Development Kit (SDK for short) for BC. In it were tools, a "NIF" exporter (NIF is the model format) for 3DS MAX R3, the Model Property Editor (MPE) to create "hardpoints" (which define the statistics for a ship, such as where the phasers are, how strong the shields are, etc, etc), an AI tool, documentation for some of the things, and, most importantly (for me anyway) all the Python files, in their .py, uncompiled, form, ready for us to read and learn.
With the scripts, we learned that things like ships, projectiles, (star) systems were just scripts, just programming, no special syntax or anything, just Python code which followed some predefined interfaces (not Java like interfaces, more API/framework interfaces). Together with the existing stock ships and the NIF exporter people went to work to create their own ships. This let to some experimentation, but some problems were found with the stock way of doing things. For example, all ship references were hardcoded. So the Single Player wasn't easily changed. There is also the Quick Battle (QB) where you can setup simple matches between ships, it uses a simple menu structure of "species->ships". But this menu was also hardcoded, order and all. The main use-case for new ships was with this QB, so for each ship you wanted to add, you had to alter the QuickBattle script. This situation wasn't sustainable, since not everyone had enough experience with scripts/programming (yes, Python is a full blown Turing Complete language). And most people using mods are looking for convenience. So, some people included their modding QuickBattle as well, but you only need 2 mods that do this to get into problems.
There is also another problem, every ship in BC has a number, that is the "species" number (different from the species mentioned above, every type of ship is it's own species, even every type of projectile, but that's a whole other section (Multiplayer, yes, the ship species number is also used in multiplayer). In this case, it made sure the right icon was assigned to the ship for the interface (this was a common problem in those days).
To solve these problems a fellow named "Dasher42" (also of Homeworld fame with the mods Favour The Bold and Sacrifice of the Angles) created a Dynamic Ship Plugin (name unsure, it's old, and it was superceded before I even got BC, I only know of it because 2 persons came across it on 2 days with atleast a year across). With this system a person could write a plugin in a directory called scripts/Custom/Ships (the entire Custom directory was originally meant for extra missions, for example addons by Totally Games), and then you could add a single line to a file in that same directory, to "import" the ship into the game. These ShipPlugin files would then execute and ShipDef objects are created, one for each ship.
With this system, a person called "NanoByte" create a tool that could both create these ship plugin files from stock-like scripts, and it could update the import file as well. NanoByte eventually also created a "BCMod" format, a simple file that concatenated several files and could overwrite the files in your BC installation, it contained a bug where empty files were omitted, this caused a wave of problems with one of his major mods later on.
Even this system didn't entirely feel complete, since you still had to manually change files. This changed with the advent of one of the first "big" mods, QuickBattleReplacement.
QuickBattleReplacement (QBR) is a mod by a person called Banbury, it's intent is to, as the name suggests, be a replacement for the stock QB, it too was setup as a Mission (QB is just a mission with GUI), it just allowed more things to be done with it. Just a couple of examples, you could set the exact location of a ship, you could have more than 1 system to travel to (QB was, originally, limited to 1 system, in a way this still is, except that you can change a file to load more systems when you start QB), you could even have a neutral set of ships, instead of the stock Friendly/Enemy split. But one thing changed it, it could save a setup, and then later load it as well, this code dynamically loaded a set of files. I think the code was originally based on a section in the mainmenu, where it loads custom missions, or that Banbury already knew Python. It doesn't really matter I suppose, he created a small snippit of code that you could point to a directory, and it would attempt to load every module in it. This, combined with the advent of Bridge modding (I did mention the interaction with the crew? That too happens in full 3D), created a small revolution. Dasher42 incorporated the "load every file" snippit into a more advanced plugin framework for BC, which he called "Foundation".
Before we get to Foundation, there are 2 other mods Banbury made, together with Dasher on some aspects of it, before Foundation. They should be noted, not because of their popularity (which is somewhat of a mixed bag, loved by those that know, and have managed to run it, unknown to others), but because they started something.
They added completely new features to BC.
The mods were Shuttle Launching and Secondary Targetting. I have to admit, Starbases (AI-only "ships") could already target multiple ships and in the SinglePlayer there are shuttles being launched, but as far as I could determine, Banbury didn't look at the stock scripts. But still, this was new for the user. The Shuttle launching capabilities, which used the "load each module from a package" snippit, could be added to any ship, complete with configurable launchers for each shuttle, and the number of shuttles used. And could be launched through the Science menu (the distribution of tasks is a bit different from what is seen onscreen, Science is more like Ops here). One interesting ommision was retrieval of the Shuttles, which was added later as another mod by the scripter Defiant (post Foundation).
The second mod, Secondary Targetting, exploited the fact that while a ship instance has a target, it's weapons could be redirected to any other number of targets. It isn't well known these days, because it was hard to get it working correctly, and to use it in the first place. Because it exploited the above fact, it also meant that the camera would always point to the ship you were targetting, not the ship(s) the weapons were targetting. It also used buttons, instead of mosue clicks to target more enemies, and if memory serves me right, you also had to unselect an enemy before you could use that "slot" (10 slots maximum) again. But at the time, it was massive! It was this (type of) technique that someone else (called Sneaker, we shall meet him later on) used for another mod, Inaccurate Phasers. But this is, again, a post Foundation mod.
But then, the Prophecy unfolded, Foundation is born and unleashed to the world, no more changing stock files!
Hark! Hear those Angels sing!
It is this Foundation that is now the basis for all new mods, and it has been since early 2003 (and before?).
Aside for Ships and Bridges, Foundation also provides a couple of other functionalities. For example, "mutators", a way to turn any element included in Foundation (except other mutators) on or off. This, incidently, also was the first MainMenu mod. It also provided "Overrides", Python is a very open language, it allows you to change nearly everything, I even believe (tough can't find it right now) that the Python documentation read "Nothing is Sacred!" In short, this allowed Foundation to reach into a piece of code (modules), and replace functions and values (In Python, there isn't much different from the two). Aside from overides, Sounds, Systems (Maps) and TGLs were added as mutable resources, similar to ships and bridges. Some are more succesfull than others, sounds are very easy to create, just the "name" (to use internally), the file to play, the (optional) volume and (optional) the mutator to use, and others are just harder to do, such as Systems, one is now unused, TGLs, this is (mostlikely) because BC loads a couple of libraries from hardcoded locations, somewhere around last year (written early 2009) I wrote a small Python library that could write (and read) TGL files. I should mention that TGL stands for Totally Games Localization file, and provide a binding from keys to text and audio, so E1M1IntroLuiLine1 would be a key to the text (for example) "Congratulations on your promotion Captain". But by simply replacing this text you could get German (or French) game. At any rate, a lot of these files were loaded through hardcoded paths, and the Python in BC (version 1.5.2) has been modified, for example, we aren't allowed to read or write outside of scripts/Custom/ not even a listing is allowed, or loading modules from outside scripts/, altough are ways around the listing part (through the Load/Save dialog and programmatic access to the internal GUI structure). So I couldn't even replace the original TGLs with my new (and overridable) TGLs that were autogenerated for use. But I'm getting ahead of myself. Foundation was born! And the dawn of a new era in BC modding! (Yes, we do speak of a pre and post Foundation era in BC modding)
It seems pretty neat, doesn't it? The one modification that shall be the one on which all other mods are build, the one file change to end all file changes. It is 42. And yet, not all is quiet, but that is for another installment.
It is the time of Post Foundation.
Considering this article has grown rather long, I'm going split it here. It seems like a neat place to stop. Being a turning point in BC modding. I do appologize if the text has a rather abrupt ending because of it. You better come back for the next installment.
Also to come in later logposts, I shall be looking at some of the mods mentioned here and look at the details that made those mods briliant.
See you next time,
--MLeo
