xenocide-programming — The Programming Xenocide Mailing List

[Xenocide-programming] updated GeoData.h

[<chr...@ju...>]

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

Re: [Xenocide-programming] GeoData.h

[<chr...@ju...>]

Since I'm developing on Linux I was just using a generic list and string class for the time being.  The functions that were missing returns were intended to be bool, but void will work fine as well.  I'm not sure why I made that id static... it must have made since to me at the time.  :-/  
I figured the entire class would be loaded via a pointer.. but I haven't used counted reference pointers before, so am not sure how they work.  I'll have to do some research of my own on that. :)  I'll also try to integrate the STL classes with what I have.

What I'm mostly concerned about is the functionality.  Does this class do what we want it to??  There have been many different versions of this class and I just want to make sure it's meeting the requirements.  Then I was going to add the finishing touches..

-chrisp

---------- Forwarded Message ----------
Quoting chr...@ju...:

> Here's a new version of GeoData.h.
> 
> If this is just used to load data in the start of the game, then I'm not sure
> if all of the virtual classes are necessary.  So.. this is much more basic. 
> After the previous discussion, it seems to me that there is not much to this
> class.
> 
> -chrisp
> 

Minor details:

#include"String.hh"
#include"List.h"

import the xenocide utility pack for it. And use the STL ones for lists and
strings (String in Xenocide).

The enums naming do not conform to the standard

enum terrainType { 
         GRASSLAND, 
         FOREST, 
         TROPICAL_RAINFOREST,
         TEMPERATE_RAINFOREST, 
         PLAINS, 
         BADLANDS,
         DESERT, 
         SAHARA, 
         TUNDRA, 
         ARCTIC, 
         COAST,
         WATER  //need to know that we can't go here
      };

should be:

enum TERRAINTYPE 
{
    _TTFOREST,
    _TTTROPICALRAINFOREST,
    _TTTEMPERATERAINFOREST,
...
    _TTWATER
};

Species is not an enum, but for now is ok as the other part is not coded yet.

Some functions do not have return values.

addCountry( Country newCountries );
setDescriptor( String newDescription );

should be:

void addCountry( Country newCountries );
void setDescriptor( String newDescription );

Be careful with this: 

static Real id;

That means there is only one instance for all object.... Each continent may have
an ID if it really needed at all.

As you dont use pointers anywhere, there is no way to do defered loading if the
memory requirements of this class gets too big. If you want to be safe, use
counted referenced pointers from the utility package.

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!

Re: [Xenocide-programming] GeoData.h

[<red...@pr...>]

Quoting chr...@ju...:

> Here's a new version of GeoData.h.
> 
> If this is just used to load data in the start of the game, then I'm not sure
> if all of the virtual classes are necessary.  So.. this is much more basic. 
> After the previous discussion, it seems to me that there is not much to this
> class.
> 
> -chrisp
> 

Minor details:

#include"String.hh"
#include"List.h"

import the xenocide utility pack for it. And use the STL ones for lists and
strings (String in Xenocide).

The enums naming do not conform to the standard

enum terrainType { 
         GRASSLAND, 
         FOREST, 
         TROPICAL_RAINFOREST,
         TEMPERATE_RAINFOREST, 
         PLAINS, 
         BADLANDS,
         DESERT, 
         SAHARA, 
         TUNDRA, 
         ARCTIC, 
         COAST,
         WATER  //need to know that we can't go here
      };

should be:

enum TERRAINTYPE 
{
    _TTFOREST,
    _TTTROPICALRAINFOREST,
    _TTTEMPERATERAINFOREST,
...
    _TTWATER
};

Species is not an enum, but for now is ok as the other part is not coded yet.

Some functions do not have return values.

addCountry( Country newCountries );
setDescriptor( String newDescription );

should be:

void addCountry( Country newCountries );
void setDescriptor( String newDescription );

Be careful with this: 

static Real id;

That means there is only one instance for all object.... Each continent may have
an ID if it really needed at all.

As you dont use pointers anywhere, there is no way to do defered loading if the
memory requirements of this class gets too big. If you want to be safe, use
counted referenced pointers from the utility package.

Greetings
Red Knight

Re: [Xenocide-programming] XML Parsing

[<fl...@ma...>]

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

[Xenocide-programming] XML Parsing

[<chr...@ju...>]

Sorry to re-open this particular can of worms, but it is time to get an XML parser that works.

To review my earlier experiences with Xercesc.. I downloaded the Xercesc libraries and spent as long as a few months (off and on) trying to get them work.  I don't run an NT based windows and I run gcc 3.3.2 using Linux (which is what I pretty much use for everything besides some games and sound related programs).  Xercesc requires NT based Windows, and in Linux it seems broken with newer versions of gcc.  This prevented me from being able to compile any actual Xercesc code.  I did take a lot of time to go through the API and see how it worked, however.  I posted these findings to this list and moved on.  Since then I've been keeping an tried out alternative parsers.  I believe the best of which to be expat.  I downloaded, installed, and was XML parsing with expat within a matter minutes.  The interface was straightforward and seemed to have more than enough features to meet our needs.

Other open source projects that use expat for XML parsing include  Mozilla, the Perl XML parsing library, and the PHP XML parsing library. I think it's likely that our XML parsing needs won't exceed the requirements of the former pojects, so expat should be more than adequate.  It also has an intuitive interface. This is very much unlike Xerces which requires you to spend a massive amount of time learning how to interact with the libraries.  Just figuring WHICH libraries to include is difficult in Xerces.  

Expat is C based, but so are many standard C++ libraries.  I don't think that would have a negative impact.  The interface lends itself very well to object oriented programming and is usually used in C++ apps.

