xenocide-programming Mailing List for Xenocide (Page 3)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

No defines as I am confused about where will these really go.

centurion
I2luY2x1ZGUgPHV0aWxpdHkvY29tbW9uLmg+DQ0KI2luY2x1ZGUgPGNvbW1vbi94ZW5vcmVxdWlz
aXRlcy5oPg0NCm5hbWVzcGFjZSBYZW5vY2lkZQ17DQoNCmNsYXNzIERhdGVUaW1lDQp7DQpwdWJs
aWM6DQoNCiAgIERhdGVUaW1lICgpOw0KICAgRGF0ZVRpbWUgKCBjb25zdCBEYXRlVGltZSYgZGF0
ZVRpbWUgKTsNCiAgIERhdGVUaW1lICggVUludDggZGF5LCBVSW50OCBtb250aCwgVUludDMyIHll
YXIsIFVJbnQzMiB0aW1lSW5NaWxsaXNlY29uZHMgKTsNCiAgIERhdGVUaW1lICggVUludDggZGF5
LCBVSW50OCBtb250aCwgVUludDMyIHllYXIsIFVJbnQzMiBtaWxsaXNlY29uZCwgVUludDggc2Vj
b25kLCBVSW50OCBtaW51dGUsIFVJbnQ4IGhvdXIgKTsgICANCg0KICAgVUludDMyIGdldE1pbGxp
c2Vjb25kICgpIGNvbnN0Ow0KICAgVUludDggZ2V0U2Vjb25kICgpIGNvbnN0Ow0KICAgVUludDgg
Z2V0TWludXRlICgpIGNvbnN0Ow0KICAgVUludDggZ2V0SG91ciAoKSBjb25zdDsNCg0KICAgVUlu
dDggZ2V0RGF5ICgpIGNvbnN0Ow0KICAgVUludDggZ2V0TW9udGggKCkgY29uc3Q7DQogICBVSW50
MzIgZ2V0WWVhciAoKSBjb25zdDsNCg0KICAgSW50MzIgY29tcGFyZSAoIGNvbnN0IERhdGVUaW1l
JiBkYXRlVGltZSApIGNvbnN0Ow0KICAgc3RhdGljIEludDMyIGNvbXBhcmUgKCBjb25zdCBEYXRl
VGltZSYgZmlyc3QsIGNvbnN0IERhdGVUaW1lJiBzZWNvbmQgKTsNCiAgIA0KICAgVUludDMyIGdl
dFRpbWVJbk1pbGxpc2Vjb25kcyAoKSBjb25zdDsNCiAgIFVJbnQzMiBnZXRNaWxsaXNlY29uZHNT
aW5jZSAoIGNvbnN0IERhdGVUaW1lJiBkYXRlVGltZSApIGNvbnN0Ow0KDQogICBTdHJpbmcgdG9T
dHJpbmcgKCk7DQoNCn07DQoNCmNsYXNzIFN1bk9yYml0Q2FsY3VsYXRvcg0Kew0KcHVibGljOg0K
DQogICBTdW5PcmJpdENhbGN1bGF0b3IgKCBSZWFsIHJhZGl1cyApOw0KICAgdmlydHVhbCB+U3Vu
T3JiaXRDYWxjdWxhdG9yICgpOyANCg0KICAgVXRpbGl0eTo6VmVjdG9yMzxSZWFsPiBnZXRTdW5Q
b3NpdGlvbiAoIGNvbnN0IERhdGVUaW1lJiBkYXRlVGltZSApOw0KDQp9Ow0KDQ0KfSAvLyBYZW5v
Y2lkZQ==

Like this?
Getting data from XML into DOM object would not cause any problems - any
DOM-supporting parser will have a method to do the whole work. The problem
here would be that the DOM object and methods to access its content would be
parser specific, if we would change the parser, we more likely need to
change the way we extract data from the DOM.

From what I remember now, I think it would be possible to limit number of
methods used to access data from DOM. That basically would allow us to write
a wrapper (or proxy?) class to access data from the DOM, which would contain
parser specific method calls. Or we can even put those methods inside of XML
loader itself.

So, here is an example:

