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: <fl...@ma...> - 2004-01-31 14:49:09
|
Hi Vlad, (forwarding to the list), I am glad to announce you that the Counted Reference template I had made based on some interesting ideas that I collected from the internet is live and kicking :P ... I cannot update it cause I dont have internet at home for (I hope) a few days. But it had overcomed my own expectations (I had even done a test suite -regression test- for it and they work as expected)... The only thing that I had been having trouble is to integrate the Singleton template from another compilation unit (I created a singleton in one .lib and try to use it from the main program), it do not get created but I cannot reseach it further until I have internet again. As a side note, I am very convinced that the network persistent data will follow the same approach as CountedRef<classname> because of its simplicity and has an additional system that will keep them synchronized. So we will have 2 new templates NetworkRef<classname> and ServerRef<classname> that will be used to do the effective store (so there will be a map between instances). And of course a NetworkReferenceManager and a ServerReferenceManager (or a single NetworkReferenceManager) that will handle the load to communicate to the other side what objects changed and how and in the case of a NetworkRef change issue the command to the server for data and action validation. Any idea on the latest issue just drop it to the list (that's for all readers). Greetings Red Knight |
|
From: Cpt. B. <cpt...@te...> - 2004-01-27 01:22:56
|
Hey all,
Please, critique away. We're trying to write a great game, not just
'pretty good'. :)
I agree that logically, having crafts in the hanger node makes more sense.
I was just thinking that in the object model itself, all a hanger needs to
know is A) is a craft assigned to it and B) is the craft currently in it.
The first is only used when purchasing or transferring, and the second only
for the baseview. Everything else (Equip, Intercept, sell/sack (which hits
item A as previous)) looks at crafts as belonging to the base, rather a
specific hanger. I thought it would be easier/faster to have a master list
of crafts, and the hangers just have a reference to an item on that list.
That's not necessarily the way we'll do it, of course, plus XML logic
doesn't need to copy internal logic anyways. It doesn't matter to me which
way we do it...I just wanted to explain my thinking.
Here's a sample of how the craft would be portrayed (wherever it ends up):
<craft name="Interceptor1" status="Available"> <!-- name is uid. -->
<type>Interceptor</type>
<name>Interceptor 1</name> <!-- <name> is user editable title-->
<hanger>Hanger1</hanger> <!-- reference to hanger. moot if craft is
contained by hanger -->
<currentHP>100</currentHP>
<weapons>
<item name="Cannon" ammo="500" hardpoint="1" /> <!--hardpoint indicates
index/uid of specific weapon location -->
<item name="Ajax Launcher" ammo="6" hardpoint="2" />
</weapons>
</craft>
I agree that the transfer section is redundant. Just wanted a second
opinion. Consider it gone.
I like your suggestion of how to handle transfers. Simple, elegant, and
does the job. I'll try to have it in in the next version.
I'm not sure what else would go under <scientists> at this point. Since the
scientists aren't individual units (in this version at least), there's
nothing else to keep track of. I figured the Lab facility would keep track
of actual research topics. Workshops would look pretty much the same.
<facility name="Laboratory1" type="Laboratory">
<location x="3" y="2" />
<complete>true</complete>
<builddays>0</builddays>
<capacity>50</capacity>
<usedcapacity>10</usedcapacity>
<contents>
<scientist quantity="5">Laser Weapons</scientists>
<scientist quantity="5">Medikit</scientists>
</contents>
</facility>
I agree that barracks and stores facilities have no need of <contents>
now...but I know that base damage is high on the list for v1+, and adding
that level of granularity now would save time in the future. Of course, the
item itself could just have reference to the parent facility...but that's
the crafts/hanger argument again.
For v1, knowing which barracks a unit is in (randomly assigned when hired, I
assume) could be used to determine starting locations during base attacks,
and having stored items (weapons, primarily) available on the battlescape
during base attacks could be done easily ( Id don't know it that's on the
feature list for v1 or not).
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of Vlad
Judys
Sent: Saturday, January 24, 2004 7:52 PM
To: 'Cpt. Boxershorts'; xen...@li...
Subject: RE: [Xenocide-programming] Other XML Layouts?
Hi Cpt. and all.
I started to write the answer with critics, but it did not look good. So I
added this line here J Critics are below.
Overall, I think that layout looks really well. However, I did not like
the <content> and <transfer> sections. I think they should be combined. The
item in content must have more information about it status, where content is
one of them. Let’s say you have a gun in stores. So, the status of it is
‘stored’ or something. Then you transfer it to another base, the item
changes the base it belongs to and its status is ‘transferred’. We might
even have the number of hours till arrival.
Then for some specific content entries, for example scientists, we would
definitely want more information. But those are details which could be
flushed out later.
More major issue is that whether contained items must be described within
container or base itself. For example, crafts. There is a section in the
<base> which lists crafts, but then there is a reference to them from
<hangar>. From programming point of view it is just difference in one method
of Base class: either retrieve list of crafts within Base object itself or
create a list of crafts from the crafts from all hangars. I would prefer
that crafts would be listed inside the hangars – the XML would be clearer.
But that is different for stores or living quarters: it is not important
what store the pistol is in or what barrack John Doe is in – we are not
going to display them differently or provide that kind of info for players.
Regards
mamutas
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
|
|
From: Mamutas P. <ma...@pr...> - 2004-01-25 04:04:28
|
Hi all, I just read the discussion about stats and their relations to the game and XNet. I need to say that I agree with Breunor and others on that we need to have a separate stats file which should be used both for game and XNet. The modding of such file will be very easy - just change value in XML. Earlier I thought that stats should be the part of XNet file, but now I favor a separate file idea. There was a work done on XML file for XNet but not finalized yet. I do not have anything that I can show you here. So, I think we can consider this issue open. I would like very much to resolve that issue as soon as possible. Cpt. has finished his research tree XML, which is very likely to interweave with XNet. If you and Breunor can put your heads together, than maybe you can reuse parts of research tree XML and finish the XNet one too. Regarding, one big file for XNet texts or not, I personally do not have any preferences. Just remember, that we XNet definition file (the one that describes names of models, images, sounds, videos, etc. as well as text description) should uniquely identify the text to be displayed. Regards, Mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Breunor Sent: Thursday, January 22, 2004 5:53 PM To: xen...@li... Subject: [Xenocide-programming] game stats via XML followup I think most everyone would agree that the X-Net info should call from the stats file that is called by the game code, that makes the most sense if the data is either in the same format or can be converted by each. Based on what I've been reading on calling data from XML files, if all the various stats are compiled together and used for every item, even if it doesn't pertain to it, then that data can be filtered out easily enough. For example every item would have a <speed> and <damage> attribute, and it would just be 0 where it doesn't apply. Then you could call what you want from there. So all the stats would be in a single XML file like a catalog, but what about the descriptive text you'd read in the X-Net? Some of the texts are as large as the entire stat file combined, so I wonder if that would affect performance? Probably, so IMO having a second file for the descriptive text would be a wise idea. I'm not too hot on having a seperate text file for every entry however, as you could just have all the entries in 1 without hurting anything IMO. My reasoning would be that it makes it easier to mod/translate, because when you search for a particular name you'll catch all occurances at 1 time, rather than having to check every file. I'm sure you can probably search multiple files just as easily, so I guess it's a personal preference. What are other's opinion on this? If you're not opposed to a single description file, I can create a rough draft as part of an online viewer project in the works as X-Net eyecandy. Adios, Breunor --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 |
|
From: Vlad J. <vj...@au...> - 2004-01-25 03:52:31
|
Hi Cpt. and all. =20 I started to write the answer with critics, but it did not look good. So = I added this line here :-) Critics are below. Overall, I think that layout looks really well. However, I did not like = the <content> and <transfer> sections. I think they should be combined. The = item in content must have more information about it status, where content is = one of them. Let=92s say you have a gun in stores. So, the status of it is =91stored=92 or something. Then you transfer it to another base, the = item changes the base it belongs to and its status is =91transferred=92. We = might even have the number of hours till arrival. Then for some specific content entries, for example scientists, we would definitely want more information. But those are details which could be flushed out later.=20 More major issue is that whether contained items must be described = within container or base itself. For example, crafts. There is a section in the <base> which lists crafts, but then there is a reference to them from <hangar>. From programming point of view it is just difference in one = method of Base class: either retrieve list of crafts within Base object itself = or create a list of crafts from the crafts from all hangars. I would prefer that crafts would be listed inside the hangars =96 the XML would be = clearer. But that is different for stores or living quarters: it is not important what store the pistol is in or what barrack John Doe is in =96 we are = not going to display them differently or provide that kind of info for = players.=20 =20 Regards mamutas --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 =20 |
|
From: Breunor <br...@pr...> - 2004-01-22 23:42:19
|
I think most everyone would agree that the X-Net info should call from the stats file that is called by the game code, that makes the most sense if the data is either in the same format or can be converted by each. Based on what I've been reading on calling data from XML files, if all the various stats are compiled together and used for every item, even if it doesn't pertain to it, then that data can be filtered out easily enough. For example every item would have a <speed> and <damage> attribute, and it would just be 0 where it doesn't apply. Then you could call what you want from there. So all the stats would be in a single XML file like a catalog, but what about the descriptive text you'd read in the X-Net? Some of the texts are as large as the entire stat file combined, so I wonder if that would affect performance? Probably, so IMO having a second file for the descriptive text would be a wise idea. I'm not too hot on having a seperate text file for every entry however, as you could just have all the entries in 1 without hurting anything IMO. My reasoning would be that it makes it easier to mod/translate, because when you search for a particular name you'll catch all occurances at 1 time, rather than having to check every file. I'm sure you can probably search multiple files just as easily, so I guess it's a personal preference. What are other's opinion on this? If you're not opposed to a single description file, I can create a rough draft as part of an online viewer project in the works as X-Net eyecandy. Adios, Breunor -- Yahoo IM ID:lord_breunor ICQ ID:69881954 |
|
From: Jeffrey W. <je...@ca...> - 2004-01-19 06:37:10
|
I think Xnet should be consistent with the rest of the game. How that works out is still the question. I don't know if it would be better for Xnet to look to the game unit stats config for these numbers or if the game should look to Xnet for the numbers. In my opinion I think that Xnet should look at the game config, that way people looking to do a very simple mod to the game wouldn't have to go any further than the game config file. -mindstorm -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of cpt...@te... Sent: Sunday, January 18, 2004 9:15 PM To: xen...@li... Subject: RE: [Xenocide-programming] Creative Texts in XML format I have a related question....where will the game get stats for everything? For example, the top speed on an interceptor is 2100 (as stated in ufopaedia/xnet). Is that speed just made up number, or will the ufo-pursuit algorithm use it (rather than something simpler) to determine outcomes. If I wanted to mod the game so that interceptors were as fast as battleships, would the change I made (in some hypothetical config file) be reflected in the xnet entry? Or would the xnet entry itself be the config file? Or would the xnet entry be simple text, no matter what the in-game value is? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...]On Behalf Of Breunor Sent: Sunday, January 18, 2004 8:16 PM To: Xeno Progamming Sourceforge List Subject: [Xenocide-programming] Creative Texts in XML format Hey Everyone, I've read back in the archives and it seems like this item is still at large but in progress. Regarding the text descriptions we'll see in the X-Net/UFOPedia interface, is it accurate to say each entry with be a text file using XML tags (not yet defined?) and those tags will be used by the code to format the visual layout of the text? If that's an accurate assumption, are you looking at the specs for something like xml.openoffice.org layout or something else? I'm curious because we are building up quite a number of text descriptions as well as related texts that are either in txt or rtf format, and even the text itself isn't in a standard layout to date. I'd like to direct the CTD members along a narrower path so we have less follow up work later on. If the XML format for these texts has not been considered yet, I can write up a proposal based on my research in the text description area. It would appear to be a fairly limited set of tags, for things like font type and size, underline/bold, line feeds and carriage returns, that type of thing. Thanks, Breunor -- Yahoo IM ID:lord_breunor ICQ ID:69881954 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Cpt. B. <cpt...@te...> - 2004-01-19 05:14:01
|
I have a related question....where will the game get stats for everything? For example, the top speed on an interceptor is 2100 (as stated in ufopaedia/xnet). Is that speed just made up number, or will the ufo-pursuit algorithm use it (rather than something simpler) to determine outcomes. If I wanted to mod the game so that interceptors were as fast as battleships, would the change I made (in some hypothetical config file) be reflected in the xnet entry? Or would the xnet entry itself be the config file? Or would the xnet entry be simple text, no matter what the in-game value is? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...]On Behalf Of Breunor Sent: Sunday, January 18, 2004 8:16 PM To: Xeno Progamming Sourceforge List Subject: [Xenocide-programming] Creative Texts in XML format Hey Everyone, I've read back in the archives and it seems like this item is still at large but in progress. Regarding the text descriptions we'll see in the X-Net/UFOPedia interface, is it accurate to say each entry with be a text file using XML tags (not yet defined?) and those tags will be used by the code to format the visual layout of the text? If that's an accurate assumption, are you looking at the specs for something like xml.openoffice.org layout or something else? I'm curious because we are building up quite a number of text descriptions as well as related texts that are either in txt or rtf format, and even the text itself isn't in a standard layout to date. I'd like to direct the CTD members along a narrower path so we have less follow up work later on. If the XML format for these texts has not been considered yet, I can write up a proposal based on my research in the text description area. It would appear to be a fairly limited set of tags, for things like font type and size, underline/bold, line feeds and carriage returns, that type of thing. Thanks, Breunor -- Yahoo IM ID:lord_breunor ICQ ID:69881954 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Breunor <br...@pr...> - 2004-01-19 04:05:59
|
Hey Everyone, I've read back in the archives and it seems like this item is still at large but in progress. Regarding the text descriptions we'll see in the X-Net/UFOPedia interface, is it accurate to say each entry with be a text file using XML tags (not yet defined?) and those tags will be used by the code to format the visual layout of the text? If that's an accurate assumption, are you looking at the specs for something like xml.openoffice.org layout or something else? I'm curious because we are building up quite a number of text descriptions as well as related texts that are either in txt or rtf format, and even the text itself isn't in a standard layout to date. I'd like to direct the CTD members along a narrower path so we have less follow up work later on. If the XML format for these texts has not been considered yet, I can write up a proposal based on my research in the text description area. It would appear to be a fairly limited set of tags, for things like font type and size, underline/bold, line feeds and carriage returns, that type of thing. Thanks, Breunor -- Yahoo IM ID:lord_breunor ICQ ID:69881954 |
|
From: Cpt. B. <cpt...@te...> - 2004-01-16 04:40:54
|
Glad you think I'm up to it. :P Embarrassingly enough, I AM a
programmer...it's just that my C++ sucks (I learned C about 6 years ago, and
never used it since). I actually picked up a C++ book a few months ago,
figuring since I was out of work, it would be a good time to learn. Then I
got a job two days later (hadn't even cracked the cover), and I haven't had
the time since. :)
Well, here's a few samples. The first is the overall layout for the
bases element. I'm not sure if I like the <transfers/> element though...it
might be better to just have a status flag (available|out|in transit) for
most items...easier to calculate limits on living space, storage, etc.,
because items (& personnel, whatever) will be listed in with stuff that's
already there.
The next are a few samples of facilities. Basically, all facilities will
have the first three elements,(location, complete, builddays) but only
certain ones will have the last three(capacity, usedcapacity, contents).
I'm not sure whether individual "Stores" facilities should own items in
them, or if the item should know which stores it's in. The latter is
computationally easier (the whole list is one place, under the <stores/>
tag, rather than scattered through the facilities list), but it seems
counterintuitive. What do you guys think?
-The Captain
<bases>
<base name="Base 1">
<!--no idea how locations on the geoscape are recorded, so this is
placeholder.
Think of x and y as latitude and longitude. -->
<location x="0" y="0" />
<!-- Contains basic details regarding facilities at this base
location, status (under construction, etc), capacity, and so
on -->
<facilities/>
<!-- Contains basic details of all personnel associated with this
base -->
<personnel/>
<!-- Contains basic details of all crafts associated with this
base -->
<crafts/>
<!-- Contains basic details of all stored items associated with
this base -->
<stores/>
<!-- Contains basic details of all incoming transfers associated
with this base -->
<transfers/>
</base>
</bases>
<!-- Small Radar Facility -->
<facility name="SmallRadar1" type="SmallRadar"> <!-- name is a uid. Type
describes which type of facility -->
<location x="1" y="2" /> <!-- location in the baseview grid, bottom left
is 0,0. easy to add "z" value for freeform in v1+ -->
<complete>true</complete> <!-- is the facility completely built. May be
redundant to builddays -->
<builddays>0</builddays> <!--how many days left to build facility -->
</facility>
<!-- Storage Facility -->
<facility name="Stores1" type="Stores">
<location x="2" y="2"/>
<complete>true</complete>
<builddays>0</builddays>
<maxcapacity>50</maxcapacity> <!--maxmium amount of "X" the facility
contains. "X" depends on type attribute -->
<usedcapacity>36</usedcapacity> <!-- amount of "X" currently in this
facility -->
<contents/> <!-- "X" described -->
</facility>
<!-- Research Lab Facility -->
<facility name="Laboratory1" type="Laboratory">
<location x="3" y="2" />
<complete>true</complete>
<builddays>0</builddays>
<capacity>50</capacity>
<usedcapacity>10</usedcapacity>
<contents> <!-- contents of this lab. Lab can only contains <scientist>
elements. Workshops contains <engineer> elements in the same format -->
<scientist quantity="5">Laser Weapons</scientists>
<scientist quantity="5">Medikit</scientists>
</contents>
</facility>
<!-- Hanger Facility -->
<facility name="Hanger2" type="Hanger">
<location x="4" y="0" />
<complete>true</complete>
<builddays>0</builddays>
<capacity>1</capacity>
<usedcapacity>1</usedcapacity> <!-- for hangers, this is only zero if a
craft is not assigned to the hanger -->
<contents> <!-- for hangers, contents is only a reference back to the
craft. the craft itself keeps track of which hanger it belongs to -->
<craft name="Intercepter2"/>
</contents>
</facility>
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
mamutas
Sent: Thursday, January 15, 2004 11:04 AM
To: xen...@li...
Subject: Re: [Xenocide-programming] Other XML Layouts?
I agree with you. Sooner or later such work must be done. And it does not
matter whether it is done by programmer or not. The one must know the
original game very well, that is for sure. And I think that Cpt. is
qualified for that job. :)
I just wanted to stress the priorities. Unfortunately, I was not able to
come up with an urgent task myself. So, unless there is one, than working on
entities XML is as good as any other tasks.
Regards.
mamutas
P.S. I try to delete quoted emails from my replay, as non-deleted looks
very ugly from SF viewer.
|
|
From: mamutas <mam...@ho...> - 2004-01-15 19:05:46
|
I agree with you. Sooner or later such work must be done. And it does = not matter whether it is done by programmer or not. The one must know = the original game very well, that is for sure. And I think that Cpt. is = qualified for that job. :) I just wanted to stress the priorities. Unfortunately, I was not able to = come up with an urgent task myself. So, unless there is one, than = working on entities XML is as good as any other tasks. Regards. mamutas P.S. I try to delete quoted emails from my replay, as non-deleted looks = very ugly from SF viewer. |
|
From: Cpt. B. <cpt...@te...> - 2004-01-14 22:37:36
|
How many other XML layouts do we still need? I know someone (can't remember who off hand) is working on the xnet layout. I'll be happy to start on a 'Bases' layout (base locations, facilities, personnel, crafts, stores, and everything associated). -The Captain |
|
From: Mamutas P. <ma...@pr...> - 2004-01-11 19:27:26
|
Looks fine to me. Thanks, Mamutas --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 |
|
From: Cpt. B. <cpt...@te...> - 2004-01-11 18:47:07
|
Sorry it took so long to get back to this.... Here's a sample of the save game version of the techtree. I moved researchtime down into the <research> section, just to keep everything tidy. <!--Plasma Rifle --> <topic name="Plasma Rifle" researchtime="300"> <research> <completed>False</completed> <researchtime>100</researchtime> <hoursresearched>0</hoursresearched> </research> <prerequisite> <item name="Plasma Rifle" /> </prerequisite> <researchbonus /> <grants> <xnet name="Plasma Rifle" /> <item name="Plasma Rifle" /> </grants> <obsoletes> <topic name="Plasma Rifle" /> </obsoletes> </topic> -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...]On Behalf Of mamutas Sent: Monday, January 05, 2004 7:19 AM To: Federico Andres Lois; xen...@li... Subject: Re: [Xenocide-programming] Tech Tree XML layout Hi there, RK has answered the question in the same words I would use. Base should keep track about scientist assignment to project. Regards, mamutas |
|
From: Chris P. <chr...@ju...> - 2004-01-07 02:47:36
|
The link for downloading the NT4 binaries is down. So, even if it might work, I can't get it. I have strange problems with compiling w/ BCB6 also. I get a very undetailed error saying just: file.x "can't be written." There is an actual BCB6 project file available with source, so I don't see what would cause this. I can do my development using Linux and GCC, but I will have to stick with char*'s rather than use the string class. Otherwise, I'll have to wait a few months until I get (yet another) new computer that can run XP at decent speed. Regards, chrisp On Mon, 5 Jan 2004 21:03:18 -0600 "Mamutas Plaukotas" <ma...@pr...> writes: I am not sure why would you need to compile C++ version. Cant you take binaries and use them in your project? Regards Mamutas Makes sense. I just wanted to make sure before I started compiling the C++ version. That will probably take quite a long time. Regards, chrisp --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: <chr...@ju...> - 2004-01-06 16:24:56
|
I'll try the binaries and see if they work. The only binaries available for windows is for NT4 and XP. I'm running 98, so that might be a problem. It did seem to be a problem with compiling. regards, 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: Mamutas P. <ma...@pr...> - 2004-01-06 03:03:39
|
I am not sure why would you need to compile C++ version. Can=92t you = take binaries and use them in your project? Regards Mamutas =20 _____ =20 =20 Makes sense. I just wanted to make sure before I started compiling the = C++ version. That will probably take quite a long time. =20 Regards, chrisp --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 =20 |
|
From: Cpt. B. <cpt...@te...> - 2004-01-05 16:36:22
|
Sounds good....I'll send out an updated layout later today. -----Original Message----- From: xen...@li... [mailto:xen...@li...]On Behalf Of mamutas Sent: Monday, January 05, 2004 7:19 AM To: Federico Andres Lois; xen...@li... Subject: Re: [Xenocide-programming] Tech Tree XML layout Hi there, RK has answered the question in the same words I would use. Base should keep track about scientist assignment to project. Regards, mamutas |
|
From: mamutas <mam...@ho...> - 2004-01-05 15:19:51
|
Hi there, RK has answered the question in the same words I would use. Base should = keep track about scientist assignment to project. Regards, mamutas |
|
From: Cpt. B. <cpt...@te...> - 2004-01-04 23:15:37
|
Hi Mamutas,
If the number of scientists assigned will be stored elsewhere (something I
admit I hadn't considered), do we really need anything beyond just hours and
completed? I may have over-analyzed this a bit.
The Captain
-----Original Message-----
From: mamutas [mailto:mam...@ho...]
Sent: Friday, January 02, 2004 7:23 PM
To: Cpt. Boxershorts; xen...@li...
Subject: Re: [Xenocide-programming] Tech Tree XML layout
Hi Cpt.
My suggestion was just one of many options. Having a enumerator is fine too,
as long as our validator will catch invalid values there. I do not remember,
can you enforce that in DTD? I think you can do it with attributes, but not
with tag values, right? If that is true, then attribute for state looks like
a better option for me. Also, I don't think we need to have both 'In
Progress' and 'Active', as the difference in them will be the number of
scientists allocated, right? But that information is not going to be stored
in that XML, but in some other places. We should avoid duplicate storage of
the same meaning in two different places, therefore I suggest to combine
those two states in one and rely on number of scientists.
Regards,
mamutas
----- Original Message -----
From: "Cpt. Boxershorts" <cpt...@te...>
To: "Mamutas Plaukotas" <ma...@pr...>;
<xen...@li...>
Sent: Thursday, January 01, 2004 5:38 PM
Subject: RE: [Xenocide-programming] Tech Tree XML layout
> Hi Mamutas,
>
> You're right, it would be simpler computationally to keep separate
> variables. How about an actual enumerated state? I see topics as having
> four states: Unresearched, In Progress (has some hours put into, but not
> currently being researched), Active (currently being researched), and
> Complete.
>
> Would it be better to have it as attributes or elements? I'd like to
avoid
> overloading the topic node with too many attributes. What do you think of
> something like one of these this for each topic:
>
> <status> <!-- individual fields -->
> <started>False</started> <!-- has research begun on this topic? -->
> <completed>False</completed> <!-- has this topic been completely
> researched? -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> or
>
> <status> <!-- state enum -->
> <state>Unresearched</> <!-- values ("Unresearched"|"In
> Progress"|"Active"|"Complete") -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> I think we will need a <location/> tag as well...while researched
knowledge
> is global (shared among the bases), when you open a saved game, the topics
> that were actively being researched should still be active at the same lab
> as when you saved. It could just be however the facility is referenced
for
> the baseview.
>
> -The Captain
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...]On Behalf Of
> Mamutas Plaukotas
> Sent: Thursday, January 01, 2004 10:12 AM
> To: 'Cpt. Boxershorts'; 'Vlad Judys';
> xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
> Hello Captain,
>
> See my answers below.
>
> Regards,
> Mamutas
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
Cpt.
> Boxershorts
> Sent: Monday, December 29, 2003 12:28 AM
> To: Vlad Judys; xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
> Hi Mamutas,
>
> You're right, this layout is primarily designed for program
> initialization,
> rather than active games. I agree, I think it could work as a save game
> too (and it's better to have just the one format to parse). Is the
research
> tree going to be loaded into some form of database table, or just kept in
> xml node format?
>
> <mamutas>I think that it would be fine to keep loaded XML in the DOM of
the
> parser. The object which will load and provide interfaces to the DOM (fro
> example XNet Data Loader object) will know where and how to access the
> required data. And the XML will be parsed and validated once during the
> loading and then it will be kept in the memory. I don't see any advantages
> to convert XML to some internal representation, unless there will be
> significant performance issues.</mamutas>
>
> For the saved game version, rather than several fields, why just a single
> numeric 'amount completed' field? As I see it, knowing whether a topic
has
> been researched is the most important (must be quick/easy to find out)
> factor. 'amount completed' has values ranging from zero to the topic's
> researchtime property. This way, we keep the exact number of hours
> researched, and finding out if the topic is complete is a simple
calculation
> ('researchhours' = 'amountcompleted').
>
> Possible values for 'amountcompleted' work out as follows:
>
> 0 = Not started.
> 1 to (topic.researchhours - 1) = Started, but incomplete.
> topic.researchhours (max value) = complete
>
> <mamutas>Yes, it is possible to use just one variable, but as you
mentioned
> than you need to keep in mind that '1' for 'just started topics'. It will
> save us some memory, but will add a code complexity. I would rather have
> explicit flags in this case, just to keep code clear.</mamutas>
>
> Just to simplify it, maybe 'completed' status should be ('researchhours'
<=
> 'amountcompleted'), rather than equals. That would save alot of headaches
> in calculating research hours.
>
> <mamutas>This is valid comment. It is always better not to use exact
> equality with real numbers. I learned that my first year in programming.
:)
> </mamutas>
>
> Would it need a variable for where (which lab/base it's being researched
at)
> as well? It might need to wait until the savegame layout for bases is
done,
> although we could always just put in a stub.
>
> <mamutas>Not sure about that yet, but something like that should be
> necessary as research tree is shared between all bases. In the same motion
> we can think about storing number of scientist allocated and other things,
> but I would leave it to later times to decide.</mamutas>
>
>
> To answoer your other questions, what I sent out is not really for
xenocide
> per se...it's just a sample of the layout applied to the x-com tree so
that
> everyone has a common frame of reference. The xenocide tree already has a
> couple of differences in it (a 'Plasma Technology' node, for one). Once
the
> format is settled, I'll write a xenocide version of the simple tree, as
well
> as a few variations I'd like to suggest. The main reason I undertook this
> was to show off the variants discussed in the 'Technology' workshop on a
> webpage (it seemed easier to use the official layout than make one of my
> own, and then I discovered it was incomplete).
>
> I hate to say this, but I managed to lose the version I sent out :P Could
> you please send me a copy back? Thanks!
>
> <mamutas>:) The copy is attached.. </mamutas>
>
> -The Captain
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
|
|
From: Jeffrey W. <je...@ca...> - 2004-01-04 21:56:08
|
I'm not very experienced in game programming, so this might be a dumb question but I'll ask it anyway. Why would we need a scripting language? What purpose would it serve? -mindstorm -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of fl...@ma... Sent: Sunday, January 04, 2004 10:33 AM To: xen...@li... Subject: [Xenocide-programming] Scripting Language for XenoEngine Hi all, I had been looking for an Scripting Language for XenoEngine and eventually Xenocide. I have found that most of the projects use LUA or Python as script languages. Most of the game projects use Lua and do the C++ integration with Luabind an Open Source project. There are several commercial games that had used Lua before like Grim Fandango and Escape from the Monkey Island from Lucasarts, or Neverwinter Nights and MDK2 from Bioware among others. From what I had heard about it, it is very extensible and a pretty interesting option. And it is quite easy to integrate into the engine code. I would like to know if anyone here has knowledge on any of those languages and its interations with C++, so we can know for sure. The same if you have knowledge on using python in games. Some pointers to LUA: http://www.lua.org http://www.gamedev.net/reference/programming/features/lua/page6.asp A Python comparizon, warning may be biased. http://lua-users.org/wiki/LuaVersusPython LUA Mailing List (Lots of mails, so it sounds like that it is active... not a Python community, that is for sure) http://lua-users.org/lists/lua-l/ More LUA Referencies, like tutorial kind of reference http://kakariko.ne.client2.attbi.com/lua/Lua_Workshop_files/frame.html Well that is mostly what I could found. Any though? Greetings Red Knight ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Federico A. L. <fl...@ma...> - 2004-01-04 18:30:01
|
Hi all, I had been looking for an Scripting Language for XenoEngine and eventually Xenocide. I have found that most of the projects use LUA or Python as script languages. Most of the game projects use Lua and do the C++ integration with Luabind an Open Source project. There are several commercial games that had used Lua before like Grim Fandango and Escape from the Monkey Island from Lucasarts, or Neverwinter Nights and MDK2 from Bioware among others. From what I had heard about it, it is very extensible and a pretty interesting option. And it is quite easy to integrate into the engine code. I would like to know if anyone here has knowledge on any of those languages and its interations with C++, so we can know for sure. The same if you have knowledge on using python in games. Some pointers to LUA: http://www.lua.org http://www.gamedev.net/reference/programming/features/lua/page6.asp A Python comparizon, warning may be biased. http://lua-users.org/wiki/LuaVersusPython LUA Mailing List (Lots of mails, so it sounds like that it is active... not a Python community, that is for sure) http://lua-users.org/lists/lua-l/ More LUA Referencies, like tutorial kind of reference http://kakariko.ne.client2.attbi.com/lua/Lua_Workshop_files/frame.html Well that is mostly what I could found. Any though? Greetings Red Knight |
|
From: Chris P. <chr...@ju...> - 2004-01-04 16:39:32
|
Makes sense. I just wanted to make sure before I started compiling the C++ version. That will probably take quite a long time. Regards, chrisp On Sat, 3 Jan 2004 20:19:10 -0600 "Mamutas Plaukotas" <ma...@pr...> writes: Yes, of course. Why would we use Java version? It requires a JVM, it will be much slower and we will need to deal with C++ to Java bridge (to say the truth, I have no experience in that one. I dont think I have heard anything about such a thing before). So, C++ version it is. Regards, Mamutas --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: Mamutas P. <ma...@pr...> - 2004-01-04 02:41:26
|
Everything looks fine to me, except for that complex way of ContainerIterators creation and destruction process. Could you provide more explanation behind those invalid field and invalidate() method? Regards, mamutas --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: Mamutas P. <ma...@pr...> - 2004-01-04 02:19:33
|
Yes, of course. Why would we use Java version? It requires a JVM, it = will be much slower and we will need to deal with C++ to Java bridge (to say the truth, I have no experience in that one. I don=92t think I have heard = anything about such a thing before). So, C++ version it is. Regards, Mamutas --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 =20 |
|
From: Federico A. L. <fl...@ma...> - 2004-01-03 21:36:57
|
I2luY2x1ZGUgImljYXJyaWFibGUuaCINCg0KbmFtZXNwYWNlIFhlbm9jaWRlDQp7DQogICAgbmFt ZXNwYWNlIEFiaWxpdHkNCiAgICB7DQoNCiAgICB9DQp9DQoNCg== |
58 messages has been excluded from this view by a project administrator.