Well that's my 2 cents.  The question is what does everyone want to spend their time developing on?  Many classes will require an XML interface, so this is really an important aspect of the project.  Expat seems to be an excellent combination of speed, ease of use, and stability.

-chrisp

________________________________________________________________
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!

[Xenocide-programming] GeoData.h

[<chr...@ju...>]

Here's a new version of GeoData.h.

If this is just used to load data in the start of the game, then I'm not sure if all of the virtual classes are necessary.  So.. this is much more basic.  After the previous discussion, it seems to me that there is not much to this class.

-chrisp

RE: [Xenocide-programming] datainterfaces update

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

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

RE: [Xenocide-programming] datainterfaces update

[Mamutas P. <ma...@pr...>]

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
 

Re: [Xenocide-programming] mailing list dupes

[Tommy P. <to...@ho...>]

Andrew Pokrovski wrote:
> Perhaps the answer may be as simple as the following: Check where you're 
> sending the reply email. If you click 'reply to all' or whatever, it'll 
> reply to the mailing list in addition to the person who first sent out 
> the message. I figure this is the case because when I get duplicates, 
> they're usually addressed both to me and the mailing list.
> 
> So, check where the reply is going to, and make sure it only goes to the 
> mailing list.
> 

Or, everyone could just remember to use the Reply-To: header and set it 
to xen...@li....

All e-mail clients worth the name should have this ability.

Try to reply to this mail, what do you see in the To: field?

Tommy "LordT" Persson
to...@ho...

RE: [Xenocide-programming] mailing list dupes

[Andrew P. <a_p...@ho...>]

Perhaps the answer may be as simple as the following: Check where you're 
sending the reply email. If you click 'reply to all' or whatever, it'll 
reply to the mailing list in addition to the person who first sent out the 
message. I figure this is the case because when I get duplicates, they're 
usually addressed both to me and the mailing list.

So, check where the reply is going to, and make sure it only goes to the 
mailing list.

Andrew Pokrovski / "NickAragua"

_________________________________________________________________
Get a FREE online computer virus scan from McAfee when you click here. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Fw: Re: [Xenocide-programming] GeoData.h

[<chr...@ju...>]

Sounds goog to me. -chrisp

---------- Forwarded Message ----------
I just replied to Chrisp's email, where I basically stated the same ideas.
We can implement swappable terrain in the separate data storage, which would
have higher priority over static data.

Regards,
mamutas

----- Original Message ----- 
From: "Jason Jones" <ja...@ki...>
To: <xen...@li...>
Sent: Sunday, March 07, 2004 2:00 PM
Subject: RE: [Xenocide-programming] GeoData.h


> Seems to me that we can do the swappable terrain type thing AND
> implement a seperate class for save data.  If we try to throw too much
> gamestate into geodata it will wind up with a bunch of stuff that
> doesn't relate.  Remember save games have to include player name,
> soldier names, research states, funding, etc.
>
> The changeable terrain thing (I think) is simply a matter of granularity
> of tiles.  The geodata object in memory during the game has to know what
> terrain type each tile of the world is.  This can of course be changed
> by a scripting choice or mod dll (or post 1.0 code we write).  So long
> as it doesn't store terrain type as continent-sized chunks (maybe city-
> sized?) a mod can replace tiles dynamically as the situation warrants.
>
> That is the way I see it, anyway.  Someone correct me if I have anything
> wrong, as I'm just getting my brain around the project.
>
> -Thalo
>


-------------------------------------------------------
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!

[Xenocide-programming] mailing list dupes

[breunor <br...@pr...>]

I receive the daily archive email rather than single emails, and there was 
3 of RK's message in there. Normally I never receive dupes, perhaps his 
ISP had a hiccup and copied it out twice?

Breunor

Re: [Xenocide-programming] GeoData.h

[mamutas <mam...@ho...>]

Hello Cpt.,

I am glad to hear that you are still on those XMLs! :)

One thing I think I need to mention, is that you should try to implement
your XML for very dynamic data. That is the craft be anywhere on the globe,
the soldier could be anywhere between bases, crafts and transfers. Don't
concentrate on Battleview data so far, nail it for Planetview, ok?

Regarding, defintion of static data, there was some talk earlier about using
Tuple (if I spell it correctly) - basically squares which has information
about adjusting squares, and where each square could be divided in 4 smaller
squares. :) I never dealt with such data structure, that is why I am giving
you strawman definition :)

We need to work out how do we translate coordinate on the globe to screen
coordinates and vice versa. I hope to have that resolved soon.

Regards,
mamutas

----- Original Message ----- 
From: "Cpt. Boxershorts" <cpt...@pr...>
To: <xen...@li...>
Sent: Sunday, March 07, 2004 4:34 PM
Subject: RE: [Xenocide-programming] GeoData.h


> I'm currently working on a file layout for x-corps base info, which will
> have that most of that information.  I got a little sidetracked on the
> config layouts, but I'm back on this.
>
> How will country/terrain borders be defined? A series of coordinates
> defining a polygon?
>
> Are we using basic latitude/longitude for geosphere coordinates, or
> something that translates better to base-10 calculations?
>
> -The Captain

Re: [Xenocide-programming] GeoData.h

[mamutas <mam...@ho...>]

I just replied to Chrisp's email, where I basically stated the same ideas.
We can implement swappable terrain in the separate data storage, which would
have higher priority over static data.

Regards,
mamutas

----- Original Message ----- 
From: "Jason Jones" <ja...@ki...>
To: <xen...@li...>
Sent: Sunday, March 07, 2004 2:00 PM
Subject: RE: [Xenocide-programming] GeoData.h