Class XNetDBViewer access class XNetTechnologyTreeInformation.
Class XNetTechnologyTreeInformation exposes methods giving the all
information about technology tree. XMLLoader loads any XML file and stores
its content in memory in the DOM. XMLLoader is parser specific class.
XMLLoader exposes methods for general DOM navigation and information
retrieval. XNetTechnologyTreeInformation uses those methods to extract
necessary info about technology tree. Note that
XNetTechnologyTreeInformation does not store any info in memory, but reads
it out from the DOM.

So, in this example, if we will decide to change the parser, the only class
needs to be updated is XMLLoader. But, if we will decide to change the XML
format, the only class needs to be updated is XNetTechnologyTreeInformation.
XMLLoader does not care about content of the file.
XNetTechnologyTreeInformation does not care about parser used.

Regards,
mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Chris
Phillips
Sent: Thursday, March 25, 2004 3:27 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] XML interface

That's along the lines of what I was thinking.  The
real tricky part is deciding how you store the data in
memory once it's loaded.  DOM modules seem to be
specific to Xerces and other parsers, so I'm not sure
if we'll be able to use this in outside classes.  As
far as I know there is no generic DOM class for C++
(am I wrong? - I hope I am..).  

This creates several difficult problems.  First,
loading everything into a DOM object and then from
that into another generic temporary storage object
which is then used to pass data into the actual object
is overly redundant.  Second, passing the DOM object
breaks the encapsulation we're trying for.  Third, we
may be more limited in terms of what functionality
we're able to use since we're doing an indirect
interface. 

So.. I'm still trying to figure out how we can make
this work..  The Xerces parser libs still don't work
for me (although most of the other Xerces libs do) so
that doesn't help.  I might just try and get something
like this working with expat, and someone else with a
Xerces comapatible system (most likely Windows) would
need to do a Xerces version. 

Regards,
chrisp

> I really favor that approach, what do you think
> about something like this:
> 
> class IExternalizable
> {
> public:
> 
>     // filename is the name without extension
>     void saveToFile ( String filename );
>     void loadFromFile ( String filename );
> };
> 
> Then we just have to reimplement the loading of
> every independent class
> that needs to be externalizable on its own.
> 
> Greetings
> Red Knight

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

Yeah, sooner or later a weapon needs to be reloaded, even if it means to put
more xenium into plasma cannon reactor.
On the other hand, isn't it the same as to have unlimited ammo as to have
very cheap clip which holds lots of charge, for example 10000? So, when you
buy your plasma cannon, you buy some xenium charge for few bucks and it will
not run off until the end of the game. :)

So, I suggest we should have all weapons with clips. We will balance the
number of charges and the price later. The only bad thing I can think of, is
that it will become a bit more annoying to buy a clip for every weapon, but
it still needs to be done for regular rifles and cannons. So, I think it
will be OK.

mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Jason
Jones
Sent: Saturday, March 20, 2004 11:15 AM
To: xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data

In my opinion, all weapons should have an ammo object (for consistency), 
but some ammo objects can be hidden and/or have unlimited ammunition.  
This handles things like laser rifles and psi-amps.

Personally I used the laser rifle as a standard weapon in the original, 
just because I didn't have to worry about ammo.  This is part of the 
original feel, but I think that there should be a tradeoff for sure.  
Perhaps the laser rifle is much weaker compared to the original game, or 
something. But if we make laser rifles not have the unlimited ammo, we 
break with that part of the original.

-----Original Message-----
From: fl...@ma...
To: xen...@li...
Date: Sat, 20 Mar 2004 11:28:02 -0300 (ART)
Subject: RE: [Xenocide-programming] XML facility-item data

> Basicly my reason to avoid non ammo charged weapons is that it is
> completly unrealistic, how they get the energy or round to fire???
> About
> non interim 'ammo' even if can be useful would need a reactor on the
> weapon :P, the point is that the user havent have to manufacture ammo
> to
> use it, something in my opinion is wrong from the gameplay viewpoint.
> 
> And I agree it simplify a lot the interface. (Simplicity is the key to
> understanding), and a earlier finished game :D
> 
> Greetings
> Red Knight
>

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

Mainly implementations (going barmy from thinking around interfaces), no
work this weekend due to RL duties.

centurion
That's along the lines of what I was thinking.  The
real tricky part is deciding how you store the data in
memory once it's loaded.  DOM modules seem to be
specific to Xerces and other parsers, so I'm not sure
if we'll be able to use this in outside classes.  As
far as I know there is no generic DOM class for C++
(am I wrong? - I hope I am..).  

