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: Guyver <gu...@ho...> - 2004-05-10 20:16:06
|
Here's first part of my assignment. Class Facility and it's derivated classed are specialized in one task (Defense, Shield etc.). Check it out and feel free to review it and/or post ideas. Guyver PS. Get to work all developers out there. The truth is out there. Like aliens... there're waiting for Xenocide to kick human asses. And we need to give them what they want, cuz if not they're gonna tear us all apart, starting from the ones that haven't worked at all... really. :) |
|
From: Guyver <gu...@ho...> - 2004-05-10 13:58:15
|
Here's my first code (not much thou:). Working on baseview I found that no one has tried to read data, that is really needed, becouse we are making data driven engine. While RedKnight is working in collaboration with Yake developers on creating automatic serialization mechanism, I drafted small replacement, to use in my developement. Derive from it and implement serialize as you like. Guyver PS. There's also IDataInterface class, which is supposed to work as workaround for purpose of registring variables and/or functions to use in scripting engine like Lua, (I'm using luabind becouse of it's simplicity). It's not like scripting will look like in future, but helps before that future comes. |
|
From: Tamas T. <te...@cs...> - 2004-05-06 18:03:05
|
If you want correct colours, this is the right attachment (darn, darn). centurion |
|
From: Tamas T. <te...@cs...> - 2004-05-06 17:56:32
|
Here are my 2 cents, with my usual ICarrier madness. centurion |
|
From: Robert B. <rbe...@an...> - 2004-05-05 04:23:33
|
Hi, I'm Jolly Robert, and I'm working on modeling a bunch of the internal rules for this. I'm relatively new, and don't know about much of what's been done; but here's my comments on the Items/Weapons system draft. Cheers: JollyRobert -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of xen...@li... Sent: Tuesday, May 04, 2004 11:08 PM To: xen...@li... Subject: Xenocide-programming digest, Vol 1 #163 - 1 msg Send Xenocide-programming mailing list submissions to xen...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/xenocide-programming or, via email, send a message with subject or body 'help' to xen...@li... You can reach the person managing the list at xen...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Xenocide-programming digest..." Today's Topics: 1. RE: Draft for the Items/Weapons System (Andrew Pokrovski) --__--__-- Message: 1 From: "Andrew Pokrovski" <a_p...@ho...> To: xen...@li... Subject: RE: [Xenocide-programming] Draft for the Items/Weapons System Date: Tue, 04 May 2004 11:28:24 -0400 Hey guys. Sorry for the long absence, I've been quite loaded down with university work and a job as well. Luckily, it's summer break time, so I should be able to put in a little more time. To weigh in on the 'hazardous environment' discussion, it's probably a good idea to have a special category for them - not only do they inflict damage over time, but (possibly) the area of effect could shrink/expand over that time span. Think fire spreading or smoke clearing. So, you'd have a 'time span' and a 'area of effect growth/shrink rate' and extra rules for that. Also, question on items: where does picking up and dropping things fit in? Is it at the 'FieldCarriable' level? Andrew / NickAragua _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362 ave/direct/01/ --__--__-- _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming End of Xenocide-programming Digest |
|
From: Andrew P. <a_p...@ho...> - 2004-05-04 15:28:34
|
Hey guys. Sorry for the long absence, I've been quite loaded down with university work and a job as well. Luckily, it's summer break time, so I should be able to put in a little more time. To weigh in on the 'hazardous environment' discussion, it's probably a good idea to have a special category for them - not only do they inflict damage over time, but (possibly) the area of effect could shrink/expand over that time span. Think fire spreading or smoke clearing. So, you'd have a 'time span' and a 'area of effect growth/shrink rate' and extra rules for that. Also, question on items: where does picking up and dropping things fit in? Is it at the 'FieldCarriable' level? Andrew / NickAragua _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/ |
|
From: Federico A. L. <fl...@ma...> - 2004-05-01 23:42:35
|
This is the draft of the Items/Weapons system, I didnt finish cause I couldnt... but better an incomplete design doc, than no design doc at all... I will try to finish it tomorrow. If anyone find anything in the draft (better now than later) send a mail so I can correct it. The file attached is a .zip that contains a 1.4 MB of rtf file (the good part is that the zip is only 200 Kb :D ), but I have to change its name cause SF Net refuses to accept it. Greetings Red Knight |
|
From: mamutas <ma...@pr...> - 2004-04-24 02:12:29
|
Great stuff! And even documented!!! I just had a chance to download it. I hope to look through it over the weekend and provide some feedback. Thanks, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: Sunday, April 18, 2004 6:11 PM To: xen...@li... Subject: RE: [Xenocide-programming] XML facility-item data Well, since it looks like the ftp site got restored from a back up, the previous link is bad. I uploaded it again, as well as the unzipped files. I also added one more file I had missed...config.planets.xml. It's designed to hold info for geodata.h http://www.projectxenocide.com/public/CTD/CptBoxershorts/xml/Config/ The Captain --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004 |
|
From: Christopher C. P. <chr...@sb...> - 2004-04-19 02:43:02
|
Hey Everyone, Since I'm not able to contribute much to the XML interface of the game (due to my troubles with Xerces not working in Linux), I've been looking into areas I can contribute. I think one thing that is slowing down development, is that the workload doesn't seem to have been divided up into units. If we could divide things up into classes that still need to be developed, I think it would help a lot. The process of finding work is very vague. I think it would help a lot if we just maintained a list of classes and their development status. That we it would be easy to see what's inactive or not started. We don't need to do the entire design documentation for this, just a simple list. Your thoughts? Regards, chrisp |
|
From: Cpt. B. <cpt...@pr...> - 2004-04-18 23:11:44
|
Well, since it looks like the ftp site got restored from a back up, the previous link is bad. I uploaded it again, as well as the unzipped files. I also added one more file I had missed...config.planets.xml. It's designed to hold info for geodata.h http://www.projectxenocide.com/public/CTD/CptBoxershorts/xml/Config/ The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: April 16, 2004 2:07 PM To: xen...@li... Subject: RE: [Xenocide-programming] XML facility-item data Ta-da! At long last, here are the xml files and documentation for configuring most every object in the game. Let me know if I missed anything. All of the files except for *.items.* have internal DTD validation. The *.items.* files use config.items.dtd. I know raw xml is tough to read, so look at the documentation first. Just to warn you, I may have gotten a bit carried away...but everything is so interrelated, I kind of had to. I have a website that displays most of these in a much more readable format than raw xml. It's currently broken due to fun times with IIS and xml layout changes. As soon as it's working (maybe over the weekend if I have time), I'll post the link. Apparently SourceForge is not accepting zipped files, so you can get all them here: http://www.projectxenocide.com/public/CTD/CptBoxershorts/XML/XMLconfig.z ip -The Captain ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Cpt. B. <cpt...@pr...> - 2004-04-16 21:07:26
|
Ta-da! At long last, here are the xml files and documentation for configuring most every object in the game. Let me know if I missed anything. All of the files except for *.items.* have internal DTD validation. The *.items.* files use config.items.dtd. I know raw xml is tough to read, so look at the documentation first. Just to warn you, I may have gotten a bit carried away...but everything is so interrelated, I kind of had to. I have a website that displays most of these in a much more readable format than raw xml. It's currently broken due to fun times with IIS and xml layout changes. As soon as it's working (maybe over the weekend if I have time), I'll post the link. Apparently SourceForge is not accepting zipped files, so you can get all them here: http://www.projectxenocide.com/public/CTD/CptBoxershorts/XML/XMLconfig.z ip -The Captain |
|
From: Tamas T. <te...@cs...> - 2004-04-14 07:55:23
|
Thinking about it, making ICombatants ICarriables isn't terribly unreal, and would make IAircraft simpler (and only posiible problem is with names, as an ICombatant would have an ICarrier name and an ICarriable name). So ICarrier would have to handle non-rectangle containers (btw where is the positionless interface? couldn't find it, so I've put in my own idea in the attachment). To engines, will we have a simplified way of handling it (engine determines max speed, acceleration, everything), or make things dependent on both the engine and the craft (say, fuel capacity is not something logically bound to the engine)? centurion |
|
From: Christopher C. P. <chr...@sb...> - 2004-04-13 04:17:38
|
> That is a very good news indeed, however I am quite troubled about hearing > that you have to tweak OGRE code to make it work in Linux. Unfortunately this is a problem I've run into often recently. The main dificulty is the rapidly changing nature of C++ and how the GCC compiler compiles it. Depracated features have a very short lifespan in GCC. Since most open source projects freeze their development environment while developing (for good reason), the version of GCC used gradually becomes outdated. In the case of OGRE they are using GCC 3.1, while I have 3.3.2. The changes I made reflected this difference. The good news is that I was able to make all changes at the top level config file (OgreConfig.h). It's not too difficult when you know where to look, there just isn't much documentation on how to do this and OGRE's automatic configuration isn't quite there yet. Since they're in a somewhat early development phase, these things will surely improve in time. If worse comes to worse, I can build binaries using our chosen configuration and distribute them. Really though, given the complexity of OGRE I was surprised it wasn't more difficult to get it working. It certainly is NOTHING compared to the nightmare I've experience with Xerces. BTW.. I've tried contacting their developers regarding my problems and have recieved no response. > On the other side, I would like to know what part of the Xenocide source has > been changed so I can crosscheck it and commit the source to the CVS. Send > me a patch, and be careful that some libraries had change a lot in the > latest 10 days (mostly Network Library). You can do that from your CVS > client and post it in the Xenocide Sourceforge patch area (I will be > informed by Sourceforge in like 10 minutes after you do that). The changes to the libs were pretty lite. They mostly involved changing string and integer settings. No changes were made to the network library (that I can remember). The code I have checked out is older, but here is what I have. I'll have to update the code and try recompiling, but I think it should work fine. I think all of my changes were in Common.h and the common directory. > About Linux support, well we already have a nice Rendering engine working in > Linux (OGRE), so crossplatform is not that much away, cause Xenocide source > was developed with portability in mind. About supported compiler, the actual > GCC stable version (3.3.2??) sounds like a good tradeoff, any other desition > that you need that I take about platform specific stuff, just drop it as > always. GCC 3.3.2 makes sense for now, but I think we should shoot for 3.3.3 (once it comes out) as our baseline. The reason for this is that 3.3.2 has been out for some time now, and we want to have THE most modern version as our baseline so that we stay current for as long as possible. This should give us a 6-12 month boost for that, and it shouldn't be difficult to get everything working in 3.3.3 at this early stage We also need to decide on what bin-utils version to use. For this we should probably choose whatever version is most current once GCC 3.3.3 is out. It is very important to decide on this because bin-utils contains automake and autoconf which we'll want so that we don't have to build our makefiles from scratch *shudder*. Updating GCC and bin-utils is a real undertaking, so it's best to get out of the way early on. Plus.. we need to decide on an IDE to use. I recommend KDevelop. It is the most mature IDE for Linux. It's a little more difficult to use than .net and Borland, but it is very solid and has an extensive set of features (CVS & SVN integration, full debugging capabilities, performance analizers, even a check for memory leaks!). What version we use is less important for this. Either 3.1 or 3.2+ should be fine. That's pretty much it I think.. If all of this sounds good, I can come up with some documentation for our Linux development standard and put it on the boards. Sorry for the lengthy email! Regards, chrisp > -------Original Message------- > > From: Christopher C. Phillips > Date: 04/12/04 17:59:37 > To: xen...@li... > Subject: [Xenocide-programming] Linux Development - Everything compiles > > I sent this message last week, but it didn't seem to get through due to my > email problems (I was wondering why there was no response :P ). Let me > know your thougths.. -chrisp > > > Some good news for those of us interested in developing > and compiling Xenocide in Linux. > > After a fair amount of effort, I was able to successfully build and > install Ogre on my Linux machine using GCC 3.3.2. There were several > required libraries that need to be installed, and some of them required a > little tweaking of the source code to compile in Linux. The Ogre source > also involved some source tweaking. I have also made some (relatively > minor) changes to the utility libraries. > > With this done, I was able to compile the xenoengine framework and some > of intermediate code (haven't tried it all) in Linux without any problems. > (WOOHOO!) > > If there is interest, I can upload the altered Ogre and required libraries > source to the ftp site. If we decide to develop in parallel (which I > think we should), there are a number of decisions that would need to be made > regarding standard tools we use to build in Linux. I think allowing > people to develop in Linux would bring in a great deal of help, since > Linux is obviously the open source platform of choice. Also, developing > in Linux would make a Mac port that much easier. Of course this shouldn't > come at the sacrifice of Windows. At this point, it seems like code > developed in Linux should have no problem compiling in Windows. It > shouldn't slow down development. In fact, I think it would greatly > increase it. > > Regards, > chrisp > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > |
|
From: Christopher C. P. <chr...@sb...> - 2004-04-12 20:58:33
|
I sent this message last week, but it didn't seem to get through due to my email problems (I was wondering why there was no response :P ). Let me know your thougths.. -chrisp Some good news for those of us interested in developing and compiling Xenocide in Linux. After a fair amount of effort, I was able to successfully build and install Ogre on my Linux machine using GCC 3.3.2. There were several required libraries that need to be installed, and some of them required a little tweaking of the source code to compile in Linux. The Ogre source also involved some source tweaking. I have also made some (relatively minor) changes to the utility libraries. With this done, I was able to compile the xenoengine framework and some of intermediate code (haven't tried it all) in Linux without any problems. (WOOHOO!) If there is interest, I can upload the altered Ogre and required libraries source to the ftp site. If we decide to develop in parallel (which I think we should), there are a number of decisions that would need to be made regarding standard tools we use to build in Linux. I think allowing people to develop in Linux would bring in a great deal of help, since Linux is obviously the open source platform of choice. Also, developing in Linux would make a Mac port that much easier. Of course this shouldn't come at the sacrifice of Windows. At this point, it seems like code developed in Linux should have no problem compiling in Windows. It shouldn't slow down development. In fact, I think it would greatly increase it. Regards, chrisp |
|
From: Christopher C. P. <chr...@sb...> - 2004-04-12 20:09:35
|
My email woes were caused by incorrect sender information being sent through with my emails. This prevented me from recieving replies to my emails and caused problems with sending/receiving from the sourceforge list. It is corrected now. If you want to reply to me personally regarding previous messages email me at: chr...@sb... Future messages should be fine.. Sorry for the trouble! -chrisp |
|
From: mamutas <ma...@pr...> - 2004-04-11 19:53:33
|
First option is the easiest to read which is important, cause XML will be created by human. And XML allows making entry optional, so the user could put only necessary entries. The parser will follow what is in DTD, so it should not be a big deal for the parser to detect what entry is expected. -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: Wednesday, April 07, 2004 10:38 PM To: xen...@li... Subject: RE: [Xenocide-programming] XML facility-item data Hey all, One more question, and then I should have the config files posted as soon as I finish the design docs. I'm finishing up the cross-references between different items, research nodes, crafts, etc., and I've come up with three possible ways to record it. So that everybody understands what I'm talking about, a cross reference is where one entry points to another entry, e.g. the Pistol Ammo Clip item has a reference to the Pistol item that indicates which item it can reload. That's a simple one....two items, same document, same 'type'. In the research tree, there are references to six different entry types (other topics, crafts, items, personnel, facilities, and missions) The specific 'type' must be able to be determined by the parser so it knows which document to look in for the associated entry. The first way is to have a separate xml element for each reference type. So it would look like this: <craft craftid="craft1"/> <item itemid="item1"/> <facility facilityid="facility1"/> Pros: Each element immediately defines the 'type' of reference. Minimal processing (just a select case, really) is needed to determine where the associated document is. Cons: Not every entry uses all element types, so the xml is overly complicated. The parser would need to recognize and watch for all the different possible reference elements. Adding a new reference element might require extensive code work. The second idea is to combine them into one element with multiple attributes. Only one of the attributes would ever be used. <reference craftid="craft1"/> <reference itemid="item1"/> <facility facilityid="facility1"/> Pros: easy to read, easy for the parser to know what element is a reference. Cons: More process intensive. Each attribute would have to be tested for a valid value to find the id value. Third idea takes it a step farther. Since in xml, a unique identifier must start with an alphabetic character, I ened up changing all the id values from "1, 2, 3..." to "item1, item2, item3..." with the actual 'type' as a prefix to the id (it seemed better than using an arbitrary string). So technically, with a bit of string manipulation, you can tell what 'type' the reference is to, and there's no need for multiple attributes: <reference refid="craft1"/> <reference refid="item1"/> <facility refid="facility1"/> Pros: Easy to read, easy to pick the id value out Cons: String manipulation is major processor hog. Thought? -The Captain --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.650 / Virus Database: 416 - Release Date: 4/4/2004 |
|
From: Cpt. B. <cpt...@pr...> - 2004-04-11 01:36:30
|
Hi RK, >> Should the data file for crafts contain size/shape of the hold as well? >> Currently I just have amounts for smallunits (operatives), largeunits >> (xcaps), and equipment (toys). What about for alien crafts? >Do you have any idea for this kind of thing? I created a uniform container >based >system for storing things (with position aware interface and positionless >interface too). Do you have an XML entity idea of what would be needed? I started to do this, but I couldn't come up with anything for non-rectangular shapes (specifically, the belt area on a combat unit). The idea suggested (I don't remember if it was you or centurion) about defining a rectangle, and then flagging specific coordinates as unavailable would work. >BTW Cpt. if you want to define the data needed for the diferent Object >interfaces, then go for it cause they will then coded in C++ or offloaded >to a >loader. In that case we already have the loading code, and even if it not >we >will have a guideline for entity object design. (XML can be very Object >Oriented if well crafted). I've got most of the data outlined...I'll start posting the layouts as I finish the documentation. Some of the layouts (items, specifically) are quite complicated, and probably unreadable without the docs. -The Captain > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Tamas Terpai > Sent: April 8, 2004 12:26 PM > To: xen...@li... > Subject: [Xenocide-programming] non-rectangle aircraft holds > > Attached is a version of IAircraft with the soldier hold that's not > necessarily a rectangle (no way of initializing one yet, though), like > the > Ultimate Craft in one of the equipping concept pics; additionally, > 'personnel' and 'hullOccupancy' now cross-reference each other, which > makes things faster (at least with non-rectangle hulls) but needs more > memory. So I'd like to know whether it's ok or the memory will be the > bottleneck with idle CPU time present. > To the flight path update question: if the TimeDate has appropriate > resolution, then it can be updated during each frame (.1 milliseconds > resolution at 100 fps = 1% discrepancy between rounded simulation time > and > real time, I doubt anybody would notice). > > centurion > > > > > ------------------------------------------------------- > 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 |
|
From: <red...@pr...> - 2004-04-10 03:38:52
|
> Are we going to institute an Engine class as well as an Armor class? It > might be good for future-proofing. Well having an Engine class wont be anything bad at all, cause we can offload the problem of getters/setters of velocity-fuel-etc and maybe some simulation (who knows) into the Engine class. I say that we can try to see how it works out. Any other idea? > Should the data file for crafts contain size/shape of the hold as well? > Currently I just have amounts for smallunits (operatives), largeunits > (xcaps), and equipment (toys). What about for alien crafts? Do you have any idea for this kind of thing? I created a uniform container based system for storing things (with position aware interface and positionless interface too). Do you have an XML entity idea of what would be needed? BTW Cpt. if you want to define the data needed for the diferent Object interfaces, then go for it cause they will then coded in C++ or offloaded to a loader. In that case we already have the loading code, and even if it not we will have a guideline for entity object design. (XML can be very Object Oriented if well crafted). Greetings Red Knight > > On a related topic, should the data file contain size/shape of weapon > points too? > > -The Captain > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Tamas Terpai > Sent: April 8, 2004 12:26 PM > To: xen...@li... > Subject: [Xenocide-programming] non-rectangle aircraft holds > > Attached is a version of IAircraft with the soldier hold that's not > necessarily a rectangle (no way of initializing one yet, though), like > the > Ultimate Craft in one of the equipping concept pics; additionally, > 'personnel' and 'hullOccupancy' now cross-reference each other, which > makes things faster (at least with non-rectangle hulls) but needs more > memory. So I'd like to know whether it's ok or the memory will be the > bottleneck with idle CPU time present. > To the flight path update question: if the TimeDate has appropriate > resolution, then it can be updated during each frame (.1 milliseconds > resolution at 100 fps = 1% discrepancy between rounded simulation time > and > real time, I doubt anybody would notice). > > centurion > > > > > ------------------------------------------------------- > 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: Cpt. B. <cpt...@pr...> - 2004-04-08 22:51:05
|
Are we going to institute an Engine class as well as an Armor class? It might be good for future-proofing. Should the data file for crafts contain size/shape of the hold as well? Currently I just have amounts for smallunits (operatives), largeunits (xcaps), and equipment (toys). What about for alien crafts? On a related topic, should the data file contain size/shape of weapon points too? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Tamas Terpai Sent: April 8, 2004 12:26 PM To: xen...@li... Subject: [Xenocide-programming] non-rectangle aircraft holds Attached is a version of IAircraft with the soldier hold that's not necessarily a rectangle (no way of initializing one yet, though), like the Ultimate Craft in one of the equipping concept pics; additionally, 'personnel' and 'hullOccupancy' now cross-reference each other, which makes things faster (at least with non-rectangle hulls) but needs more memory. So I'd like to know whether it's ok or the memory will be the bottleneck with idle CPU time present. To the flight path update question: if the TimeDate has appropriate resolution, then it can be updated during each frame (.1 milliseconds resolution at 100 fps = 1% discrepancy between rounded simulation time and real time, I doubt anybody would notice). centurion |
|
From: <red...@pr...> - 2004-04-08 22:02:34
|
> Attached is a version of IAircraft with the soldier hold that's not > necessarily a rectangle (no way of initializing one yet, though), like the > Ultimate Craft in one of the equipping concept pics; additionally, > 'personnel' and 'hullOccupancy' now cross-reference each other, which > makes things faster (at least with non-rectangle hulls) but needs more > memory. So I'd like to know whether it's ok or the memory will be the > bottleneck with idle CPU time present. Forget about both CPU efficience and or memory consumption efficiency, what we really need is coding efficiency so an easy, well designed interface is what we should aim to. I am sending a very simplified version (took out a lot of code just for showing the most important concepts). I think we should start from here following the same guidelines, to define the interface in that way. Always aim for programmers/debug convenience, dont use strange flags, very meaningful names, etc. You choosed very experimental code to implement, as not much interface work had been done with it yet. You shouldnt waste your time implementing unfinished interfaces. I can assure you the one that I proposed to implement is near final, so you can implement it. For interface work, you should put toghether and interface, submit it for discussion in the list (dont even write a line of code, cause it will change - I assure you ;) ). And only after is agreed on, start doing the implementation work. We work faster that way, the problem is not much people is doing interface definition and some very important (very basic) classes are not ready so most code cannot even get into CVS after those classes are (even if in dummy form). Greetings Red Knight |
|
From: Tamas T. <te...@cs...> - 2004-04-08 19:26:40
|
Attached is a version of IAircraft with the soldier hold that's not necessarily a rectangle (no way of initializing one yet, though), like the Ultimate Craft in one of the equipping concept pics; additionally, 'personnel' and 'hullOccupancy' now cross-reference each other, which makes things faster (at least with non-rectangle hulls) but needs more memory. So I'd like to know whether it's ok or the memory will be the bottleneck with idle CPU time present. To the flight path update question: if the TimeDate has appropriate resolution, then it can be updated during each frame (.1 milliseconds resolution at 100 fps = 1% discrepancy between rounded simulation time and real time, I doubt anybody would notice). centurion |
|
From: <red...@pr...> - 2004-04-08 17:31:19
|
> How do we plan on updating interceptor/UFO flight paths? They would jump > a lot if updated every second, or would we map a new flight path for them > to follow each second and have them "fly" in between intervals? > > -chrisp The position interval is just a simulation step ( there is no time involved ) as the simulation timestep use a high resolution time tracker that do not involve the knowledge of seconds, let alone days or string representation of it. However it is important to find a map between the simulation time for events such as crash lands (if we ever track them down) or the actual time for lighting in the battlescape or the sun lighting in the planetscape (everywhere when a high resolution timer is either not necesary or not suitable for the task). Greetings Red Knight |
|
From: Cpt. B. <cpt...@pr...> - 2004-04-08 03:38:32
|
Hey all, One more question, and then I should have the config files posted as soon as I finish the design docs. I'm finishing up the cross-references between different items, research nodes, crafts, etc., and I've come up with three possible ways to record it. So that everybody understands what I'm talking about, a cross reference is where one entry points to another entry, e.g. the Pistol Ammo Clip item has a reference to the Pistol item that indicates which item it can reload. That's a simple one....two items, same document, same 'type'. In the research tree, there are references to six different entry types (other topics, crafts, items, personnel, facilities, and missions) The specific 'type' must be able to be determined by the parser so it knows which document to look in for the associated entry. The first way is to have a separate xml element for each reference type. So it would look like this: <craft craftid="craft1"/> <item itemid="item1"/> <facility facilityid="facility1"/> Pros: Each element immediately defines the 'type' of reference. Minimal processing (just a select case, really) is needed to determine where the associated document is. Cons: Not every entry uses all element types, so the xml is overly complicated. The parser would need to recognize and watch for all the different possible reference elements. Adding a new reference element might require extensive code work. The second idea is to combine them into one element with multiple attributes. Only one of the attributes would ever be used. <reference craftid="craft1"/> <reference itemid="item1"/> <facility facilityid="facility1"/> Pros: easy to read, easy for the parser to know what element is a reference. Cons: More process intensive. Each attribute would have to be tested for a valid value to find the id value. Third idea takes it a step farther. Since in xml, a unique identifier must start with an alphabetic character, I ened up changing all the id values from "1, 2, 3..." to "item1, item2, item3..." with the actual 'type' as a prefix to the id (it seemed better than using an arbitrary string). So technically, with a bit of string manipulation, you can tell what 'type' the reference is to, and there's no need for multiple attributes: <reference refid="craft1"/> <reference refid="item1"/> <facility refid="facility1"/> Pros: Easy to read, easy to pick the id value out Cons: String manipulation is major processor hog. Thought? -The Captain |
|
From: <red...@pr...> - 2004-04-06 21:36:22
|
Hi all, > [is it considered ill manners not to write something on the top of an e-mail?] <RK> I dont think so. > Precision: float is inaccurate, but if there won't be lots of DateTime instantiations that will run for a long time aside one another, I can see no problem with double (in)accuracy or using an integer seconds value separately from the fractional part; during a game year at 100 time updates per game second <4E9 increases happen, producing something like a 100 seconds error in total, which is irrelevant if there is nothing to compare with. <RK> You are right in that, but I prefer to think of it for Xenocide as a timestep. (Interpreted as a second, that is the current needed resolution). > Doesn't matter, your call, microseconds used as minimal values (UInt32 isn't enough even for 10 ms units). <RK> Using microseconds is far too much for our needs (that is a high resolution timer :D )... we are ok using seconds. > > A fully implemented (gaudy) calendar is IMHO completely unnecessary, we > >only need it to show the user amounts of time, and only in usual terms. So > >all constants went private, but stayed static (why create unnecessary > >instants of them every time a DateTime is created). I was thinking on in gaudy calendar terms when I gave you the links, but in posible localization needs, thats why the conversions should be virtual (for instance in here que use pretty diferent ways to write the string version of the daytime) > Am I correct in thinking DateTime will be instantiated 1)as the game clock and 2)as workshop/arrival date holder only? Mhh probably nope. We may have other uses for it, that includes event initiation times, posibly stored on the data structures used for information holding. That includes UI things like the one needed on the planetview, etc. It is a general time helper class. Thats why I pointed to those DateTime classes the most interesting stuff is the add, diference, and that functionality. > To use OGRE's PI value I have to know where it will be, and I don't have the slightest idea. I will handle that then before committing the sources. Greetings Red Knight |
|
From: Red K. <red...@pr...> - 2004-04-05 18:46:47
|
I2luY2x1ZGUgPHV0aWxpdHkvY29tbW9uLmg+DSNpbmNsdWRlICJ4ZW5vY2lkZS9zcmMvY29tbW9u L3hlbm9yZXF1aXNpdGVzLmgiDQ0KLy8gPFJLPiBXYXRjaCBvdXQgeW91IGhhdmUgc2VyaW91cyBw cm9ibGVtcyB3aXRoIGVuZCBsaW5lcywgZWl0aGVyIHlvdXIgZWRpdG9yIG9yIHlvdXIgbWFpbCBj bGllbnQgaXMNLy8gY29ycnVwdGluZyB0aGUgZmlsZXMgc28gSSBnZXQgb25lIGxpbmUgYW5kIGFu IGVtcHR5IGxpbmUgYWZ0ZXIgdGhhdCBvbmUuIChmb3IgYWxsIGxpbmVzKSA8Uks+DW5hbWVzcGFj ZSBYZW5vY2lkZQ17DQ0KLy8gPFJLPiBUYWtlIGEgbG9vayBhdCBoZXJlIHlvdSB3aWxsIGZpbmQg c29tZSBpbnRlcmVzdGluZyBpZGVhczoNCi8vIGh0dHA6Ly9vc3Muc29mdHdhcmUuaWJtLmNvbS9p Y3UvdXNlcmd1aWRlL2RhdGVDYWxlbmRhci5odG1sI2NhbA0KLy8gQW5vdGhlciBnb29kIHNvdXJj ZSBpcyB0aGUgSmF2YSBvciAuTkVUIEFQSSBmb3IgYSB3ZWxsIGRvbmUgQ2FsZW5kYXIvRGF0ZVRp bWUgDQovLyBPT1AgY29ycmVjdCBzb2x1dGlvbi4NCg0KY2xhc3MgRGF0ZVRpbWUNCnsNCnB1Ymxp YzoNDQoJRGF0ZVRpbWUoUmVhbCB0aW1lKTsNDQoJRGF0ZVRpbWUoY29uc3QgRGF0ZVRpbWUmIGRh dGVUaW1lKTsNDQoJRGF0ZVRpbWUoVUludDMyIHllYXIsIFVJbnQ4IG1vbnRoLCBVSW50OCBkYXks IFVJbnQ4IGhvdXIgPSAwLCBVSW50OCBtaW51dGUgPSAwLCBSZWFsIHNlY29uZCA9IDApOw0NCgl2 aXJ0dWFsIH5EYXRlVGltZSgpOw0NCg0vLyBBbGwgdGhpcyBpcyBub3Qgc3VwcG9zZWQgdG8gYmUg ZWl0aGVyIHN0YXRpYyBub3IgcHVibGljLg0vLyBFbmNhcHN1bGF0ZSBpdCBpbiBhIHZpcnR1YWwg Y2FsbCBpbiBhIHByb3RlY3RlZCBmdW5jdGlvbiBpZiBpbnNpZGUgeW91IHdhbnQgdG8gdXNlIA0v LyBhbiBzdGF0aWMgdmFyaWJsZSB0byBoYW5kbGUgaXQsIGl0IGlzIHVwIHRvIHlvdSBidXQgdGhl cmUgaXMgbm8gcG9pbnQsIG5vciBPT1AgdmFsaWQNLy8gcmVhc29uIHRvIGRvIGl0IHRoaXMgd2F5 LiA8Uks+DQ0gICAvLyBhbGwgdGltZSBpcyBpbiBzZWNvbmRzIGFmdGVyIGJlZ2lubmluZyBvZiBO ZXcgWWVhciBEYXkgbnVsbFllYXINCXN0YXRpYyBjb25zdCBVSW50MzIgbnVsbFllYXI7DQkvLyBk YXkgb2Ygd2VlayBhdCAxc3QgSmFuIG51bGxZZWFyDQlzdGF0aWMgY29uc3QgVUludDggbnVsbFdl ZWtEYXk7DQlzdGF0aWMgY29uc3QgVXRpbGl0eTo6U3RyaW5nIG1vbnRoTmFtZXMgWzEyXTsNCXN0 YXRpYyBjb25zdCBVdGlsaXR5OjpTdHJpbmcgbW9udGhOYW1lTmlja3MgWzEyXTsNCXN0YXRpYyBj b25zdCBVdGlsaXR5OjpTdHJpbmcgd2Vla0RheU5hbWVzIFsxMl07DQlzdGF0aWMgVUludDggc3Rk TW9udGhMZW5ndGhzIFsxMl07DQlzdGF0aWMgVUludDggZXh0TW9udGhMZW5ndGhzIFsxMl07DSAg IFVJbnQ4ICgqbW9udGhMZW5ndGhzKVsxMl07DQ0KCXN0YXRpYyBCb29sIGlzRXh0ZW5kZWRZZWFy KFVJbnQzMiB5ZWFyKTsNDQoJdm9pZCBzZXRBY3RpdmVNb250aHMoY29uc3QgVUludDMyIHllYXIp Ow0NCglzdGF0aWMgVUludDMyIG51bWJlck9mRGF5cyhVSW50MzIgeWVhcik7DS8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8NCg0NCi8vIDxSSz4gVGhvc2UgYXJl IHZhbGlkIGZpZWxkcyBmb3IgYSBkYXRldGltZSBldmVuIGlmIHlvdSB1c2UgYW4gVVRDIHZhbHVl Lg0KCVVJbnQ4IGdldFNlY29uZCgpOw0JVUludDggZ2V0TWludXRlKCk7DQlVSW50OCBnZXRIb3Vy KCk7DQlVSW50OCBnZXREYXkoKTsNCVVJbnQ4IGdldERheU9mV2VlaygpOw0JVUludDggZ2V0TW9u dGgoKTsNCVVJbnQzMiBnZXRZZWFyKCk7DQ0KDS8vIDxSSz4gWW91IGhhdmUgdG8gYXZvaWQgdXNp bmcgcmVhbCBudW1iZXJzIGZvciB0aW1lcywgYmVjYXVzZSB0aGV5IGFyZSBsb3NpbmcgDQovLyBw cmVjaXRpb24gYXMgbG9uZyBhcyB0aGV5IHJ1biwgaXQgaXMgYmV0dGVyIHRvIHVzZSBhbiBpbnRl Z2VyIG51bWJlciB0aGF0IGhhcw0KLy8gYSBmaXhlZCBzdGVwIGJldHdlZW4gdmFsaWQgbnVtYmVy cy4NCgl2b2lkIGFkZFRpbWUoUmVhbCBleHRyYVRpbWUpOw0NCi8vIDxSSz4gVGhvc2UgYXJlIGNv bXBsZXRseSBwcml2YXRlIGZ1bmN0aW9ucy4NCi8vIDxSSz4gVGhvc2UgaGF2ZSB0byBiZSB2aXJ0 dWFsIHNvIHlvdSBjYW4gbG9jYWxpemUgbGF0ZXIgaWYgbmVlZGVkLCBCVFcgZmluZCBiZXR0ZXIg bmFtZXMgZm9yIHRoZW0NICAgVXRpbGl0eTo6U3RyaW5nIGludGVnZXJUb1N0cmluZyhVSW50MzIg bnVtYmVyKTsNCVV0aWxpdHk6OlN0cmluZyBpbnRlZ2VyVG9GaXhTaXplZFN0cmluZyhVSW50MzIg bnVtYmVyLCBVSW50OCBzaXplKTsNCVV0aWxpdHk6OlN0cmluZyBnZXROYW1lT2ZPcmRpbmFsKFVJ bnQ4IG51bWJlcik7DS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vDQoN Cg0vLyA8Uks+IFRob3NlIGhhdmUgdG8gYmUgdmlydHVhbCBzbyB5b3UgY2FuIGxvY2FsaXplIGxh dGVyIGlmIG5lZWRlZA0gICAvLyBNb25kYXkgNXRoIEFwcmlsIDIwMDQgMTg6NTU6NDMNCVV0aWxp dHk6OlN0cmluZyBnZXRGdWxsVGltZVN0cmluZygpOw0JLy8gTW9uZGF5IDV0aCBBcHJpbCAyMDA0 DQlVdGlsaXR5OjpTdHJpbmcgZ2V0RnVsbERhdGVTdHJpbmcoKTsNCS8vIDE4OjU1OjQzDSAgIFV0 aWxpdHk6OlN0cmluZyBnZXRUaW1lU3RyaW5nKCk7DQkvLyA1IEFwciAyMDA0DQlVdGlsaXR5OjpT dHJpbmcgZ2V0U2hvcnREYXRlU3RyaW5nKCk7DQ0KLy8gPFJLPiBZb3UgaGF2ZSB0byBhdm9pZCB1 c2luZyByZWFsIG51bWJlcnMgZm9yIHRpbWVzLCBiZWNhdXNlIHRoZXkgYXJlIGxvc2luZyANCi8v IHByZWNpdGlvbiBhcyBsb25nIGFzIHRoZXkgcnVuLCBpdCBpcyBiZXR0ZXIgdG8gdXNlIGFuIGlu dGVnZXIgbnVtYmVyIHRoYXQgaGFzDQovLyBhIGZpeGVkIHN0ZXAgYmV0d2VlbiB2YWxpZCBudW1i ZXJzLg0gICBSZWFsIGdldFRpbWVWYWx1ZSgpOw0KDQovLyA8Uks+IENvbXBhcmluZyB0d28gdGlt ZXMgaXMgYW4gaW1wb3J0YW50IHRhc2ssIEkgc2hvdWxkIHB1dCBpdCBiYWNrLg0KLy8gPFJLPiBU aGUgc2FtZSB0byBhZGQgYW5kIGdldCBhIGRpZmZlcmVuY2Ugb2YgdHdvIGRhdGV0aW1lcy4NCiAg IA0KcHJpdmF0ZToNLy8gPFJLPiBZb3UgaGF2ZSB0byBhdm9pZCB1c2luZyByZWFsIG51bWJlcnMg Zm9yIHRpbWVzLCBiZWNhdXNlIHRoZXkgYXJlIGxvc2luZyANCi8vIHByZWNpdGlvbiBhcyBsb25n IGFzIHRoZXkgcnVuLCBpdCBpcyBiZXR0ZXIgdG8gdXNlIGFuIGludGVnZXIgbnVtYmVyIHRoYXQg aGFzDQovLyBhIGZpeGVkIHN0ZXAgYmV0d2VlbiB2YWxpZCBudW1iZXJzLg0KCVJlYWwgdGltZVZh bHVlOw0NCn07DQ0KDQ0KfSAvLyBYZW5vY2lkZQ== |
58 messages has been excluded from this view by a project administrator.