> Seems to me that we can do the swappable terrain type thing AND
> implement a seperate class for save data.  If we try to throw too much
> gamestate into geodata it will wind up with a bunch of stuff that
> doesn't relate.  Remember save games have to include player name,
> soldier names, research states, funding, etc.
>
> The changeable terrain thing (I think) is simply a matter of granularity
> of tiles.  The geodata object in memory during the game has to know what
> terrain type each tile of the world is.  This can of course be changed
> by a scripting choice or mod dll (or post 1.0 code we write).  So long
> as it doesn't store terrain type as continent-sized chunks (maybe city-
> sized?) a mod can replace tiles dynamically as the situation warrants.
>
> That is the way I see it, anyway.  Someone correct me if I have anything
> wrong, as I'm just getting my brain around the project.
>
> -Thalo
>

Re: [Xenocide-programming] GeoData.h

[mamutas <mam...@ho...>]

Chrisp,

I understand where do you come from. I actually even expected a similar
reply. :)

I think that you attempt to put too much information into the one class.
That is very dangerous approach especially when information is not related
to each other tightly. OOP principles suggest implementation of very
granular objects - objects which are very selfcontained and very limited in
scope of data and functionality.

Actually, your ideas made me think, that whole GeoData approach is not
correct at all. We try to put too much data in it. It must be split in
multiple objects, which serve only specific data. Here is what coming to my
mind:
-- geographical information - terrain, continents, seas, etc.
-- political information - countries, regions (like Europe, North America,
etc.)
-- demographical information - cities, villages, cost of building a base,
etc.

So, when I need to know the landscape, I ask one class. There could be a
super class on top of all mentioned above, which will handle all data, but
we might wait till we see the need for it.

As regarding destroying cities and changing terrain, then nothing prevents
us to combine dynamic data with static. Let say, you have class with all
city information in the static storage. The same class has a dynamic
storage, which has higher priority than static. If one city got destroyed,
it is noted in dynamic storage, so when next time anyone asks about that
city, the dynamic data will be served. That dynamic data will be stored next
to game save stats. What do you say?

As for whole game state, then Cpt. Boxershorts is working on XML file. We
started this way, but eventually there will be a class which will work with
that XML file and represent all dynamic game data: research, bases, troops,
crafts, etc.

Regards,
mamutas
----- Original Message ----- 
From: <chr...@ju...>
To: <xen...@li...>
Sent: Saturday, March 06, 2004 11:55 PM
Subject: RE: [Xenocide-programming] GeoData.h


>
>
> We also may want to think about how we want to save the state of the game.
We'll want to be able to save all crash/base/terror locations and and the
locations of any aircraft in the air.  This is why I initially put all of
this in GeoData.  I was thinking of this as being the class that essentially
stored the state of the game.  So this state could be saved and reloaded
with ease.  Of course starting a new game wouldn't require all of this other
data.  But, saving a game in progress will.  Doing it this way would also
allow the terrain data to be dynamic.  This may sound silly, but I can think
of situations where it could be very beneficial.  Imagine the type of
emotional impact that seeing Earth's cities destroyed would have.  Near the
end of the game the Aliens could be given the ability to destroy entire
cities or regions.  Of course this would have large economic and political
impacts that would make the game much more challenging and engaging.
Storing the data this way would allow us to swap terrain types to 'city
ruins' or 'nuclear wasteland.'  I think we could take the concept of putting
the Earth in danger much much farther.  I know this is all post v1.0, but I
think we should be creating an architecture designed to be easily extendable
for v2.0.  That way 2.0 isn't a patch job or rewrite.  That's why I think we
should store this data in GeoData.  It doesn't mean that every time an air
vehicle's position changes that GeoData gets updated.  The save routine can
do this at save-time, and the entire GeoData class can then be written to
disk.  We could do the same thing with BattleScape using a BattleData class.
>
> -chrisp

Re: [Xenocide-programming] datainterfaces update

[mamutas <mam...@ho...>]

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.

mamutas
----- Original Message ----- 
From: "Tamas Terpai" <te...@cs...>
To: <xen...@li...>
Sent: Saturday, March 06, 2004 10:31 AM
Subject: [Xenocide-programming] datainterfaces update


> I'm not entirely sure about passive ICarriable; how will the battlescape
> engine decide whether a unit can fire with the (per definitionem)
> ICarriable item in its hand? IMO it would be logical to have basic usage
> types put into all battlescape items, so that one just overloads the
> throw(...) for grenades and such, maybe using another class that will
> be intantiated during mission loading?
>
> centurion
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004
>
>
>

Re: [Xenocide-programming] mailing list dupes?

[Jason J. <ja...@ki...>]

I got three...  maybe you're signed up twice somehow?

-----Original Message-----
From: "Cpt. Boxershorts" <cpt...@pr...>
To: <xen...@li...>
Date: Sun, 7 Mar 2004 16:05:09 -0800
Subject: [Xenocide-programming] mailing list dupes?

> 
> I just got six copies of this message...and I get doubles of messages
> about 50% of the time.  Anyone know what gives?
> 
> -The Captain
> 
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Red Knight
> Sent: Sunday, March 07, 2004 3:43 PM
> To: Tamas Terpai
> Cc: xen...@li...
> Subject: Re: [Xenocide-programming] datainterfaces update
> 
> Hi Tamas,
> 
> I will check the new update at home in the next days and get back to 
> you then... See if you propose new interfaces.
> 
> > I'm not entirely sure about passive ICarriable; how will the 
> battlescape
> > engine decide whether a unit can fire with the (per definitionem)
> > ICarriable item in its hand? IMO it would be logical to have basic 
> usage
> > types put into all battlescape items, so that one just overloads the
> > throw(...) for grenades and such, maybe using another class that will
> > be intantiated during mission loading?
> 
> ICarriable is just a view or the object, that is called in OOP theory 
> as View Inheritance (from Meyer)... You give different views to the 
> different systems, the carrying system (the one that ICarriable is a 
> member of) do not need/want to know whether the object is a gun, a 
> granade, a corpse or whatever you may think of... For instance, 
> Missiles are carriable stuff too, but cannot be carried by agents 
> because of its heavy weight and size, but they could nonetheless from 
> the Carrying system view (if not where for its properties). 
> 
> So there is no reason to let the carrying system to know anything 
> about what it is being carried. ICarriable is a passive entity, 
> because, for active behaivior you have other views to apply to the 
> object (via inheritance) using its cooresponding interface.
> 
> Hope that helps to clarify the issue.
> 
> Greetings
> Red Knight
> 
> Simplicity is the key to understanding.
> 
> 
> -------------------------------------------------------
> 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