This creates several difficult problems.  First,
loading everything into a DOM object and then from
that into another generic temporary storage object
which is then used to pass data into the actual object
is overly redundant.  Second, passing the DOM object
breaks the encapsulation we're trying for.  Third, we
may be more limited in terms of what functionality
we're able to use since we're doing an indirect
interface. 

So.. I'm still trying to figure out how we can make
this work..  The Xerces parser libs still don't work
for me (although most of the other Xerces libs do) so
that doesn't help.  I might just try and get something
like this working with expat, and someone else with a
Xerces comapatible system (most likely Windows) would
need to do a Xerces version. 

Regards,
chrisp

> I really favor that approach, what do you think
> about something like this:
> 
> class IExternalizable
> {
> public:
> 
>     // filename is the name without extension
>     void saveToFile ( String filename );
>     void loadFromFile ( String filename );
> };
> 
> Then we just have to reimplement the loading of
> every independent class
> that needs to be externalizable on its own.
> 
> Greetings
> Red Knight
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
>
https://lists.sourceforge.net/lists/listinfo/xenocide-programming

Hi Chrisp,

>> Pros:
>> - Only one class will deal with Xerces for a given XML file.
>
> We could switch XML parsers at our convenience.  So if one doesn't meet
> our
> needs we could easily axe it.

I really favor that approach, what do you think about something like this:

class IExternalizable
{
public:

    // filename is the name without extension
    void saveToFile ( String filename );
    void loadFromFile ( String filename );
};

Then we just have to reimplement the loading of every independent class
that needs to be externalizable on its own.

Greetings
Red Knight

On Friday 19 March 2004 16:42, mamutas wrote:
> For each XML file we would have, there would be a processing class written.
> Let take for example, technology tree. The class XMLTechTreeLoader will be
> the intermediate class between the rest of the game code and the Xerces.
> The class will use Xerces to read, parse, validate, etc. the XML file. The
> class will load the whole file data into memory in DOM structure. To do
> that the class should not really use many Xerces methods as I imagine: few
> methods to initialize and set parameters, then very few methods to initiate
> reading and creating of the DOM. The same class will expose set of methods
> to access the data from the DOM, which will be used by the rest of the
> game. Here some more Xerces methods will be used, but all in the same form.
> It would be possible to write a wrapper method for data retrieval calls, so
> all Xerces methods will be located in one place.

That seems sensible to me..

> There are some pros and cons about that approach.
> Cons:
> - There will be as many intermediate classes as many XML files.
> - If XML file will be changed, the intermediate class will need to be
> update to expose additional interfaces.

It seems to me like there should be ways to avoid both of these problems.  
Couldn't a generic class be created that contains the parsed XML?  We could 
also need to wrap the DOM class, although I'm not really sure on that.  It 
seems like the XML data would have to match what the loader needs, but I 
would think you could use a generic interface to recieve this data.  

> Pros:
> - Only one class will deal with Xerces for a given XML file.

We could switch XML parsers at our convenience.  So if one doesn't meet our 
needs we could easily axe it.

> What are your suggestions?

Only that I think we need to think about this more and be careful how we do 
it.  I'll try and take some time this week to come up with some more definite 
ideas.  

-chrisp

