Menu
▾
▴
xenocide-programming — The Programming Xenocide Mailing List
You can subscribe to this list here.
| 2003 |
Jan
(9) |
Feb
(6) |
Mar
|
Apr
(2) |
May
|
Jun
(4) |
Jul
(19) |
Aug
(18) |
Sep
(11) |
Oct
(14) |
Nov
(16) |
Dec
(50) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(42) |
Feb
(39) |
Mar
(66) |
Apr
(26) |
May
(32) |
Jun
(21) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: mamutas <ma...@pr...> - 2003-12-19 03:26:52
|
I am not quite sure I can imagine situation where we would want to display a technology as researchable when _any_ research on such technology will not produce any results. Could you give an example of situation you refer to? mamutas >-----Original Message----- >From: Cpt. Boxershorts [mailto:cpt...@te...] >Sent: Thursday, December 18, 2003 5:01 PM >To: mamutas; 'Andrew Pokrovski'; >xen...@li... >Cc: br...@pr... >Subject: RE: [Xenocide-programming] Tech Tree XML layout > > >I guess the 'obsoletes' functionality could be handled in >code...I just thought it would be more flexible to have it in >the data. If the business logic (for when/if a research node >becomes unavailable) is hardcoded, it limits future >development. The <or> tags (or the equivalent) will still be >needed, to flag the node so the code knows how to treat it. > >-The Captain > > > > >-----Original Message----- >From: xen...@li... >[mailto:xen...@li...]On >Behalf Of mamutas >Sent: December 10, 2003 8:55 PM >To: 'Cpt. Boxershorts'; 'Andrew Pokrovski'; >xen...@li... >Cc: br...@pr... >Subject: RE: [Xenocide-programming] Tech Tree XML layout > > >Great discussion is going on here! > >I really have very little to add after Andrew's response. I >was actually thinking very similarly. I agree that XML should >describe relationships only, but code must check whether one >type of craft is shown versus another. I also think that in >case of engineers and medics, there should be some indications >that no more info can be extracted instead of 'nothing' as it >was in the original game. After such message was received by >player, it is entirely up to him what to do with all those >engineers and medics. > >As for obsolete field, I do not really think it is necessary >at all. Each unresearhed technology potentially could be >researched. Why would we hide its name from list? In the case >of medics/engineers as well as other alien races/professions, >they should disappear from research list as long as the >research of them will not yeild any new results. If sectoid >engineer is not going to tell anything else, why should it be >on research list? Our scientists are smart enough about what >to present in the reports to their management (the player). > >Regards, >mamutas > >>-----Original Message----- >>From: xen...@li... >>[mailto:xen...@li...] On >Behalf Of >>Cpt. Boxershorts >>Sent: Tuesday, December 09, 2003 4:08 PM >>To: Andrew Pokrovski; xen...@li... >>Cc: br...@pr... >>Subject: RE: [Xenocide-programming] Tech Tree XML layout >> >> >>Hey Andrew, >> >> I'm pretty sure that the actual responses from >>interrogating medics and engineers aren't random. Medics will only >>give either that race, or the associated race (so a snakeman >will give >>you Snakeman or Chrysillid, a sectoid will give you sectoid or >>cyberdisc, etc). Engineers can only give you data on the ship they >>were in (so no matter how many large scouts you capture, you >won't get >>Battleship info). >> >>That being said, I think your layout is good place to start. >>I was thinking of something similar, only instead of a 'random' >>attribute (since it's not really random), have them contained >within an >><xor> element (similar to the way <prerequisite> elements can >be within >>an <or> element). You're right though, the internal code will have to >>handle the details about which one specifically to choose. >> >>My main idea about having a node obsolete itself after all of it's >><grants><xor> fields have been finished is just to make it more user >>friendly. The player can still remove live aliens from >>containment...but either way, they won't be cluttering up the >research >>window. >> >>-The Captain >> >> >> >> >>-----Original Message----- >>From: xen...@li... >>[mailto:xen...@li...]On >>Behalf Of Andrew Pokrovski >>Sent: December 9, 2003 9:38 AM >>To: xen...@li... >>Cc: br...@pr... >>Subject: RE: [Xenocide-programming] Tech Tree XML layout >> >> >> >> >> >>>From: "Cpt. Boxershorts" <cpt...@te...> >>>To: "mamutas" >>><ma...@pr...>,<xen...@li... >>ceforge.n >>>et> >>>CC: <br...@pr...> >>>Subject: RE: [Xenocide-programming] Tech Tree XML layout >>>Date: Mon, 8 Dec 2003 11:39:03 -0800 >>> >>>I 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. >> >>True, though you could gain a lot of "live alien" info by >interrogating >>medics rather than having to go out and capture the aliens yourself. >>Still, I know what you mean, if you have about 20 aliens taking up >>containment space even though you've already interrogated >them as much >>as you can. I don't think this should be dealt with by the research >>section, you should always be able to interrogate an alien >prisoner. If >>you feel you don't want to, however, there should be an option to >>"throw them out" (execution, sell them to corporate labs, >>etc). That's not really relevant here though. >> >>Also, I agree with you that the 'obsoletes' field is pretty useless >>here. The only use for it I see is to mark a node as "done >with" so it >>no longer shows up on the research tree - by this token, the only >>research topics that are never "done with" are live aliens. >> >>> >>>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? >> >>I believe medics and engineers both give you a random entry each time >>you research one, until there are no more entries in that section, at >>which point they give you nothing. A possible idea is to decouple the >>research entries a research item enables from the XNet entries it >>shows. This way, a research topic can enable stuff in the tech tree, >>but will also show some XNet entries that aren't necessarily >tech tree >>items. For dealing with randomly selected benefits (like UFOs and >>corpses) one could add a tag to indicate whether or not the >>UFO or whatever has been enabled already. For >>example: >> >><!--Sectoid Engineer--> >><topic name="Sectoid" rank="engineer" researchtime="1000"> >> >><prerequisite> >> <Item name="Sectoid" rank="engineer" /> //reference to Item list >></prerequisite> >> >><researchbonus/> >> >><grants> >> <XNetEntry name = "Sectoid Interrogation"/> >> <XNetEntry name = "UFOSpec1" random=true/> >> <XNetEntry name = "UFOSpec2" random=true/> >> <Item name = "Sectoid Corpse"/> >></grants> >></topic> >> >>So, the engineer (a researching dead-end, as I recall), would show a >>'sectoid interrogation' entry no matter what, and will also randomly >>display one of the UFOSpecs (they've got that random tag). Also, >>researching an engineer could possibly yield a corpse or >other items (a >>sectoid arm or something). Consistency of random UFO picks should >>probably be handled in the code, otherwise, we'd have to keep >track of >>which UFOs have been picked for ALL engineer entries (one per sentient >>race). By consistency, I mean that if a UFO has been displayed >>already, another one should be picked. >> >>Andrew/"Nick Aragua" >> >>_________________________________________________________________ >>Get holiday tips for festive fun. >>http://special.msn.com/network/happyholidays.ar>mx >> >> >> >> >>------------------------------------------------------- >> >>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 >> >> >> >> >>------------------------------------------------------- >>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 >> >> >>--- >>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 > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.552 / Virus Database: 344 - Release Date: 2003/12/15 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.552 / Virus Database: 344 - Release Date: 2003/12/15 |
|
From: Cpt. B. <cpt...@te...> - 2003-12-18 22:57:20
|
I guess the 'obsoletes' functionality could be handled in code...I just thought it would be more flexible to have it in the data. If the business logic (for when/if a research node becomes unavailable) is hardcoded, it limits future development. The <or> tags (or the equivalent) will still be needed, to flag the node so the code knows how to treat it. -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...]On Behalf Of mamutas Sent: December 10, 2003 8:55 PM To: 'Cpt. Boxershorts'; 'Andrew Pokrovski'; xen...@li... Cc: br...@pr... Subject: RE: [Xenocide-programming] Tech Tree XML layout Great discussion is going on here! I really have very little to add after Andrew's response. I was actually thinking very similarly. I agree that XML should describe relationships only, but code must check whether one type of craft is shown versus another. I also think that in case of engineers and medics, there should be some indications that no more info can be extracted instead of 'nothing' as it was in the original game. After such message was received by player, it is entirely up to him what to do with all those engineers and medics. As for obsolete field, I do not really think it is necessary at all. Each unresearhed technology potentially could be researched. Why would we hide its name from list? In the case of medics/engineers as well as other alien races/professions, they should disappear from research list as long as the research of them will not yeild any new results. If sectoid engineer is not going to tell anything else, why should it be on research list? Our scientists are smart enough about what to present in the reports to their management (the player). Regards, mamutas >-----Original Message----- >From: xen...@li... >[mailto:xen...@li...] On >Behalf Of Cpt. Boxershorts >Sent: Tuesday, December 09, 2003 4:08 PM >To: Andrew Pokrovski; xen...@li... >Cc: br...@pr... >Subject: RE: [Xenocide-programming] Tech Tree XML layout > > >Hey Andrew, > > I'm pretty sure that the actual responses from >interrogating medics and engineers aren't random. Medics will >only give either that race, or the associated race (so a >snakeman will give you Snakeman or Chrysillid, a sectoid will >give you sectoid or cyberdisc, etc). Engineers can only give >you data on the ship they were in (so no matter how many large >scouts you capture, you won't get Battleship info). > >That being said, I think your layout is good place to start. >I was thinking of something similar, only instead of a >'random' attribute (since it's not really random), have them >contained within an <xor> element (similar to the way ><prerequisite> elements can be within an <or> element). >You're right though, the internal code will have to handle the >details about which one specifically to choose. > >My main idea about having a node obsolete itself after all of >it's <grants><xor> fields have been finished is just to make >it more user friendly. The player can still remove live >aliens from containment...but either way, they won't be >cluttering up the research window. > >-The Captain > > > > >-----Original Message----- >From: xen...@li... >[mailto:xen...@li...]On >Behalf Of Andrew Pokrovski >Sent: December 9, 2003 9:38 AM >To: xen...@li... >Cc: br...@pr... >Subject: RE: [Xenocide-programming] Tech Tree XML layout > > > > > >>From: "Cpt. Boxershorts" <cpt...@te...> >>To: "mamutas" >><ma...@pr...>,<xen...@li... >ceforge.n >>et> >>CC: <br...@pr...> >>Subject: RE: [Xenocide-programming] Tech Tree XML layout >>Date: Mon, 8 Dec 2003 11:39:03 -0800 >> >>I 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. > >True, though you could gain a lot of "live alien" info by >interrogating medics rather than having to go out and capture >the aliens yourself. Still, I know what you mean, if you have >about 20 aliens taking up containment space even though you've >already interrogated them as much as you can. I don't think >this should be dealt with by the research section, you should >always be able to interrogate an alien prisoner. If you feel >you don't want to, however, there should be an option to >"throw them out" (execution, sell them to corporate labs, >etc). That's not really relevant here though. > >Also, I agree with you that the 'obsoletes' field is pretty >useless here. The only use for it I see is to mark a node as >"done with" so it no longer shows up on the research tree - by >this token, the only research topics that are never "done >with" are live aliens. > >> >>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? > >I believe medics and engineers both give you a random entry >each time you research one, until there are no more entries in >that section, at which point they give you nothing. A possible >idea is to decouple the research entries a research item >enables from the XNet entries it shows. This way, a research >topic can enable stuff in the tech tree, but will also show >some XNet entries that aren't necessarily tech tree items. For >dealing with randomly selected benefits (like UFOs and >corpses) one could add a tag to indicate whether or not the >UFO or whatever has been enabled already. For >example: > ><!--Sectoid Engineer--> ><topic name="Sectoid" rank="engineer" researchtime="1000"> > ><prerequisite> > <Item name="Sectoid" rank="engineer" /> //reference to Item >list </prerequisite> > ><researchbonus/> > ><grants> > <XNetEntry name = "Sectoid Interrogation"/> > <XNetEntry name = "UFOSpec1" random=true/> > <XNetEntry name = "UFOSpec2" random=true/> > <Item name = "Sectoid Corpse"/> ></grants> ></topic> > >So, the engineer (a researching dead-end, as I recall), would >show a 'sectoid interrogation' entry no matter what, and will >also randomly display one of the UFOSpecs (they've got that >random tag). Also, researching an engineer could possibly >yield a corpse or other items (a sectoid arm or something). >Consistency of random UFO picks should probably be handled in >the code, otherwise, we'd have to keep track of which UFOs >have been picked for ALL engineer entries (one per sentient >race). By consistency, I mean that if a UFO has been displayed >already, another one should be picked. > >Andrew/"Nick Aragua" > >_________________________________________________________________ >Get holiday tips for festive fun. >http://special.msn.com/network/happyholidays.ar>mx > > > > >------------------------------------------------------- > >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 > > > > >------------------------------------------------------- >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 > > >--- >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 |
|
From: mamutas <ma...@pr...> - 2003-12-11 04:55:22
|
Great discussion is going on here! I really have very little to add after Andrew's response. I was actually thinking very similarly. I agree that XML should describe relationships only, but code must check whether one type of craft is shown versus = another. I also think that in case of engineers and medics, there should be some indications that no more info can be extracted instead of 'nothing' as = it was in the original game. After such message was received by player, it = is entirely up to him what to do with all those engineers and medics. As for obsolete field, I do not really think it is necessary at all. = Each unresearhed technology potentially could be researched. Why would we = hide its name from list? In the case of medics/engineers as well as other = alien races/professions, they should disappear from research list as long as = the research of them will not yeild any new results. If sectoid engineer is = not going to tell anything else, why should it be on research list? Our scientists are smart enough about what to present in the reports to = their management (the player). Regards, mamutas >-----Original Message----- >From: xen...@li...=20 >[mailto:xen...@li...] On=20 >Behalf Of Cpt. Boxershorts >Sent: Tuesday, December 09, 2003 4:08 PM >To: Andrew Pokrovski; xen...@li... >Cc: br...@pr... >Subject: RE: [Xenocide-programming] Tech Tree XML layout > > >Hey Andrew, > > I'm pretty sure that the actual responses from=20 >interrogating medics and engineers aren't random. Medics will=20 >only give either that race, or the associated race (so a=20 >snakeman will give you Snakeman or Chrysillid, a sectoid will=20 >give you sectoid or cyberdisc, etc). Engineers can only give=20 >you data on the ship they were in (so no matter how many large=20 >scouts you capture, you won't get Battleship info). > >That being said, I think your layout is good place to start. =20 >I was thinking of something similar, only instead of a=20 >'random' attribute (since it's not really random), have them=20 >contained within an <xor> element (similar to the way=20 ><prerequisite> elements can be within an <or> element). =20 >You're right though, the internal code will have to handle the=20 >details about which one specifically to choose. > >My main idea about having a node obsolete itself after all of=20 >it's <grants><xor> fields have been finished is just to make=20 >it more user friendly. The player can still remove live=20 >aliens from containment...but either way, they won't be=20 >cluttering up the research window. > >-The Captain > > > > >-----Original Message----- >From: xen...@li... >[mailto:xen...@li...]On=20 >Behalf Of Andrew Pokrovski >Sent: December 9, 2003 9:38 AM >To: xen...@li... >Cc: br...@pr... >Subject: RE: [Xenocide-programming] Tech Tree XML layout > > > > > >>From: "Cpt. Boxershorts" <cpt...@te...> >>To: "mamutas"=20 >><ma...@pr...>,<xen...@li... >ceforge.n >>et> >>CC: <br...@pr...> >>Subject: RE: [Xenocide-programming] Tech Tree XML layout >>Date: Mon, 8 Dec 2003 11:39:03 -0800 >> >>I think the separate attribute (at least for rank) is good idea,=20 >>because it would make it easier to mod in the future. Adding a new=20 >>rank (or alien race, for that matter) is that much better defined. =20 >>This way, the topic "Grey Commander" (stored as (name=3D"Grey"=20 >>rank=3D"commander") is parsed as a grey (sectoid) first, and commander = >>second. >> >>I agree that we should minimize extraneous attributes (or=20 >elements, for=20 >>that matter). >> >> >>Which leads us, of course, into adding a new field for dealing with=20 >>multiple researches of the same topic. I can see two ways of doing=20 >>this : default, or specific. >> >>Default Method: Currently more or less what we have. Unless=20 >flagged in=20 >>some way (attribute or element), research topics are one-shot deals. =20 >>By default, >>parent (researched) nodes in the tree can only be researched once. >> >>Specific Method: In the original techtree xml file, there was an=20 >><obsoletes/> element, that would contain topics and items that the=20 >>player could no longer access. I took it out because the way it was=20 >>being used (to block earlier technologies) seemed to be a=20 >waste of time=20 >>at best, and counter productive at worst (AP ammo isn't obsolete just=20 >>because you have Lasers). However, we could use this to=20 >specify a node=20 >>obsoleting itself. This is the more flexible route, as it=20 >opens up all=20 >>sorts of possibilities in future versions. >> >>There might be some sort of condition possible in here as well...once=20 >>all possible child nodes are researched, then the node obsoletes=20 >>itself. Otherwise, you have the same annoying problem that x-com had,=20 >>where you end up with 20+ snakeman medics on your research list, even=20 >>though you researched one 6 months ago. > >True, though you could gain a lot of "live alien" info by=20 >interrogating medics rather than having to go out and capture=20 >the aliens yourself. Still, I know what you mean, if you have=20 >about 20 aliens taking up containment space even though you've=20 >already interrogated them as much as you can. I don't think=20 >this should be dealt with by the research section, you should=20 >always be able to interrogate an alien prisoner. If you feel=20 >you don't want to, however, there should be an option to=20 >"throw them out" (execution, sell them to corporate labs,=20 >etc). That's not really relevant here though. > >Also, I agree with you that the 'obsoletes' field is pretty=20 >useless here. The only use for it I see is to mark a node as=20 >"done with" so it no longer shows up on the research tree - by=20 >this token, the only research topics that are never "done=20 >with" are live aliens. > >> >>However, there's another catch in here...when you research an=20 >engineer,=20 >>you aren't given a new topic or item....just new information. Just to=20 >>make things more complicated, the information (IIRC) depends on the=20 >>ship the engineer came from. Would that sort of thing be handled=20 >>entirely in the code itself? Or would the techtree need to list all=20 >>possible crafts as results from an engineer, and the research=20 >code just=20 >>picks the correct one off the list? > >I believe medics and engineers both give you a random entry=20 >each time you research one, until there are no more entries in=20 >that section, at which point they give you nothing. A possible=20 >idea is to decouple the research entries a research item=20 >enables from the XNet entries it shows. This way, a research=20 >topic can enable stuff in the tech tree, but will also show=20 >some XNet entries that aren't necessarily tech tree items. For=20 >dealing with randomly selected benefits (like UFOs and=20 >corpses) one could add a tag to indicate whether or not the=20 >UFO or whatever has been enabled already. For >example: > ><!--Sectoid Engineer--> ><topic name=3D"Sectoid" rank=3D"engineer" researchtime=3D"1000"> > ><prerequisite> > <Item name=3D"Sectoid" rank=3D"engineer" /> //reference to Item=20 >list </prerequisite> > ><researchbonus/> > ><grants> > <XNetEntry name =3D "Sectoid Interrogation"/> > <XNetEntry name =3D "UFOSpec1" random=3Dtrue/> > <XNetEntry name =3D "UFOSpec2" random=3Dtrue/> > <Item name =3D "Sectoid Corpse"/> ></grants> ></topic> > >So, the engineer (a researching dead-end, as I recall), would=20 >show a 'sectoid interrogation' entry no matter what, and will=20 >also randomly display one of the UFOSpecs (they've got that=20 >random tag). Also, researching an engineer could possibly=20 >yield a corpse or other items (a sectoid arm or something).=20 >Consistency of random UFO picks should probably be handled in=20 >the code, otherwise, we'd have to keep track of which UFOs=20 >have been picked for ALL engineer entries (one per sentient=20 >race). By consistency, I mean that if a UFO has been displayed=20 >already, another one should be picked. > >Andrew/"Nick Aragua" > >_________________________________________________________________ >Get holiday tips for festive fun.=20 >http://special.msn.com/network/happyholidays.ar>mx > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program.=20 >Does SourceForge.net help you be more productive? Does it=20 >help you create better code? SHARE THE LOVE, and help us help=20 >YOU! Click Here: http://sourceforge.net/donate/=20 >_______________________________________________ >Xenocide-programming mailing list=20 >Xen...@li... >https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program.=20 >Does SourceForge.net help you be more productive? Does it=20 >help you create better code? SHARE THE LOVE, and help us help=20 >YOU! Click Here: http://sourceforge.net/donate/=20 >_______________________________________________ >Xenocide-programming mailing list=20 >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.545 / Virus Database: 339 - Release Date: 2003/11/27 >=20 > --- 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 =20 |
|
From: mamutas <ma...@pr...> - 2003-12-11 04:39:22
|
Hi all,
Here are comments for header files. Search for <mamutas> and you will find
them. :)
In general, I want to say, that I am glad to see that level of quality in
the work. Keep it up Wolfman!
Regards,
mamutas
>-----Original Message-----
>From: xen...@li...
>[mailto:xen...@li...] On
>Behalf Of Ralph Tittensor
>Sent: Thursday, December 04, 2003 5:40 AM
>To: xen...@li...
>Subject: [Xenocide-programming] StaticGeoData
>
>
>Hello all!
>
>If you dont know me then I will first introduce myself as this
>is my first mail to the mailing list!
>
>My name is Wolfman, 22 yrs old, from the United Kingdom.
>
>Disclaimers in first (hehe), this is the first time I have
>worked on a project such as this, and also the first time I
>have had my programming peer reviewed! I expect I have got a
>lot wrong, dont go easy on me, let me know what I did wrong
>and how I can do it better in the future!
>
>By the way, I had a look at the doc containing the coding
>style pointers, but it didnt have anything regarding naming
>enumerations or structs. What is the correct way to do this?
>
>Ok back on topic. Attached is a zip file containing 4 headers.
>These headers are all part of what I have called
>"StaticGeoData". If you think of a better name let me know!
>
>The aim of the "StaticGeoData" class is to give the simulation
>engine any *static* data about the geosphere. By static I mean
>static in the sense of unchanging, not in the C++ sense of static. :)
>
>Thus with the headers as I have given, the SE has to simply
>(Psuedoish code):
>
>// When initialising
>StaticGeoData *sgd = new StaticGeoData();
>if(sgd->loadData("./data/earth.blah") != 0)
> anERROR();
>
>// When using
>StaticGeoDataStruct *data = sgd->getData(x, y);
>
>if(data->terrainType == OCEAN)
> ....
>else
> ....
>// end
>
>Simple eh? The tricky bit is the StaticGeoData class itself.
>When loading the data it has to convert it all from whatever
>format and coordinate system into the coordinate system and
>format that the SE can handle.
>
>Here is what I propose to do for each type of data that the SE
>will need:
>
>1) Terrain
>I suggest that the terrain (like RK said) should be loaded up
>in the form of a Quad Tree, based upon a texture map. This has
>several advantages. Once loaded it is quick and easy to find
>the terrain for a given x,y. It is also possible to tailer the
>amount of memory used by the quad tree by adjusting how it
>tests to see if a region is homogeneous. For example, if you
>want it to use lots of memory, simply only say a region is
>homogeneous if all pixels in the region are the same type.
>However, if you want to use less memory say that only 2/3 of
>the pixels have to be the same type.
>
>2) Countries & Cities.
>I thought quite a lot on this, and the system I came up with
>was this. There is an XML file that describes a list of
>countries. This is simply the name of the country, a unique
>colour (You will see in a moment), a list of cities within
>that country, and any other information that will be needed
>for further versions. The cities have an X,Y coord (or
>whatever other coord type we will use for the cities - ie
>spherical?). Perhaps whoever is doing the code for drawing the
>geoscape should decide if countries & cities are going to be
>drawn, if so they might want to adjust the XML format
>accordingly?? When loading the countries, the XML file is
>parsed, and a list of GeoCountrys and GeoCitys are
>constructed. Then what I propose happens is that another quad
>tree is constructed, this time from a seperate special texture
>that has each country individualy coloured. As the quad tree
>is constructed it looks up in the list of countries to see
>which country corresponds to which colour.
>The reason I think a quad tree would be good for this as well
>as the terrain is that it has all the advantages of the quad
>trees, plus the fact that no vector data, or any other format
>is needed. Of course there are other solutions, if you have
>one feel free to suggest and we can discuss!
>
>There we go, a bit longer than I meant, but if you still have
>any questions feel free to drop me a line!
>
>-wolfman
>
>P.S Sorry RedKnight, it was a bit longer than a day to do this
>because I have just got broadband after being on a 56k for so
>long I went on a bit of a download and online gaming frenzy. :)
>
>
>--
>___________________________________________________________
>Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
>
>
>---
>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
|
|
From: <red...@pr...> - 2003-12-10 15:42:10
|
Hi All, sorry to be late but there had been a lot happening in here. Just a couple of things. XML Parser is not defined YET, as that is not my expertise area I hope someone can send me some pointers to start evaluating (I will be able only to evaluate based on Code Readability, and Learning Curve, nothing else). However always remember that our design principle is Performance dont Matters if Code Readability suffers too much... (You can always optimize -meke code ugly- later if you really need to)... About what to look for XML, if anyone can find a good, active, stable, small and simple XML Parser just let me know (bahh if you find that, we have found our XML Parser :D ), so just send the pointers... I have heard about TinyXML (last message) and Xerces (from Apache), I will take a look at them when I get a some spare Internet Time... After XMas for sure (will be online 24/7). Greetings Red Knight Quoting Chris Phillips <chr...@ju...>: > > 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 > > > > > > |
|
From: mamutas <ma...@pr...> - 2003-12-10 05:10:11
|
It is not like we already decided on the parser. But rather we do not have resources to do that extensive comparision. However, I know the reputation of Xerces and has been using its Java version for a few years. It is also parser of choice within my company. I would like to see the results of comparision between those two parsers or any others, if anyone will take that assignment. I do not think that memory size matters. As well as performance. Rather the stability of the code and ease to use are more important in my opinion. Regards. >-----Original Message----- >From: xen...@li... >[mailto:xen...@li...] On >Behalf Of Chris Phillips >Sent: Tuesday, December 09, 2003 5:24 PM >To: dr...@cf... >Cc: xen...@li... >Subject: Re: [Xenocide-programming] RE: Xenocide-programming >digest, Vol 1 #75 - 2 msgs > > > >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. Adding a new rank (or >> alien = >> race, for=20 >> that matter) is that much better defined. This way, the >> = >> topic "Grey=20 >> Commander" (stored as (<FONT face=3DTahoma>name=3D"<SPAN=20 >> class=3D648020306-04122003>Grey</SPAN>" </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> </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> </DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = >> class=3D224390419-08122003><SPAN=20 >> class=3D648020306-04122003></SPAN></SPAN></FONT> </DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = >> class=3D224390419-08122003><SPAN=20 >> class=3D648020306-04122003>Which leads us, of course, into >> adding a = >> new field=20 >> for dealing with multiple researches of the same topic. 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> </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. Unless flagged in some way (attribute or element), >> research = >> topics=20 >> are one-shot deals. By default, parent (researched) >> nodes 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> </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 <obsoletes/> element, that would contain topics >> and = >> items=20 >> that the player could no longer access. 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). However, we could use this to specify a node = >> obsoleting=20 >> <EM>itself</EM>. 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> </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 </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 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> </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. Just to make things more complicated, the >> information = >> (IIRC)=20 >> depends on the ship the engineer came from. Would that sort of >> = >> thing be=20 >> handled entirely in the code itself? Or would the techtree >> need to = >> list=20 >> all possible crafts as results from an engineer, and the research >> code = >> just=20 >> picks the correct one off 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> </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> </DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = >> class=3D224390419-08122003><SPAN=20 >> class=3D648020306-04122003></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> </DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = >> class=3D224390419-08122003><SPAN=20 >> class=3D648020306-04122003></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> </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> </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> </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 necessary. For example, Nick suggested to separate rank >> = >> from race=20 >> and I supported him. However, the approach he was suggesting is >> good = >> for=20 >> dynamic game data, and not for static research tree. Therefore, >> limit = >> the=20 >> number of attributes for necessary ones only.</FONT></SPAN></DIV> >> <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = >> lor=3D#0000ff=20 >> size=3D2></FONT></SPAN> </DIV> >> <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = >> color=3D#0000ff=20 >> size=3D2>Regards,</FONT></SPAN></DIV> >> <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = >> color=3D#0000ff=20 >> size=3D2>mamutas.</FONT></SPAN></DIV> >> <BLOCKQUOTE dir=3Dltr=20 >> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff >> 2px = >> solid; MARGIN-RIGHT: 0px"> >> <DIV></DIV> >> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = >> align=3Dleft><FONT=20 >> face=3DTahoma size=3D2>-----Original >> Message-----<BR><B>From:</B> = >> Cpt.=20 >> Boxershorts [mailto:cpt...@te...] <BR><B>Sent:</B> >> = >> Thursday,=20 >> December 04, 2003 12:12 AM<BR><B>To:</B> mamutas;=20 >> xen...@li...<BR><B>Subject:</B> >> RE:=20 >> [Xenocide-programming] Tech Tree XML >> layout<BR><BR></FONT></DIV> >> <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial = >> color=3D#000080=20 >> size=3D2>It's 'name' so that it fits with everything else in the >> = >> tech=20 >> tree. This is just a research topic...it won't hold actual >> = >> alien data=20 >> (stats and the like), just information related to the tech = >> tree. The=20 >> actual entry (made commander just for extra fields) would look >> like=20 >> this:</FONT></SPAN></DIV> >> <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial = >> color=3D#000080=20 >> size=3D2></FONT></SPAN> </DIV> >> <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial> >> <DIV><FONT face=3DTahoma><SPAN >> class=3D103305922-28112003><FONT=20 >> color=3D#000080><FONT size=3D2><SPAN=20 >> class=3D648020306-04122003><!--</SPAN><SPAN=20 >> class=3D648020306-04122003>Sectoid = >> Commander--></SPAN><BR><topic=20 >> name=3D"<SPAN >> class=3D648020306-04122003>Sectoid</SPAN>" <SPAN=20 >> class=3D648020306-04122003>rank=3D"<FONT = >> face=3DArial>commander</FONT>"=20 >> </SPAN>researchtime=3D"<SPAN=20 >> = >> >class=3D648020306-04122003>1000</SPAN>"></FONT></FONT></SPAN >></FONT></ >= >> DIV> >> <DIV><FONT color=3D#000080 size=3D2></FONT> </DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 >> = >> >class=3D103305922-28112003> <prerequisite></SPAN></F >ONT><FONT >> = >> >> size=3D+0><SPAN class=3D103305922-28112003><BR><FONT >> face=3DTahoma = >> color=3D#000080=20 >> size=3D2> <<SPAN = >> class=3D648020306-04122003>Item</SPAN>=20 >> name=3D"<SPAN >> class=3D648020306-04122003>Sectoid</SPAN>"<SPAN=20 >> class=3D648020306-04122003> rank=3D"<FONT=20 >> face=3DArial>commander</FONT>"</SPAN> /><SPAN=20 >> class=3D648020306-04122003> //reference to Item=20 >> = >> >list</SPAN><BR> </prerequisite><BR> <BR> & >lt;researc >= >> hbonus<SPAN=20 >> = >> >class=3D648020306-04122003>/></SPAN><BR> <BR> < >grants> >= >> <BR> <<SPAN=20 >> class=3D648020306-04122003>t</SPAN><SPAN = >> class=3D648020306-04122003>opic=20 >> </SPAN>name=3D"<SPAN class=3D648020306-04122003>Psi=20 >> = >> >Lab</SPAN>"/><BR> </grants><BR></topic></FO >NT></SPAN> >= >> </FONT></DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 >> class=3D103305922-28112003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 >> class=3D103305922-28112003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 >> class=3D103305922-28112003><SPAN=20 >> = >> >class=3D648020306-04122003></SPAN></SPAN></FONT> </DIV></F >ONT></SPAN >= >> ></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>=20 >> xen...@li...=20 >> [mailto:xen...@li...]<B>On >> = >> Behalf Of=20 >> </B>mamutas<BR><B>Sent:</B> December 3, 2003 8:32 >> PM<BR><B>To:</B> = >> 'Cpt.=20 >> Boxershorts';=20 >> xen...@li...<BR><B>Subject:</B> >> RE:=20 >> [Xenocide-programming] Tech Tree XML >> layout<BR><BR></FONT></DIV> >> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = >> color=3D#0000ff=20 >> size=3D2>Yeah, that is exactly what I was suggesting. = >> </FONT></SPAN></DIV> >> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = >> color=3D#0000ff=20 >> size=3D2>Unfortunately, I do not think it is possible to >> refernce = >> IDs=20 >> between files, but things might have been changed=20 >> recently...</FONT></SPAN></DIV> >> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = >> color=3D#0000ff=20 >> size=3D2></FONT></SPAN> </DIV> >> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = >> color=3D#0000ff=20 >> size=3D2>I suggest to go with second approach: different = >> properties in=20 >> different attributes. And change 'name' to 'race': Sectoid, = >> Floater,=20 >> Human...</FONT></SPAN></DIV> >> <BLOCKQUOTE dir=3Dltr=20 >> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: >> #0000ff = >> 2px solid; MARGIN-RIGHT: 0px"> >> <DIV></DIV> >> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = >> align=3Dleft><FONT=20 >> face=3DTahoma size=3D2>-----Original = >> Message-----<BR><B>From:</B> Cpt.=20 >> Boxershorts [mailto:cpt...@te...] >> <BR><B>Sent:</B> = >> Monday,=20 >> December 01, 2003 7:32 PM<BR><B>To:</B> mamutas;=20 >> >> >xen...@li...<BR><B>Subject:</B> = RE:=20 >> [Xenocide-programming] Tech Tree XML >> layout<BR><BR></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003>So, what you're saying >> is = >> move the=20 >> <filereferences> element into a global item >> list? = >> That's no=20 >> problem.</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003>Do you know if it's possible to >> = >> enforce id=20 >> integrity across files? I know you can do it in a >> single=20 >> file.</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003>Does anyone know how captured >> aliens = >> will be=20 >> recorded? Will it be an actual "Alien" class with a >> Rank = >> property,=20 >> or just a one line reference?</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003>Basically, I'm asking if it >> would=20 >> be:</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003><topic name=3D"Sectiod=20 >> Soldier"/></SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003>or</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003><topic name =3D "Sectoid"=20 >> rank=3D"Soldier"/></SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003>The first is easier to >do, but the >> = >> second might=20 >> be better for future-proofing (for multiplayer, when you can >> = >> capture=20 >> enemy humans as well)</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003>-The Captain</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 >> class=3D841092201-02122003></SPAN></FONT> </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 = >> 1, 2003=20 >> 2:47 PM<BR><B>To:</B> 'Cpt. Boxershorts';=20 >> >> >xen...@li...<BR><B>Subject:</B> = RE:=20 >> [Xenocide-programming] Tech Tree XML = >> layout<BR><BR></FONT></DIV> >> <DIV><SPAN class=3D977004422-01122003><FONT face=3DArial >> = >> color=3D#0000ff=20 >> size=3D2>Yes, visual representation is the images, text, >> = >> models -=20 >> everything what is displayed to the user. I suggest to >> break = >> down=20 >> information into separate files: one containing >> relationship = >> for XNet=20 >> DB view, another with relationships and data for research, >> and = >> another=20 >> with list of all entities and their visual representation >> = >> (models,=20 >> text, video, etc.). Then first two files could refer to >> the = >> last one.=20 >> How is that?</FONT></SPAN></DIV> >> <BLOCKQUOTE dir=3Dltr=20 >> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: >> = >> #0000ff 2px solid; MARGIN-RIGHT: 0px"> >> <DIV></DIV> >> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr >> = >> align=3Dleft><FONT=20 >> face=3DTahoma size=3D2>-----Original = >> Message-----<BR><B>From:</B> Cpt.=20 >> Boxershorts [mailto:cpt...@te...] = >> <BR><B>Sent:</B>=20 >> Monday, December 01, 2003 4:07 PM<BR><B>To:</B> >> mamutas;=20 >> = >> xen...@li...<BR><B>Subject:</B> >> RE:=20 >> [Xenocide-programming] Tech Tree XML = >> layout<BR><BR></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 >> size=3D2><SPAN=20 >> class=3D338460222-01122003>I'm not quite sure if I = >> understand. =20 >> By "visual representation", do you mean the part of the >> data = >> that=20 >> the player actually sees (i.e.: the xnet info), or or >> you = >> suggesting=20 >> a further breakdown of the underlying data (so >> there = >> would be=20 >> an XML file containing a simple list of all = >> researchable items,=20 >> and separate file containing the = >> relationships)?</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#000080 >> size=3D2><SPAN=20 >> class=3D338460222-01122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#000080 >> size=3D2><SPAN=20 >> class=3D338460222-01122003>-The >> Captain</SPAN></FONT></DIV> >> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> >> <DIV class=3DOutlookMessageHeader dir=3Dltr = >> align=3Dleft><FONT=20 >> face=3DTahoma size=3D2>-----Original = >> Message-----<BR><B>From:</B>=20 >> xen...@li...=20 >> = >> [mailto:xen...@li...]<B>On=20 >> Behalf Of </B>mamutas<BR><B>Sent:</B> November 30, >> 2003 = >> 8:32=20 >> PM<BR><B>To:</B> 'Andrew Franks';=20 >> = >> xen...@li...<BR><B>Subject:</B> >> RE:=20 >> [Xenocide-programming] Tech Tree XML = >> layout<BR><BR></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003>Looks pretty good to=20 >> me.</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003>I take a look at the >> structure = >> of XML=20 >> file and did not really checked the dependencies >> between=20 >> researcheable items.</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003>I have one concern here: >> the = >> definition=20 >> integrates both research tree hierarchy and visual = >> representation=20 >> for the entities. In my opinion these two should be = >> separated,=20 >> perhaps in two XML files: first to describe >> dependencies = >> only,=20 >> second to provide information for entry visual=20 >> presentation.</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003>In addition, I think that >> this = >> project=20 >> should be performed in parallel with XNet DB model = >> definition.=20 >> ChrisP has started it, but not finished yet. Here I >> think = >> we need=20 >> two XML as well: one to describe categories and >> entities = >> and=20 >> another to describe visual representation of entity. >> The = >> second=20 >> could be the same as the one for research,=20 >> see?</SPAN></FONT></DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> class=3D067575103-01122003></SPAN></FONT> </DIV> >> <DIV><FONT face=3DArial color=3D#0000ff >> size=3D2><SPAN=20 >> >> class=3D067575103-01122003>Regards.</SPAN></FONT></DIV> >> <BLOCKQUOTE dir=3Dltr=20 >> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; >> BORDER-LEFT: = >> #0000ff 2px solid; MARGIN-RIGHT: 0px"> >> <DIV></DIV> >> <DIV class=3DOutlookMessageHeader lang=3Den-us >> dir=3Dltr = >> >> align=3Dleft><FONT face=3DTahoma >> size=3D2>-----Original=20 >> Message-----<BR><B>From:</B>=20 >> xen...@li...=20 >> = >> [mailto:xen...@li...] <B>On=20 >> Behalf Of </B>Andrew Franks<BR><B>Sent:</B> Friday, >> = >> November 28,=20 >> 2003 5:05 PM<BR><B>To:</B> mamutas;=20 >> = >> xen...@li...<BR><B>Subject:</B>=20 >> RE: [Xenocide-programming] Tech Tree XML=20 >> layout<BR><BR></FONT></DIV> >> <DIV><SPAN class=3D103305922-28112003><FONT >> face=3DArial = >> >> color=3D#000080 size=3D2>Okay, here's a first = >> draft. I=20 >> included every field I could think of...let me know >> if I = >> missed=20 >> anything.</FONT></SPAN></DIV> >> <DIV><SPAN class=3D103305922-28112003><FONT >> face=3DArial = >> >> color=3D#000080 size=3D2>Is X-Net going to have it's >> own = >> xml layout,=20 >> or will it share with the tech >> tree?</FONT></SPAN></DIV> >> <DIV><SPAN class=3D103305922-28112003><FONT >> face=3DArial = >> >> color=3D#000080 size=3D2></FONT></SPAN> </DIV> >> <DIV><SPAN class=3D103305922-28112003><FONT >> face=3DArial = >> >> color=3D#000080 size=3D2>Here's a short sample, see >> the = >> attachment=20 >> for more detailed comments</FONT></SPAN></DIV> >> <DIV><FONT face=3DTahoma><FONT face=3DArial = >> color=3D#000080=20 >> size=3D2><SPAN=20 >> = >> class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> >> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 >> class=3D103305922-28112003>//Plasma >> Pistol<BR><topic=20 >> name=3D"Plasma Pistol"=20 >> researchtime=3D"100"></SPAN></FONT></FONT></DIV> >> <DIV> </DIV> >> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 >> = >> >class=3D103305922-28112003> <prerequisite><BR> > < >= >> topic=20 >> name=3D"Plasma Weapons" >> /><BR> <item = >> name=3D"Plasma=20 >> Pistol"=20 >> = >> >/><BR> </prerequisite><BR> <BR> <res >earchbonus >= >> >=20 >> // so if the player researched rifle before pistol, >> = >> pistol would=20 >> only take 95% of = >> researchtime<BR> //these=20 >> are cumulative, so if both were researched already, >> = >> pistol would=20 >> take 90% of researchtime<BR> <topic = >> name=3D"Plasma=20 >> Rifle" bonus=3D"5" /><BR> <topic = >> name=3D"Heavy=20 >> Plasma" bonus=3D"5"=20 >> = >> >/><BR> </researchbonus><BR> <BR> <fi >lepaths> >= >> >;<BR> <unresearched>/xnet/texts/unresearched/p >lasmapisto >= >> l.rtf</unresearched>=20 >> = >> ><BR> <xnet_image>/xnet/images/plasmapistol.3ds ></xnet_ >= >> image>=20 >> = >> ><BR> <xnet_text>/xnet/texts/weapons/plasmapist >ol.rtf< >= >> /xnet_text>=20 >> = >> ><BR> </filepaths><BR> <BR> <grants>< >BR> & >= >> nbsp;<item=20 >> name=3D"Plasma=20 >> = >> >Pistol"/><BR> </grants><BR></topic></SPAN>< >/FONT></FO >= >> NT></DIV> >> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 >> = >> class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> >> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 >> = >> class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> >> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 >> = >> class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> >> <DIV><FONT size=3D+0><SPAN = >> class=3D103305922-28112003><FONT=20 >> face=3DTahoma><FONT size=3D2> <SPAN = >> class=3D103305922-28112003>-=20 >> Cpt. = >> Boxershorts</SPAN></FONT></FONT></SPAN></FONT></DIV><BR> >> <P><FONT size=3D2>---<BR>Incoming mail is certified >> = >> Virus=20 >> Free.<BR>Checked by AVG anti-virus system=20 >> (http://www.grisoft.com).<BR>Version: 6.0.538 / >> Virus = >> Database:=20 >> 333 - Release Date: 2003/11/10<BR></FONT></P> >> <P><FONT face=3DArial = >> size=3D2></FONT></P></BLOCKQUOTE><BR> >> <P><FONT size=3D2>---<BR>Outgoing mail is certified >> Virus=20 >> Free.<BR>Checked by AVG anti-virus system=20 >> (http://www.grisoft.com).<BR>Version: 6.0.538 / Virus >> = >> Database:=20 >> 333 - Release Date: = >> 2003/11/10<BR></FONT></P></BLOCKQUOTE><BR> >> <P><FONT size=3D2>---<BR>Incoming mail is certified >> Virus=20 >> Free.<BR>Checked by AVG anti-virus system=20 >> (http://www.grisoft.com).<BR>Version: 6.0.545 / Virus = >> Database: 339=20 >> - Release Date: >> 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> >> <P><FONT size=3D2>---<BR>Outgoing mail is certified >> Virus=20 >> Free.<BR>Checked by AVG anti-virus system=20 >> (http://www.grisoft.com).<BR>Version: 6.0.545 / Virus = >> Database: 339 -=20 >> Release Date: 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> >> <P><FONT size=3D2>---<BR>Incoming mail is certified Virus = >> Free.<BR>Checked=20 >> by AVG anti-virus system >> (http://www.grisoft.com).<BR>Version: = >> 6.0.545 /=20 >> Virus Database: 339 - Release Date:=20 >> 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> >> <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus = >> Free.<BR>Checked=20 >> by AVG anti-virus system (http://www.grisoft.com).<BR>Version: >> = >> 6.0.545 /=20 >> Virus Database: 339 - Release Date:=20 >> 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> >> <P><FONT size=3D2>---<BR>Incoming mail is certified Virus = >> cked by=20 >> AVG anti-virus system (http://www.grisoft.com).<BR>Version: >> 6.0.545 = >> / Virus=20 >> Database: 339 - Release Date: = >> 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> >> <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus = >> Free.<BR>Checked by=20 >> AVG anti-virus system (http://www.grisoft.com).<BR>Version: >> 6.0.545 / = >> Virus=20 >> Database: 339 - Release Date:=20 >> 2003/11/27<BR></FONT></P></BLOCKQUOTE></BODY></HTML> >> >> ------=_NextPart_000_0010_01C3BD7F.E18BAEF0-- >> >> >> >> >> >> --__--__-- >> >> _______________________________________________ >> Xenocide-programming mailing list >> Xen...@li... >> https://lists.sourceforge.net/lists/listinfo/xenocide-programming >> >> >> End of Xenocide-programming Digest >> >> >> >> >> ------------------------------------------------------- >> 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! > > >------------------------------------------------------- >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 > > >--- >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 |
|
From: mamutas <ma...@pr...> - 2003-12-10 05:03:14
|
Hi Federico,
Strange, but I did not see your note about continuing research.
Anyway, I did not have time to even download it. We release our 'real =
life'
product this Friday, so you can imagine how busy we all are. It is =
something
like before final exam, if you know what I mean. :)
I will try to do it later this week, but no promise.
Regards,
Mamutas
>-----Original Message-----
>From: red...@pr...=20
>[mailto:red...@pr...]=20
>Sent: Tuesday, December 09, 2003 2:19 PM
>To: mamutas
>Subject: Re: [Xenocide-programming] StaticGeoData
>
>
>Hi Vlad, you sent this to the wrong list :D I am the only one=20
>that can see=20
>it...
>
>This is the header of the mail
>------------------------------------------
>Date: Mon, 8 Dec 2003 13:29:41 -0600=20
>From: mamutas <mam...@ho...>=20
>To: xen...@li...=20
>Subject: Re: [Xenocide-programming] StaticGeoData=20
>------------------------------------------
>
>TO: xenocide-programming{-admin}@lists.sourceforge.net
>
>Thanksfully I will be able to continue with the Ogre/Nebula2=20
>research (I have=20
>already discarded the other two - NeoEngine and Lithtech) so=20
>expect news=20
>soon... How was your test at it?
>
>Greetings
>Federico=20
>
>
>Quoting mamutas <mam...@ho...>:
>
>> Hi Ralph,
>>=20
>> Great work! I am glad to see so much details put in the headers.
>>=20
>> I have some comments, of course. :) But first, see my=20
>answers on your=20
>> questions embedded in your original mail below.
>>=20
>> Umm, I thought I will have time to comment on files, but I do not. I=20
>> will comment on the headers later.
>>=20
>> Regards,
>> mamutas
---
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
=20
|
|
From: Chris P. <chr...@ju...> - 2003-12-09 23:09:30
|
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. Adding a new rank (or > alien = > race, for=20 > that matter) is that much better defined. This way, the > = > topic "Grey=20 > Commander" (stored as (<FONT face=3DTahoma>name=3D"<SPAN=20 > class=3D648020306-04122003>Grey</SPAN>" </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> </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> </DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = > class=3D224390419-08122003><SPAN=20 > class=3D648020306-04122003></SPAN></SPAN></FONT> </DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = > class=3D224390419-08122003><SPAN=20 > class=3D648020306-04122003>Which leads us, of course, into > adding a = > new field=20 > for dealing with multiple researches of the same topic. 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> </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. Unless flagged in some way (attribute or element), > research = > topics=20 > are one-shot deals. By default, parent (researched) > nodes 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> </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 <obsoletes/> element, that would contain topics > and = > items=20 > that the player could no longer access. 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). However, we could use this to specify a node = > obsoleting=20 > <EM>itself</EM>. 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> </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 </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 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> </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. Just to make things more complicated, the > information = > (IIRC)=20 > depends on the ship the engineer came from. Would that sort of > = > thing be=20 > handled entirely in the code itself? Or would the techtree > need to = > list=20 > all possible crafts as results from an engineer, and the research > code = > just=20 > picks the correct one off 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> </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> </DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = > class=3D224390419-08122003><SPAN=20 > class=3D648020306-04122003></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> </DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = > class=3D224390419-08122003><SPAN=20 > class=3D648020306-04122003></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> </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> </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> </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 necessary. For example, Nick suggested to separate rank > = > from race=20 > and I supported him. However, the approach he was suggesting is > good = > for=20 > dynamic game data, and not for static research tree. Therefore, > limit = > the=20 > number of attributes for necessary ones only.</FONT></SPAN></DIV> > <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = > lor=3D#0000ff=20 > size=3D2></FONT></SPAN> </DIV> > <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = > color=3D#0000ff=20 > size=3D2>Regards,</FONT></SPAN></DIV> > <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = > color=3D#0000ff=20 > size=3D2>mamutas.</FONT></SPAN></DIV> > <BLOCKQUOTE dir=3Dltr=20 > style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff > 2px = > solid; MARGIN-RIGHT: 0px"> > <DIV></DIV> > <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = > align=3Dleft><FONT=20 > face=3DTahoma size=3D2>-----Original > Message-----<BR><B>From:</B> = > Cpt.=20 > Boxershorts [mailto:cpt...@te...] <BR><B>Sent:</B> > = > Thursday,=20 > December 04, 2003 12:12 AM<BR><B>To:</B> mamutas;=20 > xen...@li...<BR><B>Subject:</B> > RE:=20 > [Xenocide-programming] Tech Tree XML > layout<BR><BR></FONT></DIV> > <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial = > color=3D#000080=20 > size=3D2>It's 'name' so that it fits with everything else in the > = > tech=20 > tree. This is just a research topic...it won't hold actual > = > alien data=20 > (stats and the like), just information related to the tech = > tree. The=20 > actual entry (made commander just for extra fields) would look > like=20 > this:</FONT></SPAN></DIV> > <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial = > color=3D#000080=20 > size=3D2></FONT></SPAN> </DIV> > <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial> > <DIV><FONT face=3DTahoma><SPAN > class=3D103305922-28112003><FONT=20 > color=3D#000080><FONT size=3D2><SPAN=20 > class=3D648020306-04122003><!--</SPAN><SPAN=20 > class=3D648020306-04122003>Sectoid = > Commander--></SPAN><BR><topic=20 > name=3D"<SPAN > class=3D648020306-04122003>Sectoid</SPAN>" <SPAN=20 > class=3D648020306-04122003>rank=3D"<FONT = > face=3DArial>commander</FONT>"=20 > </SPAN>researchtime=3D"<SPAN=20 > = > class=3D648020306-04122003>1000</SPAN>"></FONT></FONT></SPAN></FONT></ = > DIV> > <DIV><FONT color=3D#000080 size=3D2></FONT> </DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 > = > class=3D103305922-28112003> <prerequisite></SPAN></FONT><FONT > = > > size=3D+0><SPAN class=3D103305922-28112003><BR><FONT > face=3DTahoma = > color=3D#000080=20 > size=3D2> <<SPAN = > class=3D648020306-04122003>Item</SPAN>=20 > name=3D"<SPAN > class=3D648020306-04122003>Sectoid</SPAN>"<SPAN=20 > class=3D648020306-04122003> rank=3D"<FONT=20 > face=3DArial>commander</FONT>"</SPAN> /><SPAN=20 > class=3D648020306-04122003> //reference to Item=20 > = > list</SPAN><BR> </prerequisite><BR> <BR> <researc = > hbonus<SPAN=20 > = > class=3D648020306-04122003>/></SPAN><BR> <BR> <grants> = > <BR> <<SPAN=20 > class=3D648020306-04122003>t</SPAN><SPAN = > class=3D648020306-04122003>opic=20 > </SPAN>name=3D"<SPAN class=3D648020306-04122003>Psi=20 > = > Lab</SPAN>"/><BR> </grants><BR></topic></FONT></SPAN> = > </FONT></DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 > class=3D103305922-28112003></SPAN></FONT> </DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 > class=3D103305922-28112003></SPAN></FONT> </DIV> > <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 > class=3D103305922-28112003><SPAN=20 > = > class=3D648020306-04122003></SPAN></SPAN></FONT> </DIV></FONT></SPAN = > ></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>=20 > xen...@li...=20 > [mailto:xen...@li...]<B>On > = > Behalf Of=20 > </B>mamutas<BR><B>Sent:</B> December 3, 2003 8:32 > PM<BR><B>To:</B> = > 'Cpt.=20 > Boxershorts';=20 > xen...@li...<BR><B>Subject:</B> > RE:=20 > [Xenocide-programming] Tech Tree XML > layout<BR><BR></FONT></DIV> > <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = > color=3D#0000ff=20 > size=3D2>Yeah, that is exactly what I was suggesting. = > </FONT></SPAN></DIV> > <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = > color=3D#0000ff=20 > size=3D2>Unfortunately, I do not think it is possible to > refernce = > IDs=20 > between files, but things might have been changed=20 > recently...</FONT></SPAN></DIV> > <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = > color=3D#0000ff=20 > size=3D2></FONT></SPAN> </DIV> > <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = > color=3D#0000ff=20 > size=3D2>I suggest to go with second approach: different = > properties in=20 > different attributes. And change 'name' to 'race': Sectoid, = > Floater,=20 > Human...</FONT></SPAN></DIV> > <BLOCKQUOTE dir=3Dltr=20 > style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: > #0000ff = > 2px solid; MARGIN-RIGHT: 0px"> > <DIV></DIV> > <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = > align=3Dleft><FONT=20 > face=3DTahoma size=3D2>-----Original = > Message-----<BR><B>From:</B> Cpt.=20 > Boxershorts [mailto:cpt...@te...] > <BR><B>Sent:</B> = > Monday,=20 > December 01, 2003 7:32 PM<BR><B>To:</B> mamutas;=20 > > xen...@li...<BR><B>Subject:</B> = > RE:=20 > [Xenocide-programming] Tech Tree XML > layout<BR><BR></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003>So, what you're saying > is = > move the=20 > <filereferences> element into a global item > list? = > That's no=20 > problem.</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003>Do you know if it's possible to > = > enforce id=20 > integrity across files? I know you can do it in a > single=20 > file.</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003>Does anyone know how captured > aliens = > will be=20 > recorded? Will it be an actual "Alien" class with a > Rank = > property,=20 > or just a one line reference?</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003>Basically, I'm asking if it > would=20 > be:</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003><topic name=3D"Sectiod=20 > Soldier"/></SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003>or</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003><topic name =3D "Sectoid"=20 > rank=3D"Soldier"/></SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003>The first is easier to do, but the > = > second might=20 > be better for future-proofing (for multiplayer, when you can > = > capture=20 > enemy humans as well)</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003>-The Captain</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 > class=3D841092201-02122003></SPAN></FONT> </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 = > 1, 2003=20 > 2:47 PM<BR><B>To:</B> 'Cpt. Boxershorts';=20 > > xen...@li...<BR><B>Subject:</B> = > RE:=20 > [Xenocide-programming] Tech Tree XML = > layout<BR><BR></FONT></DIV> > <DIV><SPAN class=3D977004422-01122003><FONT face=3DArial > = > color=3D#0000ff=20 > size=3D2>Yes, visual representation is the images, text, > = > models -=20 > everything what is displayed to the user. I suggest to > break = > down=20 > information into separate files: one containing > relationship = > for XNet=20 > DB view, another with relationships and data for research, > and = > another=20 > with list of all entities and their visual representation > = > (models,=20 > text, video, etc.). Then first two files could refer to > the = > last one.=20 > How is that?</FONT></SPAN></DIV> > <BLOCKQUOTE dir=3Dltr=20 > style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: > = > #0000ff 2px solid; MARGIN-RIGHT: 0px"> > <DIV></DIV> > <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr > = > align=3Dleft><FONT=20 > face=3DTahoma size=3D2>-----Original = > Message-----<BR><B>From:</B> Cpt.=20 > Boxershorts [mailto:cpt...@te...] = > <BR><B>Sent:</B>=20 > Monday, December 01, 2003 4:07 PM<BR><B>To:</B> > mamutas;=20 > = > xen...@li...<BR><B>Subject:</B> > RE:=20 > [Xenocide-programming] Tech Tree XML = > layout<BR><BR></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 > size=3D2><SPAN=20 > class=3D338460222-01122003>I'm not quite sure if I = > understand. =20 > By "visual representation", do you mean the part of the > data = > that=20 > the player actually sees (i.e.: the xnet info), or or > you = > suggesting=20 > a further breakdown of the underlying data (so > there = > would be=20 > an XML file containing a simple list of all = > researchable items,=20 > and separate file containing the = > relationships)?</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#000080 > size=3D2><SPAN=20 > class=3D338460222-01122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#000080 > size=3D2><SPAN=20 > class=3D338460222-01122003>-The > Captain</SPAN></FONT></DIV> > <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> > <DIV class=3DOutlookMessageHeader dir=3Dltr = > align=3Dleft><FONT=20 > face=3DTahoma size=3D2>-----Original = > Message-----<BR><B>From:</B>=20 > xen...@li...=20 > = > [mailto:xen...@li...]<B>On=20 > Behalf Of </B>mamutas<BR><B>Sent:</B> November 30, > 2003 = > 8:32=20 > PM<BR><B>To:</B> 'Andrew Franks';=20 > = > xen...@li...<BR><B>Subject:</B> > RE:=20 > [Xenocide-programming] Tech Tree XML = > layout<BR><BR></FONT></DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003>Looks pretty good to=20 > me.</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003>I take a look at the > structure = > of XML=20 > file and did not really checked the dependencies > between=20 > researcheable items.</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003>I have one concern here: > the = > definition=20 > integrates both research tree hierarchy and visual = > representation=20 > for the entities. In my opinion these two should be = > separated,=20 > perhaps in two XML files: first to describe > dependencies = > only,=20 > second to provide information for entry visual=20 > presentation.</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003>In addition, I think that > this = > project=20 > should be performed in parallel with XNet DB model = > definition.=20 > ChrisP has started it, but not finished yet. Here I > think = > we need=20 > two XML as well: one to describe categories and > entities = > and=20 > another to describe visual representation of entity. > The = > second=20 > could be the same as the one for research,=20 > see?</SPAN></FONT></DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > class=3D067575103-01122003></SPAN></FONT> </DIV> > <DIV><FONT face=3DArial color=3D#0000ff > size=3D2><SPAN=20 > > class=3D067575103-01122003>Regards.</SPAN></FONT></DIV> > <BLOCKQUOTE dir=3Dltr=20 > style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; > BORDER-LEFT: = > #0000ff 2px solid; MARGIN-RIGHT: 0px"> > <DIV></DIV> > <DIV class=3DOutlookMessageHeader lang=3Den-us > dir=3Dltr = > > align=3Dleft><FONT face=3DTahoma > size=3D2>-----Original=20 > Message-----<BR><B>From:</B>=20 > xen...@li...=20 > = > [mailto:xen...@li...] <B>On=20 > Behalf Of </B>Andrew Franks<BR><B>Sent:</B> Friday, > = > November 28,=20 > 2003 5:05 PM<BR><B>To:</B> mamutas;=20 > = > xen...@li...<BR><B>Subject:</B>=20 > RE: [Xenocide-programming] Tech Tree XML=20 > layout<BR><BR></FONT></DIV> > <DIV><SPAN class=3D103305922-28112003><FONT > face=3DArial = > > color=3D#000080 size=3D2>Okay, here's a first = > draft. I=20 > included every field I could think of...let me know > if I = > missed=20 > anything.</FONT></SPAN></DIV> > <DIV><SPAN class=3D103305922-28112003><FONT > face=3DArial = > > color=3D#000080 size=3D2>Is X-Net going to have it's > own = > xml layout,=20 > or will it share with the tech > tree?</FONT></SPAN></DIV> > <DIV><SPAN class=3D103305922-28112003><FONT > face=3DArial = > > color=3D#000080 size=3D2></FONT></SPAN> </DIV> > <DIV><SPAN class=3D103305922-28112003><FONT > face=3DArial = > > color=3D#000080 size=3D2>Here's a short sample, see > the = > attachment=20 > for more detailed comments</FONT></SPAN></DIV> > <DIV><FONT face=3DTahoma><FONT face=3DArial = > color=3D#000080=20 > size=3D2><SPAN=20 > = > class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> > <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 > class=3D103305922-28112003>//Plasma > Pistol<BR><topic=20 > name=3D"Plasma Pistol"=20 > researchtime=3D"100"></SPAN></FONT></FONT></DIV> > <DIV> </DIV> > <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 > = > class=3D103305922-28112003> <prerequisite><BR> < = > topic=20 > name=3D"Plasma Weapons" > /><BR> <item = > name=3D"Plasma=20 > Pistol"=20 > = > /><BR> </prerequisite><BR> <BR> <researchbonus = > >=20 > // so if the player researched rifle before pistol, > = > pistol would=20 > only take 95% of = > researchtime<BR> //these=20 > are cumulative, so if both were researched already, > = > pistol would=20 > take 90% of researchtime<BR> <topic = > name=3D"Plasma=20 > Rifle" bonus=3D"5" /><BR> <topic = > name=3D"Heavy=20 > Plasma" bonus=3D"5"=20 > = > /><BR> </researchbonus><BR> <BR> <filepaths> = > ;<BR> <unresearched>/xnet/texts/unresearched/plasmapisto = > l.rtf</unresearched>=20 > = > <BR> <xnet_image>/xnet/images/plasmapistol.3ds</xnet_ = > image>=20 > = > <BR> <xnet_text>/xnet/texts/weapons/plasmapistol.rtf< = > /xnet_text>=20 > = > <BR> </filepaths><BR> <BR> <grants><BR> & = > nbsp;<item=20 > name=3D"Plasma=20 > = > Pistol"/><BR> </grants><BR></topic></SPAN></FONT></FO = > NT></DIV> > <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 > = > class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> > <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 > = > class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> > <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 > = > class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> > <DIV><FONT size=3D+0><SPAN = > class=3D103305922-28112003><FONT=20 > face=3DTahoma><FONT size=3D2> <SPAN = > class=3D103305922-28112003>-=20 > Cpt. = > Boxershorts</SPAN></FONT></FONT></SPAN></FONT></DIV><BR> > <P><FONT size=3D2>---<BR>Incoming mail is certified > = > Virus=20 > Free.<BR>Checked by AVG anti-virus system=20 > (http://www.grisoft.com).<BR>Version: 6.0.538 / > Virus = > Database:=20 > 333 - Release Date: 2003/11/10<BR></FONT></P> > <P><FONT face=3DArial = > size=3D2></FONT></P></BLOCKQUOTE><BR> > <P><FONT size=3D2>---<BR>Outgoing mail is certified > Virus=20 > Free.<BR>Checked by AVG anti-virus system=20 > (http://www.grisoft.com).<BR>Version: 6.0.538 / Virus > = > Database:=20 > 333 - Release Date: = > 2003/11/10<BR></FONT></P></BLOCKQUOTE><BR> > <P><FONT size=3D2>---<BR>Incoming mail is certified > Virus=20 > Free.<BR>Checked by AVG anti-virus system=20 > (http://www.grisoft.com).<BR>Version: 6.0.545 / Virus = > Database: 339=20 > - Release Date: > 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> > <P><FONT size=3D2>---<BR>Outgoing mail is certified > Virus=20 > Free.<BR>Checked by AVG anti-virus system=20 > (http://www.grisoft.com).<BR>Version: 6.0.545 / Virus = > Database: 339 -=20 > Release Date: 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> > <P><FONT size=3D2>---<BR>Incoming mail is certified Virus = > Free.<BR>Checked=20 > by AVG anti-virus system > (http://www.grisoft.com).<BR>Version: = > 6.0.545 /=20 > Virus Database: 339 - Release Date:=20 > 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> > <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus = > Free.<BR>Checked=20 > by AVG anti-virus system (http://www.grisoft.com).<BR>Version: > = > 6.0.545 /=20 > Virus Database: 339 - Release Date:=20 > 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> > <P><FONT size=3D2>---<BR>Incoming mail is certified Virus = > cked by=20 > AVG anti-virus system (http://www.grisoft.com).<BR>Version: > 6.0.545 = > / Virus=20 > Database: 339 - Release Date: = > 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> > <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus = > Free.<BR>Checked by=20 > AVG anti-virus system (http://www.grisoft.com).<BR>Version: > 6.0.545 / = > Virus=20 > Database: 339 - Release Date:=20 > 2003/11/27<BR></FONT></P></BLOCKQUOTE></BODY></HTML> > > ------=_NextPart_000_0010_01C3BD7F.E18BAEF0-- > > > > > > --__--__-- > > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > End of Xenocide-programming Digest > > > > > ------------------------------------------------------- > 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! |
|
From: Cpt. B. <cpt...@te...> - 2003-12-09 22:04:56
|
Hey Andrew, I'm pretty sure that the actual responses from interrogating medics and engineers aren't random. Medics will only give either that race, or the associated race (so a snakeman will give you Snakeman or Chrysillid, a sectoid will give you sectoid or cyberdisc, etc). Engineers can only give you data on the ship they were in (so no matter how many large scouts you capture, you won't get Battleship info). That being said, I think your layout is good place to start. I was thinking of something similar, only instead of a 'random' attribute (since it's not really random), have them contained within an <xor> element (similar to the way <prerequisite> elements can be within an <or> element). You're right though, the internal code will have to handle the details about which one specifically to choose. My main idea about having a node obsolete itself after all of it's <grants><xor> fields have been finished is just to make it more user friendly. The player can still remove live aliens from containment...but either way, they won't be cluttering up the research window. -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...]On Behalf Of Andrew Pokrovski Sent: December 9, 2003 9:38 AM To: xen...@li... Cc: br...@pr... Subject: RE: [Xenocide-programming] Tech Tree XML layout >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 > >I 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. True, though you could gain a lot of "live alien" info by interrogating medics rather than having to go out and capture the aliens yourself. Still, I know what you mean, if you have about 20 aliens taking up containment space even though you've already interrogated them as much as you can. I don't think this should be dealt with by the research section, you should always be able to interrogate an alien prisoner. If you feel you don't want to, however, there should be an option to "throw them out" (execution, sell them to corporate labs, etc). That's not really relevant here though. Also, I agree with you that the 'obsoletes' field is pretty useless here. The only use for it I see is to mark a node as "done with" so it no longer shows up on the research tree - by this token, the only research topics that are never "done with" are live aliens. > >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? I believe medics and engineers both give you a random entry each time you research one, until there are no more entries in that section, at which point they give you nothing. A possible idea is to decouple the research entries a research item enables from the XNet entries it shows. This way, a research topic can enable stuff in the tech tree, but will also show some XNet entries that aren't necessarily tech tree items. For dealing with randomly selected benefits (like UFOs and corpses) one could add a tag to indicate whether or not the UFO or whatever has been enabled already. For example: <!--Sectoid Engineer--> <topic name="Sectoid" rank="engineer" researchtime="1000"> <prerequisite> <Item name="Sectoid" rank="engineer" /> //reference to Item list </prerequisite> <researchbonus/> <grants> <XNetEntry name = "Sectoid Interrogation"/> <XNetEntry name = "UFOSpec1" random=true/> <XNetEntry name = "UFOSpec2" random=true/> <Item name = "Sectoid Corpse"/> </grants> </topic> So, the engineer (a researching dead-end, as I recall), would show a 'sectoid interrogation' entry no matter what, and will also randomly display one of the UFOSpecs (they've got that random tag). Also, researching an engineer could possibly yield a corpse or other items (a sectoid arm or something). Consistency of random UFO picks should probably be handled in the code, otherwise, we'd have to keep track of which UFOs have been picked for ALL engineer entries (one per sentient race). By consistency, I mean that if a UFO has been displayed already, another one should be picked. Andrew/"Nick Aragua" _________________________________________________________________ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx ------------------------------------------------------- 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 |
|
From: Jeremy <dr...@cf...> - 2003-12-09 21:03:16
|
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. Adding a new rank (or alien = race, for=20 that matter) is that much better defined. This way, the = topic "Grey=20 Commander" (stored as (<FONT face=3DTahoma>name=3D"<SPAN=20 class=3D648020306-04122003>Grey</SPAN>" </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> </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> </DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = class=3D224390419-08122003><SPAN=20 class=3D648020306-04122003></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = class=3D224390419-08122003><SPAN=20 class=3D648020306-04122003>Which leads us, of course, into adding a = new field=20 for dealing with multiple researches of the same topic. 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> </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. Unless flagged in some way (attribute or element), research = topics=20 are one-shot deals. By default, parent (researched) nodes 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> </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 <obsoletes/> element, that would contain topics and = items=20 that the player could no longer access. 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). However, we could use this to specify a node = obsoleting=20 <EM>itself</EM>. 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> </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 </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 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> </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. Just to make things more complicated, the information = (IIRC)=20 depends on the ship the engineer came from. Would that sort of = thing be=20 handled entirely in the code itself? Or would the techtree need to = list=20 all possible crafts as results from an engineer, and the research code = just=20 picks the correct one off 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> </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> </DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = class=3D224390419-08122003><SPAN=20 class=3D648020306-04122003></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> </DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN = class=3D224390419-08122003><SPAN=20 class=3D648020306-04122003></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> </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> </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> </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 necessary. For example, Nick suggested to separate rank = from race=20 and I supported him. However, the approach he was suggesting is good = for=20 dynamic game data, and not for static research tree. Therefore, limit = the=20 number of attributes for necessary ones only.</FONT></SPAN></DIV> <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Regards,</FONT></SPAN></DIV> <DIV><SPAN class=3D835134705-08122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>mamutas.</FONT></SPAN></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> = Cpt.=20 Boxershorts [mailto:cpt...@te...] <BR><B>Sent:</B> = Thursday,=20 December 04, 2003 12:12 AM<BR><B>To:</B> mamutas;=20 xen...@li...<BR><B>Subject:</B> RE:=20 [Xenocide-programming] Tech Tree XML layout<BR><BR></FONT></DIV> <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial = color=3D#000080=20 size=3D2>It's 'name' so that it fits with everything else in the = tech=20 tree. This is just a research topic...it won't hold actual = alien data=20 (stats and the like), just information related to the tech = tree. The=20 actual entry (made commander just for extra fields) would look like=20 this:</FONT></SPAN></DIV> <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial = color=3D#000080=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D648020306-04122003><FONT face=3DArial> <DIV><FONT face=3DTahoma><SPAN class=3D103305922-28112003><FONT=20 color=3D#000080><FONT size=3D2><SPAN=20 class=3D648020306-04122003><!--</SPAN><SPAN=20 class=3D648020306-04122003>Sectoid = Commander--></SPAN><BR><topic=20 name=3D"<SPAN class=3D648020306-04122003>Sectoid</SPAN>" <SPAN=20 class=3D648020306-04122003>rank=3D"<FONT = face=3DArial>commander</FONT>"=20 </SPAN>researchtime=3D"<SPAN=20 = class=3D648020306-04122003>1000</SPAN>"></FONT></FONT></SPAN></FONT></= DIV> <DIV><FONT color=3D#000080 size=3D2></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 = class=3D103305922-28112003> <prerequisite></SPAN></FONT><FONT = size=3D+0><SPAN class=3D103305922-28112003><BR><FONT face=3DTahoma = color=3D#000080=20 size=3D2> <<SPAN = class=3D648020306-04122003>Item</SPAN>=20 name=3D"<SPAN class=3D648020306-04122003>Sectoid</SPAN>"<SPAN=20 class=3D648020306-04122003> rank=3D"<FONT=20 face=3DArial>commander</FONT>"</SPAN> /><SPAN=20 class=3D648020306-04122003> //reference to Item=20 = list</SPAN><BR> </prerequisite><BR> <BR> <researc= hbonus<SPAN=20 = class=3D648020306-04122003>/></SPAN><BR> <BR> <grants>= <BR> <<SPAN=20 class=3D648020306-04122003>t</SPAN><SPAN = class=3D648020306-04122003>opic=20 </SPAN>name=3D"<SPAN class=3D648020306-04122003>Psi=20 = Lab</SPAN>"/><BR> </grants><BR></topic></FONT></SPAN>= </FONT></DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 class=3D103305922-28112003></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 class=3D103305922-28112003></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#000080 size=3D2><SPAN=20 class=3D103305922-28112003><SPAN=20 = class=3D648020306-04122003></SPAN></SPAN></FONT> </DIV></FONT></SPAN= ></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>=20 xen...@li...=20 [mailto:xen...@li...]<B>On = Behalf Of=20 </B>mamutas<BR><B>Sent:</B> December 3, 2003 8:32 PM<BR><B>To:</B> = 'Cpt.=20 Boxershorts';=20 xen...@li...<BR><B>Subject:</B> RE:=20 [Xenocide-programming] Tech Tree XML layout<BR><BR></FONT></DIV> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Yeah, that is exactly what I was suggesting. = </FONT></SPAN></DIV> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Unfortunately, I do not think it is possible to refernce = IDs=20 between files, but things might have been changed=20 recently...</FONT></SPAN></DIV> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D272442804-04122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>I suggest to go with second approach: different = properties in=20 different attributes. And change 'name' to 'race': Sectoid, = Floater,=20 Human...</FONT></SPAN></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original = Message-----<BR><B>From:</B> Cpt.=20 Boxershorts [mailto:cpt...@te...] <BR><B>Sent:</B> = Monday,=20 December 01, 2003 7:32 PM<BR><B>To:</B> mamutas;=20 xen...@li...<BR><B>Subject:</B> = RE:=20 [Xenocide-programming] Tech Tree XML layout<BR><BR></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003>So, what you're saying is = move the=20 <filereferences> element into a global item list? = That's no=20 problem.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003>Do you know if it's possible to = enforce id=20 integrity across files? I know you can do it in a single=20 file.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003>Does anyone know how captured aliens = will be=20 recorded? Will it be an actual "Alien" class with a Rank = property,=20 or just a one line reference?</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003>Basically, I'm asking if it would=20 be:</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003><topic name=3D"Sectiod=20 Soldier"/></SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003>or</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003><topic name =3D "Sectoid"=20 rank=3D"Soldier"/></SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003>The first is easier to do, but the = second might=20 be better for future-proofing (for multiplayer, when you can = capture=20 enemy humans as well)</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003>-The Captain</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D841092201-02122003></SPAN></FONT> </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 = 1, 2003=20 2:47 PM<BR><B>To:</B> 'Cpt. Boxershorts';=20 xen...@li...<BR><B>Subject:</B> = RE:=20 [Xenocide-programming] Tech Tree XML = layout<BR><BR></FONT></DIV> <DIV><SPAN class=3D977004422-01122003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Yes, visual representation is the images, text, = models -=20 everything what is displayed to the user. I suggest to break = down=20 information into separate files: one containing relationship = for XNet=20 DB view, another with relationships and data for research, and = another=20 with list of all entities and their visual representation = (models,=20 text, video, etc.). Then first two files could refer to the = last one.=20 How is that?</FONT></SPAN></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original = Message-----<BR><B>From:</B> Cpt.=20 Boxershorts [mailto:cpt...@te...] = <BR><B>Sent:</B>=20 Monday, December 01, 2003 4:07 PM<BR><B>To:</B> mamutas;=20 = xen...@li...<BR><B>Subject:</B> RE:=20 [Xenocide-programming] Tech Tree XML = layout<BR><BR></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D338460222-01122003>I'm not quite sure if I = understand. =20 By "visual representation", do you mean the part of the data = that=20 the player actually sees (i.e.: the xnet info), or or you = suggesting=20 a further breakdown of the underlying data (so there = would be=20 an XML file containing a simple list of all = researchable items,=20 and separate file containing the = relationships)?</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D338460222-01122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#000080 size=3D2><SPAN=20 class=3D338460222-01122003>-The Captain</SPAN></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original = Message-----<BR><B>From:</B>=20 xen...@li...=20 = [mailto:xen...@li...]<B>On=20 Behalf Of </B>mamutas<BR><B>Sent:</B> November 30, 2003 = 8:32=20 PM<BR><B>To:</B> 'Andrew Franks';=20 = xen...@li...<BR><B>Subject:</B> RE:=20 [Xenocide-programming] Tech Tree XML = layout<BR><BR></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003>Looks pretty good to=20 me.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003>I take a look at the structure = of XML=20 file and did not really checked the dependencies between=20 researcheable items.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003>I have one concern here: the = definition=20 integrates both research tree hierarchy and visual = representation=20 for the entities. In my opinion these two should be = separated,=20 perhaps in two XML files: first to describe dependencies = only,=20 second to provide information for entry visual=20 presentation.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003>In addition, I think that this = project=20 should be performed in parallel with XNet DB model = definition.=20 ChrisP has started it, but not finished yet. Here I think = we need=20 two XML as well: one to describe categories and entities = and=20 another to describe visual representation of entity. The = second=20 could be the same as the one for research,=20 see?</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D067575103-01122003>Regards.</SPAN></FONT></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT face=3DTahoma size=3D2>-----Original=20 Message-----<BR><B>From:</B>=20 xen...@li...=20 = [mailto:xen...@li...] <B>On=20 Behalf Of </B>Andrew Franks<BR><B>Sent:</B> Friday, = November 28,=20 2003 5:05 PM<BR><B>To:</B> mamutas;=20 = xen...@li...<BR><B>Subject:</B>=20 RE: [Xenocide-programming] Tech Tree XML=20 layout<BR><BR></FONT></DIV> <DIV><SPAN class=3D103305922-28112003><FONT face=3DArial = color=3D#000080 size=3D2>Okay, here's a first = draft. I=20 included every field I could think of...let me know if I = missed=20 anything.</FONT></SPAN></DIV> <DIV><SPAN class=3D103305922-28112003><FONT face=3DArial = color=3D#000080 size=3D2>Is X-Net going to have it's own = xml layout,=20 or will it share with the tech tree?</FONT></SPAN></DIV> <DIV><SPAN class=3D103305922-28112003><FONT face=3DArial = color=3D#000080 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D103305922-28112003><FONT face=3DArial = color=3D#000080 size=3D2>Here's a short sample, see the = attachment=20 for more detailed comments</FONT></SPAN></DIV> <DIV><FONT face=3DTahoma><FONT face=3DArial = color=3D#000080=20 size=3D2><SPAN=20 = class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 class=3D103305922-28112003>//Plasma Pistol<BR><topic=20 name=3D"Plasma Pistol"=20 researchtime=3D"100"></SPAN></FONT></FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 = class=3D103305922-28112003> <prerequisite><BR> <= topic=20 name=3D"Plasma Weapons" /><BR> <item = name=3D"Plasma=20 Pistol"=20 = /><BR> </prerequisite><BR> <BR> <researchbonus= >=20 // so if the player researched rifle before pistol, = pistol would=20 only take 95% of = researchtime<BR> //these=20 are cumulative, so if both were researched already, = pistol would=20 take 90% of researchtime<BR> <topic = name=3D"Plasma=20 Rifle" bonus=3D"5" /><BR> <topic = name=3D"Heavy=20 Plasma" bonus=3D"5"=20 = /><BR> </researchbonus><BR> <BR> <filepaths>= ;<BR> <unresearched>/xnet/texts/unresearched/plasmapisto= l.rtf</unresearched>=20 = <BR> <xnet_image>/xnet/images/plasmapistol.3ds</xnet_= image>=20 = <BR> <xnet_text>/xnet/texts/weapons/plasmapistol.rtf<= /xnet_text>=20 = <BR> </filepaths><BR> <BR> <grants><BR> &= nbsp;<item=20 name=3D"Plasma=20 = Pistol"/><BR> </grants><BR></topic></SPAN></FONT></FO= NT></DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 = class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 = class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 = class=3D103305922-28112003></SPAN></FONT></FONT> </DIV> <DIV><FONT size=3D+0><SPAN = class=3D103305922-28112003><FONT=20 face=3DTahoma><FONT size=3D2> <SPAN = class=3D103305922-28112003>-=20 Cpt. = Boxershorts</SPAN></FONT></FONT></SPAN></FONT></DIV><BR> <P><FONT size=3D2>---<BR>Incoming mail is certified = Virus=20 Free.<BR>Checked by AVG anti-virus system=20 (http://www.grisoft.com).<BR>Version: 6.0.538 / Virus = Database:=20 333 - Release Date: 2003/11/10<BR></FONT></P> <P><FONT face=3DArial = size=3D2></FONT></P></BLOCKQUOTE><BR> <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus=20 Free.<BR>Checked by AVG anti-virus system=20 (http://www.grisoft.com).<BR>Version: 6.0.538 / Virus = Database:=20 333 - Release Date: = 2003/11/10<BR></FONT></P></BLOCKQUOTE><BR> <P><FONT size=3D2>---<BR>Incoming mail is certified Virus=20 Free.<BR>Checked by AVG anti-virus system=20 (http://www.grisoft.com).<BR>Version: 6.0.545 / Virus = Database: 339=20 - Release Date: 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus=20 Free.<BR>Checked by AVG anti-virus system=20 (http://www.grisoft.com).<BR>Version: 6.0.545 / Virus = Database: 339 -=20 Release Date: 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> <P><FONT size=3D2>---<BR>Incoming mail is certified Virus = Free.<BR>Checked=20 by AVG anti-virus system (http://www.grisoft.com).<BR>Version: = 6.0.545 /=20 Virus Database: 339 - Release Date:=20 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus = Free.<BR>Checked=20 by AVG anti-virus system (http://www.grisoft.com).<BR>Version: = 6.0.545 /=20 Virus Database: 339 - Release Date:=20 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> <P><FONT size=3D2>---<BR>Incoming mail is certified Virus = Free.<BR>Checked by=20 AVG anti-virus system (http://www.grisoft.com).<BR>Version: 6.0.545 = / Virus=20 Database: 339 - Release Date: = 2003/11/27<BR></FONT></P></BLOCKQUOTE><BR> <P><FONT size=3D2>---<BR>Outgoing mail is certified Virus = Free.<BR>Checked by=20 AVG anti-virus system (http://www.grisoft.com).<BR>Version: 6.0.545 / = Virus=20 Database: 339 - Release Date:=20 2003/11/27<BR></FONT></P></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0010_01C3BD7F.E18BAEF0-- --__--__-- _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming End of Xenocide-programming Digest |
|
From: Andrew P. <a_p...@ho...> - 2003-12-09 17:38:02
|
>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 > >I 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. True, though you could gain a lot of "live alien" info by interrogating medics rather than having to go out and capture the aliens yourself. Still, I know what you mean, if you have about 20 aliens taking up containment space even though you've already interrogated them as much as you can. I don't think this should be dealt with by the research section, you should always be able to interrogate an alien prisoner. If you feel you don't want to, however, there should be an option to "throw them out" (execution, sell them to corporate labs, etc). That's not really relevant here though. Also, I agree with you that the 'obsoletes' field is pretty useless here. The only use for it I see is to mark a node as "done with" so it no longer shows up on the research tree - by this token, the only research topics that are never "done with" are live aliens. > >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? I believe medics and engineers both give you a random entry each time you research one, until there are no more entries in that section, at which point they give you nothing. A possible idea is to decouple the research entries a research item enables from the XNet entries it shows. This way, a research topic can enable stuff in the tech tree, but will also show some XNet entries that aren't necessarily tech tree items. For dealing with randomly selected benefits (like UFOs and corpses) one could add a tag to indicate whether or not the UFO or whatever has been enabled already. For example: <!--Sectoid Engineer--> <topic name="Sectoid" rank="engineer" researchtime="1000"> <prerequisite> <Item name="Sectoid" rank="engineer" /> //reference to Item list </prerequisite> <researchbonus/> <grants> <XNetEntry name = "Sectoid Interrogation"/> <XNetEntry name = "UFOSpec1" random=true/> <XNetEntry name = "UFOSpec2" random=true/> <Item name = "Sectoid Corpse"/> </grants> </topic> So, the engineer (a researching dead-end, as I recall), would show a 'sectoid interrogation' entry no matter what, and will also randomly display one of the UFOSpecs (they've got that random tag). Also, researching an engineer could possibly yield a corpse or other items (a sectoid arm or something). Consistency of random UFO picks should probably be handled in the code, otherwise, we'd have to keep track of which UFOs have been picked for ALL engineer entries (one per sentient race). By consistency, I mean that if a UFO has been displayed already, another one should be picked. Andrew/"Nick Aragua" _________________________________________________________________ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx |
|
From: Cpt. B. <cpt...@te...> - 2003-12-09 09:27:56
|
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
|
|
From: Chris P. <chr...@ju...> - 2003-12-09 04:27:46
|
> 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! |
|
From: mamutas <ma...@pr...> - 2003-12-08 06:18:34
|
Hi Chris, Welcome back. It was a while since there was a news from you. Also, there were some changes and additions in the current list of = working items. One being the research tree XML definition file, which Cpt. Boxershorts is working on. As I see the Xnet DB and the research tree = XML files have lots in common, so they should not be developed individually. 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. 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. The XML processing will be present in many areas of the project, so there is a need for fast and reliable parser, which will work with any = XML formats. So far, we planning to use Xerces from Apache and that is what = you should plan on too. 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 implementatioin. 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. Again, sorry if I was to criticizing. I really appreciate the work you = are doing and efforts you are putting in the project. Best regards, Mamutas. > -----Original Message----- > From: xen...@li...=20 > [mailto:xen...@li...] On=20 > Behalf Of Chris Phillips > Sent: Friday, December 05, 2003 1:49 AM > To: xen...@li... > Subject: Re: [Xenocide-programming] Tech Tree XML layout >=20 >=20 >=20 > Hi Everyone, >=20 > Sorry I have been absent for so long. I have been extremely=20 > busy recently. I'm essentially=20 > working three jobs right now, but I would still like to=20 > continue contributing to this project. >=20 > I was originally to do the X-Net XML file and X-Net data=20 > loader a couple of months ago. =20 > I have an example of an XML file and the X-Net data loader is=20 > further along. I am going to post a more complete version of=20 > the XNDL class this weekend. I have not been able to do any=20 > significant development on it until just a couple of days ago. >=20 > The XNDL is close to being able to completely tokenize an XML=20 > file (although it may not appear to be..). We need to decide=20 > on a format for an X-Net XML file, though. If we=20 > want a full-fledged XML parser, than the implementation will=20 > be much more tricky. Basically,=20 > you're dealing with a compiler front-end with that. =20 > Otherwise, we will have to use canned tags=20 > or meet somewhere in between. We can base the XML file on my=20 > example, or any other. =20 > It doesn't matter much to me. But keep in mind, that the=20 > simpler the XML syntax, the more=20 > likely it is to be compatible with the XNDL. Please keep the=20 > syntax simple for the time being. :) =20 >=20 > I have attached the current state of the XNDL code. It is very raw.=20 > Don't worry about=20 > critiquing the code. It's in way to poor of a state for=20 > that. :) I also included my example XML file. I will post=20 > more comments and updated code later.=20 >=20 > Regards, > chrisp >=20 > --- > 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 > =20 > =20 >=20 --- 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 =20 |
|
From: mamutas <ma...@pr...> - 2003-12-08 06:00:09
|
As I mentioned in my previous post, the generality would work for dynamic
data, and not for static data as research tree. So, I think that Cpt.
Boxershorts is right in this case.
Regards,
Mamutas.
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On
> Behalf Of Cpt. Boxershorts
> Sent: Thursday, December 04, 2003 12:25 AM
> To: Andrew Pokrovski; xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
> I admit I like the idea...but I don't know if it's practical
> to make it more general. For the basic tech-tree, most
> everything falls into fairly well defined categories...but
> enough items don't that I think it would defeat the purpose.
> And once the game is modded, and the tech tree starts to
> grow, I think it would be more of a hindrance than a help.
>
> -The Captain
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...]On
> Behalf Of Andrew Pokrovski
> Sent: December 3, 2003 8:36 PM
> To: xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
> Hi guys, I joined up a while back, but have been REALLY busy
> with coursework (in fact, still will be until the 16th, then
> I"m done for the semester).
>
> Anyway, I'd think it would be best to decouple an alien's
> rank from the race. It should make the XML parsing logic a
> little easier to follow, i.e. more object-oriented.
>
> With the compound value (<topic name="Sectoid Commander">),
> if you just wanted the rank you'd have to parse through the
> whole string (i.e.
> nameString->getSubstring(starting at "sectoid"->length+1, ending at
> nameString->string
> terminator))
>
> On the other hand, <topic name="sectoid" rank="commander">,
> you can presumably just call something like
> XMLtag->getParameter("rank") and let the XML parser do that.
>
> Computationally speaking, if we're writing our own XML
> parser, it shouldn't make that much of a difference in terms
> of effeciency, but it'll be a lot easier to understand the
> code if we separate rank from race. Similar things should go
> for other things, for example
>
> <topic category="laser" specifictype="rifle"> or
> <topic category="laser" specifictype="grenade>.
>
> Just kidding, there are no laser grenades. :)
>
> Andrew / "Nick Aragua"
>
> _________________________________________________________________
> Tired of slow downloads and busy signals? Get a high-speed
> Internet connection! Comparison-shop your local high-speed
> providers here. https://broadband.msn.com
>
>
>
> -------------------------------------------------------
> 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
>
>
>
>
> -------------------------------------------------------
> 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
>
>
> ---
> 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
|
|
From: mamutas <ma...@pr...> - 2003-12-08 05:57:32
|
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.
=20
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.
=20
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.
=20
Regards,
mamutas.
-----Original Message-----
From: Cpt. Boxershorts [mailto:cpt...@te...]=20
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:
=20
<!--Sectoid Commander-->
<topic name=3D"Sectoid" rank=3D"commander" researchtime=3D"1000">
=20
<prerequisite>
<Item name=3D"Sectoid" rank=3D"commander" /> //reference to Item list
</prerequisite>
=20
<researchbonus/>
=20
<grants>
<topic name=3D"Psi Lab"/>
</grants>
</topic>
=20
=20
=20
-----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.=20
Unfortunately, I do not think it is possible to refernce IDs between =
files,
but things might have been changed recently...
=20
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...]=20
Sent: Monday, December 01, 2003 7:32 PM
To: mamutas; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
=20
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.
=20
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?
=20
Basically, I'm asking if it would be:
=20
<topic name=3D"Sectiod Soldier"/>
=20
or
=20
<topic name =3D "Sectoid" rank=3D"Soldier"/>
=20
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)
=20
-The Captain
=20
=20
=20
=20
=20
-----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...]=20
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)?
=20
-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.
=20
I take a look at the structure of XML file and did not really checked =
the
dependencies between researcheable items.
=20
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.
=20
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?
=20
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?
=20
Here's a short sample, see the attachment for more detailed comments
=20
//Plasma Pistol
<topic name=3D"Plasma Pistol" researchtime=3D"100">
=20
<prerequisite>
<topic name=3D"Plasma Weapons" />
<item name=3D"Plasma Pistol" />
</prerequisite>
=20
<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=3D"Plasma Rifle" bonus=3D"5" />
<topic name=3D"Heavy Plasma" bonus=3D"5" />
</researchbonus>
=20
<filepaths>
<unresearched>/xnet/texts/unresearched/plasmapistol.rtf</unresearched> =
<xnet_image>/xnet/images/plasmapistol.3ds</xnet_image>=20
<xnet_text>/xnet/texts/weapons/plasmapistol.rtf</xnet_text>=20
</filepaths>
=20
<grants>
<item name=3D"Plasma Pistol"/>
</grants>
</topic>
=20
=20
=20
- 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
=20
|
|
From: mamutas <ma...@pr...> - 2003-12-08 05:45:27
|
Hi Nick,
You are making very valid comments and I agree with you 100%.
If there is a little chance that the string will be parsed, then the =
complex
string should be presented as two strings. But as I see it, the game =
code
will be very much interested in knowing whether the alien is a sectoid =
or
floater, so having two different string will be more beneficient.
As for writing our own XML parser, then I strongly discourage anyone to =
do
that. As much fun as it sounds, there are no reasons to reinvent the
bicycle: we will never write a compiler as fast and efficient as those
already present on the market before the end of this project. I =
recommend to
look at Xerces from Apache. I have not tried C++ version personally, but
their Java implementation is the best.
Regards,
Mamutas.
> -----Original Message-----
> From: xen...@li...=20
> [mailto:xen...@li...] On=20
> Behalf Of Andrew Pokrovski
> Sent: Wednesday, December 03, 2003 10:36 PM
> To: xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>=20
>=20
> Hi guys, I joined up a while back, but have been REALLY busy=20
> with coursework=20
> (in fact, still will be until the 16th, then I"m done for the=20
> semester).
>=20
> Anyway, I'd think it would be best to decouple an alien's=20
> rank from the=20
> race. It should make the XML parsing logic a little easier to=20
> follow, i.e.=20
> more object-oriented.
>=20
> With the compound value (<topic name=3D"Sectoid Commander">),=20
> if you just=20
> wanted the rank you'd have to parse through the whole string (i.e.=20
> nameString->getSubstring(starting at "sectoid"->length+1, ending at=20
> nameString->string
> terminator))
>=20
> On the other hand, <topic name=3D"sectoid" rank=3D"commander">, you =
can=20
> presumably just call something like=20
> XMLtag->getParameter("rank") and let the=20
> XML parser do that.
>=20
> Computationally speaking, if we're writing our own XML=20
> parser, it shouldn't=20
> make that much of a difference in terms of effeciency, but=20
> it'll be a lot=20
> easier to understand the code if we separate rank from race.=20
> Similar things=20
> should go for other things, for example
>=20
> <topic category=3D"laser" specifictype=3D"rifle"> or
> <topic category=3D"laser" specifictype=3D"grenade>.
>=20
> Just kidding, there are no laser grenades. :)
>=20
> Andrew / "Nick Aragua"
>=20
> _________________________________________________________________
> Tired of slow downloads and busy signals? Get a high-speed Internet=20
> connection! Comparison-shop your local high-speed providers here.=20
> https://broadband.msn.com
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive? Does it=20
> help you create better code? SHARE THE LOVE, and help us=20
> help YOU! Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> Xenocide-programming mailing list=20
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>=20
>=20
> ---
> 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
> =20
>=20
---
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
=20
|
|
From: Chris P. <chr...@ju...> - 2003-12-05 07:36:52
|
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 |
|
From: Ralph T. <ra...@em...> - 2003-12-04 11:39:54
|
Hello all!
If you dont know me then I will first introduce myself as this is my first mail to the mailing list!
My name is Wolfman, 22 yrs old, from the United Kingdom.
Disclaimers in first (hehe), this is the first time I have worked on a project such as this, and also the first time I have had my programming peer reviewed! I expect I have got a lot wrong, dont go easy on me, let me know what I did wrong and how I can do it better in the future!
By the way, I had a look at the doc containing the coding style pointers, but it didnt have anything regarding naming enumerations or structs. What is the correct way to do this?
Ok back on topic. Attached is a zip file containing 4 headers. These headers are all part of what I have called "StaticGeoData". If you think of a better name let me know!
The aim of the "StaticGeoData" class is to give the simulation engine any *static* data about the geosphere. By static I mean static in the sense of unchanging, not in the C++ sense of static. :)
Thus with the headers as I have given, the SE has to simply (Psuedoish code):
// When initialising
StaticGeoData *sgd = new StaticGeoData();
if(sgd->loadData("./data/earth.blah") != 0)
anERROR();
// When using
StaticGeoDataStruct *data = sgd->getData(x, y);
if(data->terrainType == OCEAN)
....
else
....
// end
Simple eh? The tricky bit is the StaticGeoData class itself. When loading the data it has to convert it all from whatever format and coordinate system into the coordinate system and format that the SE can handle.
Here is what I propose to do for each type of data that the SE will need:
1) Terrain
I suggest that the terrain (like RK said) should be loaded up in the form of a Quad Tree, based upon a texture map. This has several advantages. Once loaded it is quick and easy to find the terrain for a given x,y. It is also possible to tailer the amount of memory used by the quad tree by adjusting how it tests to see if a region is homogeneous. For example, if you want it to use lots of memory, simply only say a region is homogeneous if all pixels in the region are the same type. However, if you want to use less memory say that only 2/3 of the pixels have to be the same type.
2) Countries & Cities.
I thought quite a lot on this, and the system I came up with was this. There is an XML file that describes a list of countries. This is simply the name of the country, a unique colour (You will see in a moment), a list of cities within that country, and any other information that will be needed for further versions. The cities have an X,Y coord (or whatever other coord type we will use for the cities - ie spherical?). Perhaps whoever is doing the code for drawing the geoscape should decide if countries & cities are going to be drawn, if so they might want to adjust the XML format accordingly??
When loading the countries, the XML file is parsed, and a list of GeoCountrys and GeoCitys are constructed. Then what I propose happens is that another quad tree is constructed, this time from a seperate special texture that has each country individualy coloured. As the quad tree is constructed it looks up in the list of countries to see which country corresponds to which colour.
The reason I think a quad tree would be good for this as well as the terrain is that it has all the advantages of the quad trees, plus the fact that no vector data, or any other format is needed. Of course there are other solutions, if you have one feel free to suggest and we can discuss!
There we go, a bit longer than I meant, but if you still have any questions feel free to drop me a line!
-wolfman
P.S Sorry RedKnight, it was a bit longer than a day to do this because I have just got broadband after being on a 56k for so long I went on a bit of a download and online gaming frenzy. :)
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
|
|
From: Cpt. B. <cpt...@te...> - 2003-12-04 06:21:33
|
I admit I like the idea...but I don't know if it's practical to make it more
general. For the basic tech-tree, most everything falls into fairly well
defined categories...but enough items don't that I think it would defeat the
purpose. And once the game is modded, and the tech tree starts to grow, I
think it would be more of a hindrance than a help.
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
Andrew Pokrovski
Sent: December 3, 2003 8:36 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Hi guys, I joined up a while back, but have been REALLY busy with coursework
(in fact, still will be until the 16th, then I"m done for the semester).
Anyway, I'd think it would be best to decouple an alien's rank from the
race. It should make the XML parsing logic a little easier to follow, i.e.
more object-oriented.
With the compound value (<topic name="Sectoid Commander">), if you just
wanted the rank you'd have to parse through the whole string (i.e.
nameString->getSubstring(starting at "sectoid"->length+1, ending at string
terminator))
On the other hand, <topic name="sectoid" rank="commander">, you can
presumably just call something like XMLtag->getParameter("rank") and let the
XML parser do that.
Computationally speaking, if we're writing our own XML parser, it shouldn't
make that much of a difference in terms of effeciency, but it'll be a lot
easier to understand the code if we separate rank from race. Similar things
should go for other things, for example
<topic category="laser" specifictype="rifle"> or
<topic category="laser" specifictype="grenade>.
Just kidding, there are no laser grenades. :)
Andrew / "Nick Aragua"
_________________________________________________________________
Tired of slow downloads and busy signals? Get a high-speed Internet
connection! Comparison-shop your local high-speed providers here.
https://broadband.msn.com
-------------------------------------------------------
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
|
|
From: Cpt. B. <cpt...@te...> - 2003-12-04 06:08:38
|
MessageIt'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
|
|
From: Andrew P. <a_p...@ho...> - 2003-12-04 04:36:03
|
Hi guys, I joined up a while back, but have been REALLY busy with coursework
(in fact, still will be until the 16th, then I"m done for the semester).
Anyway, I'd think it would be best to decouple an alien's rank from the
race. It should make the XML parsing logic a little easier to follow, i.e.
more object-oriented.
With the compound value (<topic name="Sectoid Commander">), if you just
wanted the rank you'd have to parse through the whole string (i.e.
nameString->getSubstring(starting at "sectoid"->length+1, ending at string
terminator))
On the other hand, <topic name="sectoid" rank="commander">, you can
presumably just call something like XMLtag->getParameter("rank") and let the
XML parser do that.
Computationally speaking, if we're writing our own XML parser, it shouldn't
make that much of a difference in terms of effeciency, but it'll be a lot
easier to understand the code if we separate rank from race. Similar things
should go for other things, for example
<topic category="laser" specifictype="rifle"> or
<topic category="laser" specifictype="grenade>.
Just kidding, there are no laser grenades. :)
Andrew / "Nick Aragua"
_________________________________________________________________
Tired of slow downloads and busy signals? Get a high-speed Internet
connection! Comparison-shop your local high-speed providers here.
https://broadband.msn.com
|
|
From: mamutas <ma...@pr...> - 2003-12-04 04:32:04
|
Yeah, that is exactly what I was suggesting.=20
Unfortunately, I do not think it is possible to refernce IDs between =
files,
but things might have been changed recently...
=20
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...]=20
Sent: Monday, December 01, 2003 7:32 PM
To: mamutas; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
=20
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.
=20
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?
=20
Basically, I'm asking if it would be:
=20
<topic name=3D"Sectiod Soldier"/>
=20
or
=20
<topic name =3D "Sectoid" rank=3D"Soldier"/>
=20
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)
=20
-The Captain
=20
=20
=20
=20
=20
-----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...]=20
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)?
=20
-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.
=20
I take a look at the structure of XML file and did not really checked =
the
dependencies between researcheable items.
=20
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.
=20
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?
=20
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?
=20
Here's a short sample, see the attachment for more detailed comments
=20
//Plasma Pistol
<topic name=3D"Plasma Pistol" researchtime=3D"100">
=20
<prerequisite>
<topic name=3D"Plasma Weapons" />
<item name=3D"Plasma Pistol" />
</prerequisite>
=20
<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=3D"Plasma Rifle" bonus=3D"5" />
<topic name=3D"Heavy Plasma" bonus=3D"5" />
</researchbonus>
=20
<filepaths>
<unresearched>/xnet/texts/unresearched/plasmapistol.rtf</unresearched> =
<xnet_image>/xnet/images/plasmapistol.3ds</xnet_image>=20
<xnet_text>/xnet/texts/weapons/plasmapistol.rtf</xnet_text>=20
</filepaths>
=20
<grants>
<item name=3D"Plasma Pistol"/>
</grants>
</topic>
=20
=20
=20
- 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
=20
|
|
From: Cpt. B. <cpt...@te...> - 2003-12-04 01:12:27
|
Message/*
It looks like my first reply to this message got eaten when I changed my
email address, so here it again. I apologize if this ends up as a
duplicate.
*/
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: xen...@li...
[mailto:xen...@li...]On Behalf Of
mamutas
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
|
|
From: Cpt. B. <cpt...@te...> - 2003-12-02 22:00:46
|
MessageI'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
|
58 messages has been excluded from this view by a project administrator.