Re: [Xenocide-programming] mailing list dupes?

[<fl...@ma...>]

Could be, but i guess it is this sucky webmail... Sorry for the dupes.

Greetings
Red Knight

>
> I just got six copies of this message...and I get doubles of messages
> about 50% of the time.  Anyone know what gives?
>
> -The Captain
>
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Red Knight
> Sent: Sunday, March 07, 2004 3:43 PM
> To: Tamas Terpai
> Cc: xen...@li...
> Subject: Re: [Xenocide-programming] datainterfaces update
>
> Hi Tamas,
>
> I will check the new update at home in the next days and get back to
> you then... See if you propose new interfaces.
>
>> I'm not entirely sure about passive ICarriable; how will the
> battlescape
>> engine decide whether a unit can fire with the (per definitionem)
>> ICarriable item in its hand? IMO it would be logical to have basic
> usage
>> types put into all battlescape items, so that one just overloads the
>> throw(...) for grenades and such, maybe using another class that will
>> be intantiated during mission loading?
>
> ICarriable is just a view or the object, that is called in OOP theory
> as View Inheritance (from Meyer)... You give different views to the
> different systems, the carrying system (the one that ICarriable is a
> member of) do not need/want to know whether the object is a gun, a
> granade, a corpse or whatever you may think of... For instance,
> Missiles are carriable stuff too, but cannot be carried by agents
> because of its heavy weight and size, but they could nonetheless from
> the Carrying system view (if not where for its properties).
>
> So there is no reason to let the carrying system to know anything
> about what it is being carried. ICarriable is a passive entity,
> because, for active behaivior you have other views to apply to the
> object (via inheritance) using its cooresponding interface.
>
> Hope that helps to clarify the issue.
>
> Greetings
> Red Knight
>
> Simplicity is the key to understanding.
>
>
> -------------------------------------------------------
> 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
>

[Xenocide-programming] mailing list dupes?

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

I just got six copies of this message...and I get doubles of messages
about 50% of the time.  Anyone know what gives?

-The Captain


-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Red Knight
Sent: Sunday, March 07, 2004 3:43 PM
To: Tamas Terpai
Cc: xen...@li...
Subject: Re: [Xenocide-programming] datainterfaces update

Hi Tamas,

I will check the new update at home in the next days and get back to 
you then... See if you propose new interfaces.

> I'm not entirely sure about passive ICarriable; how will the 
battlescape
> engine decide whether a unit can fire with the (per definitionem)
> ICarriable item in its hand? IMO it would be logical to have basic 
usage
> types put into all battlescape items, so that one just overloads the
> throw(...) for grenades and such, maybe using another class that will
> be intantiated during mission loading?

ICarriable is just a view or the object, that is called in OOP theory 
as View Inheritance (from Meyer)... You give different views to the 
different systems, the carrying system (the one that ICarriable is a 
member of) do not need/want to know whether the object is a gun, a 
granade, a corpse or whatever you may think of... For instance, 
Missiles are carriable stuff too, but cannot be carried by agents 
because of its heavy weight and size, but they could nonetheless from 
the Carrying system view (if not where for its properties). 

So there is no reason to let the carrying system to know anything 
about what it is being carried. ICarriable is a passive entity, 
because, for active behaivior you have other views to apply to the 
object (via inheritance) using its cooresponding interface.

Hope that helps to clarify the issue.

Greetings
Red Knight

Simplicity is the key to understanding.


-------------------------------------------------------
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

Re: [Xenocide-programming] datainterfaces update

[Red K. <red...@pr...>]

Hi Tamas,

I will check the new update at home in the next days and get back to 
you then... See if you propose new interfaces.

> I'm not entirely sure about passive ICarriable; how will the 
battlescape
> engine decide whether a unit can fire with the (per definitionem)
> ICarriable item in its hand? IMO it would be logical to have basic 
usage
> types put into all battlescape items, so that one just overloads the
> throw(...) for grenades and such, maybe using another class that will
> be intantiated during mission loading?

ICarriable is just a view or the object, that is called in OOP theory 
as View Inheritance (from Meyer)... You give different views to the 
different systems, the carrying system (the one that ICarriable is a 
member of) do not need/want to know whether the object is a gun, a 
granade, a corpse or whatever you may think of... For instance, 
Missiles are carriable stuff too, but cannot be carried by agents 
because of its heavy weight and size, but they could nonetheless from 
the Carrying system view (if not where for its properties). 

So there is no reason to let the carrying system to know anything 
about what it is being carried. ICarriable is a passive entity, 
because, for active behaivior you have other views to apply to the 
object (via inheritance) using its cooresponding interface.

Hope that helps to clarify the issue.

Greetings
Red Knight

Simplicity is the key to understanding.

Re: [Xenocide-programming] datainterfaces update

[Red K. <red...@pr...>]

Hi Tamas,

I will check the new update at home in the next days and get back to 
you then... See if you propose new interfaces.

