From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25029 invoked by alias); 19 Sep 2004 20:10:29 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 24997 invoked from network); 19 Sep 2004 20:10:26 -0000 Received: from unknown (HELO smtp809.mail.sc5.yahoo.com) (66.163.168.188) by sourceware.org with SMTP; 19 Sep 2004 20:10:26 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@67.121.168.201 with plain) by smtp809.mail.sc5.yahoo.com with SMTP; 19 Sep 2004 20:10:25 -0000 Subject: Re: XconqGIS Reply Summary (Ironically Long) From: Lincoln Peters To: cstevens@gencom.us Cc: Xconq Mailing List In-Reply-To: <1095617482.7956.126.camel@localhost> References: <1095617482.7956.126.camel@localhost> Content-Type: text/plain Message-Id: <1095624762.15989.23784.camel@localhost> Mime-Version: 1.0 Date: Sun, 19 Sep 2004 21:31:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01185.txt.bz2 On Sun, 2004-09-19 at 11:11, D. Cooper Stevenson wrote: > >Lincoln Peters: I suspect that Xconq's existing terrain libraries might > need to be modified (or a new, separate terrain library be written from > scratch) to accept the data you describe. > > Agreed. I am divided on this. On one hand, writing a GIS library to > interface with the Xconq kernel will be no small task. Also, Matthew > seems to have written a coordinate system that may just do the trick. On > the other, I beckon one of the fundamental laws of Unix > http://www.faqs.org/docs/artu/: > > "Design and build software, even operating systems, to be tried early, > ideally within weeks. Don't hesitate to throw away the clumsy parts and > rebuild them." More specifically, I'm thinking that a new terrain module might need to be written. You've probably noticed that in different games, terrain sometimes looks the same, but not always. This is because most games use either stdterr.g or advterr.g to define their terrain types, or they use a custom terrain library. > > This does not mean to imply that I think the library is clumsy. I > frankly think otherwise for it's purposes. I don't know if it would be > better for the libraries to be modified of if writing them from scratch > is necessary. I pray for the former. A new terrain module capable of handling the data you describe would certainly be more complicated than any of the existing terrain modules, and would most likely require some modifications to the kernel, but I'm sure that it can be done. It might even be easier than it sounds, but I can't make any promises. > > >Lincoln Peters: I have a few questions about the GIS data: 1. Does it > track vegetation separately from terrain? > > It sure does. Get a load of this: > http://wiki.xconqgis.org/index.php?GeologicalInformationSystemInformationGuide Interesting. > > I know too that GIS permits ASCII dumps of individual layers. I'm not > clear on all aspects; I'm a GIS newbie. I'm even more of a GIS newbie than you are. I suspect that, if the GIS data allows you to track vegetation separately from topography, it would make sense to use a new terrain module capable of doing that. Specifically, I'm thinking that most of the terrain features (soil composition, vegetation, etc.) would be implemented as terrain coatings. If you look at the message "Bug in day/night code?" that I posted yesterday, you'll find a pre-alpha version of such a terrain module. > > >Lincoln Peters: 2. Does it provide meteorological statistics, such as > average rainfall, wind patterns, etc.? I can see that a game based based > on something as detailed as GIS data might want to include such > statistics... > > The tutorial does mention rainfall statistics. I believe this is the > case. I tried to test this, but my tutorial data did not include the > rainfall rastering layer that they mentioned in the tutorial. I hadn't considered rainfall (I just considered the weather features Xconq currently supports), but now that you mention it, I can see that it would be important in modeling any other weather features. > > >Lincoln Peters: 3. Does it provide any detailed information about area, > such as soil composition or specific kinds of vegetation? > > Yes. This includes soils.Kfactor, soils.Tfactor, (whatever these mean) > soils.ph, and soils.range. Also included is a separate layer for > vegetation. I'd guess that soils.Kfactor is a measure of the potassium in the soil. I'm not sure about soils.Tfactor (it doesn't seem to correspond to anything on the periodic table the way that "K" does); I'll have to look into that. > > >Lincoln Peters: There are a few technical difficulties involved with > such a project that I can see already. One thing that comes to mind is > its representation of rivers. > > You got me here. I'm an Xconq map newbie. I will be documenting things > as I learn... To some extent, the implementation of rivers would depend on the scale of the game. As for implementing them as borders or connections, that would likely depend on how they are used in a game, unless it is possible for a game designer to make a border behave like a connection and vise versa in the case of specific units. I was hoping that someone else on the list will chime in on this, and it looks like Eric has done so. > > > Cooper Stevenson: I am working to build an aggressive new image set for > XCONQ. > > Eric McDonald: Excellent. > > Thank you! > > Eric has more terrain map insight specific to Xconq. I have to look at > this more before I can give intellegent dialog. I will do this soon; I > hope that I have provided a good start. And I see that he has commented about the rivers issue. I'm sure that there are other people who could provide useful information about the terrain code, but it looks like they haven't jumped in yet. > Also, before you read the following, note that I am a _die_hard_ > optimist. I think the following could be done with a lot of work. I > suspect that some of you have thought too along these lines: > > What would happen if the units you selected were actual human beings > connected to the main server via the Internet? To the individuals, the > game looks like a 3D game similar to Castle Wolfenstein: Enemy > territory. > > So when you select troops at the batallion view and give them > waypoints to follow into battle, that looks to them like a green arrow > on the horizon for them to go. The best part is that there are human > units on the other team trying to do the same thing to you. > > Now, combine that with a 3D battalion view, generated in real time. > When the battalion commander selects tanks, he's selecting _real_ > players. > Also, every game client reports the user's position back to the main > server their position as GIS data. This is an interesting idea, but I think that it would require a lot more work than anything you've suggested so far. Probably the most important first step would be to improve the isometric view code (which I think could be very useful when trying to determine line-of-sight, e.g. when you want to set up an artillery unit so that it has line-of-sight to its target). Maybe if it was re-implemented with OpenGL... --- Lincoln Peters Lies! All lies! You're all lying against my boys! -- Ma Barker