By: Jason Kane (aka: Mordok)
Everyone and their grandmother wants to create their own little corner of space. But there isn't (yet) any official documentation on how to do it. So, here goes.
Note that most of the information here is based on guesswork and many trial and error attempts. The game designers are extremely helpful but most of us are more interested in having hem working on the game instead of writing documentation (something we all wholeheartedly support). Most of what's here has been gathered from postings in the Stellar Frontiers newsgroup (stardock.games.sf) and it's subgroups.
There are still some really big gaps, any assistance in filling them in would be appreciated. Please post comments/additions to the stardock newsgroup and/or email them to me (jkane@broadlink.com ) for inclusion in future postings.
Note: Most of this info is at least useful. I have not written anything to
explain the #include style file arrangements.
The .dat file is split up into sections, each section describes a particular aspect of the game. There are three basic types of section "bitmap", "data" and "design".
Now I'm going to go through each section of a dat file explaining the format, as well as what each option does.
The game data section includes a series of variable names and corresponding values. These values affect the entire solar system.
| Tag | Description | Default | ||||||||
| year | This parameter gives you a way of randomizing the positions of the planets. Each value of year will result in a different configuration of the planets in their orbits, unless their initial angles are hard coded. (See Planet Data section for more info) | 3015 | ||||||||
| players | Maximum number of simultaneous players. This includes both humans and computer controlled ships. | 64 | ||||||||
| robots | Total # of computer controlled ships (be sure you have at least this many AI names/ships defined in the robots data section) | 16 | ||||||||
| max_acc | maximum acceleration (not maximum velocity) | 50 | ||||||||
| light_speed | this is the measure of c in pixels per second | 200 | ||||||||
| ship_g | This is the gravitational constant that is applied to gravity between planets and ships. The mass and distance is still factored in, but by making this constant independent from the planets-to-planet gravity we can turn off the planet-planet gravity and keeps the planets positions constant. | 50 | ||||||||
| planet_g | This makes the planets more attractive to each other, but does not affect ships. Changing this to be nonzero will turn on planet-to-planet gravity, which means that the planets will begin to orbit each other and/or the sun. This tends to not work very well | 0 | ||||||||
| debris_count | This is the number of debris/powerup bitmaps that have been defined for each race. | 4 | ||||||||
| extra_colonies | By default, the game will not allow more colonies than there are planets. This parameter allows you to expand that capacity. For example, if the solar system has 32 planets defined and extra_colonies is set to 4 then the game will allow up to 36 colonies. | 4 | ||||||||
| allow_surrender | In days gone by, you took over a colony with brute force. When allow_surrender is 'yes' colonies will give up when under sustained assult (see defection_rate and loyalty_cycle for more details) | no | ||||||||
| defection_rate | The %probability / second that a colony with -100 loyalty will defect. | 6000 | ||||||||
| offensive_factor | the % factor that an attacking colony will have over a defending one. | 200 | ||||||||
| loyalty_cycle | The number of seconds that a 100% loyal colony will wait for help after falling under attack before surrendering. | 1800 | ||||||||
| robot_population_total | Determines how many robots are available (shared among all races) based on total population. | 8 | ||||||||
| robot_population_rate | This determines at what rate robots are handed out
per percentage point of total population. For the numbers you gave above,
there are 16 robots, 8 of which are distributed to each race based on total
population. One robot is given for every 3% of the total possible system-wide
population.
In addition, a separate pool of robots (in this case 8) is available based on how many planets each race has. To control this there are robot_planet_total and robot_planet_rate, which set how many robots are available and how many planets are necessary for each one. |
2 | ||||||||
| robot_planet_total | Determines how many robots are available (shared among all races) based on number of planets. | 0 | ||||||||
| robot_planet_rate | determines at what rate robots are handed out per percentage point of planets controlled. | 0 | ||||||||
| powerup_action | There are "swap", "level+##%", "value+##%", "credit+##%" where ## is
a number between 0 and 100.
|
|||||||||
| AI_level | Unknown, your guess is as good as mine. | High | ||||||||
| laser_defense | enables/disables autofiring lasers to destroy incoming missles. This is a fairly significant advantage for Admirals Club members. | Off? | ||||||||
| name | One line name for this scenario. This is what is displayed when players are choosing a server. | |||||||||
| desc | Multi-line description of this scenario. This is displayed when players first enter this scenario. | |||||||||
| salvage_right_pct | You can also specify how much credit you get for capturing an enemy held planet -- by dropping a colony, not by bombardment. |
Fortunately for us, all the bitmap sections share the same basic format. I have started with the descriptions given in the .ini comment and expanded them where they may be difficult to understand.
| class | Bitmap class, this can be ship, missile, explosion, Planet, Moon, Asteroid, colony, Warp, MainWindow, VideoWindow, MapWindow, ChatWindow, or debris. Generally you'll know what class you should use (ship, missile etc..) so odds are you'll get this one right. | ||||||
| name | Bitmap name. Used as a default in case object has no name, in other words, if you do everything right this field will be ignored. It's a one-word description of what this is an image of. | ||||||
| file | Bitmap filename without the .bmp and without the path. All of the images you add will be in the /bmp/256 directory. | ||||||
| nF | Number of frames in bitmap. Frame 0 starts at bottom of bmp and frame nF-1 is at the top. As you can see if you open up one of the ships or weapons that come with the game, animated bmp files look like little movie strips. SF uses the bottom-most image first and moves up the strip. Take a look at the seqT parameter also. | ||||||
| Sz | Size of the bitmap. Used for collision detection in the game. Saturn is a good example of why you would want to specify this parameter at all. | ||||||
| seqT | Sequence type:
|
||||||
| tc | Transparent color. 0 = black. Use something like 10 to set all pixels darker than RGB 10:10:10 transparent. My results on this have been less than conclusive. My advice is to use 15:15:15 as 'solid' black and 0:0:0 as transparent. That may mean tweaking the color palette for your images, Paint Shop Pro does a pretty good job at this. | ||||||
| alpha | Alpha factor. 100 sets all pixels to their full brightness. 50 is 50% brightness. 0 is completely black. The default setup has everything but mines at 100, mines are at 75. Why you wouldn't just tweak down the brightness of the 'origional' image I don't know. |
| name | see login |
| login | I'm not sure which of these first two serves as the actual name of the ship's captain. I suspect the 'name' field needs to be unique, but the login is the label displayed by SF. |
| rank | Rank of is robot (starting at 0) |
| race | Robot race (0 - 3 with standard races) |
| st | ship type, this is set in ship designs section under "ship id". |
| ship_name | Name of this robot's ship (duhh) |
| nm | Number of missions for this robot |
| nk | Number of kills for this robot |
| name | Name of the race (Arcean, Terran etc..) | ||
| id | Numeric identifier for the race (0,1,2 ...) | ||
| home | Homeplanet, this is where players of this race 'start' | ||
| pg/dt | |||
| debstart | |||
| temp | This races prefered temperature, 300 is default for terrans. This presumably effects population growth and habitability. | ||
| atmP | This races prefered atmospheric pressure, works like temp | ||
| grav | This races preferred planetary gravity (like temp and atmP) | ||
| bonus | |||
| col% | |||
| condition | These are the conditions necessary for this race
to be victorious. This is set as a string and all the possible forms it might
take are unknown (I don't recall Stardock ever giving us a complete list
of the possibilities). Known options are (with # representing a configurable
number):
|
| rank | Cosmetic rank string |
| level | Numeric Rank Identifier, this corresponds with the rank requirements in the ship design section. |
| active score | |
| total score | Score required for this rank |
| total kills | # of kills required for this rank |
| duty | ? Determines AI behavior ? |
| inverval(s) | |
| acc |
| Class | should be "Star", "Planet", "Moon", or "Minor" (asteroid). |
| name | the name of the planet. |
| rad | the radius of the orbit in units that depend on what class of planet it is. The stars, planets and asteroids use a unit that used to be such that 1 was the radius of the Earth's orbit, but things have been rescaled and the result is that Earth is at 0.2 and Pluto is at 0.49. Moon orbits are more typically around 1.0. |
| angle | the angular position in the orbit in degrees. |
| mass | depends on the class. Stars are in units of Sol's mass, so Sol would be 1.0. Planets and asteroids are on the same scale so they should have something in the range 0.05 (asteroid) up to around 17 (Jupiter) with Earth at 1.0. Moons are measured on a Luna scale, so Luna is 1.0. |
| ap | atmoshperic pressure, which is one of the factors that determines how liveable a planet is. It is 1.0 for Earth and everything else scales from that. |
| bi | the bitmap index or name from the planet bitmap section. |
| temp | temperature of the planet's surface in degrees Kelvin. Earth is around 300 K. |
| hp | hydrographic percentage. It is the percentage of the surface that is covered by a liquid surface and determines how many people can live on the surface (0 if hp is 100%). |
| sg | surface gravity, which is also a factor in the habitability of a planet. The units are based on Earth. |
| rr | the race that the planet will revert to after the server resets. |
| ab | accuracy bonus. This is now much of a accuracy bonus a colony will get when it lands on the planet. A 100% accuracy will make full use of the predictive code when aiming shots so the shots will lead a moving target. |
| tf | terrafrom percentage. This also is a factor in how liveable a planet is. Even if a planet is not very hospitable, it can be terraformed so that the optimal population is higher. A 100% terraformed planet is limited only by the amount of liveable area (basically surface area * hydro%). A 0 tf% means that the people are exposed to the raw characteristics of the planet (ap, sg, temp). The longer a planet is inhabited the higher the tf% will rise. |
| Field Identifier |
Sample |
Description |
||||||||||||||||||||
| class |
[race] |
it says class, but it really means
race. Which makes for a rather interesting social statement which may
eventually lead to riots and global condemnation of stellar frontier as a
game which forwards the backwards dogmas of our tangled and violent history. |
||||||||||||||||||||
| name |
Scout |
Even the fungus between my toes doesn't need a description
for this one. |
||||||||||||||||||||
| when available |
0 |
In every mod I've got handy this
is set to zero, other values will have unknown results. So unless you
want to have just another mod that works instead of a unique statement of
your self-ness and personal independance from the tyrannies of the world
you had better change this to something which better reflects your true self. |
||||||||||||||||||||
| rank needed |
0 |
Here's one every two-bit hack wants to mess with.
This determines the rank level that a player needs in order to be able to
select this ship design. |
||||||||||||||||||||
| max speed |
.25 |
This is a bit of a misnomer because
ships can move more quickly than this in a variety of ways. The obvious
one is qdrive, but we'll ignore that. The other obvious way is with
a boost unit. We'll also ignore that. The third obvious way is
death, which is the fastest way to move from anywhere in the universe to
your homeplanet. But we'll ignore that too. So this 'max speed'
is the fastest speed your ship can reach. |
||||||||||||||||||||
| ship bitmap index |
* | The * means that the game should try to figure it
out. It uses the 'name' field and compares it against the third field
of the ship bitmaps section of the dat. If it can't find a match the
game will automatically dial your mother through your modem and tell her
what a nasty person her little boy/girl turned out to be. So be careful. |
||||||||||||||||||||
| explosion bitmap index |
Ship |
When this ship blows up, what does
it look like? |
||||||||||||||||||||
| sound index |
explodeS |
Which sound from the sound_data will be played when
this ship explodes? There are some really amusing possibilities with
this one. (one of these days I'll make a mod with verbal taunts in
here ala scorched earth) |
||||||||||||||||||||
| ship id |
[r]001 |
This must be unique for every ship-design
in the game. Remember that the [r] is going to be replaced by the race
number. |
||||||||||||||||||||
| race id |
[r] |
Why have a race id when the 'class' of the ship also
holds the race? Heck if I know. |
||||||||||||||||||||
| volume |
2000 |
How much space is available on this
ship design. |
||||||||||||||||||||
| module slots |
12 |
Number of slots available on the ship. Note
that the scout has a 12 here, but there are only 11 modules defined.
That's why scouts 'pick up' and install counters, brakes, etc.. anything
that will fit in a slot. What happens when you use a value greater
than 12? Well, it sorta works. Some parts of the game may have
problems however (notably the refit screen won't scroll to show you the additional
modules so you cannot easily upgrade them, sell them or drop them). |
||||||||||||||||||||
| modules |
(power:1, shield:2, engine:2, qdrive:3, [r]4001*4*0*0*-8*8, [r]4001*-4*0*0*-8*8, sensor:3, boost:1, cloak, tractor*18*0*18, [r]4006) |
This is where things get funny.
Each module type has a different set of parameters, each of which have different
effects. New server have gotten much smarter. They can take something
like 'power:1' and understand that you mean module id [r]1001. Similarly
'tractor' is a named module (in the module data section it has a value under
the name column), so it can be directly referenced here as 'tractor' even
though the actual module type is 'dock' (same deal with cloak). It's
easy to get confused here, take it slow and don't be afraid to experiment.
|
[race] * 3 50 -200 200 torpedo1 none tube*60*4000*800*[r]001 [r]4001
[race] * 3 50 -500 100 minedrop none tube*15*20000*10*[r]003*6 [r]4003
[race] * 3 50 -500 200 plasma none tube*15*6000*800*[r]004 [r]4004
[race] * 3 50 -1000 200 torpedo2 none tube*100*80000*4*[r]006*6 [r]4006
[race] * 3 50 -500 200 none none tube*15*20000*12*[r]007*6 [r]4007
[race] * 3 50 -200 200 none none tube*20*6000*300*[r]008 [r]4008
[race] * 3 50 -200 200 none none tube*20*6000*300*[r]009 [r]4009
What does this mean? Well, I've gotten a lot of questions lately on this very subject so I'm going to dive into some rather painful details. First as you'll note from the [r] and [race] that this is from a .sec file not a .dat file. The [race] will be replaced with the cosmetic race identifier string (ie: Drengin, Terran, etc..). The [r] will be replaced with the race number. Why have both unique strings and unique numbers? Easy. The [r]'s (here and elsewhere) serve to guarantee that module identifiers are unique between races. The far right column is for module identifiers, and the game will have some serious problems if two modules have the same identifier.
So what do all these numbers mean?
| field name |
sample value |
description |
||||||||||||||||||||||||||||||||
| class | [race] | String identifier that tells the server which races can buy this item in starbases as well as which colonies will produce this item. This is also used to color this item throughout the game as well as select the proper debris image. | ||||||||||||||||||||||||||||||||
| name | * | the asterisk indicates that the game should come up with a string describing the module in question. It's the *'s in the module section that can turn shield1 into PlasmaShield (for instance). In the case of tube modules, this field has no effect (since the description string for tubes is based on the ordinance). But more on that later. | ||||||||||||||||||||||||||||||||
| vol | 3 | Volumn. Every ship has a limited amount of space available. | ||||||||||||||||||||||||||||||||
| mass | 50 | Mass can be confusing. First note that mass is entirely independant of volumn. Next, while each ship type can hold only a particular volumn of modules the amount of mass a ship can lug around is based on your engine. When the game says "your engine cannot handle the upgrade" (whatever, I can't remember the exact message but you know what I mean) that's the games way of telling you that if you added that item your engine would not be strong enough to move the resulting weight of ship. | ||||||||||||||||||||||||||||||||
| power | -200 | The only strange thing here is the negative sign. Whatever value is in the 'power' entry is added to the ships power supply. So when you have a -200 power item in your inventory (regardless of whether or not you're using it, this is the power required to maintain the module) your 'top' powerlevel is decreased by 200. That's a little confusing, here's another example. Suppose your power plant provides 800 units of power. Adding this -200 item reduces the amount of available power to 600. Whatever 'excess' power your ship has goes straight into charging up your guns and replenishing your shields so be careful not to overindulge on high-power items. | ||||||||||||||||||||||||||||||||
| damage | 200 | There is a two-edged sword in damage. But first an explanation. Damage is the number of points of harm that an item can suffer before failing. We've all run into the situation where our boost and engines are knocked out and we're drifting in space. The trick is, the higher the damage number the more hits a component can take before it fails. However, items with high damage numbers (like power units) take a long time to repair without starbase assistance. | ||||||||||||||||||||||||||||||||
| activate sound | torpedo1 | Simple enough, when this module is turned on the indicated sound is played. | ||||||||||||||||||||||||||||||||
| deactiate sound | none | Obviously this is the sound used when the module is turned off. | ||||||||||||||||||||||||||||||||
| function*parms | tube*60*4000*800*[r]001 | This is the nastiest part of the module section. The
function*params field determine first what kind of module we're talking about
and second what sorts of parameters are associated with that module. There
are a lot of different module types. It's rather difficult to determine
exactly what each of the parameters do. Here they are,
along with what little I know for sure about them:
|