RE: [Xenocide-programming] Tech Tree XML layout

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

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