> I'm not entirely sure about passive ICarriable; how will the 
battlescape
> engine decide whether a unit can fire with the (per definitionem)
> ICarriable item in its hand? IMO it would be logical to have basic 
usage
> types put into all battlescape items, so that one just overloads the
> throw(...) for grenades and such, maybe using another class that will
> be intantiated during mission loading?

ICarriable is just a view or the object, that is called in OOP theory 
as View Inheritance (from Meyer)... You give different views to the 
different systems, the carrying system (the one that ICarriable is a 
member of) do not need/want to know whether the object is a gun, a 
granade, a corpse or whatever you may think of... For instance, 
Missiles are carriable stuff too, but cannot be carried by agents 
because of its heavy weight and size, but they could nonetheless from 
the Carrying system view (if not where for its properties). 

So there is no reason to let the carrying system to know anything 
about what it is being carried. ICarriable is a passive entity, 
because, for active behaivior you have other views to apply to the 
object (via inheritance) using its cooresponding interface.

Hope that helps to clarify the issue.

Greetings
Red Knight

Simplicity is the key to understanding.

Re: [Xenocide-programming] datainterfaces update

[Red K. <red...@pr...>]

Hi Tamas,

I will check the new update at home in the next days and get back to 
you then... See if you propose new interfaces.

> I'm not entirely sure about passive ICarriable; how will the 
battlescape
> engine decide whether a unit can fire with the (per definitionem)
> ICarriable item in its hand? IMO it would be logical to have basic 
usage
> types put into all battlescape items, so that one just overloads the
> throw(...) for grenades and such, maybe using another class that will
> be intantiated during mission loading?

ICarriable is just a view or the object, that is called in OOP theory 
as View Inheritance (from Meyer)... You give different views to the 
different systems, the carrying system (the one that ICarriable is a 
member of) do not need/want to know whether the object is a gun, a 
granade, a corpse or whatever you may think of... For instance, 
Missiles are carriable stuff too, but cannot be carried by agents 
because of its heavy weight and size, but they could nonetheless from 
the Carrying system view (if not where for its properties). 

So there is no reason to let the carrying system to know anything 
about what it is being carried. ICarriable is a passive entity, 
because, for active behaivior you have other views to apply to the 
object (via inheritance) using its cooresponding interface.

Hope that helps to clarify the issue.

Greetings
Red Knight

Simplicity is the key to understanding.

RE: [Xenocide-programming] GeoData.h

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

I'm currently working on a file layout for x-corps base info, which will
have that most of that information.  I got a little sidetracked on the
config layouts, but I'm back on this.

How will country/terrain borders be defined? A series of coordinates
defining a polygon?  

Are we using basic latitude/longitude for geosphere coordinates, or
something that translates better to base-10 calculations?

-The Captain



-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Jason Jones
Sent: Sunday, March 07, 2004 12:01 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] GeoData.h

Seems to me that we can do the swappable terrain type thing AND 
implement a seperate class for save data.  If we try to throw too much 
gamestate into geodata it will wind up with a bunch of stuff that 
doesn't relate.  Remember save games have to include player name, 
soldier names, research states, funding, etc.

The changeable terrain thing (I think) is simply a matter of granularity

of tiles.  The geodata object in memory during the game has to know what

terrain type each tile of the world is.  This can of course be changed 
by a scripting choice or mod dll (or post 1.0 code we write).  So long 
as it doesn't store terrain type as continent-sized chunks (maybe city-
sized?) a mod can replace tiles dynamically as the situation warrants.

That is the way I see it, anyway.  Someone correct me if I have anything

wrong, as I'm just getting my brain around the project.

-Thalo

-----Original Message-----
From: chr...@ju...
To: xen...@li...
Date: Sun, 7 Mar 2004 05:55:13 GMT
Subject: RE: [Xenocide-programming] GeoData.h

