Thread: Re: [Xenocide-programming] RE: Xenocide-programming digest, Vol 1 #75 - 2 msgs

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'm open to other suggestions on XML parsers.  If anyone knows of 
any others, go ahead and list them.  I think smaller would be better.
It should keep as small of a memory footprint as possible.  Execution
speed isn't really a factor (IMO).

chrisp

On Tue, 9 Dec 2003 13:52:47 -0500 "Jeremy" <dr...@cf...> writes:
> FYI, it looks like you've already decided on an XML parser, but I 
> have
> experience using TinyXML and it's very simple and quick.
> http://sourceforge.net/projects/tinyxml Just thought I'd throw that 
> out
> there
> 
> Jeremy
> 
> 
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf 
> Of
> xen...@li...
> Sent: Tuesday, December 09, 2003 4:28 AM
> To: xen...@li...
> Subject: Xenocide-programming digest, Vol 1 #75 - 2 msgs
> 
> Send Xenocide-programming mailing list submissions to
>         xen...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>        
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> or, via email, send a message with subject or body 'help' to
>         xen...@li...
> 
> You can reach the person managing the list at
>         xen...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xenocide-programming digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Tech Tree XML layout (Chris Phillips)
>    2. RE: Tech Tree XML layout (Cpt. Boxershorts)
> 
> --__--__--
> 
> Message: 1
> To: ma...@pr...
> Cc: xen...@li...
> Date: Mon, 8 Dec 2003 23:41:59 -0500
> Subject: Re: [Xenocide-programming] Tech Tree XML layout
> From: Chris Phillips <chr...@ju...>
> 
> > Welcome back. It was a while since there was a news from you.
> 
> THX.  Sorry I've been out of touch. :(
> 
> >As I see the Xnet DB and the research > tree XML
> > files have lots in common, so they should not be developed 
> > individually.
> 
> Makes sense to me.
> 
> > First of all, I think that we should split information about visual 
> 
> > entry presentation into separate file and to have a file with
> relationship 
> > info (like 'rifle' is 'weapon', 'tank' is 'hwp', kind of info) 
> which
> will 
> > refer to the visual info file. That visual info file will be used 
> by 
> > research tree XML in the same way.
> 
> I believe this is how I understood it would work.  I'm not 
> completely
> sure I follow what you are saying though...
> 
> > Second, I strongly recommend you not to spent your time on writing 
> 
> > an XML parser (unless you want to do it just for fun), but use 
> already 
> > existing one.  So far, we planning to use Xerces from Apache and 
> that
> is 
> > what you should plan on too.
> 
> DOH!!!  At least I haven't invested too much time in the parsing 
> yet.
> I was not aware of Xerces.  Yes.. let's use that and stay sane. :)
> I suppose I may attempt my own if I happen to have a great deal of
> free time.  That might happen... 
> 
> > Third, there is a String class in STL which is widely used with 
> the 
> > project, so you should use it as well instead of your 
> implementation.
> 
> I plan on doing this.  I just used my own String class since I was
> developing
> using gcc, and it's something I can use easily when creating 
> prototype
> code.  
> I'll just run a script on it to switch over when I get to the real 
> thing.
> 
> > Also, there was a significant work done on converting original 
> names 
> > to the ones we will use in the game, which should be utilized
> everywhere. 
> > The XML file of XNDL must use it as well. Breunor or Cpt. 
> Boxershorts
> will 
> > give you more info and directions on that.
> 
> It shouldn't impact XNDL development.  I'll focus on that for now. 
> :)
> 
> > Again, sorry if I was to criticizing. I really appreciate the work 
> 
> > you are  doing and efforts you are putting in the project.
> 
> Don't worry about it.  I'd rather have somebody point out that I am
> taking
> the wrong approach.  That way I don't waste my time on something 
> that 
> can't be used.  I'll look into ways to integrate Xerces.  
> 
> Regards,
> chrisp
> 
> > > -----Original Message-----
> > > From: xen...@li... 
> > > [mailto:xen...@li...] On 
> > > Behalf Of Chris Phillips
> > > Sent: Friday, December 05, 2003 1:49 AM
> > > To: xen...@li...
> > > Subject: Re: [Xenocide-programming] Tech Tree XML layout
> > > 
> > > 
> > > 
> > > Hi Everyone,
> > > 
> > > Sorry I have been absent for so long.  I have been extremely 
> > > busy recently.  I'm essentially 
> > > working three jobs right now, but I would still like to 
> > > continue contributing to this project.
> > > 
> > > I was originally to do the X-Net XML file and X-Net data 
> > > loader a couple of months ago.  
> > > I have an example of an XML file and the X-Net data loader is 
> > > further along.  I am going to post a more complete version of 
> > > the XNDL class this weekend.  I have not been able to do any 
> > > significant development on it until just a couple of days ago.
> > > 
> > > The XNDL is close to being able to completely tokenize an XML 
> > > file (although it may not appear to be..).  We need to decide 
> > > on a format  for an X-Net XML file, though.  If we 
> > > want a full-fledged XML parser, than the implementation will 
> > > be much more tricky.  Basically, 
> > > you're dealing with a compiler front-end with that.  
> > > Otherwise, we will have to use canned tags 
> > > or meet somewhere in between. We can base the XML file on my 
> > > example, or any other.  
> > > It doesn't matter much to me. But keep in mind, that the 
> > > simpler the XML syntax, the more 
> > > likely it is to be compatible with the XNDL.  Please keep the 
> > > syntax simple for the time being. :)  
> > > 
> > > I have attached the current state of the XNDL code.  It is very 
> 
> > raw. 
> > > Don't worry about 
> > > critiquing the code.  It's in way to poor of a state for 
> > > that. :)  I also included my example XML file.  I will post 
> > > more comments and updated code later. 
> > > 
> > > Regards,
> > > chrisp
> > > 
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.545 / Virus Database: 339 - Release Date: 
> 2003/11/27
> > >  
> > >   
> > > 
> > 
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27
> >  
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Xenocide-programming mailing list
> > Xen...@li...
> > https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> > 
> > 
> 
> ________________________________________________________________
> The best thing to hit the internet in years - Juno SpeedBand!
> Surf the web up to FIVE TIMES FASTER!
> Only $14.95/ month - visit www.juno.com to sign up today!
> 
> 
> --__--__--
> 
> Message: 2
> From: "Cpt. Boxershorts" <cpt...@te...>
> To: "mamutas" <ma...@pr...>,
>         <xen...@li...>
> Cc: <br...@pr...>
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
> Date: Mon, 8 Dec 2003 11:39:03 -0800
> 
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_0010_01C3BD7F.E18BAEF0
> Content-Type: text/plain;
>         charset="Windows-1252"
> Content-Transfer-Encoding: 7bit
> 
> MessageI think the separate attribute (at least for rank) is good 
> idea,
> because it would make it easier to mod in the future.  Adding a new 
> rank (or
> alien race, for that matter)  is that much better defined.  This 
> way, the
> topic "Grey Commander" (stored as (name="Grey" rank="commander") is 
> parsed
> as a grey (sectoid) first, and commander second.
> 
> I agree that we should minimize extraneous attributes (or elements, 
> for that
> matter).
> 
> 
> Which leads us, of course, into adding a new field for dealing with 
> multiple
> researches of the same topic.  I can see two ways of doing this : 
> default,
> or specific.
> 
> Default Method: Currently more or less what we have.  Unless flagged 
> in some
> way (attribute or element), research topics are one-shot deals.  By 
> default,
> parent (researched) nodes in the tree can only be researched once.
> 
> Specific Method: In the original techtree xml file, there was an
> <obsoletes/> element, that would contain topics and items that the 
> player
> could no longer access.  I took it out because the way it was being 
> used (to
> block earlier technologies) seemed to be a waste of time at best, 
> and
> counter productive at worst (AP ammo isn't obsolete just because you 
> have
> Lasers).  However, we could use this to specify a node obsoleting 
> itself.
> This is the more flexible route, as it opens up all sorts of 
> possibilities
> in future versions.
> 
> There might be some sort of condition possible in here as 
> well...once all
> possible child nodes are researched, then the node obsoletes 
> itself.
> Otherwise, you have the same annoying problem that x-com had, where 
> you end
> up with 20+ snakeman medics on your research list, even though you
> researched one 6 months ago.
> 
> However, there's another catch in here...when you research an 
> engineer, you
> aren't given a new topic or item....just new information. Just to 
> make
> things more complicated, the information (IIRC) depends on the ship 
> the
> engineer came from.  Would that sort of thing be handled entirely in 
> the
> code itself?  Or would the techtree need to list all possible crafts 
> as
> results from an engineer, and the research code just picks the 
> correct one
> off the list?
> 
> -The Captain
> 
> 
> 
> 
> 
>   -----Original Message-----
>   From: mamutas [mailto:ma...@pr...]
>   Sent: December 7, 2003 9:58 PM
>   To: 'Cpt. Boxershorts'; 
> xen...@li...
>   Cc: br...@pr...
>   Subject: RE: [Xenocide-programming] Tech Tree XML layout
> 
> 
>   You now make me think that some research topics did not have a 
> visual
> representation in the original game. More than that, it was possible 
> to
> research the same alien navigator and to get more and more of 
> different info
> from him. Everytime you research a navigator, you would get an info 
> about an
> alien craft. In that case, there multiple outcome from the research 
> and
> research item could be reused. It is very important to implement 
> suppor for
> such functionality in your XML format.
> 
>   Again, some research topics did not have a visual representation 
> in the
> original game at all. For example: laser weapons. There was nothing 
> shown at
> the end of research, except for 'You can research laser pistol and 
> rifle
> now'. The question, are we going to follow that scheme? Or we will 
> have a
> visual representation for each research topic? I do not know yet.
> 
>   So, now I am thinking, that since research tree is static and 
> completely
> defined at the beginning of the game, there is no need to introduce 
> more
> properties than it is necessary. For example, Nick suggested to 
> separate
> rank from race and I supported him. However, the approach he was 
> suggesting
> is good for dynamic game data, and not for static research tree. 
> Therefore,
> limit the number of attributes for necessary ones only.
> 
>   Regards,
>   mamutas.
>     -----Original Message-----
>     From: Cpt. Boxershorts [mailto:cpt...@te...]
>     Sent: Thursday, December 04, 2003 12:12 AM
>     To: mamutas; xen...@li...
>     Subject: RE: [Xenocide-programming] Tech Tree XML layout
> 
> 
>     It's 'name' so that it fits with everything else in the tech 
> tree.  This
> is just a research topic...it won't hold actual alien data (stats 
> and the
> like), just information related to the tech tree.  The actual entry 
> (made
> commander just for extra fields) would look like this:
> 
>     <!--Sectoid Commander-->
>     <topic name="Sectoid" rank="commander" researchtime="1000">
> 
>      <prerequisite>
>       <Item name="Sectoid" rank="commander" /> //reference to Item 
> list
>      </prerequisite>
> 
>      <researchbonus/>
> 
>      <grants>
>       <topic name="Psi Lab"/>
>      </grants>
>     </topic>
> 
> 
> 
>       -----Original Message-----
>       From: xen...@li...
> [mailto:xen...@li...]On Behalf 
> Of
> mamutas
>       Sent: December 3, 2003 8:32 PM
>       To: 'Cpt. Boxershorts'; 
> xen...@li...
>       Subject: RE: [Xenocide-programming] Tech Tree XML layout
> 
> 
>       Yeah, that is exactly what I was suggesting.
>       Unfortunately, I do not think it is possible to refernce IDs 
> between
> files, but things might have been changed recently...
> 
>       I suggest to go with second approach: different properties in
> different attributes. And change 'name' to 'race': Sectoid, 
> Floater,
> Human...
>         -----Original Message-----
>         From: Cpt. Boxershorts [mailto:cpt...@te...]
>         Sent: Monday, December 01, 2003 7:32 PM
>         To: mamutas; xen...@li...
>         Subject: RE: [Xenocide-programming] Tech Tree XML layout
> 
> 
> 
>         So, what you're saying is move the <filereferences> element 
> into a
> global item list?  That's no problem.
>         Do you know if it's possible to enforce id integrity across 
> files?
> I know you can do it in a single file.
> 
>         Does anyone know how captured aliens will be recorded?  Will 
> it be
> an actual "Alien" class with a Rank property, or just a one line 
> reference?
> 
>         Basically, I'm asking if it would be:
> 
>         <topic name="Sectiod Soldier"/>
> 
>         or
> 
>         <topic name = "Sectoid" rank="Soldier"/>
> 
>         The first is easier to do, but the second might be better 
> for
> future-proofing (for multiplayer, when you can capture enemy humans 
> as well)
> 
>         -The Captain
> 
> 
> 
> 
> 
>           -----Original Message-----
>           From: mamutas [mailto:ma...@pr...]
>           Sent: December 1, 2003 2:47 PM
>           To: 'Cpt. Boxershorts'; 
> xen...@li...
>           Subject: RE: [Xenocide-programming] Tech Tree XML layout
> 
> 
>           Yes, visual representation is the images, text, models -
> everything what is displayed to the user. I suggest to break down
> information into separate files: one containing relationship for 
> XNet DB
> view, another with relationships and data for research, and another 
> with
> list of all entities and their visual representation (models, text, 
> video,
> etc.). Then first two files could refer to the last one. How is 
> that?
>             -----Original Message-----
>             From: Cpt. Boxershorts 
> [mailto:cpt...@te...]
>             Sent: Monday, December 01, 2003 4:07 PM
>             To: mamutas; xen...@li...
>             Subject: RE: [Xenocide-programming] Tech Tree XML 
> layout
> 
> 
>             I'm not quite sure if I understand.  By "visual 
> representation",
> do you mean the part of the data that the player actually sees 
> (i.e.: the
> xnet info), or or you suggesting a further breakdown of the 
> underlying data
> (so there would be an XML file containing a simple list of all 
> researchable
> items, and separate file containing the relationships)?
> 
>             -The Captain
>               -----Original Message-----
>               From: 
> xen...@li...
> [mailto:xen...@li...]On Behalf 
> Of
> mamutas
>               Sent: November 30, 2003 8:32 PM
>               To: 'Andrew Franks';
> xen...@li...
>               Subject: RE: [Xenocide-programming] Tech Tree XML 
> layout
> 
> 
>               Looks pretty good to me.
> 
>               I take a look at the structure of XML file and did not 
> really
> checked the dependencies between researcheable items.
> 
>               I have one concern here: the definition integrates 
> both
> research tree hierarchy and visual representation for the entities. 
> In my
> opinion these two should be separated, perhaps in two XML files: 
> first to
> describe dependencies only, second to provide information for entry 
> visual
> presentation.
> 
>               In addition, I think that this project should be 
> performed in
> parallel with XNet DB model definition. ChrisP has started it, but 
> not
> finished yet. Here I think we need two XML as well: one to describe
> categories and entities and another to describe visual 
> representation of
> entity. The second could be the same as the one for research, see?
> 
>               Regards.
>                 -----Original Message-----
>                 From: 
> xen...@li...
> [mailto:xen...@li...] On Behalf 
> Of
> Andrew Franks
>                 Sent: Friday, November 28, 2003 5:05 PM
>                 To: mamutas; 
> xen...@li...
>                 Subject: RE: [Xenocide-programming] Tech Tree XML 
> layout
> 
> 
>                 Okay, here's a first draft.  I included every field I 
> could
> think of...let me know if I missed anything.
>                 Is X-Net going to have it's own xml layout, or will 
> it share
> with the tech tree?
> 
>                 Here's a short sample, see the attachment for more 
> detailed
> comments
> 
>                 //Plasma Pistol
>                 <topic name="Plasma Pistol" researchtime="100">
> 
>                  <prerequisite>
>                   <topic name="Plasma Weapons" />
>                   <item name="Plasma Pistol" />
>                  </prerequisite>
> 
>                  <researchbonus> // so if the player researched 
> rifle before
> pistol, pistol would only take 95% of researchtime
>                     //these are cumulative, so if both were 
> researched
> already, pistol would take 90% of researchtime
>                   <topic name="Plasma Rifle" bonus="5" />
>                   <topic name="Heavy Plasma" bonus="5" />
>                  </researchbonus>
> 
>                  <filepaths>
> 
> <unresearched>/xnet/texts/unresearched/plasmapistol.rtf</unresearched>
>                   
> <xnet_image>/xnet/images/plasmapistol.3ds</xnet_image>
> 
> <xnet_text>/xnet/texts/weapons/plasmapistol.rtf</xnet_text>
>                  </filepaths>
> 
>                  <grants>
>                   <item name="Plasma Pistol"/>
>                  </grants>
>                 </topic>
> 
> 
> 
>                  - Cpt. Boxershorts
> 
> 
>                 ---
>                 Incoming mail is certified Virus Free.
>                 Checked by AVG anti-virus system 
> (http://www.grisoft.com).
>                 Version: 6.0.538 / Virus Database: 333 - Release 
> Date:
> 2003/11/10
> 
> 
> 
> 
> 
>               ---
>               Outgoing mail is certified Virus Free.
>               Checked by AVG anti-virus system 
> (http://www.grisoft.com).
>               Version: 6.0.538 / Virus Database: 333 - Release 
> Date:
> 2003/11/10
> 
> 
> 
> 
>             ---
>             Incoming mail is certified Virus Free.
>             Checked by AVG anti-virus system 
> (http://www.grisoft.com).
>             Version: 6.0.545 / Virus Database: 339 - Release Date:
> 2003/11/27
> 
> 
> 
> 
>           ---
>           Outgoing mail is certified Virus Free.
>           Checked by AVG anti-virus system 
> (http://www.grisoft.com).
>           Version: 6.0.545 / Virus Database: 339 - Release Date: 
> 2003/11/27
> 
> 
> 
> 
>         ---
>         Incoming mail is certified Virus Free.
>         Checked by AVG anti-virus system (http://www.grisoft.com).
>         Version: 6.0.545 / Virus Database: 339 - Release Date: 
> 2003/11/27
> 
> 
> 
> 
>       ---
>       Outgoing mail is certified Virus Free.
>       Checked by AVG anti-virus system (http://www.grisoft.com).
>       Version: 6.0.545 / Virus Database: 339 - Release Date: 
> 2003/11/27
> 
> 
> 
> 
>     ---
>     Incoming mail is certified Virus Free.
>     Checked by AVG anti-virus system (http://www.grisoft.com).
>     Version: 6.0.545 / Virus Database: 339 - Release Date: 
> 2003/11/27
> 
> 
> 
> 
>   ---
>   Outgoing mail is certified Virus Free.
>   Checked by AVG anti-virus system (http://www.grisoft.com).
>   Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27
> 
> 
> ------=_NextPart_000_0010_01C3BD7F.E18BAEF0
> Content-Type: text/html;
>         charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD><TITLE>Message</TITLE>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3DWindows-1252">
> <META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003>I=20
> think the separate attribute (at least for rank) is good idea, 
> because =
> it would=20
> make it easier to mod in the future.&nbsp; Adding a new rank (or 
> alien =
> race, for=20
> that matter)&nbsp; is that much better defined.&nbsp; This way, the 
> =
> topic "Grey=20
> Commander" (stored as&nbsp;(<FONT face=3DTahoma>name=3D"<SPAN=20
> class=3D648020306-04122003>Grey</SPAN>"&nbsp;</FONT><SPAN=20
> class=3D648020306-04122003><FONT 
> face=3DTahoma>rank=3D"</FONT><FONT=20
> face=3DArial>commander</FONT><FONT face=3DTahoma>") is parsed as a 
> grey =
> (sectoid)=20
> first, and commander second.</FONT></SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>I agree that we should minimize 
> extraneous =
> attributes=20
> (or elements, for that matter).</SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>Which leads us, of course,&nbsp;into 
> adding a =
> new field=20
> for dealing with multiple researches of the same topic.&nbsp; I can 
> see =
> two ways=20
> of doing this : default, or specific.</SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>Default Method: Currently more or less 
> what =
> we=20
> have.&nbsp; Unless flagged in some way (attribute or element), 
> research =
> topics=20
> are one-shot deals.&nbsp; By default, parent (researched) 
> nodes&nbsp;in =
> the tree=20
> can only be researched once.</SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>Specific Method: In the original techtree 
> xml =
> file,=20
> there was an &lt;obsoletes/&gt; element, that would contain topics 
> and =
> items=20
> that the player could no longer access.&nbsp; I took it out because 
> the =
> way it=20
> was being used (to block earlier technologies) seemed to be a waste 
> of =
> time at=20
> best, and counter productive at worst (AP ammo isn't obsolete just 
> =
> because you=20
> have Lasers).&nbsp; However, we could use this to specify a node =
> obsoleting=20
> <EM>itself</EM>.&nbsp; This is the more flexible route, as it opens 
> up =
> all sorts=20
> of possibilities in future versions.</SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>There might be some sort of condition =
> possible in here=20
> as well...once all possible child nodes are researched, =
> <EM>then&nbsp;</EM>the=20
> node obsoletes itself. Otherwise, you have the same annoying problem 
> =
> that x-com=20
> had, where you end up with 20+ snakeman&nbsp;medics on your research 
> =
> list, even=20
> though you researched one 6 months=20
> ago.</SPAN></SPAN></FONT></DIV></SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>However, there's another catch in 
> here...when =
> you=20
> research an engineer, you aren't given a new topic or item....just 
> new=20
> information.&nbsp;Just to make things more complicated, the 
> information =
> (IIRC)=20
> depends on the ship the engineer came from.&nbsp; Would that sort of 
> =
> thing be=20
> handled entirely in the code itself?&nbsp; Or would the techtree 
> need to =
> list=20
> all possible crafts as results from an engineer, and the research 
> code =
> just=20
> picks&nbsp;the correct one&nbsp;off&nbsp;the =
> list?</SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003>-The Captain</SPAN></SPAN></FONT></DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN =
> class=3D224390419-08122003><SPAN=20
> class=3D648020306-04122003></SPAN></SPAN></FONT>&nbsp;</DIV>
> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>   <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
> face=3DTahoma=20
>   size=3D2>-----Original Message-----<BR><B>From:</B> mamutas=20
>   [mailto:ma...@pr...]<BR><B>Sent:</B> December 7, 
> 2003 =
> 9:58=20
>   PM<BR><B>To:</B> 'Cpt. Boxershorts';=20
>   xen...@li...<BR><B>Cc:</B>=20
>   br...@pr...<BR><B>Subject:</B> RE: =
> [Xenocide-programming] Tech=20
>   Tree XML layout<BR><BR></FONT></DIV>
>   <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial =
> color=3D#0000ff size=3D2>You=20
>   now make me think that some research topics did not have a 
> visual=20
>   representation in the original game. More than that, it was 
> possible =
> to=20
>   research the same alien navigator and to get more and more of =
> different info=20
>   from him. Everytime you research a navigator, you would get an 
> info =
> about an=20
>   alien craft. In that case, there multiple outcome from the 
> research =
> and=20
>   research item could be reused. It is very important to implement 
> =
> suppor for=20
>   such functionality in your XML format.</FONT></SPAN></DIV>
>   <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial =
> color=3D#0000ff=20
>   size=3D2></FONT></SPAN>&nbsp;</DIV>
>   <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial =
> color=3D#0000ff=20
>   size=3D2>Again, some research topics did not have a visual =
> representation in the=20
>   original game at all. For example: laser weapons. There was 
> nothing =
> shown at=20
>   the end of research, except for 'You can research laser pistol and 
> =
> rifle now'.=20
>   The question, are we going to follow that scheme? Or we will have 
> a =
> visual=20
>   representation for each research topic? I do not know =
> yet.</FONT></SPAN></DIV>
>   <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial =
> color=3D#0000ff=20
>   size=3D2></FONT></SPAN>&nbsp;</DIV>
>   <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial =
> color=3D#0000ff size=3D2>So,=20
>   now I am thinking, that since research tree is static and 
> completely =
> defined=20
>   at the beginning of the game, there is no need to introduce more 
> =
> properties=20
>   than it is...

[truncated message content]