Menu
▾
▴
xenocide-programming
|
From: breunor <br...@pr...> - 2004-02-21 18:01:29
|
Regarding the atmosphere type of air/water/vacuum, shouldn't that be put on most items? If we expand the game later to include the TFTD missions, I doubt we'd want the player using a pistol or incidiary rounds underwater for example. But a harpoon gun could be used out of water IMO, so it wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air, 2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then when the player gets to the site, the arming screen would only let you equip a soldier with items whose type matches the atmosphere. This point also brings up one of the laboratory ideas of having "weapon load templates", the member brought it up as using for a sniper vs. heavy assault type of load, but here you could create an "aqua" load, and have it switch weapons for you. It would be a hassle to have 24 soldiers loaded for water and switch to a land loadout, only to switch back for the next mission. But that is v1+ ideas, the point being that if you include this atmosphere type of every item, then that functionality would be possible later on. Breunor |
|
From: breunor <br...@pr...> - 2004-05-23 06:13:44
|
May I suggest an additional variable be included as part of the price. Mamutas asks what to do if market supply/demand forces affect a price, this variable could be used to reflect that. This variable could be the result of other variables being calculated somewhere else. Multiple factors could affect price, and the result of those factors could be held by a single variable. That allows you to eventually make as complicated a system as you like, but for version 1 you just define the variable as equaling 1 for everything. Later on you might say (1/(#of corpses/days of game time)) is the value or something like that. Just a thought, I'll return to my corner now... |
|
From: Mamutas P. <mam...@ho...> - 2004-02-22 18:47:06
|
I agree with Breunor. It is a reasonable suggestion. In my previous post I just wanted to point out, that there should be no difference in terms of using weapon on Mars or Earth. Or am I missing something? As for all possible comibinations of atmosphere types, we can either go as Breunor suggested or just have something like that (where atmosphere type name is optional, but at least one must present): <atmosphere type> <vacuum/> <air/> </atmosphere type> Here we can even specify how each atmosphere will effect the weapon, but it is definitely V1+: <atmosphere type> <vacuum range="1000" accuracy="1"/> <air range="500" accuracy=".5"/> </atmosphere type> Regards, Mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of breunor Sent: Saturday, February 21, 2004 11:50 AM To: xen...@li... Subject: [Xenocide-programming] XML facility-item data Regarding the atmosphere type of air/water/vacuum, shouldn't that be put on most items? If we expand the game later to include the TFTD missions, I doubt we'd want the player using a pistol or incidiary rounds underwater for example. But a harpoon gun could be used out of water IMO, so it wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air, 2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then when the player gets to the site, the arming screen would only let you equip a soldier with items whose type matches the atmosphere. This point also brings up one of the laboratory ideas of having "weapon load templates", the member brought it up as using for a sniper vs. heavy assault type of load, but here you could create an "aqua" load, and have it switch weapons for you. It would be a hassle to have 24 soldiers loaded for water and switch to a land loadout, only to switch back for the next mission. But that is v1+ ideas, the point being that if you include this atmosphere type of every item, then that functionality would be possible later on. Breunor ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 |
|
From: Federico A. L. <fl...@ma...> - 2004-02-22 20:40:41
|
I was going to say that by default the
<environments>
<atmosphere type="terrestrial" />
</<environments>
Should be allow terrestrial and vaccum (like laser, plasma, etc)... for only
terrestrial like pistols (I dont think you should be able to use them in
Mars) you put the enviroments tag...
For compound ones like those that can work in terrestrial, vaccum and
maritime (underwater) I propose something like this:
<environments>
<atmosphere type="terrestrial" />
<atmosphere type="vaccum" />
<atmosphere type="underwater" />
</<environments>
And if we need later, we can add modifiers to each one of them.
Greetings
Red Knight
-------Original Message-------
From: Mamutas Plaukotas
Date: 22/02/2004 15:42:36
To: 'breunor'; xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data
I agree with Breunor. It is a reasonable suggestion.
In my previous post I just wanted to point out, that there should be no
difference in terms of using weapon on Mars or Earth. Or am I missing
something?
As for all possible comibinations of atmosphere types, we can either go as
Breunor suggested or just have something like that (where atmosphere type
name is optional, but at least one must present):
<atmosphere type>
<vacuum/>
<air/>
</atmosphere type>
Here we can even specify how each atmosphere will effect the weapon, but it
is definitely V1+:
<atmosphere type>
<vacuum range="1000" accuracy="1"/>
<air range="500" accuracy=".5"/>
</atmosphere type>
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
breunor
Sent: Saturday, February 21, 2004 11:50 AM
To: xen...@li...
Subject: [Xenocide-programming] XML facility-item data
Regarding the atmosphere type of air/water/vacuum, shouldn't that be put
on most items? If we expand the game later to include the TFTD missions, I
doubt we'd want the player using a pistol or incidiary rounds underwater
for example. But a harpoon gun could be used out of water IMO, so it
wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air,
2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then
when the player gets to the site, the arming screen would only let you
equip a soldier with items whose type matches the atmosphere. This point
also brings up one of the laboratory ideas of having "weapon load
templates", the member brought it up as using for a sniper vs. heavy
assault type of load, but here you could create an "aqua" load, and have
it switch weapons for you. It would be a hassle to have 24 soldiers loaded
for water and switch to a land loadout, only to switch back for the next
mission. But that is v1+ ideas, the point being that if you include this
atmosphere type of every item, then that functionality would be possible
later on.
Breunor
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
|
From: Cpt. B. <cpt...@te...> - 2004-02-23 14:27:06
|
I think this would be the best way to go...it clearly defines where the item
can be used, and is easily scalable if we need to add a new atmosphere.
Regarding Breunor's suggestion (1=air, 2=water, 3=vacuum, 4=air+water,
5=air+vacuum, 6=water+vacuum, 7=all), I don't think it's worth it on the
data end of things. On the code end I'd reccomend making the atmosphere
types an enum with bitwise values (ie: terrestrial=1, vacuum=2,
underwater=4, mars=8) so that the class itself could get away with only a
single 'Environment' property. The data loader simply adds up the contents
of the <environments> tag when it build the object.
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
Federico Andres Lois
Sent: Sunday, February 22, 2004 12:34 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data
I was going to say that by default the
<environments>
<atmosphere type="terrestrial" />
</<environments>
Should be allow terrestrial and vaccum (like laser, plasma, etc)... for only
terrestrial like pistols (I dont think you should be able to use them in
Mars) you put the enviroments tag...
For compound ones like those that can work in terrestrial, vaccum and
maritime (underwater) I propose something like this:
<environments>
<atmosphere type="terrestrial" />
<atmosphere type="vaccum" />
<atmosphere type="underwater" />
</<environments>
And if we need later, we can add modifiers to each one of them.
Greetings
Red Knight
-------Original Message-------
From: Mamutas Plaukotas
Date: 22/02/2004 15:42:36
To: 'breunor'; xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data
I agree with Breunor. It is a reasonable suggestion.
In my previous post I just wanted to point out, that there should be no
difference in terms of using weapon on Mars or Earth. Or am I missing
something?
As for all possible comibinations of atmosphere types, we can either go as
Breunor suggested or just have something like that (where atmosphere type
name is optional, but at least one must present):
<atmosphere type>
<vacuum/>
<air/>
</atmosphere type>
Here we can even specify how each atmosphere will effect the weapon, but it
is definitely V1+:
<atmosphere type>
<vacuum range="1000" accuracy="1"/>
<air range="500" accuracy=".5"/>
</atmosphere type>
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
breunor
Sent: Saturday, February 21, 2004 11:50 AM
To: xen...@li...
Subject: [Xenocide-programming] XML facility-item data
Regarding the atmosphere type of air/water/vacuum, shouldn't that be put
on most items? If we expand the game later to include the TFTD missions, I
doubt we'd want the player using a pistol or incidiary rounds underwater
for example. But a harpoon gun could be used out of water IMO, so it
wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air,
2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then
when the player gets to the site, the arming screen would only let you
equip a soldier with items whose type matches the atmosphere. This point
also brings up one of the laboratory ideas of having "weapon load
templates", the member brought it up as using for a sniper vs. heavy
assault type of load, but here you could create an "aqua" load, and have
it switch weapons for you. It would be a hassle to have 24 soldiers loaded
for water and switch to a land loadout, only to switch back for the next
mission. But that is v1+ ideas, the point being that if you include this
atmosphere type of every item, then that functionality would be possible
later on.
Breunor
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
|
From: Cpt. B. <cpt...@pr...> - 2004-03-20 06:55:20
|
Hi All, I'm trying to complete config.items.xml, and I ran into a sticky spot that requires an answer from on high. Two related questions: 1) Are we going to have weapons that do not require ammo (sm/med/lg lasers, and laser cannon)? 2) Are we going to have weapons that auto-magically eat xenium without an interim 'ammo'-item (plasma cannons)? Personally, I would vote 'no' to both, if it hasn't been decided. It allows more granular control over game balance, and also simplifies coding. If every 'weapon' object requires an 'ammo' object to be able to fire, that's the only interface we need to code for. Exceptions to this mean more work, and more complicated code. -The Captain |
|
From: <fl...@ma...> - 2004-03-20 14:27:39
|
Basicly my reason to avoid non ammo charged weapons is that it is completly unrealistic, how they get the energy or round to fire??? About non interim 'ammo' even if can be useful would need a reactor on the weapon :P, the point is that the user havent have to manufacture ammo to use it, something in my opinion is wrong from the gameplay viewpoint. And I agree it simplify a lot the interface. (Simplicity is the key to understanding), and a earlier finished game :D Greetings Red Knight > Hi All, > > I'm trying to complete config.items.xml, and I ran into a sticky spot > that requires an answer from on high. > > Two related questions: > > 1) Are we going to have weapons that do not require ammo (sm/med/lg > lasers, and laser cannon)? > > 2) Are we going to have weapons that auto-magically eat xenium > without an interim 'ammo'-item (plasma cannons)? > > > Personally, I would vote 'no' to both, if it hasn't been decided. It > allows more granular control over game balance, and also simplifies > coding. If every 'weapon' object requires an 'ammo' object to be able > to fire, that's the only interface we need to code for. Exceptions to > this mean more work, and more complicated code. > > -The Captain > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > |
|
From: Jason J. <ja...@ki...> - 2004-03-20 17:16:37
|
In my opinion, all weapons should have an ammo object (for consistency), but some ammo objects can be hidden and/or have unlimited ammunition. This handles things like laser rifles and psi-amps. Personally I used the laser rifle as a standard weapon in the original, just because I didn't have to worry about ammo. This is part of the original feel, but I think that there should be a tradeoff for sure. Perhaps the laser rifle is much weaker compared to the original game, or something. But if we make laser rifles not have the unlimited ammo, we break with that part of the original. -----Original Message----- From: fl...@ma... To: xen...@li... Date: Sat, 20 Mar 2004 11:28:02 -0300 (ART) Subject: RE: [Xenocide-programming] XML facility-item data > Basicly my reason to avoid non ammo charged weapons is that it is > completly unrealistic, how they get the energy or round to fire??? > About > non interim 'ammo' even if can be useful would need a reactor on the > weapon :P, the point is that the user havent have to manufacture ammo > to > use it, something in my opinion is wrong from the gameplay viewpoint. > > And I agree it simplify a lot the interface. (Simplicity is the key to > understanding), and a earlier finished game :D > > Greetings > Red Knight > |
|
From: Mamutas P. <ma...@pr...> - 2004-03-28 04:12:31
|
Yeah, sooner or later a weapon needs to be reloaded, even if it means to put more xenium into plasma cannon reactor. On the other hand, isn't it the same as to have unlimited ammo as to have very cheap clip which holds lots of charge, for example 10000? So, when you buy your plasma cannon, you buy some xenium charge for few bucks and it will not run off until the end of the game. :) So, I suggest we should have all weapons with clips. We will balance the number of charges and the price later. The only bad thing I can think of, is that it will become a bit more annoying to buy a clip for every weapon, but it still needs to be done for regular rifles and cannons. So, I think it will be OK. mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Jason Jones Sent: Saturday, March 20, 2004 11:15 AM To: xen...@li... Subject: RE: [Xenocide-programming] XML facility-item data In my opinion, all weapons should have an ammo object (for consistency), but some ammo objects can be hidden and/or have unlimited ammunition. This handles things like laser rifles and psi-amps. Personally I used the laser rifle as a standard weapon in the original, just because I didn't have to worry about ammo. This is part of the original feel, but I think that there should be a tradeoff for sure. Perhaps the laser rifle is much weaker compared to the original game, or something. But if we make laser rifles not have the unlimited ammo, we break with that part of the original. -----Original Message----- From: fl...@ma... To: xen...@li... Date: Sat, 20 Mar 2004 11:28:02 -0300 (ART) Subject: RE: [Xenocide-programming] XML facility-item data > Basicly my reason to avoid non ammo charged weapons is that it is > completly unrealistic, how they get the energy or round to fire??? > About > non interim 'ammo' even if can be useful would need a reactor on the > weapon :P, the point is that the user havent have to manufacture ammo > to > use it, something in my opinion is wrong from the gameplay viewpoint. > > And I agree it simplify a lot the interface. (Simplicity is the key to > understanding), and a earlier finished game :D > > Greetings > Red Knight > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004 |
|
From: Cpt. B. <cpt...@pr...> - 2004-04-08 03:38:32
|
Hey all, One more question, and then I should have the config files posted as soon as I finish the design docs. I'm finishing up the cross-references between different items, research nodes, crafts, etc., and I've come up with three possible ways to record it. So that everybody understands what I'm talking about, a cross reference is where one entry points to another entry, e.g. the Pistol Ammo Clip item has a reference to the Pistol item that indicates which item it can reload. That's a simple one....two items, same document, same 'type'. In the research tree, there are references to six different entry types (other topics, crafts, items, personnel, facilities, and missions) The specific 'type' must be able to be determined by the parser so it knows which document to look in for the associated entry. The first way is to have a separate xml element for each reference type. So it would look like this: <craft craftid="craft1"/> <item itemid="item1"/> <facility facilityid="facility1"/> Pros: Each element immediately defines the 'type' of reference. Minimal processing (just a select case, really) is needed to determine where the associated document is. Cons: Not every entry uses all element types, so the xml is overly complicated. The parser would need to recognize and watch for all the different possible reference elements. Adding a new reference element might require extensive code work. The second idea is to combine them into one element with multiple attributes. Only one of the attributes would ever be used. <reference craftid="craft1"/> <reference itemid="item1"/> <facility facilityid="facility1"/> Pros: easy to read, easy for the parser to know what element is a reference. Cons: More process intensive. Each attribute would have to be tested for a valid value to find the id value. Third idea takes it a step farther. Since in xml, a unique identifier must start with an alphabetic character, I ened up changing all the id values from "1, 2, 3..." to "item1, item2, item3..." with the actual 'type' as a prefix to the id (it seemed better than using an arbitrary string). So technically, with a bit of string manipulation, you can tell what 'type' the reference is to, and there's no need for multiple attributes: <reference refid="craft1"/> <reference refid="item1"/> <facility refid="facility1"/> Pros: Easy to read, easy to pick the id value out Cons: String manipulation is major processor hog. Thought? -The Captain |
|
From: mamutas <ma...@pr...> - 2004-04-11 19:53:33
|
First option is the easiest to read which is important, cause XML will be created by human. And XML allows making entry optional, so the user could put only necessary entries. The parser will follow what is in DTD, so it should not be a big deal for the parser to detect what entry is expected. -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: Wednesday, April 07, 2004 10:38 PM To: xen...@li... Subject: RE: [Xenocide-programming] XML facility-item data Hey all, One more question, and then I should have the config files posted as soon as I finish the design docs. I'm finishing up the cross-references between different items, research nodes, crafts, etc., and I've come up with three possible ways to record it. So that everybody understands what I'm talking about, a cross reference is where one entry points to another entry, e.g. the Pistol Ammo Clip item has a reference to the Pistol item that indicates which item it can reload. That's a simple one....two items, same document, same 'type'. In the research tree, there are references to six different entry types (other topics, crafts, items, personnel, facilities, and missions) The specific 'type' must be able to be determined by the parser so it knows which document to look in for the associated entry. The first way is to have a separate xml element for each reference type. So it would look like this: <craft craftid="craft1"/> <item itemid="item1"/> <facility facilityid="facility1"/> Pros: Each element immediately defines the 'type' of reference. Minimal processing (just a select case, really) is needed to determine where the associated document is. Cons: Not every entry uses all element types, so the xml is overly complicated. The parser would need to recognize and watch for all the different possible reference elements. Adding a new reference element might require extensive code work. The second idea is to combine them into one element with multiple attributes. Only one of the attributes would ever be used. <reference craftid="craft1"/> <reference itemid="item1"/> <facility facilityid="facility1"/> Pros: easy to read, easy for the parser to know what element is a reference. Cons: More process intensive. Each attribute would have to be tested for a valid value to find the id value. Third idea takes it a step farther. Since in xml, a unique identifier must start with an alphabetic character, I ened up changing all the id values from "1, 2, 3..." to "item1, item2, item3..." with the actual 'type' as a prefix to the id (it seemed better than using an arbitrary string). So technically, with a bit of string manipulation, you can tell what 'type' the reference is to, and there's no need for multiple attributes: <reference refid="craft1"/> <reference refid="item1"/> <facility refid="facility1"/> Pros: Easy to read, easy to pick the id value out Cons: String manipulation is major processor hog. Thought? -The Captain --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.650 / Virus Database: 416 - Release Date: 4/4/2004 |
|
From: Cpt. B. <cpt...@pr...> - 2004-04-16 21:07:26
|
Ta-da! At long last, here are the xml files and documentation for configuring most every object in the game. Let me know if I missed anything. All of the files except for *.items.* have internal DTD validation. The *.items.* files use config.items.dtd. I know raw xml is tough to read, so look at the documentation first. Just to warn you, I may have gotten a bit carried away...but everything is so interrelated, I kind of had to. I have a website that displays most of these in a much more readable format than raw xml. It's currently broken due to fun times with IIS and xml layout changes. As soon as it's working (maybe over the weekend if I have time), I'll post the link. Apparently SourceForge is not accepting zipped files, so you can get all them here: http://www.projectxenocide.com/public/CTD/CptBoxershorts/XML/XMLconfig.z ip -The Captain |
|
From: Cpt. B. <cpt...@pr...> - 2004-04-18 23:11:44
|
Well, since it looks like the ftp site got restored from a back up, the previous link is bad. I uploaded it again, as well as the unzipped files. I also added one more file I had missed...config.planets.xml. It's designed to hold info for geodata.h http://www.projectxenocide.com/public/CTD/CptBoxershorts/xml/Config/ The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: April 16, 2004 2:07 PM To: xen...@li... Subject: RE: [Xenocide-programming] XML facility-item data Ta-da! At long last, here are the xml files and documentation for configuring most every object in the game. Let me know if I missed anything. All of the files except for *.items.* have internal DTD validation. The *.items.* files use config.items.dtd. I know raw xml is tough to read, so look at the documentation first. Just to warn you, I may have gotten a bit carried away...but everything is so interrelated, I kind of had to. I have a website that displays most of these in a much more readable format than raw xml. It's currently broken due to fun times with IIS and xml layout changes. As soon as it's working (maybe over the weekend if I have time), I'll post the link. Apparently SourceForge is not accepting zipped files, so you can get all them here: http://www.projectxenocide.com/public/CTD/CptBoxershorts/XML/XMLconfig.z ip -The Captain ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Christopher C. P. <chr...@sb...> - 2004-04-19 02:43:02
|
Hey Everyone, Since I'm not able to contribute much to the XML interface of the game (due to my troubles with Xerces not working in Linux), I've been looking into areas I can contribute. I think one thing that is slowing down development, is that the workload doesn't seem to have been divided up into units. If we could divide things up into classes that still need to be developed, I think it would help a lot. The process of finding work is very vague. I think it would help a lot if we just maintained a list of classes and their development status. That we it would be easy to see what's inactive or not started. We don't need to do the entire design documentation for this, just a simple list. Your thoughts? Regards, chrisp |
|
From: mamutas <ma...@pr...> - 2004-04-24 02:12:29
|
Great stuff! And even documented!!! I just had a chance to download it. I hope to look through it over the weekend and provide some feedback. Thanks, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: Sunday, April 18, 2004 6:11 PM To: xen...@li... Subject: RE: [Xenocide-programming] XML facility-item data Well, since it looks like the ftp site got restored from a back up, the previous link is bad. I uploaded it again, as well as the unzipped files. I also added one more file I had missed...config.planets.xml. It's designed to hold info for geodata.h http://www.projectxenocide.com/public/CTD/CptBoxershorts/xml/Config/ The Captain --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004 |
Thanks for helping keep SourceForge clean.
X