> 
> 
> We also may want to think about how we want to save the state of the
> game.  We'll want to be able to save all crash/base/terror locations
> and and the locations of any aircraft in the air.  This is why I
> initially put all of this in GeoData.  I was thinking of this as being
> the class that essentially stored the state of the game.  So this
state
> could be saved and reloaded with ease.  Of course starting a new game
> wouldn't require all of this other data.  But, saving a game in
> progress will.  Doing it this way would also allow the terrain data to
> be dynamic.  This may sound silly, but I can think of situations where
> it could be very beneficial.  Imagine the type of emotional impact
that
> seeing Earth's cities destroyed would have.  Near the end of the game
> the Aliens could be given the ability to destroy entire cities or
> regions.  Of course this would have large economic and political
> impacts that would make the game much more challenging and engaging. 
> Storing the data this way would allow us to swap terrain types to
'city
> ruins' or 'nuclear wasteland.'  I think we could take the concept of
> putting the Earth in danger much much farther.  I know this is all
post
> v1.0, but I think we should be creating an architecture designed to be
> easily extendable for v2.0.  That way 2.0 isn't a patch job or
rewrite.
>  That's why I think we should store this data in GeoData.  It doesn't
> mean that every time an air vehicle's position changes that GeoData
> gets updated.  The save routine can do this at save-time, and the
> entire GeoData class can then be written to disk.  We could do the
same
> thing with BattleScape using a BattleData class.
> 
> -chrisp
> 
> ---------- Forwarded Message ----------
> I imagine GeoData as a class to provide static data about the planet.
> The
> data itself will be stored in some data file, which will be tied to
the
> image we present on the globe. If you replace the image and the data
> file,
> you get another planet.
> 
> No data must be hardcoded in the class itself.
> 
> Does it make sense to everyone?
> 
> Regards,
> mamutas
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Cpt.
> Boxershorts
> Sent: Saturday, March 06, 2004 1:37 PM
> To: xen...@li...
> Subject: RE: [Xenocide-programming] GeoData.h
> 
> Is GeoData.h going to be hardcoded for each planet represented, or
will
> it be data-dependant?
> 
> -The Captain
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Vlad Judys
> Sent: Saturday, March 06, 2004 10:59 AM
> To: chr...@ju...; xen...@li...
> Subject: RE: [Xenocide-programming] GeoData.h
> 
> Hi chrisp,
> 
> I have put my answers inside your mail below.
> 
> Regards,
> mamutas
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> chr...@ju...
> Sent: Tuesday, March 02, 2004 9:53 PM
> To: xen...@li...
> Subject: Re: [Xenocide-programming] GeoData.h
> 
> 
> 
> 
> It wouldn't make sense to me either, just checking. :-)
> 
> I've been thinking along similar lines while working on this class.
> However, I don't necessarily see these things being done by the actual
> caller of GeoData, though.  What I was thinking was this would be an
> adjacent class.  Whatever class ends up interfacing with GeoData also
> interfaces with the rules class (GeoRules?).  
> >> Yes, this is absolutely true. The caller of GeoData will need to
> interface with other classes which will provide rules information on
> how
> to
> interpret data. The GeoData class itself must not have any dependences
> on
> the rules.
> 
> I was also thinking that we'll need to have a basic AI class for
> controlling
> ufo and interceptor flight paths (GeoPilot?).  It doesn't have to be
> very
> fancy.  Just add the right combination of randomness and logic to make
> it
> believable.
> >> This will be performed on the server side. There will be a separate
> class
> for dynamic information. Remember, that GeoData class _must_ be
> concerned
> only about static data of the globe. That is the data which does not
> change
> in time: terrains, location of cities, country borders, etc.
Everything
> dynamic is out of scope of the GeoData. Crafts, bases, weather do not
> belong
> to GeoData class.
> 
> 
> I've been making progress on GeoData, and it seems that this is going
> to
> be
> quite a massive series of classes.  When you take all of the data
types
> I
> defined (which is still not complete) and make them into full classes,
> you
> get one massive header file.  
> >> I would rather not to head that direction. Implementing all at once
> is
> very big task. The beauty of OOP is that you can define functionality
> for a
> very small scope of the program. My approach would be to do it in
> steps:
> implement the most necessary data first and then add bells and
> whistles.
> So
> far, I see the information about geo points as the most important.
That
> would include info about:
> - terrain type (to determine whether we can build a base here. But
> remember
> the determination will be done in other class!!); 
> - continente (to determine cost);
> - country (to determine major nationality of soldiers, but it is
> secondary
> priority comparing to first two).
> 
> We may want to break this up into multiple headers and (sub)
> namespaces.
> All of the functinality could still be encapsulated through GeoData.h
> So,
> we would have something like: GeoTerrainData.h GeoAirVehicles.h
> GeoSOI.h
> (for Sites of Interest) and GeoRegions.h.  These would be included in
> GeoData.h where the GeoData class would be responsible for interfacing
> with
> all of this data.  Finally, I was thinking we may want to scale up the
> continents/regions classes one step more and define a Planet class. 
> The
> Planet class would be helpful to isoloate what's happening on Mars
from
> what's happening on Earth.  It would not help much with v1.0, but we
> may
> have a real headache after 1.0 if we don't do this now.  Especially if
> we
> want to do a full blown Mars vs. Earth scenario.
> >> Not sure what benefit to have a Planet class. Remember, that
GeoData
> has
> no behaviour, but merely data server. I imagine it would read the data
> from
> some file and then serve it to callers. The data will describe the
> planet
> (we can have the Venus if we will want), not the code of GeoData.
> 
> One last questin.  Do we want to do some operator overloading on these
> (GeoData) classes?  I get the impression we're going for the deluxe
> style
> class implementations.  I can make these fully defined data types if
> that's
> what's wanted.  It's not a big deal to me, but I think we may as well
> do
> this now to allow for maximum flexibility.
> >> Go with major simple classes first. Adding an operator or a method
> could
> be always done later. If you are sure, we will need them add them now,
> but
> don't focus on that entirely.
> 
> >> Great work! Thanks for contributions to the project!!
> 
> Regards,
> chrisp 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/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.594 / Virus Database: 377 - Release Date: 2/24/2004
>  
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/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
> 
> 
> ________________________________________________________________
> 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

RE: [Xenocide-programming] GeoData.h

[Jason J. <ja...@ki...>]

Seems to me that we can do the swappable terrain type thing AND 
implement a seperate class for save data.  If we try to throw too much 
gamestate into geodata it will wind up with a bunch of stuff that 
doesn't relate.  Remember save games have to include player name, 
soldier names, research states, funding, etc.

The changeable terrain thing (I think) is simply a matter of granularity 
of tiles.  The geodata object in memory during the game has to know what 
terrain type each tile of the world is.  This can of course be changed 
by a scripting choice or mod dll (or post 1.0 code we write).  So long 
as it doesn't store terrain type as continent-sized chunks (maybe city-
sized?) a mod can replace tiles dynamically as the situation warrants.

That is the way I see it, anyway.  Someone correct me if I have anything 
wrong, as I'm just getting my brain around the project.

-Thalo

-----Original Message-----
From: chr...@ju...
To: xen...@li...
Date: Sun, 7 Mar 2004 05:55:13 GMT
Subject: RE: [Xenocide-programming] GeoData.h