> ----- Original Message -----
> From: "Christopher C. Phillips" <chr...@sb...>
> To: <xen...@li...>
> Cc: "mamutas" <mam...@ho...>
> Sent: Thursday, March 18, 2004 10:49 PM
> Subject: Re: [Xenocide-programming] XML interface
>
> > It would be what you describe, but for two reasons.
> >
> > 1. To hide the complexity of parsing our XML files.  Basically we just
>
> send it
>
> > to an XMLParse() type function, and get back some type of data structure.
> > I'm not really sure what the best way to return the parsed data would be,
>
> but
>
> > I think we could come up with something sensible.
> >
> > 2. I think it's dangerous to have such a major dependency on the XML
> > libraries.  Some such dependencies (like Ogre) can't be avoided, but I
>
> think
>
> > it would be best to allow us to be able to swap XML libraries.  That way
>
> if
>
> > Xerces (or any library) becomes so outdated that it won't even compile
>
> (could
>
> > definitely see that happening, then we can just write a new Parser class
>
> and
>
> > we're not SOL.  Imagine having to sift through all the code and change
> > how the parsing is done. *shudder*
> >
> > -Chrisp
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming

Aoid using plain C implementations. Having those helper functions will be
very useful when doing the lighting positioning so you should repackage
them in an appropriate abstraction.

Greetings
Red Knight

> Does what is says on the tin, getSunPhi and getSunTheta give the direction
> of the sun at a given time.
>
> centurion

Does what is says on the tin, getSunPhi and getSunTheta give the direction
of the sun at a given time.

centurion
In my opinion, all weapons should have an ammo object (for consistency), 
but some ammo objects can be hidden and/or have unlimited ammunition.  
This handles things like laser rifles and psi-amps.

Personally I used the laser rifle as a standard weapon in the original, 
just because I didn't have to worry about ammo.  This is part of the 
original feel, but I think that there should be a tradeoff for sure.  
Perhaps the laser rifle is much weaker compared to the original game, or 
something. But if we make laser rifles not have the unlimited ammo, we 
break with that part of the original.

-----Original Message-----
From: fl...@ma...
To: xen...@li...
Date: Sat, 20 Mar 2004 11:28:02 -0300 (ART)
Subject: RE: [Xenocide-programming] XML facility-item data

> Basicly my reason to avoid non ammo charged weapons is that it is
> completly unrealistic, how they get the energy or round to fire???
> About
> non interim 'ammo' even if can be useful would need a reactor on the
> weapon :P, the point is that the user havent have to manufacture ammo
> to
> use it, something in my opinion is wrong from the gameplay viewpoint.
> 
> And I agree it simplify a lot the interface. (Simplicity is the key to
> understanding), and a earlier finished game :D
> 
> Greetings
> Red Knight
>

Hi all,

 Here is yet another slightly upgraded/transformed datainterfaces
directory, and questions as usual:
 - Do we need any more datainterface classes? It seems to me that
everything is covered (more or less, but enough classes to handle
everything).
 - How are we going to handle reserved time units when users change
weapons? If you put away your RH weapon while in "TUs reserved for aimed
shot" mode, and have enough TUs to aimed fire your LH weapon, not even a
warning happens? And if there is not enough TUs to do that, then mode
switches to "plain move"? what if this happens in the equipment screen?
 - Could dummy ICarriables be used in IAircraft's personnel assignment?
Say, we create a "representative" item for any soldier/HWP assigned to a
craft and then merrily use the ICarrierContainer's placing handlers?
 - Do aircraft weapons have damage types (maybe helping to differentiate
between beam and missile weapons), or all damage is created equal?
 - How will alien psionics be coded, since they don't have to use objects
to do psi?
 - Will we stick with the original "aimed fire 1 shot, snap fire 1 shot,
auto fire 3 shot" model, or implement different ammo usage (see auto
cannon/minigun discussions on the forums)?

centurion
Basicly my reason to avoid non ammo charged weapons is that it is
completly unrealistic, how they get the energy or round to fire??? About
non interim 'ammo' even if can be useful would need a reactor on the
weapon :P, the point is that the user havent have to manufacture ammo to
use it, something in my opinion is wrong from the gameplay viewpoint.

And I agree it simplify a lot the interface. (Simplicity is the key to
understanding), and a earlier finished game :D

Greetings
Red Knight

> Hi All,
>
> I'm trying to complete config.items.xml, and I ran into a sticky spot
> that requires an answer from on high.
>
> Two related questions:
>
> 1)	Are we going to have weapons that do not require ammo (sm/med/lg
> lasers, and laser cannon)?
>
> 2)	Are we going to have weapons that auto-magically eat xenium
> without an interim 'ammo'-item (plasma cannons)?
>
>
> Personally, I would vote 'no' to both, if it hasn't been decided.  It
> allows more granular control over game balance, and also simplifies
> coding.  If every 'weapon' object requires an 'ammo' object to be able
> to fire, that's the only interface we need to code for.  Exceptions to
> this mean more work, and more complicated code.
>
> -The Captain
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

Hi All,

I'm trying to complete config.items.xml, and I ran into a sticky spot
that requires an answer from on high.

Two related questions:

1)	Are we going to have weapons that do not require ammo (sm/med/lg
lasers, and laser cannon)?

2)	Are we going to have weapons that auto-magically eat xenium
without an interim 'ammo'-item (plasma cannons)?

