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 <ma...@pr...> - 2003-12-02 03:26:16
|
Yes, visual representation is the images, text, models - everything what =
is
displayed to the user. I suggest to break down information into separate
files: one containing relationship for XNet DB view, another with
relationships and data for research, and another with list of all =
entities
and their visual representation (models, text, video, etc.). Then first =
two
files could refer to the last one. How is that?
-----Original Message-----
From: Cpt. Boxershorts [mailto:cpt...@te...]=20
Sent: Monday, December 01, 2003 4:07 PM
To: mamutas; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
I'm not quite sure if I understand. By "visual representation", do you =
mean
the part of the data that the player actually sees (i.e.: the xnet =
info), or
or you suggesting a further breakdown of the underlying data (so there =
would
be an XML file containing a simple list of all researchable items, and
separate file containing the relationships)?
=20
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
mamutas
Sent: November 30, 2003 8:32 PM
To: 'Andrew Franks'; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Looks pretty good to me.
=20
I take a look at the structure of XML file and did not really checked =
the
dependencies between researcheable items.
=20
I have one concern here: the definition integrates both research tree
hierarchy and visual representation for the entities. In my opinion =
these
two should be separated, perhaps in two XML files: first to describe
dependencies only, second to provide information for entry visual
presentation.
=20
In addition, I think that this project should be performed in parallel =
with
XNet DB model definition. ChrisP has started it, but not finished yet. =
Here
I think we need two XML as well: one to describe categories and entities =
and
another to describe visual representation of entity. The second could be =
the
same as the one for research, see?
=20
Regards.
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Andrew Franks
Sent: Friday, November 28, 2003 5:05 PM
To: mamutas; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Okay, here's a first draft. I included every field I could think =
of...let
me know if I missed anything.
Is X-Net going to have it's own xml layout, or will it share with the =
tech
tree?
=20
Here's a short sample, see the attachment for more detailed comments
=20
//Plasma Pistol
<topic name=3D"Plasma Pistol" researchtime=3D"100">
=20
<prerequisite>
<topic name=3D"Plasma Weapons" />
<item name=3D"Plasma Pistol" />
</prerequisite>
=20
<researchbonus> // so if the player researched rifle before pistol, =
pistol
would only take 95% of researchtime
//these are cumulative, so if both were researched already, pistol =
would
take 90% of researchtime
<topic name=3D"Plasma Rifle" bonus=3D"5" />
<topic name=3D"Heavy Plasma" bonus=3D"5" />
</researchbonus>
=20
<filepaths>
<unresearched>/xnet/texts/unresearched/plasmapistol.rtf</unresearched> =
<xnet_image>/xnet/images/plasmapistol.3ds</xnet_image>=20
<xnet_text>/xnet/texts/weapons/plasmapistol.rtf</xnet_text>=20
</filepaths>
=20
<grants>
<item name=3D"Plasma Pistol"/>
</grants>
</topic>
=20
=20
=20
- Cpt. Boxershorts
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27
=20
|
|
From: Cpt. B. <cpt...@te...> - 2003-12-02 03:20:14
|
Message
So, what you're saying is move the <filereferences> element into a global
item list? That's no problem.
Do you know if it's possible to enforce id integrity across files? I know
you can do it in a single file.
Does anyone know how captured aliens will be recorded? Will it be an actual
"Alien" class with a Rank property, or just a one line reference?
Basically, I'm asking if it would be:
<topic name="Sectiod Soldier"/>
or
<topic name = "Sectoid" rank="Soldier"/>
The first is easier to do, but the second might be better for
future-proofing (for multiplayer, when you can capture enemy humans as well)
-The Captain
-----Original Message-----
From: mamutas [mailto:ma...@pr...]
Sent: December 1, 2003 2:47 PM
To: 'Cpt. Boxershorts'; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Yes, visual representation is the images, text, models - everything what
is displayed to the user. I suggest to break down information into separate
files: one containing relationship for XNet DB view, another with
relationships and data for research, and another with list of all entities
and their visual representation (models, text, video, etc.). Then first two
files could refer to the last one. How is that?
-----Original Message-----
From: Cpt. Boxershorts [mailto:cpt...@te...]
Sent: Monday, December 01, 2003 4:07 PM
To: mamutas; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
I'm not quite sure if I understand. By "visual representation", do you
mean the part of the data that the player actually sees (i.e.: the xnet
info), or or you suggesting a further breakdown of the underlying data (so
there would be an XML file containing a simple list of all researchable
items, and separate file containing the relationships)?
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
mamutas
Sent: November 30, 2003 8:32 PM
To: 'Andrew Franks'; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Looks pretty good to me.
I take a look at the structure of XML file and did not really checked
the dependencies between researcheable items.
I have one concern here: the definition integrates both research tree
hierarchy and visual representation for the entities. In my opinion these
two should be separated, perhaps in two XML files: first to describe
dependencies only, second to provide information for entry visual
presentation.
In addition, I think that this project should be performed in parallel
with XNet DB model definition. ChrisP has started it, but not finished yet.
Here I think we need two XML as well: one to describe categories and
entities and another to describe visual representation of entity. The second
could be the same as the one for research, see?
Regards.
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Andrew Franks
Sent: Friday, November 28, 2003 5:05 PM
To: mamutas; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Okay, here's a first draft. I included every field I could think
of...let me know if I missed anything.
Is X-Net going to have it's own xml layout, or will it share with
the tech tree?
Here's a short sample, see the attachment for more detailed comments
//Plasma Pistol
<topic name="Plasma Pistol" researchtime="100">
<prerequisite>
<topic name="Plasma Weapons" />
<item name="Plasma Pistol" />
</prerequisite>
<researchbonus> // so if the player researched rifle before pistol,
pistol would only take 95% of researchtime
//these are cumulative, so if both were researched already,
pistol would take 90% of researchtime
<topic name="Plasma Rifle" bonus="5" />
<topic name="Heavy Plasma" bonus="5" />
</researchbonus>
<filepaths>
<unresearched>/xnet/texts/unresearched/plasmapistol.rtf</unresearched>
<xnet_image>/xnet/images/plasmapistol.3ds</xnet_image>
<xnet_text>/xnet/texts/weapons/plasmapistol.rtf</xnet_text>
</filepaths>
<grants>
<item name="Plasma Pistol"/>
</grants>
</topic>
- Cpt. Boxershorts
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27
|
|
From: mamutas <ma...@pr...> - 2003-12-01 04:32:07
|
Looks pretty good to me.
=20
I take a look at the structure of XML file and did not really checked =
the
dependencies between researcheable items.
=20
I have one concern here: the definition integrates both research tree
hierarchy and visual representation for the entities. In my opinion =
these
two should be separated, perhaps in two XML files: first to describe
dependencies only, second to provide information for entry visual
presentation.
=20
In addition, I think that this project should be performed in parallel =
with
XNet DB model definition. ChrisP has started it, but not finished yet. =
Here
I think we need two XML as well: one to describe categories and entities =
and
another to describe visual representation of entity. The second could be =
the
same as the one for research, see?
=20
Regards.
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Andrew Franks
Sent: Friday, November 28, 2003 5:05 PM
To: mamutas; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Okay, here's a first draft. I included every field I could think =
of...let
me know if I missed anything.
Is X-Net going to have it's own xml layout, or will it share with the =
tech
tree?
=20
Here's a short sample, see the attachment for more detailed comments
=20
//Plasma Pistol
<topic name=3D"Plasma Pistol" researchtime=3D"100">
=20
<prerequisite>
<topic name=3D"Plasma Weapons" />
<item name=3D"Plasma Pistol" />
</prerequisite>
=20
<researchbonus> // so if the player researched rifle before pistol, =
pistol
would only take 95% of researchtime
//these are cumulative, so if both were researched already, pistol =
would
take 90% of researchtime
<topic name=3D"Plasma Rifle" bonus=3D"5" />
<topic name=3D"Heavy Plasma" bonus=3D"5" />
</researchbonus>
=20
<filepaths>
<unresearched>/xnet/texts/unresearched/plasmapistol.rtf</unresearched> =
<xnet_image>/xnet/images/plasmapistol.3ds</xnet_image>=20
<xnet_text>/xnet/texts/weapons/plasmapistol.rtf</xnet_text>=20
</filepaths>
=20
<grants>
<item name=3D"Plasma Pistol"/>
</grants>
</topic>
=20
=20
=20
- Cpt. Boxershorts
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
=20
|
|
From: <red...@pr...> - 2003-11-28 18:44:00
|
Captain, this is the furthest that anyone have gone with the technology tree tech layout, it is a little complex by now... Remember our designs follow the principle: "Simplicity is the key to understanding" in short the KISS principle (Keep It Simple Stupid principle)... Hope this can help you. Greetings Red Knight |
|
From: mamutas <ma...@pr...> - 2003-11-28 16:02:43
|
I do not think that there is now any XML layouts created. So, you as =
well
might create your own. Please do and post your findings here.
=20
Thanks.
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Andrew Franks
Sent: Thursday, November 27, 2003 5:00 PM
To: xen...@li...
Subject: [Xenocide-programming] Tech Tree XML layout
Hi all...
=20
Could someone point me towards the current xml layout for the =
technology
tree? RK suggested I make my tech tree proposal a little easier to =
follow,
so I'm going to set up a web site so people can step through it (and the
original, for comparison). I figured since I need to write it up in xml
anyways (easiest way to do parent-child without getting into a db), I =
might
as well use the official layout.
=20
Thanks,
Andy (aka Cpt. Boxershorts)
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
=20
|
|
From: Andrew F. <And...@te...> - 2003-11-27 22:56:36
|
Hi all...
Could someone point me towards the current xml layout for the technology
tree? RK suggested I make my tech tree proposal a little easier to follow,
so I'm going to set up a web site so people can step through it (and the
original, for comparison). I figured since I need to write it up in xml
anyways (easiest way to do parent-child without getting into a db), I might
as well use the official layout.
Thanks,
Andy (aka Cpt. Boxershorts)
|
|
From: mamutas <ma...@pr...> - 2003-11-26 04:30:08
|
Yes, I have found the solution and successfully moved out paqexplorer.cpp
file out of compiler directory into the src. I have checked in updated
project file into CVS.
However, I had problems with compilation. Here are the errors:
Build
[C++ Warning] exception.impl(6): W8058 Cannot create pre-compiled header:
code in header
[C++ Warning] nopaddingenter.cfg(3): W8059 Structure packing size has
changed
[C++ Warning] nopaddingexit.cfg(3): W8059 Structure packing size has
changed
[C++ Warning] exception.impl(6): W8058 Cannot create pre-compiled header:
code in header
[C++ Warning] PAQExplorerManager.cpp(38): W8018 Assigning int to
DESCRIPTORTYPE
[C++ Warning] PAQExplorerManager.cpp(320): W8030 Temporary used for
parameter 'firstNewName' in call to 'getInsertInformations(string,char *
*,char * *,unsigned int &)'
[C++ Error] PAQExplorerManager.cpp(551): E2316 'filenameHash' is not a
member of 'PAQExplorerFileDescriptor'
[C++ Error] PAQExplorerManager.cpp(560): E2316 'fileLength' is not a
member of 'PAQExplorerFileDescriptor'
Regards,
mamutas
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On
> Behalf Of Ermete Gaudenzi
> Sent: Tuesday, November 18, 2003 3:58 AM
> To: xen...@li...
> Subject: [Xenocide-programming] Re: PAQ Explorer
>
>
>
> >Could you move paqexplorer.cpp file out of compiler
> directory? It needs
> >to be located with all other sources, and not with project files.
> I tried and for some time it worked, but I'm beginning to
> have strange
> errors ("cannot locate WinMain" when opening the project and
> "cannot create
> somefilename.$$$" when I save) so I left it with the devpack
> files. I tried to change manually the file path (with an
> editor) but I had this
> errors.
>
> If you can find a stable solution just tell me
>
> regards
> exio82
>
>
>
> -------------------------------------------------------
> 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.538 / Virus Database: 333 - Release Date: 2003/11/10
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10
|
|
From: mamutas <mam...@ho...> - 2003-11-26 02:49:14
|
Colin, =20 I am glad that you show interest in helping us with the project. =20 First, I recommend you to sign up to HYPERLINK "http://www.xcomufo.com/forums"www.xcomufo.com/forums - they have huge amount of useful information. One for example is a thread on how to = setup TortoiuseCVS - the tool which would be helpful to download the code from = our Sourceforge.net CVS repository. =20 Once you have code downloaded you would need to have a compiler to = compile it. We support Borland C++ Builder v6 now and we have a development pack (projects and libraries) to build with it. However, we cannot provide = that software to you - you would need to obtain it on your own. =20 I hope this will get you started. If you have any other questions - do = not hesitate to post here. =20 Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of = Colin Plamondon Sent: Monday, November 24, 2003 6:16 PM To: Project Xenocide Programming Mailing List Subject: [Xenocide-programming] Step by Step Instructions Please Hi everyone! I have very basic programming knowledge, and am not sure if = I=92m going to be able to help at all=85 I was wondering if someone could give = me step by step instructions to getting all the software I need downloaded, = and then getting it set up so that I can start modifying files and adding = code=85 thanks! --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10 =20 |
|
From: Colin P. <co...@pl...> - 2003-11-25 00:15:55
|
Hi everyone! I have very basic programming knowledge, and am not sure if I'm going to be able to help at all. I was wondering if someone could give me step by step instructions to getting all the software I need downloaded, and then getting it set up so that I can start modifying files and adding code. thanks! |
|
From: Ermete G. <ex...@li...> - 2003-11-22 15:32:29
|
>Could you move paqexplorer.cpp file out of compiler directory? It needs to
>be located with all other sources, and not with project files.
I tried and for some time it worked, but I'm beginning to have strange
errors ("cannot locate WinMain" when opening the project and "cannot create
somefilename.$$$" when I save) so I left it with the devpack files.
I tried to change manually the file path (with an editor) but I had this
errors.
If you can find a stable solution just tell me
regards
exio82
|
|
From: mamutas <ma...@pr...> - 2003-11-16 02:21:50
|
exio82, Could you move paqexplorer.cpp file out of compiler directory? It needs to be located with all other sources, and not with project files. Regards, mamutas > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On > Behalf Of Ermete Gaudenzi > Sent: Thursday, November 13, 2003 11:58 AM > To: xen...@li... > Subject: [Xenocide-programming] PAQ Explorer > > > Hi all, > I have prepared a test PAQ Explorer application (YEP!) > Sources are in CVS except the project files. > I attached them to this mail to add them in the devpack. It's > better if > only one person handle the devpack I think > > I wanted to attach also the application here, but with all the used > libraries it's about 1Mb and it's pretty big for a mail. > I put it on the FTP, the link for download is > http://www.projectxenocide.com/public/PAQExplorer/paqexplorer. zip regards exio82 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.538 / Virus Database: 333 - Release Date: 2003/11/10 |
|
From: Ermete G. <ex...@li...> - 2003-11-14 00:12:14
|
Hi all, I have prepared a test PAQ Explorer application (YEP!) Sources are in CVS except the project files. I attached them to this mail to add them in the devpack. It's better if only one person handle the devpack I think I wanted to attach also the application here, but with all the used libraries it's about 1Mb and it's pretty big for a mail. I put it on the FTP, the link for download is http://www.projectxenocide.com/public/PAQExplorer/paqexplorer.zip regards exio82 |
|
From: <red...@pr...> - 2003-11-08 16:36:52
|
Third email...
----- Forwarded message from mamutas <ma...@pr...> -----
Date: Sun, 2 Nov 2003 21:40:11 -0600
From: mamutas <ma...@pr...>
Reply-To: mamutas <ma...@pr...>
Subject: RE: Xenocide
To: red...@pr...
Hi guys,
See my comments inserted below.
Regards,
Vlad
> -----Original Message-----
> From: red...@pr...
> [mailto:red...@pr...]
> Sent: Thursday, October 30, 2003 5:50 PM
> To: ma...@pr...
> Cc: ex...@li...
> Subject: Xenocide
>
>
>
> Hi Vlad,
>
> >>Do you think I will not recognize you if you will send email from
> >>another address to me? LOL!
>
> I didnt remember if I had already send you a mail from my
> other account, I am
> receiving like 50 spam mails per day so I am sure that
> sometimes I delete
> important mails because of it (Computer Games writer came to my mind).
:) The email had your name written all other it. I really doubt I know
another Federico Louis.
>
> >>I have reviewed the archives you sent to me and my comments
> are below.
> >>I also attached the very first implemetation of UI
> framework together
> >>with its project file, so you can compile it if you will. Please
> >>review it and send to me your comments. Then, I will post it to the
> >>list as well. Pay attention to hierarchy, class and package names,
> >>please.
>
>
> >>I pretty much guessed your hierarcy, but my 'ui' directory is
> >>immediately under 'xenocide' where you have it under
> >>'xenocide/client'. I guess you are thinking to have more
> than just UI
> >>there, like network communication for example. I can move 'ui'
> >>directory under the 'client' and adjust package names to include
> >>Client in there too.
> You guess it almost flawlessly, I had separated client
> because we already have
> a server directory, so a client one was the better approach
> to get something
> uniform.
Ok. So I update my UI implementation by adding a Client directory and
namespace there. Oh, I just noticed that you already did that for me. :)
Thanks!
>
>
> >>Datainterfaces and its subdirectories.
> >>I notice that namespace for all interfaces is
> Xenocide::Interfaces. It
> >>could be fine not to separate them by behavior or object,
> but I think
> >>we should make a namespace Xenocide::DataInterfaces to distinguish
> >>from other
> >>(network???) kind.
> Noted and modified I think that is a very interesting idea to
> separate them,
> from other type of interfaces.
>
>
> >>Content of datainterfaces\behavior.
> >>I don't think that behavioral interfaces should have any
> data members.
> >>For example, size is not a property for IStorable object. All data
> >>attributes must belong to Object-kind interfaces. Also, I
> am not sure
> >>whether there should be any productID members, as these are
> attributes
> >>of object, but not behavior.
> About behaivioral interfaces (in general, IStorable
> excluded), I dont see a
> reason to impose that big constrain on behaivioral
> interfaces, cause most of
> the times you can use certain data methods to define the
> semantics of the
> class. That is something that you cant do in Java, Eiffel
> have the best method
> to do it via assertions, preconditions, postconditions and
> class invariants.
Java uses abstract classes for that. There is an interface usually, which
defines methods, but if your class mostly needs base functionality of it,
there is an abstract class made of the interface, which has either very
basic implementation or empty methods.
So, I think similar approach will work for us as well, but we do not need to
have interface and abstract class separately, but can combine them. My
concern is that if interface defines a behaviour, it should be stateles,
i.e. no member variables. But that is theory, in reality we could deviate
from it.
> C++ do not offer that kind of facilities, so partial
> implementation via
> C++ static
> methods calling virtual internal methods is the less invasive
> approach (You can
> see the NetworkLib's Connection object for an example) to fix
> the semantics.
> However for that approach to work you still need the data
> members defined. About the IStorable object, it is an old
> interface (I made it even before Alpha
> 1) I had just retrofited it and didnt revisited it (yet) I
> wanted to know
> exactly what you think about it. My reason at the time was to
Well, now you know what I think about it. ;)
> define a simple
> interface for every storable object. If you have to look for
> certain object you
> need its ID or something to know what it is. Because that
I agree, but that ID should not be a member variable of Istorable. There
should be method getID(), but ID must be stored in the implementor. The
reason is that some other interfaces must have getID() methods, but all of
such method would return an ID stored in the implementor class itself.
> interface was
> supposed to be the first in the inheritance tree for objects.
> Maybe a solution
> could be to put it a better name and move it to objects directory.
No, I think name and its location is fine.
>
> >>IStore is not a behaviour, but rather ability. It probably
> should be
> >>put in separate directory, where other similar interface would go
> >>(ILabaratory, IWorkshop perhaps).
> I like the idea of separating between
> objects/abilities/behaivior, and
> definitly IStore is an ability. You can store products or you
> dont. Better name
> for it or is it OK???
How about IStorer? It is a noun which describes the profession sort of. So,
labs would have IResearcher, workshops - IManufacturer, etc. Huh?
>
> >>Next, I do not think that interface should inherit from
> each other. In
> >>your example, IWearable is a child of IStorable. Again,
> interfaces in
> >>this case describe behavior. Thing, you can wear is not necessarily
> >>could be stored (although, it is not true in UFO probably). The
> >>implementing object must inherit from both interfaces if it exposes
> >>behavior of both.
> Certainly we will need to find a better name for the
> IStorable case or a better
> class hierarchy... About the inheritance with interfaces, I
> do not see any
> reason why we couldnt describe similar (or extended)
> behaiviors with interface
> inheritance... For instance you can do it in Java too, and if
> we keep the same
> kind of style like NEVER mix interface inheritance with
> implementation
> inheritance there shouldnt be any problem.
>
> I can think of a very interesting example... For instance in
> UFO you have
> Elerium, Laser Pistols, etc. All of them can be stored in a
> Storage room, be it
> an Aircraft, General Stores, etc. And for instance some of
> them can be STORED
> in the players backpacks. But to avoid the common pitfall of
> UFO (have a lot of
> useless items when arming your soldiers in a base attack),
> you create a sub
> interface that is descendant from the one that define
> storable objects that can
> be carriable by the soldier (the most correct solution). If
> not you can have
> non storable objects that can be carriable, something that is
> absurd in every
> simulation game.
>
I said 'should', not 'must'. I agree that there could be situation where we
want it, but I don't like it about IStorable and IWearable.
As for your example, there are object in UFO game which are carriable, but
not storable. Those are corpses of Xcom units. ;P
Looking forward we might have some missions (like those in WC3) where pieces
of some certain item needs to be gathered from different places. But, that
is absolutely out of V1 scope. It just a thought.
> >>IAircraft seemed OK to me. I only want to suggest to add
> another set
> >>of methods to get/receive the number of HWP the aircraft
> can carry, as
> >>those are different from units.
> Yes you are right, but we will have to think how to
> accomplish that cause the
> more I think about transport aircraft the most I think the
> interface is not
> quite right, for instance how do you check you have enough
> space. Do we impose
> a limit on HWP carry or we use the weight/size/units space
> combination? There
> are lots of important interface decitions to make there that
> are quite gameplay
> oriented. What do you think?
For that example, I think that canCarry() method could be very complex, but
I do not think we need that. I imagine aircraft are powerful enough to lift
off even if they are stuffed with the most heaviest items. So, I would just
take item/unit sizes and the empty space in the craft. Basically, exactly as
UFO had.
>
>
> >>As for the Soldier issue you mentioned there, then
> >>I am not quite sure about the problem. Could you explain it further?
>
> Soldier inheritance tree originally was like this:
>
> Personnel was the base X-Corp class
> Soldier inherits from Personnel
> Scientist inherits from Personnel
> Engenieer inherits from Personnel
>
> However if we want the aircraft to be used by both Aliens and
> Humans then we
> must modify the inheritance tree and find a new better
> abstraction. That's why
> I took it out from the code I sent you.
Your example is about aircrafts, but inheritance is about personnel? Still
did not get it. Sorry.
>
> >>IWeapon. I think that there is very little difference between
> >>isValidWeaponAmmunition() and acceptAmmunition() methods. Do you?
> There is a very subtle but important difference between them,
> If I would have
> implemented the class you would have seen it without a problem.
> isValidWeaponAmmunition() is an static linked method (note,
> not dynamic) that
> states the semantics of the validation method, which means
> make sure that the
> ammunition clip is valid for the weapon. On the other side,
> acceptAmmunition is
> the only method you override to cause the
> isValidWeaponAmmunition know of
> subclasses, and with the added value that you have the check
> needed to for the
> loadAmmunitionClip method too. It is exactly the same as the
> internalMethods
> from the NetworkLib connection.
>
> --------- (SORT OF) ACTUAL CODE ----------
>
> class HeavyPlasma
> {
>
> protected:
> virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
> {
> if (dynamic_cast<HeavyPlasmaClip*> (ammunition) != NULL)
> return true;
> else
> return false;
> };
> };
>
>
> class RocketLauncher
> {
>
> protected:
> virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
> {
>
> if (dynamic_cast<SmallRocket*> (ammunition) != NULL)
> return true;
> else if (dynamic_cast<LargeRocket*> (ammunition) != NULL)
> return true;
> else if (dynamic_cast<IncendiaryRocket*> (ammunition) != NULL)
> return true;
> else
> return false;
> };
> }
>
> OR
>
> class RocketLauncher
> {
>
> protected:
> virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
> {
> if (dynamic_cast<IRocket*> (ammunition) != NULL)
> return true;
> else
> return false;
> };
> }
>
> ------------------------------------------
> Then you delegate the actual decition whether the ammo clip
> is valid to that
> method.
>
> With the plus that you can have for instance and
> AdvanceRocketLauncher that
> shoots only EMPRockets or all type of available rockets
> (using either the first
> of second version).
Umm, Ok. I think I get it.
>
>
> >>Also, I would not use IWeapon for all kind of weapons. I
> think, that
> >>there
> should be
> >>an interface like IFireable for all weapons which can fire. In this
> >>case there would be any problems with non-fireable weapons
> like stun
> >>rod, etc. IAmmunitionClip. No comments on that one.
> I had though about it in the past, however if you think it
> this way: A Stunt
> Rod is indeed a fireable weapon, just only that is a Zero
> Range weapon. After
> all you have to trigger a button to fire the electric charge
> :D ... In that way
> we have two solutions either have IFireable, IRangeFireable
> (that inherit from
> IFireable) or we put the hierarchy upside down and make the
> range an attribute.
> I had found that the second way gives you a better design
> (not as flexible but
> easier to understand and implement) after explaining to a
> friend how to model a
> tanks simulator for his OOP class.
>
> For instance you have Tanks, and some tanks have only radio
> equipment but
> others have fixed turrets (assault tank)... Then an advance
> tank have a movable
> turret (heavy assault tank). Then the property of movable
> should be via
> inheritance or fixed turrets are not more than a specialized
> class of turret
> with a harder constrain (responding I cannot move in that
> direction, if we
> wanna aim we have to move the tank :D ).
Then we need to think about all possible items/weapons the soldier will use
in the battle. I guess grenades will get their own interface, but what about
Medikit, Motion Detector, etc.? Are those going to be a weapon? Perhaps not.
>
> >>IMountableWeapon. Again, I don't think we should inherit an
> interface
> >>from interface. Especially here: Mountable is description
> of behavior
> >>and Weapon is an object. I suggest another interface Imountable.
> Wrong name, changed to IAircraftWeapon and added
> IVehicleWeapon for HWP.
You did not change the file name though. Not a big deal, anyway.
>
> >>In general, this is all great. It finally start to feel
> like there is
> >>some gameplay present. And this is what I love!
> I do like this part too as we can feel nearer of a playable
> game, but the
> infrastructure work is as important as this if we want to make a
> mantenible/extendable game. On the other hand, it is cool we
> can make a
> windowed (not graphic) client to test all this :D ... like
> see what is in the
> stores and all that...
>
> BTW as we are getting a little more involved in the design
> (that I didnt expect
> that with the first mail) I will be sending this to Ermete
> too, and I will send
> him your mail too so we add their comments on this before
> release it to the
> mailing list.
Well, only 3 of us post in that mailing list, so you could send it there as
well - the same audience will be covered. :)
Ok. Now, you have sent me your code + my modified code. None of these files
are in CVS yet. Very quickly it could be hard to track changes in the files.
I suggest we pick a branch or two in possible hierarchy and finalize the
interfaces there. How about everything about aircrafts (weapons, storage,
speed, etc.) and bases?
Ok. That is it so far.
>
> Greetings
> Federico
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
>
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
----- End forwarded message -----
|
|
From: <red...@pr...> - 2003-11-08 16:36:33
|
This is the second email
----- Forwarded message from red...@pr... -----
Date: Thu, 30 Oct 2003 23:49:44 +0000
From: red...@pr...
Reply-To: red...@pr...
Subject: Xenocide
To: ma...@pr...
Hi Vlad,
>>I have reviewed the archives you sent to me and my comments are below. I
>>also attached the very first implemetation of UI framework together with its
>>project file, so you can compile it if you will. Please review it and send
>>to me your comments. Then, I will post it to the list as well. Pay attention
>>to hierarchy, class and package names, please.
>>I pretty much guessed your hierarcy, but my 'ui' directory is immediately
>>under 'xenocide' where you have it under 'xenocide/client'. I guess you are
>>thinking to have more than just UI there, like network communication for
>>example. I can move 'ui' directory under the 'client' and adjust package
>>names to include Client in there too.
You guess it almost flawlessly, I had separated client because we already have
a server directory, so a client one was the better approach to get something
uniform.
>>Datainterfaces and its subdirectories.
>>I notice that namespace for all interfaces is Xenocide::Interfaces. It could
>>be fine not to separate them by behavior or object, but I think we should
>>make a namespace Xenocide::DataInterfaces to distinguish from other
>>(network???) kind.
Noted and modified I think that is a very interesting idea to separate them,
from other type of interfaces.
>>Content of datainterfaces\behavior.
>>I don't think that behavioral interfaces should have any data members. For
>>example, size is not a property for IStorable object. All data attributes
>>must belong to Object-kind interfaces. Also, I am not sure whether there
>>should be any productID members, as these are attributes of object, but not
>>behavior.
About behaivioral interfaces (in general, IStorable excluded), I dont see a
reason to impose that big constrain on behaivioral interfaces, cause most of
the times you can use certain data methods to define the semantics of the
class. That is something that you cant do in Java, Eiffel have the best method
to do it via assertions, preconditions, postconditions and class invariants.
C++ do not offer that kind of facilities, so partial implementation via static
methods calling virtual internal methods is the less invasive approach (You
can
see the NetworkLib's Connection object for an example) to fix the semantics.
However for that approach to work you still need the data members defined.
About the IStorable object, it is an old interface (I made it even before
Alpha
1) I had just retrofited it and didnt revisited it (yet) I wanted to know
exactly what you think about it. My reason at the time was to define a simple
interface for every storable object. If you have to look for certain object
you
need its ID or something to know what it is. Because that interface was
supposed to be the first in the inheritance tree for objects. Maybe a solution
could be to put it a better name and move it to objects directory.
>>IStore is not a behaviour, but rather ability. It probably should be put in
>>separate directory, where other similar interface would go (ILabaratory,
>>IWorkshop perhaps).
I like the idea of separating between objects/abilities/behaivior, and
definitly IStore is an ability. You can store products or you dont. Better
name
for it or is it OK???
>>Next, I do not think that interface should inherit from each other. In your
>>example, IWearable is a child of IStorable. Again, interfaces in this case
>>describe behavior. Thing, you can wear is not necessarily could be stored
>>(although, it is not true in UFO probably). The implementing object must
>>inherit from both interfaces if it exposes behavior of both.
Certainly we will need to find a better name for the IStorable case or a
better
class hierarchy... About the inheritance with interfaces, I do not see any
reason why we couldnt describe similar (or extended) behaiviors with interface
inheritance... For instance you can do it in Java too, and if we keep the same
kind of style like NEVER mix interface inheritance with implementation
inheritance there shouldnt be any problem.
I can think of a very interesting example... For instance in UFO you have
Elerium, Laser Pistols, etc. All of them can be stored in a Storage room, be
it
an Aircraft, General Stores, etc. And for instance some of them can be STORED
in the players backpacks. But to avoid the common pitfall of UFO (have a lot
of
useless items when arming your soldiers in a base attack), you create a sub
interface that is descendant from the one that define storable objects that
can
be carriable by the soldier (the most correct solution). If not you can have
non storable objects that can be carriable, something that is absurd in every
simulation game.
>>IAircraft seemed OK to me. I only want to suggest to add another set of
>>methods to get/receive the number of HWP the aircraft can carry, as those
>>are different from units.
Yes you are right, but we will have to think how to accomplish that cause the
more I think about transport aircraft the most I think the interface is not
quite right, for instance how do you check you have enough space. Do we impose
a limit on HWP carry or we use the weight/size/units space combination? There
are lots of important interface decitions to make there that are quite
gameplay
oriented. What do you think?
>>As for the Soldier issue you mentioned there, then
>>I am not quite sure about the problem. Could you explain it further?
Soldier inheritance tree originally was like this:
Personnel was the base X-Corp class
Soldier inherits from Personnel
Scientist inherits from Personnel
Engenieer inherits from Personnel
However if we want the aircraft to be used by both Aliens and Humans then we
must modify the inheritance tree and find a new better abstraction. That's why
I took it out from the code I sent you.
>>IWeapon. I think that there is very little difference between
>>isValidWeaponAmmunition() and acceptAmmunition() methods. Do you?
There is a very subtle but important difference between them, If I would have
implemented the class you would have seen it without a problem.
isValidWeaponAmmunition() is an static linked method (note, not dynamic) that
states the semantics of the validation method, which means make sure that the
ammunition clip is valid for the weapon. On the other side, acceptAmmunition
is
the only method you override to cause the isValidWeaponAmmunition know of
subclasses, and with the added value that you have the check needed to for the
loadAmmunitionClip method too. It is exactly the same as the internalMethods
from the NetworkLib connection.
--------- (SORT OF) ACTUAL CODE ----------
class HeavyPlasma
{
protected:
virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
{
if (dynamic_cast<HeavyPlasmaClip*> (ammunition) != NULL)
return true;
else
return false;
};
};
class RocketLauncher
{
protected:
virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
{
if (dynamic_cast<SmallRocket*> (ammunition) != NULL)
return true;
else if (dynamic_cast<LargeRocket*> (ammunition) != NULL)
return true;
else if (dynamic_cast<IncendiaryRocket*> (ammunition) != NULL)
return true;
else
return false;
};
}
OR
class RocketLauncher
{
protected:
virtual Bool acceptAmmunition (IAmmunitionClip* ammunition)
{
if (dynamic_cast<IRocket*> (ammunition) != NULL)
return true;
else
return false;
};
}
------------------------------------------
Then you delegate the actual decition whether the ammo clip is valid to that
method.
With the plus that you can have for instance and AdvanceRocketLauncher that
shoots only EMPRockets or all type of available rockets (using either the
first
of second version).
>>Also, I would not use IWeapon for all kind of weapons. I think, that there
should be
>>an interface like IFireable for all weapons which can fire. In this case
>>there would be any problems with non-fireable weapons like stun rod, etc.
>>IAmmunitionClip. No comments on that one.
I had though about it in the past, however if you think it this way: A Stunt
Rod is indeed a fireable weapon, just only that is a Zero Range weapon. After
all you have to trigger a button to fire the electric charge :D ... In that
way
we have two solutions either have IFireable, IRangeFireable (that inherit from
IFireable) or we put the hierarchy upside down and make the range an
attribute.
I had found that the second way gives you a better design (not as flexible but
easier to understand and implement) after explaining to a friend how to model
a
tanks simulator for his OOP class.
For instance you have Tanks, and some tanks have only radio equipment but
others have fixed turrets (assault tank)... Then an advance tank have a
movable
turret (heavy assault tank). Then the property of movable should be via
inheritance or fixed turrets are not more than a specialized class of turret
with a harder constrain (responding I cannot move in that direction, if we
wanna aim we have to move the tank :D ).
>>IMountableWeapon. Again, I don't think we should inherit an interface from
>>interface. Especially here: Mountable is description of behavior and Weapon
>>is an object. I suggest another interface Imountable.
Wrong name, changed to IAircraftWeapon and added IVehicleWeapon for HWP.
>>In general, this is all great. It finally start to feel like there is some
>>gameplay present. And this is what I love!
I do like this part too as we can feel nearer of a playable game, but the
infrastructure work is as important as this if we want to make a
mantenible/extendable game. On the other hand, it is cool we can make a
windowed (not graphic) client to test all this :D ... like see what is in the
stores and all that...
BTW as we are getting a little more involved in the design (that I didnt
expect
that with the first mail) I will be sending this to Ermete too, and I will
send
him your mail too so we add their comments on this before release it to the
mailing list.
Greetings
Federico
----- End forwarded message -----
|
|
From: <red...@pr...> - 2003-11-08 16:32:58
|
This is for documentation purposes, this mail was sent off mailing list.
----- Forwarded message from mamutas <ma...@pr...> -----
Date: Tue, 28 Oct 2003 23:07:13 -0600
From: mamutas <ma...@pr...>
Reply-To: mamutas <ma...@pr...>
Subject: RE: Mamutas I am Red Knight
To: red...@pr...
Hi Federico,
I have reviewed the archives you sent to me and my comments are below. I
also attached the very first implemetation of UI framework together with its
project file, so you can compile it if you will. Please review it and send
to me your comments. Then, I will post it to the list as well. Pay attention
to hierarchy, class and package names, please.
I pretty much guessed your hierarcy, but my 'ui' directory is immediately
under 'xenocide' where you have it under 'xenocide/client'. I guess you are
thinking to have more than just UI there, like network communication for
example. I can move 'ui' directory under the 'client' and adjust package
names to include Client in there too.
Now about your code.
Client.
See comment about UI position above.
Datainterfaces and its subdirectories.
I notice that namespace for all interfaces is Xenocide::Interfaces. It could
be fine not to separate them by behavior or object, but I think we should
make a namespace Xenocide::DataInterfaces to distinguish from other
(network???) kind.
Content of datainterfaces\behavior.
I don't think that behavioral interfaces should have any data members. For
example, size is not a property for IStorable object. All data attributes
must belong to Object-kind interfaces. Also, I am not sure whether there
should be any productID members, as these are attributes of object, but not
behavior.
IStore is not a behaviour, but rather ability. It probably should be put in
separate directory, where other similar interface would go (ILabaratory,
IWorkshop perhaps).
Next, I do not think that interface should inherit from each other. In your
example, IWearable is a child of IStorable. Again, interfaces in this case
describe behavior. Thing, you can wear is not necessarily could be stored
(although, it is not true in UFO probably). The implementing object must
inherit from both interfaces if it exposes behavior of both.
Content of datainterfaces\object.
IAircraft seemed OK to me. I only want to suggest to add another set of
methods to get/receive the number of HWP the aircraft can carry, as those
are different from units. As for the Soldier issue you mentioned there, then
I am not quite sure about the problem. Could you explain it further?
IWeapon. I think that there is very little difference between
isValidWeaponAmmunition() and acceptAmmunition() methods. Do you? Also, I
would not use IWeapon for all kind of weapons. I think, that there should be
an interface like IFireable for all weapons which can fire. In this case
there would be any problems with non-fireable weapons like stun rod, etc.
IAmmunitionClip. No comments on that one.
IMountableWeapon. Again, I don't think we should inherit an interface from
interface. Especially here: Mountable is description of behavior and Weapon
is an object. I suggest another interface Imountable.
In general, this is all great. It finally start to feel like there is some
gameplay present. And this is what I love!
Regards,
Vlad
> -----Original Message-----
> From: Federico Andres Lois [mailto:fl...@ma...]
> Sent: Monday, October 27, 2003 6:53 PM
> To: ma...@pr...
> Subject: Mamutas I am Red Knight
>
>
>
>
> Hi Vlad, I had to use the other mail address cause I was
> having trouble with
> the other webmail. Reply to the other one...
>
> This are the projects and the xenocide interface code, I will
> be sending it to
> the list, but I want a comment from you first.
>
> Greetings
> Federico
>
>
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
>
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
----- End forwarded message -----
|
|
From: mamutas <ma...@pr...> - 2003-11-08 02:56:05
|
Hi guys, See my comments below. Here are also my answers to the questions RK raised: For soldier issue, I think we should base all the human/alien on some = Iunit interface. That interface would have the features shared between all = units. Then we might have specialized interfaces like Isoldier, Ipilot, Iresearcher. Those could be applied to mechanical units as well, like = tanks and cyberdisks. OR we can have a subclasses Ihuman and Ialien from = Iunit. But seriously I do not think it is necessary, since there very little difference in behaviour between humans and aliens.=20 I will commit the code I have in CVS. The first Xenocide game-specific = code! Yay! Regards, Vlad > -----Original Message----- > From: xen...@li...=20 > [mailto:xen...@li...] On=20 > Behalf Of Ermete Gaudenzi > Sent: Friday, November 07, 2003 6:55 PM > To: xen...@li... > Subject: [Xenocide-programming] Re: Xenocide >=20 >=20 > Hi Red, >=20 > > > In movieplayerui.h and planetviewui.h I see a singleton object=20 > > > working in different way than the ones I used in the PAQ project. > >Yes we have changed that because there are some situations=20 > when it is=20 > >better do not expose the real pointer to the user of a=20 > library, however=20 > >I was under the impression that I had changed the PAQ System=20 > too... Now=20 > >I see that I didnt. > If you are going to change the PAQ system too, I have to=20 > change my code=20 > too. It's not too expensive just tell me if you do it. The only thing you should change is to use getInstance() instead of = using the object directly, IIRC. >=20 > > > In IAircraft we can add shields support, more realistic=20 > damage (for=20 > > > example if hitted at the motors the aircraft will be=20 > slow) like in=20 > > > Tie Fighter. > >That is a pretty interesting idea, if you have any idea of how to > >implement it > >in sort of generic way I will include it... I had been=20 > thinking about it, but > >still couldnt find a good abstraction. > We can divide an aircraft in subsystems, like weaponry,=20 > motors, navigation=20 > drive, communications... > and associate a probability to be hitted to each subsystem. > For example when an aircraft with no shields and armour is=20 > hitted, there's=20 > a 50% chance to hit a subsystem in general. > If hitted, we generate a random number between 1 and 100 and=20 > basing on the=20 > result we choose the subsystem. > 1-10 navigation drive (less turn speed) > 11-40 weaponry (less damage) > 41-60 communications (bad radar and sensors) > 61-100 motors (less speed) > We can add others subsysems too, it was only an example. > About shields, I suggest we have a regenerating force shield=20 > (divided in=20 > front and back for example), then a non-repairable armour (at=20 > least not=20 > during missions) and the ship itself. This is near to be a=20 > standard in=20 > games with ships :-) > Note that if motors will be heavily damaged the ship will fall to the=20 > ground and so on... I was thinking about similar system: array of probabilites, where index corresponds to some ship part. But is there something like that in = original game? I frankly cannot remember. Well, that does not mean we should not = do it though... :) >=20 > >We dont have reload in the battlescape do we??? Maybe for advanced=20 > >weaponary as sniper rifles. IMO the reload time in=20 > milliseconds is more=20 > >useful for Aircraft Weapons. > Sorry I forgot the game is turn based :o) Yeah, I don't think we need a reload time for battlescape. But I agree = it is a must for aircraft weapons. >=20 > I'm glad to say that the PAQ Explorer first test release is=20 > near to be=20 > released. > The open and addfile functions are operative by now. I'll put=20 > a deletefile=20 > and fix some bugs in the next week I think. > When ready I'll put the code in CVS (nothing is there for=20 > now) and send a=20 > zipped exe to the list. That is great! I was thinking about PAQ the other day. I think what = would be very nice is to have a command line utility which to be used during the build process. The utility would add (if missing) or update (if = modified) file in PAQ. We would call this utility during the build (or manuall = after) with the list of files to process. We might have something like that already, I am not sure. >=20 > Regards > exio82 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09 =20 |
|
From: Ermete G. <ex...@li...> - 2003-11-08 01:10:20
|
Hi Red, > > In movieplayerui.h and planetviewui.h I see a singleton > > object working in different way than the ones I used in the PAQ > > project. >Yes we have changed that because there are some situations when it is better >do not expose the real pointer to the user of a library, however I was under >the impression that I had changed the PAQ System too... Now I see that I >didnt. If you are going to change the PAQ system too, I have to change my code too. It's not too expensive just tell me if you do it. > > In IAircraft we can add shields support, more realistic damage (for example > > if hitted at the motors the aircraft will be slow) like in Tie Fighter. >That is a pretty interesting idea, if you have any idea of how to >implement it >in sort of generic way I will include it... I had been thinking about it, but >still couldnt find a good abstraction. We can divide an aircraft in subsystems, like weaponry, motors, navigation drive, communications... and associate a probability to be hitted to each subsystem. For example when an aircraft with no shields and armour is hitted, there's a 50% chance to hit a subsystem in general. If hitted, we generate a random number between 1 and 100 and basing on the result we choose the subsystem. 1-10 navigation drive (less turn speed) 11-40 weaponry (less damage) 41-60 communications (bad radar and sensors) 61-100 motors (less speed) We can add others subsysems too, it was only an example. About shields, I suggest we have a regenerating force shield (divided in front and back for example), then a non-repairable armour (at least not during missions) and the ship itself. This is near to be a standard in games with ships :-) Note that if motors will be heavily damaged the ship will fall to the ground and so on... >We dont have reload in the battlescape do we??? Maybe for advanced weaponary >as sniper rifles. IMO the reload time in milliseconds is more useful for >Aircraft Weapons. Sorry I forgot the game is turn based :o) I'm glad to say that the PAQ Explorer first test release is near to be released. The open and addfile functions are operative by now. I'll put a deletefile and fix some bugs in the next week I think. When ready I'll put the code in CVS (nothing is there for now) and send a zipped exe to the list. Regards exio82 |
|
From: mamutas <ma...@pr...> - 2003-11-03 02:46:21
|
Hi everybody, I finally found some time to comment on that email. First, I want to say that RK did really good job on evaluation keeping = in mind the time he had for that. Second, I like pros and cons section. = That is really helpful. Pros are clear, so I will comment on cons only. * Low level. I am not certain, but I think that most of the existing = engines will feature different level of implementation or different set of API, = so we would be forced to write our wrappers around them anyway. So, I do = not see it as a big con, since it is pretty much unavoidable with = third-party engines. * Code standard. I do not expect we would be dealing with their code a = lot (same like with third-party headers), so it does not appear like a big = con either. * I understand that there is going to be an OpenGL implementation of Nebula2. I also understand that if we will be writing our wrapper around = it, it would not make any differences if we would swap DX implementation = with OpenGL lately. Would it? The biggest problem I see is a compilation issue. We probably need to discuss it a bit further. So, the bottom line seems like that we all agreed to move on it, right? = In that case, it would be nice to make some transition plan. I mean we need = to look over what do we need to do: what do we need to replace in engine, = what do we need to write around, etc.=20 Regards, mamutas > -----Original Message----- > From: xen...@li...=20 > [mailto:xen...@li...] On=20 > Behalf Of red...@pr... > Sent: Tuesday, October 28, 2003 4:14 PM > To: xen...@li... > Subject: [Xenocide-programming] Engine Research Results (Nebula2) >=20 >=20 > Hi everybody, I had been evaluating the Nebula2 Engine.=20 >=20 >=20 > It seams that it is a pretty good engine based on the core of=20 > what it was=20 > Nebula. The big drawback of Nebula was that it wasnt up to=20 > date at the time we=20 > choose to write our own engine. Nebula2 is on the other hand=20 > a fairly new (and=20 > uncomplete) open source engine that is being developed by a=20 > commercial party to=20 > make their own game, with the plus that they had already=20 > published 3 games. >=20 > There are several characteristics that make it pretty=20 > interesting, plus others=20 > that dont make it a good option. >=20 > Pros >=20 > It is shader centric, their other engine (Nebula) wasnt aware=20 > of the shaders=20 > technology (that is why at the time we choose to develop our=20 > own, none Open=20 > Source engine was shader centric). >=20 > It is very stable, most of the base classes are based on the=20 > very stable core=20 > of Nebula so it is an stable core to work with. >=20 > It has a fairly big community that is working on it, so an=20 > OpenGL port wont be=20 > that far away. Not to mention other projects that use it. >=20 > It is Open Source (at least everything that is not part of=20 > the XBox Port). >=20 > They had tons of utilities and stuff to work with models,=20 > skeletons, and other=20 > stuff. >=20 > Cons >=20 > It is fairly low level, most of the abstractions are more low=20 > level than the=20 > current design. There is not an object centric framework, not=20 > cameras,=20 > everything is done using plain matrix multiplication. >=20 > Their code standard is consistent and followed at least in=20 > most of the code,=20 > however there is ancient code that do not (for instance the=20 > vector classes,=20 > quaternion utils, etc). It is different from our code standard. >=20 > The current implementation is only Direct3D based, however it=20 > is pretty easy=20 > for someone (and I bet someone will) to port it to work with=20 > OpenGL (as it=20 > works in the same way as Nebula). The other drawback is that=20 > at the time of=20 > writing it I couldnt make it yet compile in Borland, but I am=20 > trying. Cause=20 > they had lots of interesting tools to build using VC7 (.NET)=20 > only, but it hasnt=20 > been released yet to the general public (Sourceforge) so I=20 > bet there will be=20 > sometime in the future... (If I can make it work on Borland I=20 > will contribute=20 > it :D ) ... The issue of Direct3D is not as problematic as it=20 > seams (more on=20 > this later). >=20 > They use a very different approach to publish the objects=20 > than we do (I am not=20 > saying their approach is bad, just different)... In fact it=20 > is a pretty=20 > different approach that deserves to be researched further. I=20 > had been using a=20 > similar approach in the past to make a Robot Simulation=20 > Programming Environment=20 > but the project got cancelled and we didnt work much on the=20 > practical part=20 > (most of the work was theoretic). It is based on the=20 > blackboard architecture=20 > scheme, every object can have a name and be stored in a=20 > virtual file space. So=20 > for instance you can get the kernel object with the following code. >=20 > this->kernelObject =3D "/sys/servers/kernel"; >=20 > where kernelObject is an NRef<nKernelObject*> object that=20 > works exactly as=20 > common pointer. >=20 >=20 >=20 > Evaluation Results >=20 > Using the engine will have a very big learning cost, and it=20 > isnt as easy to use=20 > cause the interface is designed to be efficient (not easy).=20 > And the fact that=20 > is uses Direct3D instead of OpenGL is a problem for=20 > compatibility. However, as=20 > we are doing a Windows Only Implementation now there is no=20 > reason why we=20 > shouldnt use it, given that lots of stuff is already done. We=20 > will have to=20 > reimplement lots of graphics code, but that code was=20 > prototype code so we was=20 > going to throw it away anyways. >=20 > There is already lots of code that works and a very high=20 > level object framework=20 > working (in XenoEngine) using Nebula2 is orthogonal to that.=20 > XenoEngine was=20 > designed as a very high level, API portable framework, so the=20 > only thing we=20 > have to do is: Improve on the XenoEngine API to incorporate some very=20 > interesting features that Nebula2 already provides out of the=20 > box. And then=20 > implement the core of XenoEngine functionality using Nebula2=20 > as the underlaying=20 > engine. In that way we win from both sides, we keep using a=20 > very high level=20 > object framework and we get the efficiency and tools from=20 > Nebula2 engine at a=20 > marginal cost. >=20 > The approach would be to revisit the interface of the=20 > XenoEngine Framework and=20 > as we are going to reimplement it improve upon it to make it=20 > even simplier and=20 > more powerful. Then use implementation inheritance or just=20 > plain delegation to=20 > implement the core functionality.=20 >=20 > About the compiler issue, that is another stick on the wheel=20 > (we use that=20 > expression here is Argentina, I dont know if it is used in=20 > another place :D ),=20 > I will have to see how to make the Nebula2 compilation=20 > process more Borland=20 > Friendly but the people that wants to use other compilers=20 > (VC7 in this case)=20 > will have an easier starting point cause the engine will be=20 > fairly easy to=20 > compile on it. >=20 > Another issue is the Direct3D stuff, well certainly Nebula=20 > already provides=20 > lots of very nice abstraction so I dont think we will need to=20 > implement that=20 > much using the Direct3D API directly, however if we are to do=20 > it. Direct3D is=20 > not that difficult to learn either, and we should try to keep=20 > that code at a=20 > minimmum as a design constrain. >=20 > I am sending this to the mailing list cause I want everybody=20 > that is seriously=20 > interested to contribute with Xenocide to give his opinion=20 > and be heard.=20 > Notheless if some of you have better understanding on Nebula2=20 > and I had made=20 > mistakes, remember that I had taken a very high level look=20 > cause I couldnt=20 > compile it (but I read lots of documentation and read lots of=20 > code). So dont=20 > hesitate to correct what I had learned wrong. >=20 > Greetings > Red Knight >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program.=20 > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/=20 > _______________________________________________ > Xenocide-programming mailing list=20 > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming >=20 >=20 > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09 > =20 >=20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09 =20 |
|
From: Ermete G. <ex...@li...> - 2003-10-29 00:29:43
|
If this does not means that my work on the PAQ management become useless, I think we can use it ;-) Seriously, basing on your informations, I don't see reasons to don't use it. I think we must ask the nebula2 team about how expensive is an openGL port (their opinion), and explore better the nebula2 capabilities, compatibility and limits. >About the compiler issue, that is another stick on the wheel (we use that >expression here is Argentina, I dont know if it is used in another place :D ) we also use that expression here in Italy :-D The XenoEngine developing is going to be suspended till we take a decision about this right? exio82 |
|
From: <red...@pr...> - 2003-10-29 00:07:44
|
Quoting Ermete Gaudenzi <ex...@li...>: > If this does not means that my work on the PAQ management become useless, I > think we can use it ;-) Yes of course, we will definitly use it. > Seriously, basing on your informations, I don't see reasons to don't use it. > I think we must ask the nebula2 team about how expensive is an openGL port > (their opinion), and explore better the nebula2 capabilities, compatibility > and limits. > > >About the compiler issue, that is another stick on the wheel (we use that > >expression here is Argentina, I dont know if it is used in another place :D > ) > we also use that expression here in Italy :-D > > The XenoEngine developing is going to be suspended till we take a decision > about this right? Nope just graphics stuff, there are tons of others thinks to do before we can work on that... lots of time to figure everything out... Greetings Red Knight |
|
From: <red...@pr...> - 2003-10-28 22:17:00
|
Hi everybody, I had been evaluating the Nebula2 Engine. It seams that it is a pretty good engine based on the core of what it was Nebula. The big drawback of Nebula was that it wasnt up to date at the time we choose to write our own engine. Nebula2 is on the other hand a fairly new (and uncomplete) open source engine that is being developed by a commercial party to make their own game, with the plus that they had already published 3 games. There are several characteristics that make it pretty interesting, plus others that dont make it a good option. Pros It is shader centric, their other engine (Nebula) wasnt aware of the shaders technology (that is why at the time we choose to develop our own, none Open Source engine was shader centric). It is very stable, most of the base classes are based on the very stable core of Nebula so it is an stable core to work with. It has a fairly big community that is working on it, so an OpenGL port wont be that far away. Not to mention other projects that use it. It is Open Source (at least everything that is not part of the XBox Port). They had tons of utilities and stuff to work with models, skeletons, and other stuff. Cons It is fairly low level, most of the abstractions are more low level than the current design. There is not an object centric framework, not cameras, everything is done using plain matrix multiplication. Their code standard is consistent and followed at least in most of the code, however there is ancient code that do not (for instance the vector classes, quaternion utils, etc). It is different from our code standard. The current implementation is only Direct3D based, however it is pretty easy for someone (and I bet someone will) to port it to work with OpenGL (as it works in the same way as Nebula). The other drawback is that at the time of writing it I couldnt make it yet compile in Borland, but I am trying. Cause they had lots of interesting tools to build using VC7 (.NET) only, but it hasnt been released yet to the general public (Sourceforge) so I bet there will be sometime in the future... (If I can make it work on Borland I will contribute it :D ) ... The issue of Direct3D is not as problematic as it seams (more on this later). They use a very different approach to publish the objects than we do (I am not saying their approach is bad, just different)... In fact it is a pretty different approach that deserves to be researched further. I had been using a similar approach in the past to make a Robot Simulation Programming Environment but the project got cancelled and we didnt work much on the practical part (most of the work was theoretic). It is based on the blackboard architecture scheme, every object can have a name and be stored in a virtual file space. So for instance you can get the kernel object with the following code. this->kernelObject = "/sys/servers/kernel"; where kernelObject is an NRef<nKernelObject*> object that works exactly as common pointer. Evaluation Results Using the engine will have a very big learning cost, and it isnt as easy to use cause the interface is designed to be efficient (not easy). And the fact that is uses Direct3D instead of OpenGL is a problem for compatibility. However, as we are doing a Windows Only Implementation now there is no reason why we shouldnt use it, given that lots of stuff is already done. We will have to reimplement lots of graphics code, but that code was prototype code so we was going to throw it away anyways. There is already lots of code that works and a very high level object framework working (in XenoEngine) using Nebula2 is orthogonal to that. XenoEngine was designed as a very high level, API portable framework, so the only thing we have to do is: Improve on the XenoEngine API to incorporate some very interesting features that Nebula2 already provides out of the box. And then implement the core of XenoEngine functionality using Nebula2 as the underlaying engine. In that way we win from both sides, we keep using a very high level object framework and we get the efficiency and tools from Nebula2 engine at a marginal cost. The approach would be to revisit the interface of the XenoEngine Framework and as we are going to reimplement it improve upon it to make it even simplier and more powerful. Then use implementation inheritance or just plain delegation to implement the core functionality. About the compiler issue, that is another stick on the wheel (we use that expression here is Argentina, I dont know if it is used in another place :D ), I will have to see how to make the Nebula2 compilation process more Borland Friendly but the people that wants to use other compilers (VC7 in this case) will have an easier starting point cause the engine will be fairly easy to compile on it. Another issue is the Direct3D stuff, well certainly Nebula already provides lots of very nice abstraction so I dont think we will need to implement that much using the Direct3D API directly, however if we are to do it. Direct3D is not that difficult to learn either, and we should try to keep that code at a minimmum as a design constrain. I am sending this to the mailing list cause I want everybody that is seriously interested to contribute with Xenocide to give his opinion and be heard. Notheless if some of you have better understanding on Nebula2 and I had made mistakes, remember that I had taken a very high level look cause I couldnt compile it (but I read lots of documentation and read lots of code). So dont hesitate to correct what I had learned wrong. Greetings Red Knight |
|
From: mamutas <ma...@pr...> - 2003-10-12 04:50:16
|
I agree that second way is preferable. Also, what design pattern did you mention? I checked the graphics. I understand that you are going to implement explorer like interface using PAQExplorerManager to communicate to PAQSolidFile. That is all clear. I think the design looks good. Regards. -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of red...@pr... Sent: Thursday, October 09, 2003 3:16 PM To: xen...@li... Subject: Re: [Xenocide-programming] PAQ Explorer schemas Hi Exio, > About the directories implementation (remember that the archive was=20 > coded without directory support, but we need it to provide a simple > interface) >=20 > there are two ways: >=20 > 1) adding empty files to the disk archive with the name (and=20 > attribute) of the directory. Operation handled by the PAQSolidFile=20 > object >=20 > 2) building the directory tree by the file names everytime the archive = > is opened. Operation handled by the PAQExplorerManager object This is the better solution, because the intend of the PAQSolidFile is speed,=20 you are using an app, having to wait a little more offline, but pays off = in=20 the using of the PAQFile at the game enviroment. > According to the design patterns (one of the few I remember!!)=20 > handling directory maintenance is business of PAQExplorerManager,=20 > cause the PAQ archives were built without directory support from the=20 > start, for speed purposes. >=20 Exactly. > >What do you mean about it? >=20 > It was just a note on the elementary functions that the interface=20 > should provide. >=20 > I'm going to implement from the start the support for multiple=20 > selection (list of files). >=20 > For deleting a group of files (for example) it's easy to call=20 > PAQExplorerManager::deleteFile for each selected file inside a > for(;;) >=20 > Showing property of a group of files is something more complicated and = > needs a separated function (I don't want to a property window for each = > file... only one for all of them is better) >=20 >=20 > Have you any idea about how to use file flags? What flags???=20 > And what about the LiveUpdate? I have a guy that is going to do it for his bachelor degree thesis... :D = It is=20 already in the drawing board. > Last thing: I discovered now that VCL is available only for windows=20 > and that for multiplatform purposes I must use CLX... >=20 > If so, I have to prepare the interface using CLX instead of VCL right? There is no much difference between the CLX and the VCL, but yes you = should=20 use it for OS portability... The hadnt much time to think much about the graphics you made, but in a = fast check it look good. Keep up the good work Exio Greetings Red Knight ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. = SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED = US provide better services: Click here: = http://sourceforge.net/supporters.php _______________________________________________ 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.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 |
|
From: mamutas <ma...@pr...> - 2003-10-12 04:42:33
|
You do not need to nest Xdata withing XNDL, it could the same class, = just merge them together. The only overhead here I see is for extra code = which will be used to load and parse file, but it is just a few KB at most. Also, as RK mentioned change structures to class, as they more likely to = be used by UI during its drawing. Regards. -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of = Chris Phillips Sent: Wednesday, October 08, 2003 4:47 PM To: ma...@pr... Cc: Xen...@li... Subject: Re: [Xenocide-programming] xnet db loader No need to apologize, being critical is a good thing in my opinion. Those are all good suggestions. I think I'll get the XNDL working w/ a regular list first. We can always upgrade it if needed. The difference = in performance probably won't be noticeable, but an improved data structure = may help free up a few resources for more processor intensive areas. Well you're right about separating the data. Since it's been decided = not to create structs outside of the data class, then it isn't as necessary to separate it. Separating it would again result in a very slight decrease = in overhead, since the loader could be destroyed once parsing is complete. = It's not likely to be noticeable. What we would have would be two structs = nested in a class, which is itself nested in a class. Regards, chrisp On Mon, 6 Oct 2003 21:51:32 -0500 "mamutas" = <ma...@pr...> writes: > Hi, >=20 > I just had a chance to look through your code. Here are my > comments: >=20 > 1) Use longer, more descriptive variable names. It is fairly > difficult to > understand what 'p' or 'hGen' might stand for. > 2) Use types defined in utility/src/utility/common/win32/types.h.=20 > This will > help in compiler and OS porting in the future. > 3) I don't think we need two separate classes XNDL and Xdata. I=20 > thought > about just one class which would have a load() method (which does=20 > parsing at > the same time) and then provides getSubject() and getEntry()=20 > methods. > 4) Subject and Entry class should have a 'key' variable, which will=20 > hold a > unique key for such object. It could be a string or an integer, does=20 > not > matter. The point is that access to these objects will be done by=20 > keys, and > not by their names, which could be spelled differently in different > languages. This as well should be reflected in xml file. > 5) addSubject() and addEntry() are private methods, right? >=20 > Also, check periodicall a thread about Xnet names, there is a file > in work > listing all names as they will appear in the game. >=20 > Just FYI, here is a source code for skip lists:=20 > http://epaperpress.com/sortsearch/txt/skl.txt > I am not quite sure whether we need such complicated data structure > for Xnet > DB, since the hierarchy is very simple and there are not many=20 > entries > anyways. I would use something like a simple list of lists myself. >=20 > Thanks for your work. I apologize, if I was criticising too much. >=20 > Regards, > mamutas >=20 > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf > Of Chris > Phillips > Sent: Thursday, October 02, 2003 9:03 PM > To: Xen...@li... > Subject: [Xenocide-programming] xnet db loader >=20 >=20 >=20 > Hey everyone, >=20 > Sorry I've been out of touch for so long. I've been busy moving and > w/ a > new job. I haven't had much time to work on the XNet db loader=20 > during the > past few weeks, so I figured I should go=20 > ahead and post the header files as they are. So.. here are the=20 > header files > w/ some basic documentation. I used my own string class, which=20 > should > definitely be changed. I also used my Skip List. Which can be=20 > changed > also. The files are attached. Let me=20 > know what changes should be made. I'll try and set aside some time=20 > to get > this done. :) >=20 >=20 > -chrisp >=20 > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.514 / Virus Database: 312 - Release Date: 2003/08/28 > =20 > =20 >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.514 / Virus Database: 312 - Release Date: 2003/08/28 > =20 >=20 >=20 >=20 ________________________________________________________________ The best thing to hit the internet in years - Juno SpeedBand! Surf the = web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign = up today! ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. = SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED = US provide better services: Click here: = http://sourceforge.net/supporters.php _______________________________________________ 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.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 |
|
From: mamutas <ma...@pr...> - 2003-10-12 04:37:30
|
The code is in CVS already. :) -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of red...@pr... Sent: Thursday, October 09, 2003 7:27 PM To: xen...@li... Subject: [Xenocide-programming] Network Library Update Well as most of you will realize after seeing the latest diary entries, = you=20 will find that lots happened on the Network Library front this latest 2 weeks.=20 The best announcement I can make is that we are ready to go for = integration of=20 the network library connection in the local xenocide client-server = model. We can use an extension I had made named IPCP (In Process Communication = Port) it=20 is lighting fast, as fast as a memory copy (everybody is encouraged to = see=20 that is the pure truth :D) The source will be available in 1 or 2 days cause I cannot commit it = from this=20 public terminal so Mamutas will be in charge of it (sorry mamu)... Diary Entries [FREQUENTLY ASKED QUESTIONS] - Why do I get exceptions when run from the debugger, is that OK? + Most of the exceptions that you are going to get are OK, you have to=20 + make sure that you can continue with your work after it has been raised. = ZThread is=20 highly based on the Exception Mechanism to provide a clean task oriented = framework, so be aware that raising some exceptions is OK provided that = they get cough where they are supposed to. If that means that the application will=20 fail it is NOT OK. - Can I use the current implementation of NetworkLib in W95/W98/WME? + You cant using the devpack provided, you will have to recompile the=20 + ZThread library to be able to use it in those OSs. [PROBLEMS TO DISCUSS] - Let the connection change its interface mechanism of communication = with the=20 application after it has been created. - How to make the servers cancel the listening after they are listening. [STILL MISSING IN ACTION] - Simulation mechanism (Have to learn ZThreads first). - Implementation of the NetworkLib internal protocol. (Have to learn ZThreads=20 first). - Event Oriented Interface (Have to learn ZThreads first). - NLIP6NetworkAddress. - Implement the Controller deamon thread via the internal run method required=20 by ZThread. - Get information about the IP4 or IP6 current protocol configuration = (like=20 what IP's our cards have and anything useful for the user/programmer). [8-10-2003/9-10-2003] (RK) - The definition of the NLIAbstractServer is even more near of being = final,=20 will have to test it a little further but it looks like I found an = stable=20 design. I EXPECT LOTS OF EVALUATION WORK, GUYS :D - Include ZThread V 2.3.1 compiled binaries into the proposed devpack + = new=20 docs section in the devpack + we are going to put it in CVS under=20 devpack.borland name cause it has matured into a very stable devpack. - Modified the signature of the listenForConnections to handle listening = errors. Updated both inprocconnection and multirequestserver. - Modified the IPCP Factory to fail with a NLEInvalidAddressType instead = of an=20 NLEInvalidParameter exception. - Added a new exception: NLEInvalidAddressType. It is used to signal an=20 unsupported address type sent into a connection factory. For instance = send a NLIP4Address into the IPCP Extension. - Added a new exception: NLEConnectionNotReady. It is used to signal a mistake=20 from the user of the library and make the send method to fail cleanly, = it is not intended to be caught just signal a mistake on the user part. = However we will see cause if catching this exception makes the code more robust and = easier to read and write we can review that rule, extensive testing is needed=20 though. - Moved the class NLIConnectionEventListener inside the NLConnection = class as=20 a public inner class. - Modified the signature of the NLConnection's send, connect and = disconnect=20 methods to add the return of error information. - Blocking Mode is implemented and the In Process Communication Port Extension=20 (IPCP) already support Blocking Mode, modified the Multirequest Server = to use=20 a blocking type of connection. - Ported the code to the new ZThread (V2.3.1) implementation, several = design changes had been done since ZThread V2.2.11 . If at the time was the = best=20 threading library I had ever evaluated, now it is even better. [5-10-2003] (RK) - Found a defect that can probably be caused by the ZThread, cause I was able=20 to isolate it and couldnt find anything wrong. Gonna test with the 2.3.1 = release cause I am using the 2.2.11 (the multirequest server generates = that=20 error, so it is defective right now and not included in CVS). UPDATE: = The=20 defect was caused by the library, it disappear when ported to the new version. - Modified the NLIAbstractServer to make it easier to use and implement=20 servers using it. Modified the examples to show the changes. - Created a new example, a multirequest syncronized server using the In=20 Process Communication Port Extension (multirequestserver.bfg) at the Examples=20 project file. It shows the use of CountingSemaphores to implement an=20 asynchronic incoming requests processing list. - Minor error corrections in the In Process Communication Port Extension (IPCP=20 Extension) regarding threaded environment. [2-10-2003/4-10-2003] (RK) - Created and Debugged the one request server/client example using the = In=20 Process Communication Port Extension (inprocextension.bfg) at the = Examples=20 project file. - Added an ASynchronious request processing to the NLIConnectionFactory. - Added Server synchronization for abstract servers (they block after a=20 listenForConnections until a new connection is entablished). - Modifications to the whole library because of minor wrong assumptions=20 regarding thread implementation (more work needed yet, nothing too critical). [1-10-2003] (RK) - Implemented the NLInProcFactory and NLInProcConnection, still have to = test them, but the code is already in place and compiling. - Added a NLInProcAddress class to be used exclusively by the In Process = Connection Mechanism. [9-9-2003] (RK) - Added Runtime Exceptions classes, throw exceptions when appropiate. = For now=20 all unimplemented methods throw a NLEOperationUnsupported exception on = call. - Added a getConnectionType method to know what type of connection is = used. - Implemented NLController class, some missing details like how to find = out=20 the local IP addresses given by the network cards. - Completly redesigned the NLNetworkAddress, made it more a la java. = Added the=20 NLIP4NetworkAddress and NLIP6NetworkAddress will be layed out to be=20 implemented after everything is done. [8-9-2003] (RK) - Modify the signature of the internal methods at NLConnection class = (the ones=20 that are implemented to have a full fledge and working connection = object). - Implemented NLConnection. - Added extra documentation on the NLConnectionStatistics class. - Delete the createEmptyPacket method at NLController. - Fixed header dependency graph (I had ordered and removed useless = #include=20 directives). Enjoy... Greetings Red Knight ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. = SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED = US provide better services: Click here: = http://sourceforge.net/supporters.php _______________________________________________ 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.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 |
|
From: <red...@pr...> - 2003-10-10 00:28:02
|
Well as most of you will realize after seeing the latest diary entries, you will find that lots happened on the Network Library front this latest 2 weeks. The best announcement I can make is that we are ready to go for integration of the network library connection in the local xenocide client-server model. We can use an extension I had made named IPCP (In Process Communication Port) it is lighting fast, as fast as a memory copy (everybody is encouraged to see that is the pure truth :D) The source will be available in 1 or 2 days cause I cannot commit it from this public terminal so Mamutas will be in charge of it (sorry mamu)... Diary Entries [FREQUENTLY ASKED QUESTIONS] - Why do I get exceptions when run from the debugger, is that OK? + Most of the exceptions that you are going to get are OK, you have to make sure that you can continue with your work after it has been raised. ZThread is highly based on the Exception Mechanism to provide a clean task oriented framework, so be aware that raising some exceptions is OK provided that they get cough where they are supposed to. If that means that the application will fail it is NOT OK. - Can I use the current implementation of NetworkLib in W95/W98/WME? + You cant using the devpack provided, you will have to recompile the ZThread library to be able to use it in those OSs. [PROBLEMS TO DISCUSS] - Let the connection change its interface mechanism of communication with the application after it has been created. - How to make the servers cancel the listening after they are listening. [STILL MISSING IN ACTION] - Simulation mechanism (Have to learn ZThreads first). - Implementation of the NetworkLib internal protocol. (Have to learn ZThreads first). - Event Oriented Interface (Have to learn ZThreads first). - NLIP6NetworkAddress. - Implement the Controller deamon thread via the internal run method required by ZThread. - Get information about the IP4 or IP6 current protocol configuration (like what IP's our cards have and anything useful for the user/programmer). [8-10-2003/9-10-2003] (RK) - The definition of the NLIAbstractServer is even more near of being final, will have to test it a little further but it looks like I found an stable design. I EXPECT LOTS OF EVALUATION WORK, GUYS :D - Include ZThread V 2.3.1 compiled binaries into the proposed devpack + new docs section in the devpack + we are going to put it in CVS under devpack.borland name cause it has matured into a very stable devpack. - Modified the signature of the listenForConnections to handle listening errors. Updated both inprocconnection and multirequestserver. - Modified the IPCP Factory to fail with a NLEInvalidAddressType instead of an NLEInvalidParameter exception. - Added a new exception: NLEInvalidAddressType. It is used to signal an unsupported address type sent into a connection factory. For instance send a NLIP4Address into the IPCP Extension. - Added a new exception: NLEConnectionNotReady. It is used to signal a mistake from the user of the library and make the send method to fail cleanly, it is not intended to be caught just signal a mistake on the user part. However we will see cause if catching this exception makes the code more robust and easier to read and write we can review that rule, extensive testing is needed though. - Moved the class NLIConnectionEventListener inside the NLConnection class as a public inner class. - Modified the signature of the NLConnection's send, connect and disconnect methods to add the return of error information. - Blocking Mode is implemented and the In Process Communication Port Extension (IPCP) already support Blocking Mode, modified the Multirequest Server to use a blocking type of connection. - Ported the code to the new ZThread (V2.3.1) implementation, several design changes had been done since ZThread V2.2.11 . If at the time was the best threading library I had ever evaluated, now it is even better. [5-10-2003] (RK) - Found a defect that can probably be caused by the ZThread, cause I was able to isolate it and couldnt find anything wrong. Gonna test with the 2.3.1 release cause I am using the 2.2.11 (the multirequest server generates that error, so it is defective right now and not included in CVS). UPDATE: The defect was caused by the library, it disappear when ported to the new version. - Modified the NLIAbstractServer to make it easier to use and implement servers using it. Modified the examples to show the changes. - Created a new example, a multirequest syncronized server using the In Process Communication Port Extension (multirequestserver.bfg) at the Examples project file. It shows the use of CountingSemaphores to implement an asynchronic incoming requests processing list. - Minor error corrections in the In Process Communication Port Extension (IPCP Extension) regarding threaded environment. [2-10-2003/4-10-2003] (RK) - Created and Debugged the one request server/client example using the In Process Communication Port Extension (inprocextension.bfg) at the Examples project file. - Added an ASynchronious request processing to the NLIConnectionFactory. - Added Server synchronization for abstract servers (they block after a listenForConnections until a new connection is entablished). - Modifications to the whole library because of minor wrong assumptions regarding thread implementation (more work needed yet, nothing too critical). [1-10-2003] (RK) - Implemented the NLInProcFactory and NLInProcConnection, still have to test them, but the code is already in place and compiling. - Added a NLInProcAddress class to be used exclusively by the In Process Connection Mechanism. [9-9-2003] (RK) - Added Runtime Exceptions classes, throw exceptions when appropiate. For now all unimplemented methods throw a NLEOperationUnsupported exception on call. - Added a getConnectionType method to know what type of connection is used. - Implemented NLController class, some missing details like how to find out the local IP addresses given by the network cards. - Completly redesigned the NLNetworkAddress, made it more a la java. Added the NLIP4NetworkAddress and NLIP6NetworkAddress will be layed out to be implemented after everything is done. [8-9-2003] (RK) - Modify the signature of the internal methods at NLConnection class (the ones that are implemented to have a full fledge and working connection object). - Implemented NLConnection. - Added extra documentation on the NLConnectionStatistics class. - Delete the createEmptyPacket method at NLController. - Fixed header dependency graph (I had ordered and removed useless #include directives). Enjoy... Greetings Red Knight |
58 messages has been excluded from this view by a project administrator.