> 
> 
> We also may want to think about how we want to save the state of the
> game.  We'll want to be able to save all crash/base/terror locations
> and and the locations of any aircraft in the air.  This is why I
> initially put all of this in GeoData.  I was thinking of this as being
> the class that essentially stored the state of the game.  So this state
> could be saved and reloaded with ease.  Of course starting a new game
> wouldn't require all of this other data.  But, saving a game in
> progress will.  Doing it this way would also allow the terrain data to
> be dynamic.  This may sound silly, but I can think of situations where
> it could be very beneficial.  Imagine the type of emotional impact that
> seeing Earth's cities destroyed would have.  Near the end of the game
> the Aliens could be given the ability to destroy entire cities or
> regions.  Of course this would have large economic and political
> impacts that would make the game much more challenging and engaging. 
> Storing the data this way would allow us to swap terrain types to 'city
> ruins' or 'nuclear wasteland.'  I think we could take the concept of
> putting the Earth in danger much much farther.  I know this is all post
> v1.0, but I think we should be creating an architecture designed to be
> easily extendable for v2.0.  That way 2.0 isn't a patch job or rewrite.
>  That's why I think we should store this data in GeoData.  It doesn't
> mean that every time an air vehicle's position changes that GeoData
> gets updated.  The save routine can do this at save-time, and the
> entire GeoData class can then be written to disk.  We could do the same
> thing with BattleScape using a BattleData class.
> 
> -chrisp
> 
> ---------- Forwarded Message ----------
> I imagine GeoData as a class to provide static data about the planet.
> The
> data itself will be stored in some data file, which will be tied to the
> image we present on the globe. If you replace the image and the data
> file,
> you get another planet.
> 
> No data must be hardcoded in the class itself.
> 
> Does it make sense to everyone?
> 
> Regards,
> mamutas
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Cpt.
> Boxershorts
> Sent: Saturday, March 06, 2004 1:37 PM
> To: xen...@li...
> Subject: RE: [Xenocide-programming] GeoData.h
> 
> Is GeoData.h going to be hardcoded for each planet represented, or will
> it be data-dependant?
> 
> -The Captain
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Vlad Judys
> Sent: Saturday, March 06, 2004 10:59 AM
> To: chr...@ju...; xen...@li...
> Subject: RE: [Xenocide-programming] GeoData.h
> 
> Hi chrisp,
> 
> I have put my answers inside your mail below.
> 
> Regards,
> mamutas
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> chr...@ju...
> Sent: Tuesday, March 02, 2004 9:53 PM
> To: xen...@li...
> Subject: Re: [Xenocide-programming] GeoData.h
> 
> 
> 
> 
> It wouldn't make sense to me either, just checking. :-)
> 
> I've been thinking along similar lines while working on this class.
> However, I don't necessarily see these things being done by the actual
> caller of GeoData, though.  What I was thinking was this would be an
> adjacent class.  Whatever class ends up interfacing with GeoData also
> interfaces with the rules class (GeoRules?).  
> >> Yes, this is absolutely true. The caller of GeoData will need to
> interface with other classes which will provide rules information on
> how
> to
> interpret data. The GeoData class itself must not have any dependences
> on
> the rules.
> 
> I was also thinking that we'll need to have a basic AI class for
> controlling
> ufo and interceptor flight paths (GeoPilot?).  It doesn't have to be
> very
> fancy.  Just add the right combination of randomness and logic to make
> it
> believable.
> >> This will be performed on the server side. There will be a separate
> class
> for dynamic information. Remember, that GeoData class _must_ be
> concerned
> only about static data of the globe. That is the data which does not
> change
> in time: terrains, location of cities, country borders, etc. Everything
> dynamic is out of scope of the GeoData. Crafts, bases, weather do not
> belong
> to GeoData class.
> 
> 
> I've been making progress on GeoData, and it seems that this is going
> to
> be
> quite a massive series of classes.  When you take all of the data types
> I
> defined (which is still not complete) and make them into full classes,
> you
> get one massive header file.  
> >> I would rather not to head that direction. Implementing all at once
> is
> very big task. The beauty of OOP is that you can define functionality
> for a
> very small scope of the program. My approach would be to do it in
> steps:
> implement the most necessary data first and then add bells and
> whistles.
> So
> far, I see the information about geo points as the most important. That
> would include info about:
> - terrain type (to determine whether we can build a base here. But
> remember
> the determination will be done in other class!!); 
> - continente (to determine cost);
> - country (to determine major nationality of soldiers, but it is
> secondary
> priority comparing to first two).
> 
> We may want to break this up into multiple headers and (sub)
> namespaces.
> All of the functinality could still be encapsulated through GeoData.h
> So,
> we would have something like: GeoTerrainData.h GeoAirVehicles.h
> GeoSOI.h
> (for Sites of Interest) and GeoRegions.h.  These would be included in
> GeoData.h where the GeoData class would be responsible for interfacing
> with
> all of this data.  Finally, I was thinking we may want to scale up the
> continents/regions classes one step more and define a Planet class. 
> The
> Planet class would be helpful to isoloate what's happening on Mars from
> what's happening on Earth.  It would not help much with v1.0, but we
> may
> have a real headache after 1.0 if we don't do this now.  Especially if
> we
> want to do a full blown Mars vs. Earth scenario.
> >> Not sure what benefit to have a Planet class. Remember, that GeoData
> has
> no behaviour, but merely data server. I imagine it would read the data
> from
> some file and then serve it to callers. The data will describe the
> planet
> (we can have the Venus if we will want), not the code of GeoData.
> 
> One last questin.  Do we want to do some operator overloading on these
> (GeoData) classes?  I get the impression we're going for the deluxe
> style
> class implementations.  I can make these fully defined data types if
> that's
> what's wanted.  It's not a big deal to me, but I think we may as well
> do
> this now to allow for maximum flexibility.
> >> Go with major simple classes first. Adding an operator or a method
> could
> be always done later. If you are sure, we will need them add them now,
> but
> don't focus on that entirely.
> 
> >> Great work! Thanks for contributions to the project!!
> 
> Regards,
> chrisp 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/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.594 / Virus Database: 377 - Release Date: 2/24/2004
>  
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/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
> 
> 
> ________________________________________________________________
> 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