Personally, I would vote 'no' to both, if it hasn't been decided.  It
allows more granular control over game balance, and also simplifies
coding.  If every 'weapon' object requires an 'ammo' object to be able
to fire, that's the only interface we need to code for.  Exceptions to
this mean more work, and more complicated code.

-The Captain

Well, your breakdown can be pretty much mapped one to one to the interfaces.

mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Friday, March 12, 2004 12:08 AM
To: xen...@li...
Subject: RE: [Xenocide-programming] datainterfaces update

Here's the breakdown that I'm using in config.items.xml.  It's fairly
comprehensive for everything that a carriable item needs to do:

weapon - carriable, has actions, does damage (eg: pistol, rifle,
grenade)

		autoshot(3-round burst)		(range, accuracy,
timeunits)
		snapshot(single round)		(range, accuracy,
timeunits)
		aimedshot(single round)		(range, accuracy,
timeunits)
		throw (single item)		(damage, accuracy,
timeunits)
		touch (hand-to-hand)		(damage, accuracy,
timeunits)
		prime (time delay)		(range, timeunits)

equipment - carriable, has actions	(eg: mind probe, motion scanner,
ammo)

		throw					(damage,
accuracy, timeunits)
		scan					(range,
accuracy, timeunits)
		heal					(wound, range,
accuracy, timeunits)
		psi					(power, cost,
range, accuracy, tiemunits)
		reload (ammo)			(unit, damage,
timeunits)

-The Captain

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Mamutas Plaukotas
Sent: Thursday, March 11, 2004 6:33 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] datainterfaces update

If you want particular set of objects to expose common behavior, then
you
should create an interface with methods for that behavior and inherit
all
objects from it.

In this case, I think good idea would be to have interface IHandHeld,
which
will define methods particularly for objects in the person hand. The
interface would have methods like: canThrow(), canShoot(), throw(),
shoot(),
etc. First two methods will let caller know whether the action is
available
(and actually does something). Second two methods will perform the
action
itself, if it is applicable to the object (shoot() may not be applicable
to
knives, so it will have no operation implementation).

Does it make sense?

Regards,
mamutas

-----Original Message-----
From: Tamas Terpai [mailto:te...@cs...] 
Sent: Wednesday, March 10, 2004 8:13 AM
To: mamutas
Subject: Re: [Xenocide-programming] datainterfaces update

On Sun, 7 Mar 2004, mamutas wrote:

> ICarriable just determines that item can be carried. If you want your
item
> be able to fire or thrown, then other appropriate interface must be
> employed.
>

And how do I determine which classes did the item in the player's hand
inherit? Try to call the appropriate function and catch the exception?
I'm
sorry, but it's absolutely unclear for me.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

Hi there,

Sorry for the delay. Somehow this thread was lost in between numerous number
of mail folders I have. But better late than never. :)

The latest version of GeoData.h looks fairly complete and usable for me.
Couple things though:
- Not sure whether we need any Base information there, since bases are
dynamic entities and will be handled by other classes.
- GeoData class itself will need probably more methods, but we can always
add them later.

Overall, very good work, which needs to be put in CVS. Why don't you put it
in CVS yourself, Chris? If you have any problems with that, let me know.

Regards,
Mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
fl...@ma...
Sent: Sunday, March 14, 2004 4:28 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] updated GeoData.h

Chrisp,

I had already programmed the reference counting template class, you can
check at the network library how to use it, since packets and connections
are counted referenced there... controller.h (in network library) and
references.h (in common package for the template).

BTW didnt check the headers yet, but you can send MAMUTAS the sources you
change to support linux on the utility package ( Sorry I cannot do CVS
commits from here, I guess I will owe more than one beer :D ).

About Geodata.h I will take a look, but it looks pretty well the last one
I checked and made comments, just what I had already told you. Will take
the file home and check it there.

Greetings
Red Knight

> I spent some time this morning trying to get GeoData.h working with the
> xeno utility librararies and in a compilable state.  I had to hack several
>  parts of the libraries to get it to compile in Linux, but it turned out
> OK.  Here is the result.  I'm still not sure how to best implement counted
> references.  I'll try and get that done this weekend.  The class should at
> least be more coherent now. :-)
>
> -chrisp
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.616 / Virus Database: 395 - Release Date: 3/8/2004

I think it would depends on how are we going to use the parser.

