Home » Stars! Clones, Extensions, Modding » FreeStars » Component File Sample (long)
 Component File Sample (long) |
Thu, 10 July 2003 14:00  |
|
|
|
Well, here's a snip of what a component currently looks like. We're using XML as the format. If you having coding/processing questions then you need to talk to Leit.
First, a "simple" part: Our buddy the Fuel Mizer engine
<Component>
<Type>Engine</Type>
<Name>Fuel Mizer</Name>
<EngineType>Ramscoop</EngineType>
<Costs>11 8 0 0 0</Costs>
<Tech>-1 -1 2 -1 -1 -1</Tech>
<Mass>6</Mass>
<FuelUsage>-10 -6 -3 -1 35 120 175 235 360 420</FuelUsage>
<SafeSpeed>9</SafeSpeed>
<MaxSpeed>10</MaxSpeed>
<FreeSpeed>4</FreeSpeed>
<BattleSpeed>6</BattleSpeed>
<Value>
<Type>Engine</Type>
<Number>6</Number>
</Value>
<LRTNeeded>Improved Fuel Efficiency</LRTNeeded>
</Component>
"Costs" are a list - Resources, Mineral1 (iron)... Mineral3 (germ) and then Crew/Population (which is currently zero for everything - but added for potential expansion.]
"Tech" is -1 if not required, otherwise the required level. Standard En, Wp, Pr, Con, El, Bio order. We're not looking at adding new tech fields.
FuelUsage is a list of the base fuel usage at each Warp Speed (1-10). Negative values are fuel gain from scooping.
The "Value" block is a recent addition. It assigns a sub-type and value to the component. In current usage the value is checked for when a starting ship design (i.e. Santa Maria colonizer) might have better tech parts available. If you have IFE and > Prop 2 at start your Santa Maria will not have a Quick Jump 5 Engine but probably a Fuel Mizer instead. The "Value" section allows the code to check if a "more valuable" component is available for that starting ship.
In addition to that I think the Value blocks might eventually prove useful for anyone wanting to automate ship design for either an utility or an AI player script.
Finally, note the "LRTNeeded" clause. This ties the component to a facet of the building race. There are also clauses to handle required PRTs and denying the part to certain LRT and PRT values.
Most things are fully named for ease of understanding.
Processing the file converts most of these into much more abstract variable values. Fairly few capabilities are inter-connected. "Ramscoop" type is differentiated for instance; you could also define "ramscoop" = "FreeSpeed > 1" (which is true for the current game). But, this prevents you from later adding
a "standard" engine with a higher free speed for instance without doing some additional changes to the processing code itself.
A "ship" inherits the abilities of its attached "components" - thus inherited classes are used to build up the full capabilites of a ship that can be easily queried and manipulated accordingly in the code.
I'll pull a ship hull next and put it in a separate message.
- Kurt
Time flies like an arrow.
Fruit flies like a banana.
- Groucho MarxReport message to a moderator
|
|
|
|
| Re: Component File Sample (long) |
Thu, 10 July 2003 14:07  |
|
|
|
OK. Now a sample ship hull... The Frigate
<Component>
<Type>Hull</Type>
<Name>Frigate</Name>
<HullClass>Scout</HullClass>
<Costs>12, 4, 2, 4, 0</Costs>
<Tech>-1, -1, -1, 6, -1, -1</Tech>
<Mass>8</Mass>
<Fuel>125</Fuel>
<Armor>45</Armor>
<InitAdj>4</InitAdj>
<Slot>
<Type>ENGINE</Type>
<Number>1</Number>
</Slot>
<Slot>
<Type>SHIELD</Type>
<Type>ARMOR</Type>
<Number>2</Number>
</Slot>
<Slot>
<Type>GENERAL</Type>
<Number>3</Number>
</Slot>
<Slot>
<Type>SCANNER</Type>
<Number>2</Number>
</Slot>
</Component>
The hull itself can have a full set of clauses assigned to it. PRT limitations, special abilities (like x2 mine laying), or basically any capability that a part component has.
In addition to this a ship hull has "Slot" Blocks. These define what additional components the ship can inherit capabilities from (when built). A slot basically defines what component type can be fitted, and how many. Note that a slot can have multiple types defined for it (the Shield/Armor slot).
Hope this is at least somewhat interesting. I can probably field general questions about the components file - and once I get caught up on the current code base I'll see about posting some further information.
- Kurt
Time flies like an arrow.
Fruit flies like a banana.
- Groucho MarxReport message to a moderator
|
|
|
| | | | | | | | | | | | |
| Re: Component File Sample (long) |
Tue, 23 December 2003 20:58 |
|
 LEit |
 | Lt. Commander |
Messages: 879
Registered: April 2003
Location: CT | |
|
I was going to leave localization to the Client programs, if those want to add some common names in other languages to the Components file, that is fine, the host program will ignore them. I think it ignores the name already.
I am trying to keep anything locale specific out of the host program. However, as a person born and raised in USA, my understanding of what is and is not specific to the US is not as good as it should be.
If I end up writing the client, I'll try to have a language be selectable, however, seeing as I only speak English, it might be hard to know what other languages need for support (right to left text for example).
- LEitReport message to a moderator
|
|
|
|
| Re: Component File Sample (long) |
Thu, 05 February 2004 10:31 |
|
|
|
Speaking of multilanguage support I could, with the help of a dictionary to fill the gaping gaps, do a Romanian translation. Although I must admit, literal translations can be hillariously bad. And I know American/Aussie english better than I know Romainian, still, I havent lost it.
Of course, has to fit around school stuff, but I could do it, there ain't THAT much to do.
Another thing to consider though, is are there any Romainians other than me who play stars?... Got me.
A good first step though.
- The Overstuffed SharpshooterReport message to a moderator
|
|
|
|
| Re: Component File Sample (long) |
Sun, 28 March 2004 13:00 |
|
| edorfaus |
 | Crewman 3rd Class |
Messages: 8
Registered: March 2004 | |
|
For localization I would suggest not modifying the existing files, but instead have files containing translations from in-file text labels to client-display text labels. That way you wouldn't have to modify the data files - and people could download only those translations they actually wanted, keeping the size low for those who don't want/need all the languages.
Besides, as LEit already mentioned, localization is really a client issue - it's up to the client to support it, so the common files shouldn't, IMO, be bogged down with text for various languages.
That being said, it wouldn't hurt to have a common file format for translations, XML would be nice, that all(or at least most of) the clients(that support localization) could use. If properly made, such a file could include anything from one to many languages.
This could also be used for "themed" games where you've renamed various components - instead of editing the core data file(although you might want to do this anyway), you write a translation file.
Although this would be completely up to the client(and perhaps not something for the first one), I'd also suggest having similar files for graphics used in the GUI, or maybe even having full "skin" support.. Fully optional, of course.
Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Sun Apr 28 01:43:56 EDT 2024
|
Members
Search
Help
Register
Login
Home
-1 for DNE, 0 for miniturization possible but no tech required. 
