Menu
▾
▴
xenocide-programming — The Programming Xenocide Mailing List
You can subscribe to this list here.
| 2003 |
Jan
(9) |
Feb
(6) |
Mar
|
Apr
(2) |
May
|
Jun
(4) |
Jul
(19) |
Aug
(18) |
Sep
(11) |
Oct
(14) |
Nov
(16) |
Dec
(50) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(42) |
Feb
(39) |
Mar
(66) |
Apr
(26) |
May
(32) |
Jun
(21) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mamutas P. <ma...@pr...> - 2004-01-03 04:46:48
|
Let me explain my idea a bit more. It might look similar to adding controls in Java's GridBagLayout, so if you are familiar with that, then you are on the fast track. :) Lets take an soldier as an example. He has following containers (not exactly like in the game, but enough for that example): left pocket, right pocket, backpack, belt. When soldier object is created, it will contain enumeration of those containers. When containers are created, each of them will be created with ContainerConstraint object, permanently attached to container. So, in our example containers might have following constraints: Container name Width Height Max Items Max Weight Type left pocket 1 2 2 10 Handheld right pocket 1 2 2 10 Handheld belt 6 1 6 20 Weapon backpack 3 4 12 100 ICarriable So, in this case if player would try to add an object with size 3x2 in his pocket, that object will not fit and the request to add will be denied. However, such object will fit easily in backpack. And... Wait a minute! Now, it occurred to me that there is a problem with layout: we need to keep track of what cells are occupied already. And we need to provide the interface for player to choose cells explicitly. So, it looks like the best way is to go with sort of table, which would describe each cell in addition to total limitations (weight, type, etc.). Well, in that case we need to assign a grid description to each container. Each cell will keep reference of the object it is storing, but the whole grid will manage weigh/type and other global parameter limitations. 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: Jeffrey W. <je...@ca...> - 2004-01-03 03:38:23
|
I agree with the idea of containers. However, the exact implementation
of this is a bit unclear to me. I've seen some games that use
dimensions, PlanetSide or MechWarrior for example. A soldier is capable
of carrying 2 units x 4 units. A pistol would be 1u x 1u, and a rifle
1u x 2u. A larger vehicle would be capable of carrying 15u x 10u. A
large object that a soldier cannot carry would have dimensions larger
than a soldier's capacity, 3u x 2u for example. This enforces the
restrictions on who can carry what and also enforces the maximum
capacity of a unit.
How this is implemented is up to the programmers, but that's an idea for
the container system.
-mindstorm
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
ma...@pr...
Sent: Thursday, January 01, 2004 10:26 AM
To: red...@pr...;
xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hello Xenocide Programmers,
I liked RK's idea about containers. It might complicate things a bit,
but
what if ICarrier interface will server the only one purpose - the
container
management?
For example, each object which is ICarrier will have number of
containers
able to hold ICarriable objects. ICarrier will provide methods to
enumerate
the containers as well as to access them by number or name.
So soldiers will have many containers (hands, pockets, backpack, mouth
:),
etc.); transports will have one container for all their cargo; armed
crafts
will have containers for their weapons.
And here is the point: each container will have an object
ContainerConstraint. This object will describe the containers and will
be
responsible to provide yes/no for requests to put the item in the
container.
ContainerConstraint will have following variables for example:
- size (width and height, or something more sophisticated if container
is
not rectangular);
- max number of items;
- max weight of items;
- type of items (craft weapons only or any handheld weapons only, etc.)
The container itself will keep values of current content, so there are
no
such varialbles like current number/weight of items in the
ContainerCOnstraint object.
So, in RK's example below hand->addObject() method would call
ContainerConstraint object to verify that Object is acceptable.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 9:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for
carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them
as
long
as the weight do pass over an specified ammount. On the other side
Soldiers
do
mind the real proportions and the specific place in where you put them.
That
makes the interface pretty difficult. One solution is to think that
carriers
have containers, and those containers specify the limits on size.
However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack"
) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify
both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those
use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :(
)
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry
them.
> 2) AbleToCarry (an object which can carry objects implemented
IsCarryable
> interfaces). Those could be aircrafts, units, general store
facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
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.556 / Virus Database: 348 - Release Date: 12/26/2003
---
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: mamutas <mam...@ho...> - 2004-01-03 03:24:08
|
Hi Cpt.
My suggestion was just one of many options. Having a enumerator is fine too,
as long as our validator will catch invalid values there. I do not remember,
can you enforce that in DTD? I think you can do it with attributes, but not
with tag values, right? If that is true, then attribute for state looks like
a better option for me. Also, I don't think we need to have both 'In
Progress' and 'Active', as the difference in them will be the number of
scientists allocated, right? But that information is not going to be stored
in that XML, but in some other places. We should avoid duplicate storage of
the same meaning in two different places, therefore I suggest to combine
those two states in one and rely on number of scientists.
Regards,
mamutas
----- Original Message -----
From: "Cpt. Boxershorts" <cpt...@te...>
To: "Mamutas Plaukotas" <ma...@pr...>;
<xen...@li...>
Sent: Thursday, January 01, 2004 5:38 PM
Subject: RE: [Xenocide-programming] Tech Tree XML layout
> Hi Mamutas,
>
> You're right, it would be simpler computationally to keep separate
> variables. How about an actual enumerated state? I see topics as having
> four states: Unresearched, In Progress (has some hours put into, but not
> currently being researched), Active (currently being researched), and
> Complete.
>
> Would it be better to have it as attributes or elements? I'd like to
avoid
> overloading the topic node with too many attributes. What do you think of
> something like one of these this for each topic:
>
> <status> <!-- individual fields -->
> <started>False</started> <!-- has research begun on this topic? -->
> <completed>False</completed> <!-- has this topic been completely
> researched? -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> or
>
> <status> <!-- state enum -->
> <state>Unresearched</> <!-- values ("Unresearched"|"In
> Progress"|"Active"|"Complete") -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> I think we will need a <location/> tag as well...while researched
knowledge
> is global (shared among the bases), when you open a saved game, the topics
> that were actively being researched should still be active at the same lab
> as when you saved. It could just be however the facility is referenced
for
> the baseview.
>
> -The Captain
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...]On Behalf Of
> Mamutas Plaukotas
> Sent: Thursday, January 01, 2004 10:12 AM
> To: 'Cpt. Boxershorts'; 'Vlad Judys';
> xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
> Hello Captain,
>
> See my answers below.
>
> Regards,
> Mamutas
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
Cpt.
> Boxershorts
> Sent: Monday, December 29, 2003 12:28 AM
> To: Vlad Judys; xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
> 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?
>
> <mamutas>I think that it would be fine to keep loaded XML in the DOM of
the
> parser. The object which will load and provide interfaces to the DOM (fro
> example XNet Data Loader object) will know where and how to access the
> required data. And the XML will be parsed and validated once during the
> loading and then it will be kept in the memory. I don't see any advantages
> to convert XML to some internal representation, unless there will be
> significant performance issues.</mamutas>
>
> 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
>
> <mamutas>Yes, it is possible to use just one variable, but as you
mentioned
> than you need to keep in mind that '1' for 'just started topics'. It will
> save us some memory, but will add a code complexity. I would rather have
> explicit flags in this case, just to keep code clear.</mamutas>
>
> Just to simplify it, maybe 'completed' status should be ('researchhours'
<=
> 'amountcompleted'), rather than equals. That would save alot of headaches
> in calculating research hours.
>
> <mamutas>This is valid comment. It is always better not to use exact
> equality with real numbers. I learned that my first year in programming.
:)
> </mamutas>
>
> 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.
>
> <mamutas>Not sure about that yet, but something like that should be
> necessary as research tree is shared between all bases. In the same motion
> we can think about storing number of scientist allocated and other things,
> but I would leave it to later times to decide.</mamutas>
>
>
> 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!
>
> <mamutas>:) The copy is attached.. </mamutas>
>
> -The Captain
>
> ---
> 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: Xenocide R. A. <rep...@pr...> - 2004-01-02 02:33:18
|
I agree with the idea of containers. However, the exact implementation
of this is a bit unclear to me. I've seen some games that use
dimensions, PlanetSide or MechWarrior for example. A soldier is capable
of carrying 2 units x 4 units. A pistol would be 1u x 1u, and a rifle
1u x 2u. A larger vehicle would be capable of carrying 15u x 10u. A
large object that a soldier cannot carry would have dimensions larger
than a soldier's capacity, 3u x 2u for example. This enforces the
restrictions on who can carry what and also enforces the maximum
capacity of a unit.
How this is implemented is up to the programmers, but that's an idea for
the container system.
-mindstorm
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
ma...@pr...
Sent: Thursday, January 01, 2004 10:26 AM
To: red...@pr...;
xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hello Xenocide Programmers,
I liked RK's idea about containers. It might complicate things a bit,
but
what if ICarrier interface will server the only one purpose - the
container
management?
For example, each object which is ICarrier will have number of
containers
able to hold ICarriable objects. ICarrier will provide methods to
enumerate
the containers as well as to access them by number or name.
So soldiers will have many containers (hands, pockets, backpack, mouth
:),
etc.); transports will have one container for all their cargo; armed
crafts
will have containers for their weapons.
And here is the point: each container will have an object
ContainerConstraint. This object will describe the containers and will
be
responsible to provide yes/no for requests to put the item in the
container.
ContainerConstraint will have following variables for example:
- size (width and height, or something more sophisticated if container
is
not rectangular);
- max number of items;
- max weight of items;
- type of items (craft weapons only or any handheld weapons only, etc.)
The container itself will keep values of current content, so there are
no
such varialbles like current number/weight of items in the
ContainerCOnstraint object.
So, in RK's example below hand->addObject() method would call
ContainerConstraint object to verify that Object is acceptable.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 9:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for
carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them
as
long
as the weight do pass over an specified ammount. On the other side
Soldiers
do
mind the real proportions and the specific place in where you put them.
That
makes the interface pretty difficult. One solution is to think that
carriers
have containers, and those containers specify the limits on size.
However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack"
) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify
both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those
use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :(
)
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry
them.
> 2) AbleToCarry (an object which can carry objects implemented
IsCarryable
> interfaces). Those could be aircrafts, units, general store
facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
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.556 / Virus Database: 348 - Release Date: 12/26/2003
---
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: Cpt. B. <cpt...@te...> - 2004-01-01 23:39:53
|
Hi Mamutas,
You're right, it would be simpler computationally to keep separate
variables. How about an actual enumerated state? I see topics as having
four states: Unresearched, In Progress (has some hours put into, but not
currently being researched), Active (currently being researched), and
Complete.
Would it be better to have it as attributes or elements? I'd like to avoid
overloading the topic node with too many attributes. What do you think of
something like one of these this for each topic:
<status> <!-- individual fields -->
<started>False</started> <!-- has research begun on this topic? -->
<completed>False</completed> <!-- has this topic been completely
researched? -->
<hours>0</hours> <!-- hours researched -->
</status>
or
<status> <!-- state enum -->
<state>Unresearched</> <!-- values ("Unresearched"|"In
Progress"|"Active"|"Complete") -->
<hours>0</hours> <!-- hours researched -->
</status>
I think we will need a <location/> tag as well...while researched knowledge
is global (shared among the bases), when you open a saved game, the topics
that were actively being researched should still be active at the same lab
as when you saved. It could just be however the facility is referenced for
the baseview.
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
Mamutas Plaukotas
Sent: Thursday, January 01, 2004 10:12 AM
To: 'Cpt. Boxershorts'; 'Vlad Judys';
xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Hello Captain,
See my answers below.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Monday, December 29, 2003 12:28 AM
To: Vlad Judys; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
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?
<mamutas>I think that it would be fine to keep loaded XML in the DOM of the
parser. The object which will load and provide interfaces to the DOM (fro
example XNet Data Loader object) will know where and how to access the
required data. And the XML will be parsed and validated once during the
loading and then it will be kept in the memory. I don't see any advantages
to convert XML to some internal representation, unless there will be
significant performance issues.</mamutas>
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
<mamutas>Yes, it is possible to use just one variable, but as you mentioned
than you need to keep in mind that '1' for 'just started topics'. It will
save us some memory, but will add a code complexity. I would rather have
explicit flags in this case, just to keep code clear.</mamutas>
Just to simplify it, maybe 'completed' status should be ('researchhours' <=
'amountcompleted'), rather than equals. That would save alot of headaches
in calculating research hours.
<mamutas>This is valid comment. It is always better not to use exact
equality with real numbers. I learned that my first year in programming. :)
</mamutas>
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.
<mamutas>Not sure about that yet, but something like that should be
necessary as research tree is shared between all bases. In the same motion
we can think about storing number of scientist allocated and other things,
but I would leave it to later times to decide.</mamutas>
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!
<mamutas>:) The copy is attached.. </mamutas>
-The Captain
---
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: Mamutas P. <ma...@pr...> - 2004-01-01 18:25:55
|
Hello Xenocide Programmers,
I liked RK's idea about containers. It might complicate things a bit, but
what if ICarrier interface will server the only one purpose - the container
management?
For example, each object which is ICarrier will have number of containers
able to hold ICarriable objects. ICarrier will provide methods to enumerate
the containers as well as to access them by number or name.
So soldiers will have many containers (hands, pockets, backpack, mouth :),
etc.); transports will have one container for all their cargo; armed crafts
will have containers for their weapons.
And here is the point: each container will have an object
ContainerConstraint. This object will describe the containers and will be
responsible to provide yes/no for requests to put the item in the container.
ContainerConstraint will have following variables for example:
- size (width and height, or something more sophisticated if container is
not rectangular);
- max number of items;
- max weight of items;
- type of items (craft weapons only or any handheld weapons only, etc.)
The container itself will keep values of current content, so there are no
such varialbles like current number/weight of items in the
ContainerCOnstraint object.
So, in RK's example below hand->addObject() method would call
ContainerConstraint object to verify that Object is acceptable.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 9:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them as
long
as the weight do pass over an specified ammount. On the other side Soldiers
do
mind the real proportions and the specific place in where you put them. That
makes the interface pretty difficult. One solution is to think that carriers
have containers, and those containers specify the limits on size. However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack" ) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :( )
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry them.
> 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> interfaces). Those could be aircrafts, units, general store facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
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.556 / Virus Database: 348 - Release Date: 12/26/2003
---
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: Mamutas P. <ma...@pr...> - 2004-01-01 18:12:28
|
Hello Captain,
See my answers below.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Monday, December 29, 2003 12:28 AM
To: Vlad Judys; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
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?
<mamutas>I think that it would be fine to keep loaded XML in the DOM of the
parser. The object which will load and provide interfaces to the DOM (fro
example XNet Data Loader object) will know where and how to access the
required data. And the XML will be parsed and validated once during the
loading and then it will be kept in the memory. I don't see any advantages
to convert XML to some internal representation, unless there will be
significant performance issues.</mamutas>
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
<mamutas>Yes, it is possible to use just one variable, but as you mentioned
than you need to keep in mind that '1' for 'just started topics'. It will
save us some memory, but will add a code complexity. I would rather have
explicit flags in this case, just to keep code clear.</mamutas>
Just to simplify it, maybe 'completed' status should be ('researchhours' <=
'amountcompleted'), rather than equals. That would save alot of headaches
in calculating research hours.
<mamutas>This is valid comment. It is always better not to use exact
equality with real numbers. I learned that my first year in programming. :)
</mamutas>
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.
<mamutas>Not sure about that yet, but something like that should be
necessary as research tree is shared between all bases. In the same motion
we can think about storing number of scientist allocated and other things,
but I would leave it to later times to decide.</mamutas>
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!
<mamutas>:) The copy is attached.. </mamutas>
-The Captain
---
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: <red...@pr...> - 2003-12-31 07:12:08
|
Hi Cpt, basicly the Interceptor Craft is like a soldier, not like a transport.
In the Interceptor you have weapons pods, the distinction is with the transport.
In the transport the object are orderless, unless we give it enough space and
arrange the objects algorithmically... After thinking at it (found out that
while writting :D ), we can think of a transport as a Nx3 container with a big N
based on transport size. In that case even transports look like the same as
soldiers, and interceptors.
If someone has another idea of how to do it, it is welcomed but I think I will
start sketching something on this line if I dont receive any further comment.
Thanks Cpt.
Greetings
Red Knight
Quoting "Cpt. Boxershorts" <cpt...@te...>:
> Why have the arbitrary distinction between crafts and combat units? An
> Intercepter would have two carrierContainers for weapons....just assign them
> a size(you could even scale it to match a soldier...a backpack is 4x6 or so,
> so a hardpoint would be 8x20), and (for v1,at least) just make sure that all
> craft weapons match that size.
>
> That way both versions would function the same way...and it leaves it open
> in the future to have limits on what craft weapons fit which craft (similar
> to Apocalypse).
>
> -The Captain
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...]On Behalf Of
> red...@pr...
> Sent: Tuesday, December 30, 2003 7:57 PM
> To: xen...@li...
> Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
>
>
> Hi mamutas and all,
>
> How about this. We have ICarriable for objects that can be carried, and
> ICarrier
> for those that can carry. In that way we can make a nice system, suppose
> this:
>
> class ICarriable
> {};
>
> class ICarrier
> {};
>
> class Soldier : public ICarrier
> {};
>
> class Aircraft : public ICarrier
> {};
>
> ICarrier should be able to present a simple but unified view for carrying
> items.
> For instance Aircraft's dont mind the size of the stuff you put on them as
> long
> as the weight do pass over an specified ammount. On the other side Soldiers
> do
> mind the real proportions and the specific place in where you put them. That
> makes the interface pretty difficult. One solution is to think that carriers
> have containers, and those containers specify the limits on size. However,
> the
> carrier itself specify the limit on weight. You can either enumerate the
> containers or give them a symbolic name (like "righthand" or "backpack" ) to
> be
> accesible from a scripting language. So for instance to move the rocket
> launcher
> from the backpack to the hand you do the following.
>
> ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
>
> // Get the object via its code or whatever.
> ICarriable* object = backpack->takeoutObject ( ... );
>
> ICarrierContainer* hand = this->getCarrierContainer ("righthand");
> if (hand->isEmpty ())
> {
> // The ... is the parameters to specify how to add them, I must say
> // that I dont have a clue how to specify those parameters to unify both
> // types of carrier objects.
> hand->addObject (object, ... );
> }
> else // we dont do anything, or rollback the action :D ;
>
> Other solution is to have different type of interfaces and that those use
> the
> same type of ICarriable objects (as we have now), one is IStore (where
> position
> in the store is not relevant, only total size or weight and the other is
> ICarrier (used to be called Wearable) where not only size and weight are
> relevant but position too.
>
> Any though will be welcomed, cause I am stuck on this.
>
> Greetings
> Red Knight
>
>
> Quoting Mamutas Plaukotas <ma...@pr...>:
>
> > Here is what I think:
> >
> > We need two interfaces (sorry, but I cannot come up with good names :( )
> > 1) IsCarryable (the item which can be carried). That is an 'Ability'
> > interface which defines that the object can be carried, for example
> weapons
> > or corpses. Some objects cannot be carried, like phones, dishes, food
> items,
> > etc., although they are small enough, but there is no need to carry them.
> > 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> > interfaces). Those could be aircrafts, units, general store facilities,
> etc.
> > That interface will be 'Behaviour' in my opinion.
> >
> > Regards,
> > mamutas
>
>
> -------------------------------------------------------
> 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
>
>
>
> -------------------------------------------------------
> 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: Cpt. B. <cpt...@te...> - 2003-12-31 04:19:13
|
Why have the arbitrary distinction between crafts and combat units? An
Intercepter would have two carrierContainers for weapons....just assign them
a size(you could even scale it to match a soldier...a backpack is 4x6 or so,
so a hardpoint would be 8x20), and (for v1,at least) just make sure that all
craft weapons match that size.
That way both versions would function the same way...and it leaves it open
in the future to have limits on what craft weapons fit which craft (similar
to Apocalypse).
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
red...@pr...
Sent: Tuesday, December 30, 2003 7:57 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Carriable Items on Xenocide
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and
ICarrier
for those that can carry. In that way we can make a nice system, suppose
this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for carrying
items.
For instance Aircraft's dont mind the size of the stuff you put on them as
long
as the weight do pass over an specified ammount. On the other side Soldiers
do
mind the real proportions and the specific place in where you put them. That
makes the interface pretty difficult. One solution is to think that carriers
have containers, and those containers specify the limits on size. However,
the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack" ) to
be
accesible from a scripting language. So for instance to move the rocket
launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those use
the
same type of ICarriable objects (as we have now), one is IStore (where
position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :( )
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example
weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food
items,
> etc., although they are small enough, but there is no need to carry them.
> 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> interfaces). Those could be aircrafts, units, general store facilities,
etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
-------------------------------------------------------
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: <red...@pr...> - 2003-12-31 03:57:16
|
Hi mamutas and all,
How about this. We have ICarriable for objects that can be carried, and ICarrier
for those that can carry. In that way we can make a nice system, suppose this:
class ICarriable
{};
class ICarrier
{};
class Soldier : public ICarrier
{};
class Aircraft : public ICarrier
{};
ICarrier should be able to present a simple but unified view for carrying items.
For instance Aircraft's dont mind the size of the stuff you put on them as long
as the weight do pass over an specified ammount. On the other side Soldiers do
mind the real proportions and the specific place in where you put them. That
makes the interface pretty difficult. One solution is to think that carriers
have containers, and those containers specify the limits on size. However, the
carrier itself specify the limit on weight. You can either enumerate the
containers or give them a symbolic name (like "righthand" or "backpack" ) to be
accesible from a scripting language. So for instance to move the rocket launcher
from the backpack to the hand you do the following.
ICarrierContainer* backpack = this->getCarrierContainer ("backpack");
// Get the object via its code or whatever.
ICarriable* object = backpack->takeoutObject ( ... );
ICarrierContainer* hand = this->getCarrierContainer ("righthand");
if (hand->isEmpty ())
{
// The ... is the parameters to specify how to add them, I must say
// that I dont have a clue how to specify those parameters to unify both
// types of carrier objects.
hand->addObject (object, ... );
}
else // we dont do anything, or rollback the action :D ;
Other solution is to have different type of interfaces and that those use the
same type of ICarriable objects (as we have now), one is IStore (where position
in the store is not relevant, only total size or weight and the other is
ICarrier (used to be called Wearable) where not only size and weight are
relevant but position too.
Any though will be welcomed, cause I am stuck on this.
Greetings
Red Knight
Quoting Mamutas Plaukotas <ma...@pr...>:
> Here is what I think:
>
> We need two interfaces (sorry, but I cannot come up with good names :( )
> 1) IsCarryable (the item which can be carried). That is an 'Ability'
> interface which defines that the object can be carried, for example weapons
> or corpses. Some objects cannot be carried, like phones, dishes, food items,
> etc., although they are small enough, but there is no need to carry them.
> 2) AbleToCarry (an object which can carry objects implemented IsCarryable
> interfaces). Those could be aircrafts, units, general store facilities, etc.
> That interface will be 'Behaviour' in my opinion.
>
> Regards,
> mamutas
|
|
From: Mamutas P. <ma...@pr...> - 2003-12-31 03:17:10
|
Here is what I think: We need two interfaces (sorry, but I cannot come up with good names :( ) 1) IsCarryable (the item which can be carried). That is an 'Ability' interface which defines that the object can be carried, for example weapons or corpses. Some objects cannot be carried, like phones, dishes, food items, etc., although they are small enough, but there is no need to carry them. 2) AbleToCarry (an object which can carry objects implemented IsCarryable interfaces). Those could be aircrafts, units, general store facilities, etc. That interface will be 'Behaviour' in my opinion. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Federico Andres Lois Sent: Tuesday, December 30, 2003 2:37 PM To: xen...@li... Subject: [Xenocide-programming] Carriable Items on Xenocide Hi, I am being working on Xenocide Data Code... And I had received some comments about the interface of Storable and Wearable Objects... Storable objects are those that can be put on Stores or Aircrafts. However Wearable objects are those that can be used by aliens/soldiers. I was thinking to change Wearable to Carriable cause you can carry corpses but you cant wear them. The problem is: Is Carriable an Ability or a Behaivioral Interface? (you can check the code to see what are on those directories). I was going to put it in Ability but I am not sure, I am open to suggestions. Greetings Red Knight ------------------------------------------------------- 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.556 / Virus Database: 348 - Release Date: 12/26/2003 --- 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: Federico A. L. <fl...@ma...> - 2003-12-30 20:37:23
|
Hi, I am being working on Xenocide Data Code... And I had received some comments about the interface of Storable and Wearable Objects... Storable objects are those that can be put on Stores or Aircrafts. However Wearable objects are those that can be used by aliens/soldiers. I was thinking to change Wearable to Carriable cause you can carry corpses but you cant wear them. The problem is: Is Carriable an Ability or a Behaivioral Interface? (you can check the code to see what are on those directories). I was going to put it in Ability but I am not sure, I am open to suggestions. Greetings Red Knight |
|
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
|
|
From: Vlad J. <vj...@au...> - 2003-12-29 04:17:46
|
Also, we need to make sure that we are using our new names, not the one from original game (for example Elerium). I think Breunor is in charge of that, so you should sync it up with him. 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: 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-28 06:09:20
|
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: mamutas <mam...@ho...> - 2003-12-28 05:31:00
|
Here is comparison of some (most popular???) XML parsers: = http://xmlbench.sourceforge.net/index.php?page=3Dresults.php The bottom line is that Xerces is one of the most flexible and powerful = parsers. It is beaten by Oracle parser though in some tests, but as far = as I understood from Oracle XDK license = (http://otn.oracle.com/software/htdocs/distlic.html?/tech/xml/xdk/softwar= e/prod/winsoft_cpp.htm) it may not be used with open source = applications. I have done a search on SF and here is what I have found (besides = TinyXML and eXpat): libxml++ (http://sourceforge.net/projects/libxmlplusplus/) a wrapper for = Linux based libxml parser - we can't use it since there is no Win32 = port; Arabica XML toolkit (http://sourceforge.net/projects/arabica/) a wrapper = for other XML parsers (including Xerces) allowing them to support SAX2 = and DOM L2 formats - we do not need such advanced features; xmlpp (http://sourceforge.net/projects/xmlpp/) - something similar to = TinyXML, but was not updated since April 2002. So, my recommendation is either TinyXML or Xerces. First is small, but = not validating. Second is big and feature filled.=20 Xerces would be my choice: with its feature support, we could be sure = that we will be covered for all our possible future needs. However, we = need to look at Xerces license to make sure we need to use it. Regards, mamutas |
|
From: <red...@pr...> - 2003-12-27 16:59:21
|
Hi Mamutas, I had been researching how big is the memory footprint of Xerces and I hadnt found much about it. I think that will be the only thing that would flip the coin to or against its adoption. The only thing that I had read was that the whole library takes like 8Mb, the bad part is that it didnt said if it was a 8Mb .DLL file or 8 Mb of main memory just on initialization... So dont take that as a fact. On the other size, there is an important issue that we will have to discuss at deep. XML data for the game will be write once, use the rest of the times. If we follow the common sense, there is no need to revalidate non modified data each time you load an XML file from the sources. Because of that XML validation is mostly important only for developers/modders, not for the game users. In that case, even if for us that means that we have to run a validation script once in a while, just to be sure that we are not messing the files (that can be programmed in Java or C++ with Xerces and we can run it everywhere), it is not that traumatic. TinyXML is though to be small and have a very small memory footprint, so that would be an interesting alternative to a full blown XML Parser like Xerces. And we offload the validation into a development only activity. BTW as we talked about SAX Style Parsers are out of the question, we will only look for DOM Parsers. So that are our alternatives. If someone else has a comment dont hesitate to drop an email to the list too. Greetings Red Knight |
|
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: 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: 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: <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-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: 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 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 |
58 messages has been excluded from this view by a project administrator.
