Menu
▾
▴
xenocide-programming — The Programming Xenocide Mailing List
You can subscribe to this list here.
| 2003 |
Jan
(9) |
Feb
(6) |
Mar
|
Apr
(2) |
May
|
Jun
(4) |
Jul
(19) |
Aug
(18) |
Sep
(11) |
Oct
(14) |
Nov
(16) |
Dec
(50) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(42) |
Feb
(39) |
Mar
(66) |
Apr
(26) |
May
(32) |
Jun
(21) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mamutas P. <ma...@pr...> - 2004-03-06 20:46:27
|
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 |
|
From: Cpt. B. <cpt...@pr...> - 2004-03-06 19:45:18
|
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 |
|
From: Vlad J. <vj...@au...> - 2004-03-06 19:07:10
|
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 |
|
From: <red...@pr...> - 2004-03-06 16:56:39
|
Hi Chris, You should get in the forums at www.xcomufo.com/forums, get an account and write in the Recruitment Center (to get Xenocide Recruit permissions), you will find instructions in the programming thread, as they had been written several times in that thread. Greetings Red Knight > Hello - > > I am interested in working on the Xenocide project as a programmer. I have > programmed in C/C++ since I was 12 (now 21) and am currently a senior > majoring > in computer science and electrical engineering at the Univ. of Wisconsin - > Milw. > > > Thanks, > Chris > |
|
From: Tamas T. <te...@cs...> - 2004-03-06 16:39:51
|
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 |
|
From: <red...@pr...> - 2004-03-06 15:25:43
|
Hi all, sorry for being very away this last 3 days. > rules class (GeoRules?). 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. That is part of the simulation engine, remember that GeoData is just the static data, after we define it, we will start with the simulation engine that is where all dynamic data is stored and manipulated... and where the Planetary AI/Strategic AI hooks are presented, so we can make our agents manipulate all this information... the right combination of randomness and logic is just an agent implementation in that model, so if you end up coding some more research oriented/fancy AI you just register its hooks. > 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 Indeed, the simulation engine (call it AI/Rules) is an adjacent framework. GeoData is just static data. > 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 AirVehicles are dynamic data, not suitable for GeoData, that is part of the simulation framework. > 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. Mhhh, lets get away of operator overloading unless really, really, really necesary... It over complicates the design on the long run. Greetings Red Knight |
|
From: <chr...@ju...> - 2004-03-03 04:00:23
|
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?). 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. 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. 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. 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. Regards, chrisp ---------- Forwarded Message ---------- No, no, no! The purpose of GeoData class in my imagination is to provide information about particular place on the globe. The initial idea for it came when I was thinking what needs to be done to determine whether I can build a base on this coordinates or not. Now it grew in something larger. Keep this in mind. You have a globe. You need a class which will provide static information about location on the globe. Coordinates of location is an input. The output must be a class describing the location: ground/water, climate, terrain, country, continent. When the caller of GeoData class will get this information, it needs to consult some rules on what is possible on that location. That is out of scope of GeoData class. RK's example of GeoData class is very close to what I imagine myself. I only mentioned those rules as a possible assignment. But, again these are out of scope of GeoData class. Regards, mamutas ----- Original Message ----- From: <chr...@ju...> To: <xen...@li...> Sent: Monday, March 01, 2004 10:21 PM Subject: RE: [Xenocide-programming] GeoData.h > > > Are you saying that we add these rules to the GeoData class? > > -chrisp > > ---------- Forwarded Message ---------- > Hei, > > Sorry for not posting anything on that issue for that long, but I really > have not much to add after Red Knight's and Cpt. Boxershort's comments. I > just want to let you guys know, that I reviewed the files though. > > Some other things to think about are that we need some rules to interpret > that GeoData. The best way is to put those rules in the script somehow. Here > is what I am talking about. We need rules to: > 1) confirm whether we can build a base at such location (or what type of > base if we will support underwater bases); > 2) evaluate the cost to build a base there; > 3) etc. > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > chr...@ju... > Sent: Sunday, February 22, 2004 5:55 PM > To: fl...@ma... > Cc: chr...@ju...; xen...@li... > Subject: Re: [Xenocide-programming] GeoData.h > > > > Thanks for the comments Federico. I like your suggestions, and will rework > the class. I knew I wouldn't get a design that worked well w/ the existing > code right away, so I was more concerned w/ thinking up all of the possible > data types. Thanks for your example. It goes a long way towards clearing > my confusion. -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 > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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! > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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! |
|
From: mamutas <mam...@ho...> - 2004-03-02 23:43:04
|
I was not thinking about making an interface for data input/output. I thought just about XML related work which could be done. mamutas ----- Original Message ----- From: "breunor" <br...@pr...> To: <xen...@li...> Sent: Tuesday, March 02, 2004 5:03 PM Subject: [Xenocide-programming] other xml layouts > Regarding the X-Net layout for XML, Cpt. B can speak on that better than I > can by a long shot, but for the actual text entries I don't think there's > any need for an interface to enter the data, it really just cut and paste > after reviewing what people submit. Something that allows you to easily > review internal game stats might be good, to verify the correct numbers > are used. > > Breunor > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > |
|
From: breunor <br...@pr...> - 2004-03-02 23:12:46
|
Regarding the X-Net layout for XML, Cpt. B can speak on that better than I can by a long shot, but for the actual text entries I don't think there's any need for an interface to enter the data, it really just cut and paste after reviewing what people submit. Something that allows you to easily review internal game stats might be good, to verify the correct numbers are used. Breunor |
|
From: mamutas <mam...@ho...> - 2004-03-02 16:44:40
|
Hi guys, Captain, forget the sleep! You can sleep it all out when you will become retired! :) Just kidding. If that would not be for a sleep, I would make much more progress myself! Yes, the file structure is pretty much done. We will tweak it later, but it is a good start. Contents, of course, needs revising: both names (need to change them to new names ASAP!) and values. The other file in work was a file for saved game data. We would need it soon as well. That basically should be the file which will reflect current state of the game including all info about XCom and about Aliens. The Captain has done work on it as well. Could you also post the latest version of it? Regards, mamutas ----- Original Message ----- From: "Cpt. Boxershorts" <cpt...@pr...> To: <xen...@li...> Sent: Tuesday, March 02, 2004 7:44 AM Subject: RE: [Xenocide-programming] Namesdatabase reworking > Hi Tommy, > > There are a number of other xml layouts in progress (primarily > the data configuration files), but I've be swamped recently so not much > has happened with them (don't try to hold down a full-time software > contract, part-time teaching job, and be a stay-at-home dad at the same > time if you have any interest in sleep). > > The techtree layout is tentatively finalized. The actual > content (and any variation from canon) is not. My proposal is here > (http://www.projectxenocide.com/public/CTD/CptBoxershorts/TechTree/Propo > sal/TechTree_v1.html), but I suspect it was bit premature. :) > > > Here's the main sample of the layout. This is a complete copy of the > Enemy Unknown tree. > > > > -The Captain |
|
From: mamutas <mam...@ho...> - 2004-03-02 16:37:20
|
No, no, no! The purpose of GeoData class in my imagination is to provide information about particular place on the globe. The initial idea for it came when I was thinking what needs to be done to determine whether I can build a base on this coordinates or not. Now it grew in something larger. Keep this in mind. You have a globe. You need a class which will provide static information about location on the globe. Coordinates of location is an input. The output must be a class describing the location: ground/water, climate, terrain, country, continent. When the caller of GeoData class will get this information, it needs to consult some rules on what is possible on that location. That is out of scope of GeoData class. RK's example of GeoData class is very close to what I imagine myself. I only mentioned those rules as a possible assignment. But, again these are out of scope of GeoData class. Regards, mamutas ----- Original Message ----- From: <chr...@ju...> To: <xen...@li...> Sent: Monday, March 01, 2004 10:21 PM Subject: RE: [Xenocide-programming] GeoData.h > > > Are you saying that we add these rules to the GeoData class? > > -chrisp > > ---------- Forwarded Message ---------- > Hei, > > Sorry for not posting anything on that issue for that long, but I really > have not much to add after Red Knight's and Cpt. Boxershort's comments. I > just want to let you guys know, that I reviewed the files though. > > Some other things to think about are that we need some rules to interpret > that GeoData. The best way is to put those rules in the script somehow. Here > is what I am talking about. We need rules to: > 1) confirm whether we can build a base at such location (or what type of > base if we will support underwater bases); > 2) evaluate the cost to build a base there; > 3) etc. > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > chr...@ju... > Sent: Sunday, February 22, 2004 5:55 PM > To: fl...@ma... > Cc: chr...@ju...; xen...@li... > Subject: Re: [Xenocide-programming] GeoData.h > > > > Thanks for the comments Federico. I like your suggestions, and will rework > the class. I knew I wouldn't get a design that worked well w/ the existing > code right away, so I was more concerned w/ thinking up all of the possible > data types. Thanks for your example. It goes a long way towards clearing > my confusion. -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 > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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! > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > |
|
From: Cpt. B. <cpt...@pr...> - 2004-03-02 13:50:13
|
Hi Tommy, There are a number of other xml layouts in progress (primarily the data configuration files), but I've be swamped recently so not much has happened with them (don't try to hold down a full-time software contract, part-time teaching job, and be a stay-at-home dad at the same time if you have any interest in sleep). The techtree layout is tentatively finalized. The actual content (and any variation from canon) is not. My proposal is here (http://www.projectxenocide.com/public/CTD/CptBoxershorts/TechTree/Propo sal/TechTree_v1.html), but I suspect it was bit premature. :) Here's the main sample of the layout. This is a complete copy of the Enemy Unknown tree. -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Tommy Persson Sent: Tuesday, March 02, 2004 5:34 AM To: xen...@li... Subject: Re: [Xenocide-programming] Namesdatabase reworking Federico Andres Lois wrote: > Hi Tommy, > > We have the very same problem that before, OGRE do not support Unicode just > ASCII for the very same reasons that I had outlined before. About changing > the database format, you are free to do it (as long as we dont lose the > actual contributions ;) ) however if you can think to do anything else that > could help it is better... > > Greetings > Red Knight Are any of the other xml-files finalized yet? I was looking at the Tech Tree XML Layout mailing-list thread but it seemed to end quite abruptly (sp?) without any real layout (read: whole file with dtd and all available for download) decided upon. Are you reading this Captain? I know you have it somewhere :) Tommy "lordt" Persson to...@ho... ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Tommy P. <to...@ho...> - 2004-03-02 12:32:47
|
Federico Andres Lois wrote: > Hi Tommy, > > We have the very same problem that before, OGRE do not support Unicode just > ASCII for the very same reasons that I had outlined before. About changing > the database format, you are free to do it (as long as we dont lose the > actual contributions ;) ) however if you can think to do anything else that > could help it is better... > > Greetings > Red Knight Are any of the other xml-files finalized yet? I was looking at the Tech Tree XML Layout mailing-list thread but it seemed to end quite abruptly (sp?) without any real layout (read: whole file with dtd and all available for download) decided upon. Are you reading this Captain? I know you have it somewhere :) Tommy "lordt" Persson to...@ho... |
|
From: <chr...@ju...> - 2004-03-02 04:27:50
|
Are you saying that we add these rules to the GeoData class? -chrisp ---------- Forwarded Message ---------- Hei, Sorry for not posting anything on that issue for that long, but I really have not much to add after Red Knight's and Cpt. Boxershort's comments. I just want to let you guys know, that I reviewed the files though. Some other things to think about are that we need some rules to interpret that GeoData. The best way is to put those rules in the script somehow. Here is what I am talking about. We need rules to: 1) confirm whether we can build a base at such location (or what type of base if we will support underwater bases); 2) evaluate the cost to build a base there; 3) etc. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Sunday, February 22, 2004 5:55 PM To: fl...@ma... Cc: chr...@ju...; xen...@li... Subject: Re: [Xenocide-programming] GeoData.h Thanks for the comments Federico. I like your suggestions, and will rework the class. I knew I wouldn't get a design that worked well w/ the existing code right away, so I was more concerned w/ thinking up all of the possible data types. Thanks for your example. It goes a long way towards clearing my confusion. -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 ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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! |
|
From: Mamutas P. <ma...@pr...> - 2004-03-02 04:06:34
|
Hei, Sorry for not posting anything on that issue for that long, but I really have not much to add after Red Knight's and Cpt. Boxershort's comments. I just want to let you guys know, that I reviewed the files though. Some other things to think about are that we need some rules to interpret that GeoData. The best way is to put those rules in the script somehow. Here is what I am talking about. We need rules to: 1) confirm whether we can build a base at such location (or what type of base if we will support underwater bases); 2) evaluate the cost to build a base there; 3) etc. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Sunday, February 22, 2004 5:55 PM To: fl...@ma... Cc: chr...@ju...; xen...@li... Subject: Re: [Xenocide-programming] GeoData.h Thanks for the comments Federico. I like your suggestions, and will rework the class. I knew I wouldn't get a design that worked well w/ the existing code right away, so I was more concerned w/ thinking up all of the possible data types. Thanks for your example. It goes a long way towards clearing my confusion. -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 |
|
From: Tommy P. <to...@ho...> - 2004-03-01 20:08:37
|
Hi all, I was thinking of re-doing the entire names database and it's interface (I couldn't think of anything better to do as a web design project in school), making it work directly with the xml-database instead of first going through an sql-database. One of the pro's is that we don't have the risk of the sql-database breaking down and leaving us with an half-complete xml-file. It also allows the use of Unicode, which brings me to why I'm posting here. Previously we decided to use the ASCII charset because of font (/engine?) limitations. Has that changed or should I still stick with ASCII? Also, maybe these kinds of tools can be developed and used for other xml-files we might have, x-net and such? Tommy "lordt" Persson to...@ho... |
|
From: Tamas T. <te...@cs...> - 2004-02-27 18:11:18
|
Here are the files I've touched recently (and some of those are the original ones, just I don't know which ones I've already posted), and a couple of questions: - do we keep all data that is used with a "soldier" object in the same class or make a friend class for the battlescape data (might be not worth the effort, but anyway)? - I assume there is/will be a way of IDing objects (at least the carriers) by a hash or something, so that objects can tell their owner? centurion |
|
From: Cpt. B. <cpt...@te...> - 2004-02-23 14:27:06
|
I think this would be the best way to go...it clearly defines where the item
can be used, and is easily scalable if we need to add a new atmosphere.
Regarding Breunor's suggestion (1=air, 2=water, 3=vacuum, 4=air+water,
5=air+vacuum, 6=water+vacuum, 7=all), I don't think it's worth it on the
data end of things. On the code end I'd reccomend making the atmosphere
types an enum with bitwise values (ie: terrestrial=1, vacuum=2,
underwater=4, mars=8) so that the class itself could get away with only a
single 'Environment' property. The data loader simply adds up the contents
of the <environments> tag when it build the object.
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
Federico Andres Lois
Sent: Sunday, February 22, 2004 12:34 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data
I was going to say that by default the
<environments>
<atmosphere type="terrestrial" />
</<environments>
Should be allow terrestrial and vaccum (like laser, plasma, etc)... for only
terrestrial like pistols (I dont think you should be able to use them in
Mars) you put the enviroments tag...
For compound ones like those that can work in terrestrial, vaccum and
maritime (underwater) I propose something like this:
<environments>
<atmosphere type="terrestrial" />
<atmosphere type="vaccum" />
<atmosphere type="underwater" />
</<environments>
And if we need later, we can add modifiers to each one of them.
Greetings
Red Knight
-------Original Message-------
From: Mamutas Plaukotas
Date: 22/02/2004 15:42:36
To: 'breunor'; xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data
I agree with Breunor. It is a reasonable suggestion.
In my previous post I just wanted to point out, that there should be no
difference in terms of using weapon on Mars or Earth. Or am I missing
something?
As for all possible comibinations of atmosphere types, we can either go as
Breunor suggested or just have something like that (where atmosphere type
name is optional, but at least one must present):
<atmosphere type>
<vacuum/>
<air/>
</atmosphere type>
Here we can even specify how each atmosphere will effect the weapon, but it
is definitely V1+:
<atmosphere type>
<vacuum range="1000" accuracy="1"/>
<air range="500" accuracy=".5"/>
</atmosphere type>
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
breunor
Sent: Saturday, February 21, 2004 11:50 AM
To: xen...@li...
Subject: [Xenocide-programming] XML facility-item data
Regarding the atmosphere type of air/water/vacuum, shouldn't that be put
on most items? If we expand the game later to include the TFTD missions, I
doubt we'd want the player using a pistol or incidiary rounds underwater
for example. But a harpoon gun could be used out of water IMO, so it
wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air,
2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then
when the player gets to the site, the arming screen would only let you
equip a soldier with items whose type matches the atmosphere. This point
also brings up one of the laboratory ideas of having "weapon load
templates", the member brought it up as using for a sniper vs. heavy
assault type of load, but here you could create an "aqua" load, and have
it switch weapons for you. It would be a hassle to have 24 soldiers loaded
for water and switch to a land loadout, only to switch back for the next
mission. But that is v1+ ideas, the point being that if you include this
atmosphere type of every item, then that functionality would be possible
later on.
Breunor
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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.576 / Virus Database: 365 - Release Date: 1/30/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
|
From: <chr...@ju...> - 2004-02-23 00:04:59
|
Thanks for the comments Federico. I like your suggestions, and will rework the class. I knew I wouldn't get a design that worked well w/ the existing code right away, so I was more concerned w/ thinking up all of the possible data types. Thanks for your example. It goes a long way towards clearing my confusion. -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! |
|
From: Federico A. L. <fl...@ma...> - 2004-02-22 23:31:04
|
Cm5hbWVzcGFjZSBYZW5vY2lkZSAKewogICBuYW1lc3BhY2UgRGF0YU1vZGVsCiAgIHsKCmNsYXNz IFRlcnJhaW5EYXRhCnsKcHVibGljOgogICBlbnVtIFRFUlJBSU5UWVBFCiAgIHsKICAgICAgX1RU R1JBU1NMQU5ELCAKICAgICAgX1RURk9SRVNULAogICAgICBfVFRUUk9QSUNBTFJBSU5GT1JFU1Qs CiAgICAgIF9UVFRFTVBFUkFURVJBSU5GT1JFU1QsCiAgICAgIF9UVFBMQUlOUywKICAgICAgX1RU QkFETEFORFMsCiAgICAgIF9UVERFU0VSVCwKICAgICAgX1RUU0FIQVJBLAogICAgICBfVFRUVU5E UkEsCiAgICAgIF9UVEFSQ1RJQywKICAgICAgX1RUQ09BU1QsCiAgICAgIF9UVFdBVEVSIC8vISBX YXRlciBpcyBpbXBvcnRhbnQgYXMgYSB0ZXJyYWluIHR5cGUgY2F1c2UgaXQgd2lsbCBnaXZlIHlv dSBhIHdheSB0byBrbm93IHRoYXQgeW91IGNhbnQgZ28gdGhlcmUuIDpECiAgIH07CgogICBUZXJy YWluRGF0YSAoIENvb3JkaW5hdGU6Ok5vcm1hbGl6ZWRQb3NpdGlvbiBjb29yZGluYXRlLCBURVJS QUlOVFlQRSB0eXBlLCBSZWFsIGVsZXZhdGlvbiApOwogICAKICAgQ29vcmRpbmF0ZTo6Tm9ybWFs aXplZFBvc2l0aW9uIGdldENvb3JkaW5hdGUgKCk7CiAgIFRFUlJBSU5UWVBFIGdldFR5cGUgKCk7 CiAgIFJlYWwgZ2V0RWxldmF0aW9uICgpOwoKcHJpdmF0ZToKCn07CgpjbGFzcyBUZXJyYWluRGF0 YUxvYWRlcgp7CnB1YmxpYzoKICAgdmlydHVhbCBDb3VudGVkUmVmPFRlcnJhaW5EYXRhPiBnZXRU ZXJyYWluRnJvbUNvb3JkaW5hdGUgKCBDb29yZGluYXRlOjpOb3JtYWxpemVkUG9zaXRpb24gY29v cmRpbmF0ZSApID0gMDsKfTsKCgoKLy8hIEEgY29vcmRpbmF0ZSBjYW4gYmUgY29uc3RydWN0ZWQg d2l0aCB3aGF0ZXZlciBjb29yZGluYXRlIHN5c3RlbSB5b3Ugd2FudAovLyEgZXZlbiAzRCwgaG93 ZXZlciB5b3UgYWx3YXlzIHJldHVybiBhIHZhbHVlIGluIG5vcm1hbGl6ZWQgY29vcmRpbmF0ZSBz eXN0ZW0gCi8vISB0byBiZSB1c2VkIGJ5IHRoZSBzaW11bGF0aW9uIGVuZ2luZS4KY2xhc3MgQ29v cmRpbmF0ZQp7CnB1YmxpYzoKCiAgIHR5cGVkZWYgVHVwbGUyPFJlYWwsUmVhbD4gTm9ybWFsaXpl ZFBvc2l0aW9uOwogICB2aXJ0dWFsIE5vcm1hbGl6ZWRQb3NpdGlvbiBnZXRDb29yZGluYXRlICgp ID0gMDsKfTsKCi8vISBFeGFtcGxlIHdpdGggTm9ybWFsaXplZCBDb29yZGluYXRlcwpjbGFzcyBO b3JtYWxpemVkQ29vcmRpbmF0ZQp7CnB1YmxpYzoKICAgTm9ybWFsaXplZENvb3JkaW5hdGUgKCBO b3JtYWxpemVkUG9zaXRpb24gY29vcmRpbmF0ZSApCiAgIHsgdGhpcy0+Y29vcmRpbmF0ZSA9IGNv b3JkaW5hdGU7IH07CiAgIAogICB2aXJ0dWFsIE5vcm1hbGl6ZWRQb3NpdGlvbiBnZXRDb29yZGlu YXRlICgpCiAgIHsgcmV0dXJuIGNvb3JkaW5hdGU7IH0KCnByb3RlY3RlZDoKICAgTm9ybWFsaXpl ZFBvc2l0aW9uIGNvb3JkaW5hdGU7Cn07CgoKCi8vISBBIHJlZ2lvbiBjYW4gYmUgZGVmaW5lZCBh cyBhIGNvbnZleCBwb2xpZ29uIHNwZWNpZmllZCBieSBOb3JtYWxpemVkQ29vcmRpbmF0ZXMuCi8v ISBAcmVtYXJrIFRoaXMgaW50ZXJmYWNlIGlzIGFuIG92ZXIgc2ltcGxpZmljYXRpb24sIGp1c3Qg dG8gc2hvdyB0aGUgZXNlbnRpYWxzCmNsYXNzIFJlZ2lvbgp7CnB1YmxpYzoKCiAgIC8vISBUaGlz IGhhdmUgdG8gYmUgdGhlIGdlbmVyYWwgcHVycG9zZSBhbGdvcml0aG0sIHlvdSBjYW4gbWFrZSBp dCBldmVuIG1vcmUgZWZmaWNpZW50CiAgIC8vISBpbiBzdWJjbGFzZXMgbGlrZSBTcXVhcmVSZWdp b24uCiAgIHZpcnR1YWwgQm9vbCBpc0luc2lkZSAoIENvb3JkaW5hdGU6Ok5vcm1hbGl6ZWRQb3Np dGlvbiBwb3NpdGlvbiApOwogICAgIAp9OwoKY2xhc3MgQ2l0eQp7CnB1YmxpYzoKCiAgIENJVFlU WVBFCiAgIHsKICAgICAgX0NUTUVHQUxPUE9MSVMsCiAgICAgIF9DVE1FVFJPUE9MSVMsCiAgICAg IF9DVENJVFksCiAgICAgIF9DVFNNQUxMQ0lUWSwKICAgICAgX0NUVE9XTiwKICAgICAgX0NUVklM TEFHRSwKICAgICAgX0NUUlVSQUwgCiAgIH07CgogICBDaXR5ICggU3RyaW5nIG5hbWUsIENvb3Jk aW5hdGU6Ok5vcm1hbGl6ZWRQb3NpdGlvbiBwb3NpdGlvbiwgQ0lUWVRZUEUgdHlwZSApOyAvLyBl eHRyYSBpbmZvICkKICAgCiAgIC8vIEdldHRlcnMsIFNldHRlcnMsIERlc3RydWN0b3IsIGV0Yy4K CiAgIFJlYWwgZ2V0RGlzdGFuY2UgKCBDb29yZGluYXRlOjpOb3JtYWxpemVkUG9zaXRpb24gcG9z aXRpb24gKTsKICAgLy8hIFJldHVybnMgdGhlIGluZmx1ZW5jZSBhcmVhIHJhZGlvIG9mIHRoZSBj aXR5LgogICBSZWFsIGdldEluZmx1ZW5jZUFyZWEgKCk7Cgp9OwoKY2xhc3MgQ291bnRyeQp7CnB1 YmxpYzoKICAgQ291bnRyeSAoU3RyaW5nIG5hbWUsIFJlZ2lvbiByZWdpb24pOwoKICAgdmlydHVh bCBCb29sIGlzSW5zaWRlICggQ29vcmRpbmF0ZTo6Tm9ybWFsaXplZFBvc2l0aW9uIHBvc2l0aW9u ICk7CiAgIHZpcnR1YWwgQm9vbCBpc0luc2lkZUFyZWFPZkluZmx1ZW5jZSAoIENvb3JkaW5hdGU6 Ok5vcm1hbGl6ZWRQb3NpdGlvbiBwb3NpdGlvbiApOwoKICAgc3RkOjp2ZWN0b3I8Q2l0eT4gZ2V0 TmVhckNpdGllcyAoIENvb3JkaW5hdGU6Ok5vcm1hbGl6ZWRQb3NpdGlvbiBwb3NpdGlvbiwgUmVh bCBkaXN0YW5jZSApOwoKcHJvdGVjdGVkOgoKICAgdmlydHVhbCB2b2lkIGxvYWRDaXRpZXMgKCk7 CgogICBzdGQ6OnZlY3RvcjxDaXR5PiBjaXRpZXM7CiAgCiAgIFN0cmluZyBuYW1lOwogICBSZWdp b24gcmVnaW9uOwoKfTsKCmNsYXNzIENvbnRpbmVudAp7CnB1YmxpYzoKICAgQ29udGluZW50ICgg U3RyaW5nIG5hbWUsIFJlZ2lvbiByZWdpb24gKTsgICAKCiAgIHZpcnR1YWwgQm9vbCBpc0luc2lk ZSAoIENvb3JkaW5hdGU6Ok5vcm1hbGl6ZWRQb3NpdGlvbiBwb3NpdGlvbiApOwogICAKICAgQ291 bnRyeSBnZXROZWFyQ291bnRyaWVzICggQ29vcmRpbmF0ZTo6Tm9ybWFsaXplZFBvc2l0aW9uIHBv c2l0aW9uLCBSZWFsIGRpc3RhbmNlICk7CiAgIHN0ZDo6dmVjdG9yPENpdHk+IGdldE5lYXJDaXRp ZXMgKCBDb29yZGluYXRlOjpOb3JtYWxpemVkUG9zaXRpb24gcG9zaXRpb24sIFJlYWwgZGlzdGFu Y2UgKTsKCnByb3RlY3RlZDoKCiAgIHZpcnR1YWwgdm9pZCBsb2FkQ291bnRyaWVzICgpOwoKICAg UmVnaW9uIHJlZ2lvbjsKICAgU3RyaW5nIG5hbWU7Cgp9OwoKCgpjbGFzcyBHZW9EYXRhCnsKcHVi bGljOgoKICAgR2VvRGF0YSAoQ291bnRlZFJlZjxUZXJyYWluRGF0YUxvYWRlcj4gdGVycmFpbkRh dGFMb2FkZXIpOwogICAKICAgQm9vbCBpc0NvbnRpbmVudCAoIENvb3JkaW5hdGU6Ok5vcm1hbGl6 ZWRQb3NpdGlvbiBwb3NpdGlvbiApOwogICBCb29sIGlzQ29udGluZW50ICggQ29vcmRpbmF0ZTo6 Tm9ybWFsaXplZFBvc2l0aW9uIHBvc2l0aW9uLCBTdHJpbmcgbmFtZSk7CiAgIENvbnRpbmVudCBn ZXRDb250aW5lbnQgKCBDb29yZGluYXRlOjpOb3JtYWxpemVkUG9zaXRpb24gcG9zaXRpb24gKTsK ICAgCiAgIHN0ZDo6dmVjdG9yPENvbnRpbmVudD4gZ2V0Q29udGluZW50cyAoIFJlZ2lvbiByZWdp b24gKTsKCiAgIHN0ZDo6dmVjdG9yPENpdHk+IGdldENpdGllcyAoIFJlZ2lvbiByZWdpb24gKTsK ICAgc3RkOjp2ZWN0b3I8Q2l0eT4gZ2V0TmVhckNpdGllcyAoIENvb3JkaW5hdGU6Ok5vcm1hbGl6 ZWRQb3NpdGlvbiBwb3NpdGlvbiApOwogICAKICAgQm9vbCBpc0NvdW50cnkgKCBDb29yZGluYXRl OjpOb3JtYWxpemVkUG9zaXRpb24gcG9zaXRpb24gKTsKICAgQm9vbCBpc0NvdW50cnkgKCBDb29y ZGluYXRlOjpOb3JtYWxpemVkUG9zaXRpb24gcG9zaXRpb24sIFN0cmluZyBuYW1lICk7CiAgIENv dW50cnkgZ2V0Q291bnRyeSAoIENvb3JkaW5hdGU6Ok5vcm1hbGl6ZWRQb3NpdGlvbiBwb3NpdGlv biApOwogICAKICAgc3RkOjp2ZWN0b3I8Q2l0eT4gZ2V0Q291bnRyaWVzICggUmVnaW9uIHJlZ2lv biApOwoKcHJvdGVjdGVkOgoKICAgc3RkOjp2ZWN0b3I8Q29udGluZW50PiBjb250aW5lbnRzOwoK ICAgQ291bnRlZFJlZjxUZXJyYWluRGF0YUxvYWRlcj4gdGVycmFpbkRhdGFMb2FkZXI7Cgp9OwoK fTsKCn07ICAvLyBYZW5vY2lkZSBuYW1lc3BhY2UK |
|
From: Federico A. L. <fl...@ma...> - 2004-02-22 20:40:41
|
I was going to say that by default the
<environments>
<atmosphere type="terrestrial" />
</<environments>
Should be allow terrestrial and vaccum (like laser, plasma, etc)... for only
terrestrial like pistols (I dont think you should be able to use them in
Mars) you put the enviroments tag...
For compound ones like those that can work in terrestrial, vaccum and
maritime (underwater) I propose something like this:
<environments>
<atmosphere type="terrestrial" />
<atmosphere type="vaccum" />
<atmosphere type="underwater" />
</<environments>
And if we need later, we can add modifiers to each one of them.
Greetings
Red Knight
-------Original Message-------
From: Mamutas Plaukotas
Date: 22/02/2004 15:42:36
To: 'breunor'; xen...@li...
Subject: RE: [Xenocide-programming] XML facility-item data
I agree with Breunor. It is a reasonable suggestion.
In my previous post I just wanted to point out, that there should be no
difference in terms of using weapon on Mars or Earth. Or am I missing
something?
As for all possible comibinations of atmosphere types, we can either go as
Breunor suggested or just have something like that (where atmosphere type
name is optional, but at least one must present):
<atmosphere type>
<vacuum/>
<air/>
</atmosphere type>
Here we can even specify how each atmosphere will effect the weapon, but it
is definitely V1+:
<atmosphere type>
<vacuum range="1000" accuracy="1"/>
<air range="500" accuracy=".5"/>
</atmosphere type>
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
breunor
Sent: Saturday, February 21, 2004 11:50 AM
To: xen...@li...
Subject: [Xenocide-programming] XML facility-item data
Regarding the atmosphere type of air/water/vacuum, shouldn't that be put
on most items? If we expand the game later to include the TFTD missions, I
doubt we'd want the player using a pistol or incidiary rounds underwater
for example. But a harpoon gun could be used out of water IMO, so it
wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air,
2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then
when the player gets to the site, the arming screen would only let you
equip a soldier with items whose type matches the atmosphere. This point
also brings up one of the laboratory ideas of having "weapon load
templates", the member brought it up as using for a sniper vs. heavy
assault type of load, but here you could create an "aqua" load, and have
it switch weapons for you. It would be a hassle to have 24 soldiers loaded
for water and switch to a land loadout, only to switch back for the next
mission. But that is v1+ ideas, the point being that if you include this
atmosphere type of every item, then that functionality would be possible
later on.
Breunor
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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.576 / Virus Database: 365 - Release Date: 1/30/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
|
|
From: Mamutas P. <mam...@ho...> - 2004-02-22 18:47:06
|
I agree with Breunor. It is a reasonable suggestion. In my previous post I just wanted to point out, that there should be no difference in terms of using weapon on Mars or Earth. Or am I missing something? As for all possible comibinations of atmosphere types, we can either go as Breunor suggested or just have something like that (where atmosphere type name is optional, but at least one must present): <atmosphere type> <vacuum/> <air/> </atmosphere type> Here we can even specify how each atmosphere will effect the weapon, but it is definitely V1+: <atmosphere type> <vacuum range="1000" accuracy="1"/> <air range="500" accuracy=".5"/> </atmosphere type> Regards, Mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of breunor Sent: Saturday, February 21, 2004 11:50 AM To: xen...@li... Subject: [Xenocide-programming] XML facility-item data Regarding the atmosphere type of air/water/vacuum, shouldn't that be put on most items? If we expand the game later to include the TFTD missions, I doubt we'd want the player using a pistol or incidiary rounds underwater for example. But a harpoon gun could be used out of water IMO, so it wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air, 2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then when the player gets to the site, the arming screen would only let you equip a soldier with items whose type matches the atmosphere. This point also brings up one of the laboratory ideas of having "weapon load templates", the member brought it up as using for a sniper vs. heavy assault type of load, but here you could create an "aqua" load, and have it switch weapons for you. It would be a hassle to have 24 soldiers loaded for water and switch to a land loadout, only to switch back for the next mission. But that is v1+ ideas, the point being that if you include this atmosphere type of every item, then that functionality would be possible later on. Breunor ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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.576 / Virus Database: 365 - Release Date: 1/30/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 |
|
From: <chr...@ju...> - 2004-02-22 01:20:22
|
Hello all, I've finished a preliminary GeoData class header file. Give it a look and let me know your comments. -chris |
|
From: breunor <br...@pr...> - 2004-02-21 18:01:29
|
Regarding the atmosphere type of air/water/vacuum, shouldn't that be put on most items? If we expand the game later to include the TFTD missions, I doubt we'd want the player using a pistol or incidiary rounds underwater for example. But a harpoon gun could be used out of water IMO, so it wouldn't be a "one or the other" type. Maybe you have 7 types: 1=air, 2=water, 3=vacuum, 4=air+water, 5=air+vacuum, 6=water+vacuum, 7=all. Then when the player gets to the site, the arming screen would only let you equip a soldier with items whose type matches the atmosphere. This point also brings up one of the laboratory ideas of having "weapon load templates", the member brought it up as using for a sniper vs. heavy assault type of load, but here you could create an "aqua" load, and have it switch weapons for you. It would be a hassle to have 24 soldiers loaded for water and switch to a land loadout, only to switch back for the next mission. But that is v1+ ideas, the point being that if you include this atmosphere type of every item, then that functionality would be possible later on. Breunor |
|
From: Mamutas P. <ma...@pr...> - 2004-02-21 03:52:02
|
It was not long before I read that file, wasn't it? It looks really good overall, but it wouldn't be me if I did not have any comments! :) 1) <capacity> should have a type of what it represents. Not really necessary, but could be helpful. The element should be optional, meaning it is equal 0. 2) radars and grav shield and mind shield have AP damage??? 3) Defenses ranges are not set. 4) <details> are optional. I like that. 5) Are build cost, build time and maintenance cost values for facilities real, or just sample? 6) Craft should have an attribute limiting loading item size. It might have a space for large units, but like Lightning might not have big door enough to fit a HWP in there. 7) Why there is a <range> for different shot types, like autoshot? What effect does it have? 8) There is a purchase cost for weapons, for example, what about sale price? 9) Not sure if we need atmosphere types that different, like terrestrial and martian. I think air/water/vacuum should do. Regards, mamutas -----Original Message----- From: Cpt. Boxershorts [mailto:cpt...@te...] Sent: Tuesday, February 17, 2004 12:25 AM To: Mamutas Plaukotas; 'Breunor' Subject: RE: Facilities config update with the new id/name convention For some reason I'm still getting an 'illegal character' message on the id. I thought it was the " " between words before, but... --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 |
58 messages has been excluded from this view by a project administrator.