I imagine it similar to following:

For each XML file we would have, there would be a processing class written.
Let take for example, technology tree. The class XMLTechTreeLoader will be
the intermediate class between the rest of the game code and the Xerces. The
class will use Xerces to read, parse, validate, etc. the XML file. The class
will load the whole file data into memory in DOM structure. To do that the
class should not really use many Xerces methods as I imagine: few methods to
initialize and set parameters, then very few methods to initiate reading and
creating of the DOM. The same class will expose set of methods to access the
data from the DOM, which will be used by the rest of the game. Here some
more Xerces methods will be used, but all in the same form. It would be
possible to write a wrapper method for data retrieval calls, so all Xerces
methods will be located in one place.

There are some pros and cons about that approach.
Cons:
- There will be as many intermediate classes as many XML files.
- If XML file will be changed, the intermediate class will need to be update
to expose additional interfaces.
Pros:
- Only one class will deal with Xerces for a given XML file.

What are your suggestions?

Regards,
mamutas
----- Original Message ----- 
From: "Christopher C. Phillips" <chr...@sb...>
To: <xen...@li...>
Cc: "mamutas" <mam...@ho...>
Sent: Thursday, March 18, 2004 10:49 PM
Subject: Re: [Xenocide-programming] XML interface

>
> It would be what you describe, but for two reasons.
>
> 1. To hide the complexity of parsing our XML files.  Basically we just
send it
> to an XMLParse() type function, and get back some type of data structure.
> I'm not really sure what the best way to return the parsed data would be,
but
> I think we could come up with something sensible.
>
> 2. I think it's dangerous to have such a major dependency on the XML
> libraries.  Some such dependencies (like Ogre) can't be avoided, but I
think
> it would be best to allow us to be able to swap XML libraries.  That way
if
> Xerces (or any library) becomes so outdated that it won't even compile
(could
> definitely see that happening, then we can just write a new Parser class
and
> we're not SOL.  Imagine having to sift through all the code and change how
> the parsing is done. *shudder*
>
> -Chrisp

It would be what you describe, but for two reasons.  

1. To hide the complexity of parsing our XML files.  Basically we just send it 
to an XMLParse() type function, and get back some type of data structure.  
I'm not really sure what the best way to return the parsed data would be, but 
I think we could come up with something sensible.

2. I think it's dangerous to have such a major dependency on the XML 
libraries.  Some such dependencies (like Ogre) can't be avoided, but I think 
it would be best to allow us to be able to swap XML libraries.  That way if 
Xerces (or any library) becomes so outdated that it won't even compile (could 
definitely see that happening, then we can just write a new Parser class and 
we're not SOL.  Imagine having to sift through all the code and change how 
the parsing is done. *shudder*  

-Chrisp

On Wednesday 17 March 2004 10:48, mamutas wrote:
> Chris,
>
> I just want to clarify what XML interface do you mean. Is that a wrapper
> around Xerces which would hide the complexity (if any) of the native
> Xerces' methods? Or is that something else?
>
> Regards,
> mamutas
>
> ----- Original Message -----
> From: "Christopher C. Phillips" <chr...@sb...>
> To: <xen...@li...>
> Sent: Tuesday, March 16, 2004 11:24 PM
> Subject: [Xenocide-programming] XML interface
>
> > I'm pretty sure this has already been brought up and ixnayed, but I think
>
> it
>
> > would be worthwhile to have a standardized XML interface for Xenocide.
>
> The
>
> > only reason I can think of not doing this would be increased overhead..
>
> but
>
> > since we're already loading an 8MB library for XML parsing than it's not
> > really a factor.  The extra overhead of a wrapper might cause that
>
> overhead
>
> > to increase to 8.1MB, a non-issue.  Since we're striving for extreme
> > modularity, this concept seems like it would fit with the design
>
> philosophy.
>
> > Also, XML parsers can come and go, but the source code can remain that
>
> much
>
> > safer from obsolescence.  This would also be easily extensible, and
> > functionality that needs to be added can be created as needed.
> >
> > So if everyone agrees with me.. I would like to create such an interface.
> >
> > -chrisp
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Xenocide-programming mailing list
> > Xen...@li...
> > https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming

Chris,

I just want to clarify what XML interface do you mean. Is that a wrapper
around Xerces which would hide the complexity (if any) of the native Xerces'
methods? Or is that something else?

Regards,
mamutas

----- Original Message ----- 
From: "Christopher C. Phillips" <chr...@sb...>
To: <xen...@li...>
Sent: Tuesday, March 16, 2004 11:24 PM
Subject: [Xenocide-programming] XML interface

>
> I'm pretty sure this has already been brought up and ixnayed, but I think
it
> would be worthwhile to have a standardized XML interface for Xenocide.
The
> only reason I can think of not doing this would be increased overhead..
but
> since we're already loading an 8MB library for XML parsing than it's not
> really a factor.  The extra overhead of a wrapper might cause that
overhead
> to increase to 8.1MB, a non-issue.  Since we're striving for extreme
> modularity, this concept seems like it would fit with the design
philosophy.
> Also, XML parsers can come and go, but the source code can remain that
much
> safer from obsolescence.  This would also be easily extensible, and
> functionality that needs to be added can be created as needed.
>
> So if everyone agrees with me.. I would like to create such an interface.
>
> -chrisp
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

I'm pretty sure this has already been brought up and ixnayed, but I think it 
would be worthwhile to have a standardized XML interface for Xenocide.  The 
only reason I can think of not doing this would be increased overhead.. but 
since we're already loading an 8MB library for XML parsing than it's not 
really a factor.  The extra overhead of a wrapper might cause that overhead 
to increase to 8.1MB, a non-issue.  Since we're striving for extreme 
modularity, this concept seems like it would fit with the design philosophy.  
Also, XML parsers can come and go, but the source code can remain that much 
safer from obsolescence.  This would also be easily extensible, and 
functionality that needs to be added can be created as needed.

So if everyone agrees with me.. I would like to create such an interface.

-chrisp

Unfortunately spoke a little too soon.  Some of the libraries get linking 
errors.  The parsing ones in particular. :(  Still.. it's an improvement!  
Maybe I can get some insight on the xerces list.

On Tuesday 16 March 2004 11:19, mamutas wrote:
> Great news!
>
> ----- Original Message -----
> From: <chr...@ju...>
> To: <xen...@li...>
> Sent: Monday, March 15, 2004 11:00 PM
> Subject: Re: [Xenocide-programming] XML Parsing
>
> > Holy Bat Poo
> >
> > I actually got it to install and compile with my headers within 20
>
> minutes.. like you said.  All that wasted time.. still I'm glad it works.
> I'll have to take time to learn it all and make sure the libraries we'll be
> using work together, but it's way further than I got before. THANKS!
>
> > -chrisp
> >
> > ---------- Forwarded Message ----------
> > Chrisp,
> >
> > I had recently worked with Xerces on Windows and for my first impression
> > I saw that the libraries werent updated. So as I do for every evaluation
> > work I check their CVS and for my complete amaze I found that the latest
> > commit was 4 hours before I checked. And not to mention that lots of
> > files had been modified in the latest 10 days (at that time)... In short
> > Xerces C++ if far from death, you only have to grab the current sources
> > (as I did) and recompiling them in your platform... It took me like 20
> > minutes to make it work at home, not to mention that I had taken 10
> > minutes to review the documentation and took like 7 minutes to build the
> > whole monster.
> >
> > Needless to say that I wanted to check a little more though before
> > sending anything to the list, but well your message got me in the middle
> > of evaluation.
> >
> > To me it is always a mistake to rely on prebuilt binaries of every Open
> > Source library. On Open Source projects you should build your own
> > library. Windows is a little more library tolerant than Linux so it is
> > easier to make a library and put it in a devpack, linux is not that
> > programmers friendly.
> >
> > You can download it from here:
> > http://apache.datahost.com.ar/xml/xerces-c/xerces-c-current.zip
> >
> > Greetings
> > Red Knight
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Xenocide-programming mailing list
> > Xen...@li...
> > https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> >
> > ________________________________________________________________
> > The best thing to hit the Internet in years - Juno SpeedBand!
> > Surf the Web up to FIVE TIMES FASTER!
> > Only $14.95/ month - visit www.juno.com to sign up today!
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Xenocide-programming mailing list
> > Xen...@li...
> > https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming

Great news!

----- Original Message ----- 
From: <chr...@ju...>
To: <xen...@li...>
Sent: Monday, March 15, 2004 11:00 PM
Subject: Re: [Xenocide-programming] XML Parsing

>
>
> Holy Bat Poo
>
> I actually got it to install and compile with my headers within 20
minutes.. like you said.  All that wasted time.. still I'm glad it works.
I'll have to take time to learn it all and make sure the libraries we'll be
using work together, but it's way further than I got before. THANKS!
>
> -chrisp
>
> ---------- Forwarded Message ----------
> Chrisp,
>
> I had recently worked with Xerces on Windows and for my first impression I
> saw that the libraries werent updated. So as I do for every evaluation
> work I check their CVS and for my complete amaze I found that the latest
> commit was 4 hours before I checked. And not to mention that lots of files
> had been modified in the latest 10 days (at that time)... In short Xerces
> C++ if far from death, you only have to grab the current sources (as I
> did) and recompiling them in your platform... It took me like 20 minutes
> to make it work at home, not to mention that I had taken 10 minutes to
> review the documentation and took like 7 minutes to build the whole
> monster.
>
> Needless to say that I wanted to check a little more though before sending
> anything to the list, but well your message got me in the middle of
> evaluation.
>
> To me it is always a mistake to rely on prebuilt binaries of every Open
> Source library. On Open Source projects you should build your own library.
> Windows is a little more library tolerant than Linux so it is easier to
> make a library and put it in a devpack, linux is not that programmers
> friendly.
>
> You can download it from here:
> http://apache.datahost.com.ar/xml/xerces-c/xerces-c-current.zip
>
> Greetings
> Red Knight
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
> ________________________________________________________________
> The best thing to hit the Internet in years - Juno SpeedBand!
> Surf the Web up to FIVE TIMES FASTER!
> Only $14.95/ month - visit www.juno.com to sign up today!
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

I can commit any code I write to CVS from here.  I have quite a bit of experience in dealing with CVS.  I just want to make and sure my code is in line with what we need before I do any commits.  Especially since I haven't written a significant amount of C++ code since '98.  Many standards have changed since then and the new libraries obviously work differently.  Since then I've done mostly Perl, and now PHP.  Nothing is more annoying (and sometimes dangerous) than a messy repository.

As for the libraries, I would like to try and maintain a Linux development branch of the entire project, but I doubt I'll have time for such an undertaking.  Meanwhile, there is plenty of low level code that can be written on pretty much any platform.

-chrisp

---------- Forwarded Message ----------
Chrisp,

I had already programmed the reference counting template class, you can
check at the network library how to use it, since packets and connections
are counted referenced there... controller.h (in network library) and
references.h (in common package for the template).

BTW didnt check the headers yet, but you can send MAMUTAS the sources you
change to support linux on the utility package ( Sorry I cannot do CVS
commits from here, I guess I will owe more than one beer :D ).

About Geodata.h I will take a look, but it looks pretty well the last one
I checked and made comments, just what I had already told you. Will take
the file home and check it there.

Greetings
Red Knight

> I spent some time this morning trying to get GeoData.h working with the
> xeno utility librararies and in a compilable state.  I had to hack several
>  parts of the libraries to get it to compile in Linux, but it turned out
> OK.  Here is the result.  I'm still not sure how to best implement counted
> references.  I'll try and get that done this weekend.  The class should at
> least be more coherent now. :-)
>
> -chrisp
>

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming

________________________________________________________________
The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!

Chrisp,

I had already programmed the reference counting template class, you can
check at the network library how to use it, since packets and connections
are counted referenced there... controller.h (in network library) and
references.h (in common package for the template).

BTW didnt check the headers yet, but you can send MAMUTAS the sources you
change to support linux on the utility package ( Sorry I cannot do CVS
commits from here, I guess I will owe more than one beer :D ).

About Geodata.h I will take a look, but it looks pretty well the last one
I checked and made comments, just what I had already told you. Will take
the file home and check it there.

Greetings
Red Knight

> I spent some time this morning trying to get GeoData.h working with the
> xeno utility librararies and in a compilable state.  I had to hack several
>  parts of the libraries to get it to compile in Linux, but it turned out
> OK.  Here is the result.  I'm still not sure how to best implement counted
> references.  I'll try and get that done this weekend.  The class should at
> least be more coherent now. :-)
>
> -chrisp
>

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

xenocide-programming Mailing List for Xenocide (Page 3)

xenocide-programming — The Programming Xenocide Mailing List