RE: [Xenocide-programming] Tech Tree XML layout

[mamutas <ma...@pr...>]

I was asking about some example of situation where obsoleteness of topics
would be more than just confirmation of their research. You crissalid
example was exactly what I wanted to see. 
Although, I personally would not want to introduce such trecheraus reseach
topics in the game :), I understand your point and agree that obsoletness
should be defined in the XML file, rather than hardcoded.

Regards, 
mamutas

>-----Original Message-----
>From: Cpt. Boxershorts [mailto:cpt...@te...] 
>Sent: Thursday, December 18, 2003 10:05 PM
>To: mamutas; 'Andrew Pokrovski'; 
>xen...@li...
>Cc: br...@pr...
>Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
>I'm not quite sure what you're asking about...the use of the 
>'obsoletes' tag?  Maybe we're not understanding each other.  
>I'll explain how I envisioned the 'obsoletes' tag being used 
>(both now, and in the future), and then I'll try to answer 
>your question as I understand it.
>
>Expanded Explanation:
>
>For v1, the 'obsoletes' tag in most topics would simply point 
>back to itself.  It's sole use would be to tell the code that 
>this node should be blocked from further (repeat) research.  
>It only affects the list of researchable topics...any 
>technologies or items resulting from the topic are still available.
>
>Basic example, once 'Plasma Pistol' is researched, it becomes 
>an obsolete topic.  While the item 'Plasma Pistol' is (for 
>obvious reasons) available, the research topic itself is 
>blocked from the list.
>
>A topic such as an alien engineer or medic (as discussed) is 
>more complicated, and would require the use of 'or' tags 
>within the 'obsoletes' tags.  This topic would only be blocked 
>from the list when all of the 'or' criteria were satisfied.
>
>For future versions of the game, the 'obsoletes' tag could be 
>used to block branches of the research tree (similar to the 
>bug in TTFD, only deliberately).
>
>Example (based on ideas proposed in the "Chryssalid Research" 
>thread in the
>lab): Capturing a live Chryssalid might give you two new 
>research topics: 'alien bio weapons' (i.e.: using x-corps 
>controlled chryssalids in combat), and the basic Chryssilid 
>topic. If you research 'Alien Bio Weapons', you can breed 
>Chyssilids in your base for use in combat...which, before you 
>can use them, break out and terrorize your base.  On the other 
>hand, if you researched the Chryssilid itself first, you'd get 
>a note at the end stating something like "While originally 
>there was though of turning these creatures against their 
>former masters, these monsters are too dangerous and powerful 
>to interact with in anything other than the most controlled of 
>circumstances.", whereupon the Topic 'Alien Bio Weapons' is 
>removed from your research topics, preventing the above 
>scenario from occurring.
>
>If it's hardcoded so that a researched node can only remove 
>itself, then scenarios like the above (and I'm sure there are 
>more creative people than I out there, who could come up with 
>better ideas) would be impossible.
>
>
>
>You asked about topics that do not produce any results?  
>Effectively, a dead-end topic that does nothing other than 
>give you research points on your score, correct?  Most of the 
>alien base equipment (Alien Food, Alien Entertainment, etc.) 
>are just dead ends...all they give you is a quick blurb, with 
>no other topics or items becoming available.
>
>Is that what you were asking?
>
>
>-The Captain
>
>
>
>
>
>
>
>-----Original Message-----
>From: mamutas [mailto:ma...@pr...]
>Sent: December 18, 2003 7:27 PM
>To: 'Cpt. Boxershorts'; 'Andrew Pokrovski'; 
>xen...@li...
>Cc: br...@pr...
>Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
>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
>
>
>
>
>
>
>---
>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