RE: [Xenocide-programming] GeoData.h

[<chr...@ju...>]

We also may want to think about how we want to save the state of the game.  We'll want to be able to save all crash/base/terror locations and and the locations of any aircraft in the air.  This is why I initially put all of this in GeoData.  I was thinking of this as being the class that essentially stored the state of the game.  So this state could be saved and reloaded with ease.  Of course starting a new game wouldn't require all of this other data.  But, saving a game in progress will.  Doing it this way would also allow the terrain data to be dynamic.  This may sound silly, but I can think of situations where it could be very beneficial.  Imagine the type of emotional impact that seeing Earth's cities destroyed would have.  Near the end of the game the Aliens could be given the ability to destroy entire cities or regions.  Of course this would have large economic and political impacts that would make the game much more challenging and engaging.  Storing the data this way would allow us to swap terrain types to 'city ruins' or 'nuclear wasteland.'  I think we could take the concept of putting the Earth in danger much much farther.  I know this is all post v1.0, but I think we should be creating an architecture designed to be easily extendable for v2.0.  That way 2.0 isn't a patch job or rewrite.  That's why I think we should store this data in GeoData.  It doesn't mean that every time an air vehicle's position changes that GeoData gets updated.  The save routine can do this at save-time, and the entire GeoData class can then be written to disk.  We could do the same thing with BattleScape using a BattleData class.

-chrisp

---------- Forwarded Message ----------
I imagine GeoData as a class to provide static data about the planet. The
data itself will be stored in some data file, which will be tied to the
image we present on the globe. If you replace the image and the data file,
you get another planet.

No data must be hardcoded in the class itself.

Does it make sense to everyone?

Regards,
mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Saturday, March 06, 2004 1:37 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] GeoData.h

Is GeoData.h going to be hardcoded for each planet represented, or will
it be data-dependant?

-The Captain

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Vlad Judys
Sent: Saturday, March 06, 2004 10:59 AM
To: chr...@ju...; xen...@li...
Subject: RE: [Xenocide-programming] GeoData.h

Hi chrisp,

I have put my answers inside your mail below.

Regards,
mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
chr...@ju...
Sent: Tuesday, March 02, 2004 9:53 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] GeoData.h




It wouldn't make sense to me either, just checking. :-)

I've been thinking along similar lines while working on this class.
However, I don't necessarily see these things being done by the actual
caller of GeoData, though.  What I was thinking was this would be an
adjacent class.  Whatever class ends up interfacing with GeoData also
interfaces with the rules class (GeoRules?).  
>> Yes, this is absolutely true. The caller of GeoData will need to
interface with other classes which will provide rules information on how
to
interpret data. The GeoData class itself must not have any dependences
on
the rules.

I was also thinking that we'll need to have a basic AI class for
controlling
ufo and interceptor flight paths (GeoPilot?).  It doesn't have to be
very
fancy.  Just add the right combination of randomness and logic to make
it
believable.
>> This will be performed on the server side. There will be a separate
class
for dynamic information. Remember, that GeoData class _must_ be
concerned
only about static data of the globe. That is the data which does not
change
in time: terrains, location of cities, country borders, etc. Everything
dynamic is out of scope of the GeoData. Crafts, bases, weather do not
belong
to GeoData class.


I've been making progress on GeoData, and it seems that this is going to
be
quite a massive series of classes.  When you take all of the data types
I
defined (which is still not complete) and make them into full classes,
you
get one massive header file.  
>> I would rather not to head that direction. Implementing all at once
is
very big task. The beauty of OOP is that you can define functionality
for a
very small scope of the program. My approach would be to do it in steps:
implement the most necessary data first and then add bells and whistles.
So
far, I see the information about geo points as the most important. That
would include info about:
- terrain type (to determine whether we can build a base here. But
remember
the determination will be done in other class!!); 
- continente (to determine cost);
- country (to determine major nationality of soldiers, but it is
secondary
priority comparing to first two).

We may want to break this up into multiple headers and (sub) namespaces.
All of the functinality could still be encapsulated through GeoData.h
So,
we would have something like: GeoTerrainData.h GeoAirVehicles.h GeoSOI.h
(for Sites of Interest) and GeoRegions.h.  These would be included in
GeoData.h where the GeoData class would be responsible for interfacing
with
all of this data.  Finally, I was thinking we may want to scale up the
continents/regions classes one step more and define a Planet class.  The
Planet class would be helpful to isoloate what's happening on Mars from
what's happening on Earth.  It would not help much with v1.0, but we may
have a real headache after 1.0 if we don't do this now.  Especially if
we
want to do a full blown Mars vs. Earth scenario.
>> Not sure what benefit to have a Planet class. Remember, that GeoData
has
no behaviour, but merely data server. I imagine it would read the data
from
some file and then serve it to callers. The data will describe the
planet
(we can have the Venus if we will want), not the code of GeoData.

One last questin.  Do we want to do some operator overloading on these
(GeoData) classes?  I get the impression we're going for the deluxe
style
class implementations.  I can make these fully defined data types if
that's
what's wanted.  It's not a big deal to me, but I think we may as well do
this now to allow for maximum flexibility.
>> Go with major simple classes first. Adding an operator or a method
could
be always done later. If you are sure, we will need them add them now,
but
don't focus on that entirely.

>> Great work! Thanks for contributions to the project!!

Regards,
chrisp 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/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.594 / Virus Database: 377 - Release Date: 2/24/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/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


________________________________________________________________
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!