RE: [Xenocide-programming] Tech Tree XML layout

[Cpt. B. <cpt...@te...>]

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