Menu
▾
▴
xenocide-programming
|
From: <red...@pr...> - 2003-11-28 18:44:00
Attachments:
technology.zip
|
Captain, this is the furthest that anyone have gone with the technology tree tech layout, it is a little complex by now... Remember our designs follow the principle: "Simplicity is the key to understanding" in short the KISS principle (Keep It Simple Stupid principle)... Hope this can help you. Greetings Red Knight |
|
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: 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: 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: 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: 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: 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: 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 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: 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: 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 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: 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: 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-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-19 04:01:00
|
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 |
|
From: mamutas <ma...@pr...> - 2003-12-19 04:12:51
|
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 |
|
From: Cpt. B. <cpt...@te...> - 2003-12-19 07:51:18
|
Glad we could get it worked out, Mamutas...I got worried we were talking in circles. I end up that way with my boss all time, and it drives me nuts. :P Okay, so here's the current tech tree layout, as per all the discussions over the past few weeks. If everybody likes it, I'll start working on a more complete, online version so people can step through it. I did have dtd for this, but it seems to have wandered off. -The Captain <research_topics> <!--Plasma Weapons --> <topic name="Plasma Weapons" researchtime="200" > <!--general topic element. idname = name of topic researchtime = scientist hours required to research this topic --> <prerequisite> <!--items and/or topics required to research this topic --> <topic/> <!--Required topic to have researched --> <item/> <!--required item (must have in inventory). This can be any item: equipment, aliens (dead or alive), components, etc. --> <or><!--or-items allow for needing any one of several items as a prerequiste --> <item name="Plasma Pistol"/> <item name="Plasma Rifle"/> <item name="Heavy Plasma"/> </or> </prerequisite> <!--If certain optional topics have been researched, a percentage reduction in research hours may be available required prerequisites SHOULD NOT grant bonuses this allows better control of the research tree --> <researchbonus/> <grants> idtopics and items made available by researching this topic. Better name? Note: anything in here must satisfy its own list of prerequistes. This topic should be a prerequisite of any item in this list--> <topic name="Plasma Pistol"/> <!--topics that can now be searched. --> <topic name="Plasma Pistol Clip"/> <topic name="Plasma Rifle"/> <topic name="Plasma Rifle Clip"/> <topic name="Heavy Plasma"/> <topic name="Heavy Plasma Clip"/> <item/> <!--Items that can now be manufactured and/or used (equipment, weapons, base facilities, etc.) --> <xor> <!-- topics that may become available, depending on prior research, and in-game factors. Only one of these topics will become available for any given research instance --> <topic/> </xor> </grants> <obsoletes> <!-- Topics only. Once the parent is researched, any topics listed here cannot be researched. --> <topic name="Plasma Weapons"/> <!-- For Xenocide v1, this will only contain a reference to the parent topic --> </obsoletes> </topic> </research_topics> -----Original Message----- From: mamutas [mailto:ma...@pr...] Sent: December 18, 2003 8:13 PM To: 'Cpt. Boxershorts'; 'Andrew Pokrovski'; xen...@li... Cc: br...@pr... Subject: RE: [Xenocide-programming] Tech Tree XML layout 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 |
|
From: <red...@pr...> - 2003-12-19 14:50:59
|
Hi I am back from near death (not really), and ready to spice up this discussion (not really :P ). First, Cpt. try to avoid using underscores in tags like this: research_topics use researchtopics or just research. Another thing is that, when we originally think about the XML file with ShadowHawk (not ShadowHawk00) the idea of the obsolete was to just flag some items (only) to be grayed out - or put in an special place all toghether to easy up the interface only. Just as a hint (it is obsolete) if you really want to manufacture it, go find it in the obsoletes list. However I left you argue on it because you found a very intriguing way to use the obsolete clause, and I wanted to see where you will take that concept. So now that the discussion is over the original meaning was that, but dont worry, that was only for clarification. Greetings Red Knight Quoting "Cpt. Boxershorts" <cpt...@te...>: > Glad we could get it worked out, Mamutas...I got worried we were talking in > circles. I end up that way with my boss all time, and it drives me nuts. > :P > > Okay, so here's the current tech tree layout, as per all the discussions > over the past few weeks. If everybody likes it, I'll start working on a > more complete, online version so people can step through it. I did have dtd > for this, but it seems to have wandered off. > > -The Captain > > <research_topics> > > <!--Plasma Weapons --> > <topic name="Plasma Weapons" researchtime="200" > <!--general topic > element. > idname = name of topic > researchtime = scientist hours required to research this topic --> > > <prerequisite> <!--items and/or topics required to research this topic --> > <topic/> <!--Required topic to have researched --> > <item/> <!--required item (must have in inventory). > This can be any item: equipment, aliens (dead or alive), components, > etc. --> > > <or><!--or-items allow for needing any one of several items as a > prerequiste --> > <item name="Plasma Pistol"/> > <item name="Plasma Rifle"/> > <item name="Heavy Plasma"/> > </or> > </prerequisite> > > <!--If certain optional topics have been researched, a percentage > reduction in research hours may be available > required prerequisites SHOULD NOT grant bonuses > this allows better control of the research tree --> > <researchbonus/> > > <grants> idtopics and items made available by researching this topic. > Better name? > Note: anything in here must satisfy its own list of prerequistes. > This topic should be a prerequisite of any item in this list--> > <topic name="Plasma Pistol"/> <!--topics that can now be > searched. --> > <topic name="Plasma Pistol Clip"/> > <topic name="Plasma Rifle"/> > <topic name="Plasma Rifle Clip"/> > <topic name="Heavy Plasma"/> > <topic name="Heavy Plasma Clip"/> > > <item/> <!--Items that can now be manufactured and/or used (equipment, > weapons, base facilities, etc.) --> > > <xor> <!-- topics that may become available, depending on prior research, > and in-game factors. > Only one of these topics will become available for any given research > instance --> > <topic/> > </xor> > </grants> > > <obsoletes> <!-- Topics only. Once the parent is researched, any topics > listed here cannot be researched. --> > <topic name="Plasma Weapons"/> <!-- For Xenocide v1, this will only > contain a reference to the parent topic --> > </obsoletes> > > </topic> > </research_topics> |
|
From: Cpt. B. <cpt...@te...> - 2003-12-23 21:15:27
|
Hey all,
I just finished typing up the original x-com research tree in the format
decided on below, and I ran into a few things regarding <grants> and
<obsoletes>.
1. Under the <grants>, we have <item> and <topic> elements. <item> points to
an item that the player can now utilise/build/whatever. <topic> points to
another research topic in the same table that is now available for
research(dependent on prerequisites, of course). However, NOTHING points to
the entry in the xnet table. Are we relying on the name of the topic being
the same as the xnet entry?
The problem is, the xnet title "Sectoid Interrogation" (the default sectoid
race data a player gets from any sectoid) is not really an 'item' per se,
and name of the research topics ("Sectoid Soldier", Sectoid Engineer", etc.)
that you can get this from can't correspond to the xnet title (because the
have different names). Excerpt from "Sectoid Soldier" record:
<grants>
<topic name="Alien Origins"/>
<item name="Sectoid Interrogation"/>
</grants>
I would feel better with an explicit reference (effectively a foreign key)
to the xnet table, as in the example below. This would have to apply to all
research topic records though, it might get a bit redundant looking for a
lot of it. It does allow more flexibility though, so rather than researching
"Plasma Cannon" to get the xnet entry 'Plasma Cannon', you can research
"Vehicle Mounted Plasma Weapons" to get 'Plasma Cannon'.
<grants>
<topic name="Alien Origins"/>
<xnet name="Sectoid Interrogation"/>
</grants>
2. Also within <grants>, we have the <xor> tag to allow for any one of
multiple research conclusions (as in Alien Engineers). When writing up the
Sectoid Leader and Commander entries, Something new came up. Below is the
<grants> from the Sectiod Leader record.
<grants>
<topic name="Alien Origins"/>
<item name="Sectoid Interrogation"/>
<xor>
<topic name="Psi Lab"/>
<topic name="The Martian Solution"/>
<item name="Alien Supply" />
<item name="Alien Research" />
<item name="Alien Harvest" />
<item name="Alien Abduction" />
<item name="Alien Infiltration" />
<item name="Alien Base" />
<item name="Alien Terror" />
<item name="Alien Retaliation" />
</xor>
</grants>
To break it down, any live alien will give "Alien Origins", so that will
always show up. Any live sectoid will give the xnet entry for "Sectoid
Interrogation". However, a Sectoid Leader can give not only tactical data
(i.e.: the missions) but info for Psi Labs or The Martian Solution. I'm
pretty sure we don't want the same leader giving up ALL of these topics on a
single researching.
I had a couple thoughts on how to settle this. First, is put it in the
business rules (hardcode it) so that topics within an <xor> tag have a
higher priority than pure research ('item' tags). That way any available
topics will be discovered before the tactical data.
Next is just a variation of the first. Have the order in which elements are
listed in the <xor> tags determine priority. So the above example would
give you the topics first, but this:
<xor>
<item name="Alien Supply" />
<topic name="Psi Lab"/>
<topic name="The Martian Solution"/>
<item name="Alien Research" />
<item name="Alien Harvest" />
<item name="Alien Abduction" />
<item name="Alien Infiltration" />
<item name="Alien Base" />
<item name="Alien Terror" />
<item name="Alien Retaliation" />
</xor>
would give you the topics only after 'Alien Supply'. (just an example..not
one that makes sense)
The other thought makes it a bit more complicated, but again allows for more
flexibility. Add a 'priority' (values 1-10) attribute to each element
inside of <xor> tags. That way should a future version want something to
appear before a topic, it can be done without extensive rewriting. However,
it's one more thing for the code to keep track of.
3. Related to the use of <xor> tags in the <grants> field, I'd like to put
them in the <obsoletes> field as well. That way it's easier to code for
whether or not to just remove the topic right away.
The current method would require the code to always check the <grants> field
for unresolved <xor> elements (whether there were <xor> elements or not).
It's not a huge deal, but it's an extra step. It also blocks the use of
multiple topics under obsoletes (it's an all-or-nothing deal).
So rather than:
<obsoletes>
<topic name="Sectoid Leader"/>
</obsoletes>
it would read:
<obsoletes>
<xor>
<topic name="Sectoid Leader"/>
</xor>
</obsoletes>
Ideas, thoughts, comments on any of this?
Merry Christmas!
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
red...@pr...
Sent: December 19, 2003 6:50 AM
To: xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Hi I am back from near death (not really), and ready to spice up this
discussion (not really :P ).
First, Cpt. try to avoid using underscores in tags like this:
research_topics
use researchtopics or just research. Another thing is that, when we
originally
think about the XML file with ShadowHawk (not ShadowHawk00) the idea of the
obsolete was to just flag some items (only) to be grayed out - or put in an
special place all toghether to easy up the interface only. Just as a hint
(it
is obsolete) if you really want to manufacture it, go find it in the
obsoletes
list. However I left you argue on it because you found a very intriguing way
to use the obsolete clause, and I wanted to see where you will take that
concept. So now that the discussion is over the original meaning was that,
but
dont worry, that was only for clarification.
Greetings
Red Knight
Quoting "Cpt. Boxershorts" <cpt...@te...>:
> Glad we could get it worked out, Mamutas...I got worried we were talking
in
> circles. I end up that way with my boss all time, and it drives me nuts.
> :P
>
> Okay, so here's the current tech tree layout, as per all the discussions
> over the past few weeks. If everybody likes it, I'll start working on a
> more complete, online version so people can step through it. I did have
dtd
> for this, but it seems to have wandered off.
>
> -The Captain
>
> <research_topics>
>
> <!--Plasma Weapons -->
> <topic name="Plasma Weapons" researchtime="200" > <!--general topic
> element.
> idname = name of topic
> researchtime = scientist hours required to research this topic -->
>
> <prerequisite> <!--items and/or topics required to research
this topic -->
> <topic/> <!--Required topic to have researched -->
> <item/> <!--required item (must have in inventory).
> This can be any item: equipment,
aliens (dead or alive), components,
> etc. -->
>
> <or><!--or-items allow for needing any one of several
items as a
> prerequiste -->
> <item name="Plasma Pistol"/>
> <item name="Plasma Rifle"/>
> <item name="Heavy Plasma"/>
> </or>
> </prerequisite>
>
> <!--If certain optional topics have been researched, a
percentage
> reduction in research hours may be available
> required prerequisites SHOULD NOT grant bonuses
> this allows better control of the research tree -->
> <researchbonus/>
>
> <grants> idtopics and items made available by researching this
topic.
> Better name?
> Note: anything in here must satisfy its own list of
prerequistes.
> This topic should be a prerequisite of any item in
this list-->
> <topic name="Plasma Pistol"/> <!--topics that can now
be
> searched. -->
> <topic name="Plasma Pistol Clip"/>
> <topic name="Plasma Rifle"/>
> <topic name="Plasma Rifle Clip"/>
> <topic name="Heavy Plasma"/>
> <topic name="Heavy Plasma Clip"/>
>
> <item/> <!--Items that can now be manufactured and/or
used (equipment,
> weapons, base facilities, etc.) -->
>
> <xor> <!-- topics that may become available, depending
on prior research,
> and in-game factors.
> Only one of these topics will become
available for any given research
> instance -->
> <topic/>
> </xor>
> </grants>
>
> <obsoletes> <!-- Topics only. Once the parent is researched,
any topics
> listed here cannot be researched. -->
> <topic name="Plasma Weapons"/> <!-- For Xenocide v1,
this will only
> contain a reference to the parent topic -->
> </obsoletes>
>
> </topic>
> </research_topics>
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
|
From: Andrew P. <a_p...@ho...> - 2003-12-24 04:38:58
|
Good idea on all counts. An explicit reference to an X-Net entry will allow revealing of multiple entries. Order of priority on the entries within an XOR tag is also good, though some bookkeeping will have to be done in any case. I don't mind in principle being able to obsolete multiple researches, though I can't currently see any practical use for it (but eh, we might need it later :). Have you thought about trying to come up with an XSD so that we can validate XML data files? You can probably generate the XSD backwards from an XML entry using XMLspy or the Microsoft XML tool (I forget what it's called). Andrew _________________________________________________________________ Make your home warm and cozy this winter with tips from MSN House & Home. http://special.msn.com/home/warmhome.armx |
|
From: Vlad J. <vj...@au...> - 2003-12-27 06:05:22
|
I agree on idea to provide links to xnet entries - that would be very useful to keep research and XNet DB in sync. As regarding the order, then I suggest to use a 'priority' attribute instead. A person tends to forget that some items are order sensitive when most of them aren't. I did some research on XML parsers and talking with RK about it as I type now. I strongly suggest we would choose an XML parser which would support validation of XML content against DTD (we could use an XML schemas, but those are a bit harder to create manually and I am not aware about good IDEs for that, which would not cost a fortune. But that does not mean there are not. :) ) So, that said, TinyXML and eXpat are out of choice since none of them is validating. Xerces is still in the game, but it is disliked because of it weight. So, position is still open. We need to look more. Any suggestions? Regards, Mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Andrew Pokrovski Sent: Tuesday, December 23, 2003 10:39 PM To: xen...@li... Subject: RE: [Xenocide-programming] Tech Tree XML layout Good idea on all counts. An explicit reference to an X-Net entry will allow revealing of multiple entries. Order of priority on the entries within an XOR tag is also good, though some bookkeeping will have to be done in any case. I don't mind in principle being able to obsolete multiple researches, though I can't currently see any practical use for it (but eh, we might need it later :). Have you thought about trying to come up with an XSD so that we can validate XML data files? You can probably generate the XSD backwards from an XML entry using XMLspy or the Microsoft XML tool (I forget what it's called). Andrew _________________________________________________________________ Make your home warm and cozy this winter with tips from MSN House & Home. http://special.msn.com/home/warmhome.armx ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ 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.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: Cpt. B. <cpt...@te...> - 2003-12-28 06:09:20
Attachments:
TechTree v0.xml
|
Since everyone liked my suggestions, I've implemented them on my copy of the x-com tech tree, and included them in the dtd. As I was doing to the revisions, I had another thought that I put in as well, (it can be easily taken out if no one likes it): a 'mission' flag, currently under the "Cydonia or Bust" topic, so that the program will know that a special mission can be undertaken at the completion of a research topic. I thought that a flag would be better than hardcoding to look for a particular research topic. It also allows for more special missions beyond just the finale, in future versions. SO here's what the entry looks like: <!-- Cydonia or Bust --> <topic name="Cydonia or Bust" researchtime="300"> <prerequisite> <or> <topic name="Sectoid Commander" /> <topic name="Floater Commander" /> <topic name="Muton Commander" /> <topic name="Snakeman Commander" /> <topic name="Ethereal Commander" /> </or> </prerequisite> <researchbonus /> <grants> <mission name="Cydonia" /> </grants> <obsoletes> <topic name="Cydonia or Bust" /> </obsoletes> </topic> I'm also including the complete file, with dtd. I've never written a dtd before, so if someone could double check me, I'd appreciate it. This file only has sectoids, rather than all the aliens (since it's mostly just for demonstration. -the Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...]On Behalf Of Vlad Judys Sent: December 26, 2003 10:05 PM To: xen...@li... Subject: RE: [Xenocide-programming] Tech Tree XML layout I agree on idea to provide links to xnet entries - that would be very useful to keep research and XNet DB in sync. As regarding the order, then I suggest to use a 'priority' attribute instead. A person tends to forget that some items are order sensitive when most of them aren't. I did some research on XML parsers and talking with RK about it as I type now. I strongly suggest we would choose an XML parser which would support validation of XML content against DTD (we could use an XML schemas, but those are a bit harder to create manually and I am not aware about good IDEs for that, which would not cost a fortune. But that does not mean there are not. :) ) So, that said, TinyXML and eXpat are out of choice since none of them is validating. Xerces is still in the game, but it is disliked because of it weight. So, position is still open. We need to look more. Any suggestions? Regards, Mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Andrew Pokrovski Sent: Tuesday, December 23, 2003 10:39 PM To: xen...@li... Subject: RE: [Xenocide-programming] Tech Tree XML layout Good idea on all counts. An explicit reference to an X-Net entry will allow revealing of multiple entries. Order of priority on the entries within an XOR tag is also good, though some bookkeeping will have to be done in any case. I don't mind in principle being able to obsolete multiple researches, though I can't currently see any practical use for it (but eh, we might need it later :). Have you thought about trying to come up with an XSD so that we can validate XML data files? You can probably generate the XSD backwards from an XML entry using XMLspy or the Microsoft XML tool (I forget what it's called). Andrew _________________________________________________________________ Make your home warm and cozy this winter with tips from MSN House & Home. http://special.msn.com/home/warmhome.armx ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ 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.556 / Virus Database: 348 - Release Date: 12/26/2003 ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Vlad J. <vj...@au...> - 2003-12-29 04:16:18
|
Captain, I really liked the idea about adding missions. As you said that would allow us to open some specific missions if some conditions met. Another observation. The XML format you have created is suitable for "priming" the game. That is, the game code will read it and initialize internal state of some research management object. I imagine the whole tree will be kept in the memory and the object will check the nodes to determine what actions to take. But what about saved games? When player will save the game, the whole research tree state (topics researched, the progress on current topic, etc.) must be saved as well. Then why couldn't we use the same format? It will fit the purpose, except that it misses the variable to reflect that state. What if you would add such variables? I think that 'topic' should have a Boolean variable to indicate whether it is researched or not, then another Boolean to indicate whether it is under research now or not, and then some integer to indicate the progress made (that is in case only when the topic is under research now)? What do you think? Anyway, the great job is done. Although, I take it is not complete yet as I have found couple oddities myself: 1) "Tank/Laser" topic is missing; 2) "Laser Rifle" prereqs a "Laser Pistol" although as far as I remember it should prereq only "Laser Weapons". It would be nice if someone from our X-Com gurus (Stewart, Micah, STJones, others ???) would go other that file and make sure that its content is correct. Again, it is really great job. I like what I see. Regards, mamutas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: Cpt. B. <cpt...@te...> - 2003-12-29 06:27:41
|
Hi Mamutas,
You're right, this layout is primarily designed for program initialization,
rather than active games. I agree, I think it could work as a save game
too (and it's better to have just the one format to parse). Is the research
tree going to be loaded into some form of database table, or just kept in
xml node format?
For the saved game version, rather than several fields, why just a single
numeric 'amount completed' field? As I see it, knowing whether a topic has
been researched is the most important (must be quick/easy to find out)
factor. 'amount completed' has values ranging from zero to the topic's
researchtime property. This way, we keep the exact number of hours
researched, and finding out if the topic is complete is a simple calculation
('researchhours' = 'amountcompleted').
Possible values for 'amountcompleted' work out as follows:
0 = Not started.
1 to (topic.researchhours - 1) = Started, but incomplete.
topic.researchhours (max value) = complete
Just to simplify it, maybe 'completed' status should be ('researchhours' <=
'amountcompleted'), rather than equals. That would save alot of headaches
in calculating research hours.
Would it need a variable for where (which lab/base it's being researched at)
as well? It might need to wait until the savegame layout for bases is done,
although we could always just put in a stub.
To answoer your other questions, what I sent out is not really for xenocide
per se...it's just a sample of the layout applied to the x-com tree so that
everyone has a common frame of reference. The xenocide tree already has a
couple of differences in it (a 'Plasma Technology' node, for one). Once the
format is settled, I'll write a xenocide version of the simple tree, as well
as a few variations I'd like to suggest. The main reason I undertook this
was to show off the variants discussed in the 'Technology' workshop on a
webpage (it seemed easier to use the official layout than make one of my
own, and then I discovered it was incomplete).
I hate to say this, but I managed to lose the version I sent out :P Could
you please send me a copy back? Thanks!
-The Captain
-----Original Message-----
From: Vlad Judys [mailto:vj...@au...]
Sent: Sunday, December 28, 2003 8:16 PM
To: 'Cpt. Boxershorts'; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Captain,
I really liked the idea about adding missions. As you said that would allow
us to open some specific missions if some conditions met.
Another observation.
The XML format you have created is suitable for "priming" the game. That is,
the game code will read it and initialize internal state of some research
management object. I imagine the whole tree will be kept in the memory and
the object will check the nodes to determine what actions to take.
But what about saved games? When player will save the game, the whole
research tree state (topics researched, the progress on current topic, etc.)
must be saved as well. Then why couldn't we use the same format? It will fit
the purpose, except that it misses the variable to reflect that state.
What if you would add such variables? I think that 'topic' should have a
Boolean variable to indicate whether it is researched or not, then another
Boolean to indicate whether it is under research now or not, and then some
integer to indicate the progress made (that is in case only when the topic
is under research now)? What do you think?
Anyway, the great job is done.
Although, I take it is not complete yet as I have found couple oddities
myself:
1) "Tank/Laser" topic is missing;
2) "Laser Rifle" prereqs a "Laser Pistol" although as far as I remember it
should prereq only "Laser Weapons".
It would be nice if someone from our X-Com gurus (Stewart, Micah, STJones,
others ???) would go other that file and make sure that its content is
correct.
Again, it is really great job. I like what I see.
Regards,
mamutas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
|
Thanks for helping keep SourceForge clean.
X