117 replies to this topic

[dteviot]

I thought I’d take a leaf out of Azrael’s book and start a thread as a blog. That way people can know what I’m up to, and I’ve got a record of my ideas, ToDo’s and progress.
Also, kind of answer’s m4st3rs question about what can he work on.

OK.
What I’m doing at moment, and where I’m likely to be going.
Currently working on “research projects” for the technology tree, specifically, parsing the file research.xml.
Have built a stub “project” class, and now working on derived “ProjectResearch” class. This has 4 major bits over a basic project , “prerequisites”, “grants”, “cost”, “research bonus”
Idea is wrap each of these parts in their own class. And ProjectResearch will contain an instance of each, which it invokes to do necessary work.

e.g.

class ProjectResearch
{
    virtual canStart(Base& base) { prerequisites.canStart(base); };
    virtual giveUserTech() { grants.giveUserTech(); };
    virtual start(Base& base) { startCosts.debitUser(base); };

private:
    Prerequisites   prerequisites;
    Grants       grants;
    StartCosts   startCosts;
        Etc.
}

At moment, I’ve got prerequisites done and checked in.
Am currently working on grants. Have tested that parsing from XML works, still need to test that giveUserTech() works.

Will next work on cost then ResearchBonus classes.

Notes to self:
1. Cost is probably common to research and workshop projects, so move to Project class. Also, Azrael has suggested changes/clarification to ResearchBonus, so should probably work on that first.


Once have this bit done, need to think about relationship between workers, bases, facilities and projects.
Ideas:
1. Workers can only belong to one project at a time, to probably best to just keep a pointer in worker object to project. (No list of workers IN project.) Means if we delete a worker, is automatically deleted from project. Of course if project is deleted, we then need to walk list of workers, and remove the project from them.
2. Currently Research Projects have field specifying facility needed to work on. So easy way to distinguish between Scientist and Engineer is field giving type of facility they use.
3. Relations between objects
a. Base OWNS people
b. Base OWNS facilities
c. Scientists WORK IN facilities
d. Scientists ASSIGNED TO projects
4. What happens when we transfer worker, who’s assigned to a project, to a different base? If base is also working on the project? If base isn’t working on project?

To Do:
Inventory Troop & Craft. Currently store items in RackDistinct. However, need to allow for physical location of item (definitely for trooper, very probably for craft. E.g. Right Wing Pod has Cannon, Left wing pod has missile – Really only needed if we want to show this to user.) Aside, do we need grid for Trooper, we could just set a “backpack size” and check that all items fit?

Possible solution: have “Position” class to record information. Is stored in Rack with item. E.g. Tvector>. Have different derived Position classes, for Troop and Craft.


Have created a demo dialog for Buy/Sell of items. Reason being if Art department can see it, will be motivation to design the final dialog, get artwork. Then can implement using existing skeleton. Will need to wait until next release for them to see it though.

Items:
ItemPrototypeFactory:: findPrototype() returns pointer. Find out why returning an ItemPtr makes it crash.

ItemCraft::getItemName() and ItemAlien::getItemName() need to translate the ItemType string for display. (ItemAlien also needs to translate Rank.)

Check that English.xml has list of items, research projects, facilities, ranks etc. from default.xsd. (Maybe someone in CTD could do it?)

Should I add Inventory::insert(ItemPtr&) that sets ItemPtr to null? Would have closer semantics than existing Inventory::insert(Item&)

Xnet, even in DagonSquirel still occasionally doesn’t close when click on top right button.

Inventory::find() need a const version of this for read only stuff.
Files tradeable[.cpp|.h] TradableFactory, TradableManager. I think these were going to be items. Probably should remove from project.

Replace TechnologyManager with ResearchManager. Not much salvage, but I like Beetle’s solution to the starting tech issue. Just find the starting tech project by it’s name, and grant everything.

Find out why my PM no longer permits attachments. Who to ask?

Python. Don’t know it. Have bought Python Cookbook. Need to find time to read it.

Expand on idea Xenocide: Realpolitik. Probably no fun to play, but document anyway:
Wealthy Govts don’t support XCORP.
They’ll shoot down your craft if discovered over flying their territory (or at least try to).
However, they will also shoot down UFOs over their territory, and will attack any UFO landing sites as well.
They will ALSO try to attack and capture any UFOs over other territory as well. (So will be race/fight for UFOs.)
If they find out you’ve captured stuff (say by your selling it), they turn up at your base with army and demand it be handed over to them. Refuse, and they invade you base. They also kidnap and torture your staff and their families.



Other things:
Craft & Items. If we track craft as items in inventory, Need to be careful if transfer craft to another base because of “people” assigned to craft. Crew must be removed from craft when move it, because crew and craft must belong to same base. Also, what about craft properties in craft.xml? Should they be moved to item.xml? probably not, because we want craft.xml to hold alien craft as well. Solution is probably pimpl, ItemCraft has (shared?)pointer to actual Craft.

RK has suggested completing Planetscape task list. I assume he means Planetscape Planning.xls. Not really sure what the “Null” “Base” “Nominal” “Optimal” columns mean. Also, should probably update I think 16 is now done, possibly 36 as well. And some of 19 & 17. I’m currently working on 20, then will be doing 18.

[red knight]

Mhhhh I am going to say that somebody didnt make the homework

I concur, it was very difficult to dig the required information and was hidden for recruits. Now I have added a link in the Wiki on how to read the Planning Sheet.

http://docs.projectx...e:Docs#Planning

Please some admin move the Planning threads from the Lounge to the Library; and this thread to the News Room .

Greetings
Red Knight

Edited by red knight, 18 January 2006 - 11:04 PM.

[dteviot]

Summary:
1. Got the “Grant” part of Research Project working.
2. Updated research project unit tests that were broken by Azreal’s latest update to research.xml
3. Updated research.xsd so that cost and bonus elements can be added to research projects. Revised research.xsd and research.xml checked into subversion.
4. Next step will be to replace TechnologyManager with ResearchManager. (I plan to do that tomorrow.)
5. Then I need to start thinking about how to represent relationship between scientists, research projects, bases & facilities in code.
6. Also, function to calculate progress. (Sort of been done already.)

More detailed waffle:

Looking at research projects. Still need to do cost and research bonus elements.
Some thoughts.

Cost element looks like this:

<cost money= 1000>
    <item  type=”ITEM_Xenium-122” quantity=10/>
</cost>

and the cost element can be used for both research projects and construction projects.
It could even be used for facilities, if we wanted them to need more than just money. But that’s really a post v1.0 feature.


Research Bonus
Again, it’s possible workshop projects could have a bonus. (After all, if we have some alien engineers, might be possible to build alien stuff faster.)

<bonus>
    <itemref name="ITEM_PLASMA_RIFLE" gain=10 /> 
    <combatantref name="ITEM_SATYRIAN" rank="RANK_ENGINEER" gain=5/>
<bonus>

e.g. for a plasma pistol,
If we know the laser pistol, we get a 10% bonus
If we have a satyrian engineer, we get a 5% bonus.
If we have both, then we get a 15% bonus.
Bonus means that when we calculate the amount of research done in a period of time, we increase the amount by the bonus. This means that if we discover or acquire something part way through a project, bouns can be applied to the remainder of the project.

Problem is, combatref doesn’t have concept of “this rank, don’t care about species.” Possible I suppose that we could build up a logical expression. E.g.

<bonus>
  <allOf>
    <itemref name="ITEM_PLASMA_RIFLE" gain=10 /> 
    <OneOf>
      <combatantref name="ITEM_SATYRIAN" rank="RANK_ENGINEER" gain=5/>
      <combatantref name="ITEM_GREY" rank="RANK_ENGINEER" gain=5/>
    <OneOf>
  </allOf>
<bonus>

But that’s getting ridiculous. Could just say we’re not going to support combatantref as bonus type. But that’s not a solution. X-COM does it so we have to.

Possible solution: expand combatantref to support rank only? E.g.

problem, it now complicates parsing/evaluating/validate correctness.

could check for technology. E.g.

Except that having interrogated an alien is not same thing as having one on hand.

Possibility: New reference type rankref


Works, but there’s a new problem, if we have a multi-base project, and some bases satisfy the “alien” bonus requirement, and some don’t, calculating the bonus needs to be done per base. It’s not THAT big a deal. Just means when calculate scientist contribution for each base, need to calculate bonus for each base, then multiply together.
e.g.
totaResearch = sum of {scientistReasearch(base) * bonus(base)}

OK, there is now an ugliness as the “ref” types now appear in 3 different places in research.xml, where they have different meanings. E.g. for itemref

1. In , check if we have an item of this type in the base.
2. In , where check if we can build/use item of this type, and also have a bonus quantity we need to deal with.
3. In , where it indicates we can build items of this type, and soldiers can use item.
Comment, it’s ugly, but I see no clean solution. If I made different class families I wind up with replicated XML parsing code.

Actually, based on fact that there are only 2 topics in tree that HAVE bonuses (Plasma Rifle and Heavy Plasma rifle) I think we can ignore them completely for time being. Update research.xsd so bonuses can be done. If Azrael (or someone) then goes and adds the bonuses to research.xml I will put in code to support. Just not at THIS point in time. Focus on getting rest of research system up: GUI that allows user to create/manage projects. (request ART Dept for assist?) Can add code for bonuses and startup costs later.
(Will need the costs for Production anyway, so once that’s done can add to Research.)

[dteviot]

Blog Update:
1. Replaced TechnologyManager with ResearchManager.
2. Removed tradeable, tradeablefactory tradeablemanager.
3. Submitted “feature list” for “Manufacturing System” in Planetscape Planning.xls

Side notes
New ResearchManager duplicates code for parsing XXXref elements from research.xml. I need to fix this.

When initially replaced TechnologyManager, got error:
..\..\..\xenocide\src\boost\statechart\detail\constructor.hpp(92) : fatal error C1204: compiler limit : internal structure overflow
when compiling uimanagerstates.cpp
Solved by removing

#include <core/gamestate/project/researchmanager.h>

from in player.h

Noticed that lot of .cpp files have #includes in non-ideal order. Need to start with most general includes, then work way down.
e.g. In xnetdocumnet.cpp:

#include "corerequisites.h"

// XNetLoader
#include "xnetdocument.h"
#include "xnetentry.h"

// Xerces 
#include <xercesc/dom/DOM.hpp>

// TechnologeManager
#include "../gamestate/player.h"

#include "common/settings/settings.h"

this is better:

#include "corerequisites.h"

// Xerces 
#include <xercesc/dom/DOM.hpp>

// ResearchManager
#include "../gamestate/player.h"
#include "common/settings/settings.h"
#include <core/gamestate/project/researchmanager.h>

// XNetLoader
#include "xnetentry.h"
#include "xnetdocument.h"

[dteviot]

Looks like reist broke the launcher (for Windows version)
I've checked a fix into subversion head, so hopefully no-one (except those who read this) will ever know.

[reist]

Programming while being dead tired - what was I thinking

[dteviot]

Looks like reist broke the launcher (for Windows version)
I've checked a fix into subversion head, so hopefully no-one (except those who read this) will ever know.

<{POST_SNAPBACK}>

In fairness to Reist, I've been breaking the Linux build.
Bad, bad me.

Edited by dteviot, 22 January 2006 - 01:05 PM.

[dteviot]

ToDo: A while ago Beetle suggested that the Facility Factory should use the element type (rather the facility ID) to choose the Facility class when building up the template prototypes from facilities.xml. Didn't seem a lot of point, as nearly every facility was a unique class.

However, for items, this is not the case, and it would probably pay to make this change to ItemPrototypeFactory.

[dteviot]

Spent some time this week collecting build time statistics, in effort to pinpoint where pre-compiled headers might most profitably be used.

Submitted proposed design for research & manufacturing projects. Waiting for feedback before starting coding.

Windows appears to have rotted on my PC. Bluescreens when I try to shutdown. Probably time for new dev image.

[dteviot]

OK, I’ve checked in the new research project dialog. (You can see it by clicking on the research button on the planet view.) It’s bare bones, to show how to talk to the project and worker classes. Hopefully the once the art department see it they can start figuring out what we really want it to look like.

The way it works.
Top left drop down picks the base you want to look at.
Top right list box will give a list of all projects that can be started at that base, but have not been started. (Click on the “Start Project” button, bottom left, to start a project.)
Middle list box shows the projects that have been started. If you click on an active project then the two bottom list boxes are filled in. Bottom left list is workers who can work on this project, and are idle at the moment. Bottom right list is the workers currently working on the project. You can add workers to a project by selecting them in the left box, and clicking on the “add worker” button (Bottom middle). You remove workers from a project by selecting them in right box, and click “remove worker” button (Bottom right.)
The “Update Progress” button (top right) adds the equivalent of 10 calendar days (i.e. 10 x number of workers) days to all active projects.
And the (unit test” button (top left) runs the unit tests.

Still to figure out:
1. Hook into “clock”?
2. How to notify user that a project has finished?
3. Research manager, needs to handle “cascade” projects, where completing one or more projects automatically completes another.
4. Update unit tests to exercise assigning/removing people from projects & starting and finishing projects.
5. Get rid of this harmless, but annoying warning: \Xenocide\xenocide\src\core\gamestate\humanbase.cpp(444) : warning C4355: 'this' : used in base member initializer list

6. Probably want to convert Transactions dialog into modal dialog now, remove the FSM stuff it currently uses.
EDIT. 2006-04-05: Believe Garo/Reist/Guyver has already done this. Thanks.

7. Update the Research story on the Wiki. reflect what has been implemented.

Edited by dteviot, 04 April 2006 - 02:43 PM.

[dteviot]

OK, it's been while since I posted. Mostly because I took 3 weeks off (20 hours/week on xenocide was killing me.) Then my PC died. So that was another 3 weeks.

Anyway.
Tasks to do:
1. Consolidate the requirements from the Planetscape planning thread. http://www.xcomufo.c...topic=242024914 and post to Wiki
http://docs.projectx...tscape_Features

2. Items.
a. item.xsd needs to be updated to add HWP weapon type. And the entries for the HWPs in item.xml need to updated.
b. need new c++ item dervied class for HWPs
c. update ItemClassFactory, so it builds prototype items based on class in item.xml, not item name. (This probably requires bringing the class trees in item.xsd and C++ into alignment.) See note below before proceeding.

Thought:
At moment, there are two different clip classes in C++ code. (One for troop items, one for craft.) - With HWPs there could be 3.
There's also two classes of craft weapon pod, and two class of troop weapon, one that takes a clip, and one that doesn't. With HWPs, this would add another two.
So: Possible simplification.
1. Go to single clip type. Only difference between clips is what uses them, and if troops can carry them. Who cares if player gets a trooper to carry cannon ammo around? Good exercise. And weapons know the ammo they use.
2. Create an AmmoInfo or similar class, that encapsulates the information about a weapon using ammo or not. Then just need single class each for troop weapon, craft weapon, or HWP class which contains an AmmoInfo class.

[dteviot]

Task:

1. Fix up name difference between facility.xsd and facilies.xml. (Defer until after trunk & stackless merge, to minimise amount of merge work.)
2. Is Gravity Shield defensive or weapon?

[dteviot]

I’ve added code that reads the construction costs of items out of items.xml, and displays them in xnet. This is a step along the way to being able to create “item construction projects.”
Currently, I’m ignoring the facility type and space information in items.xml because 1. there’s only one construction facility type, and 2. I figure workshop space used is purely a function of number of engineers on the project.

[dteviot]

Xenocide IM log

(08:07:03) dteviot: OK, time for me to start a flame war. Joking. However, I have a couple of thoughts that are probably contentious.
(08:07:42) dteviot: First, when project started out, it was C++, then LUA was added with intent of doing AI. Then LUA was replaced with Python.
(08:08:18) dteviot: Then Python was expanded to do GUI logic as well as AI.
(08:08:28) dteviot: Then Python replaced with stackless python.
(08:08:48) dteviot: So: thought is, why not do ALL game logic in stackless.
(08:09:20) dteviot: C++ is just relegated to interface layer, to provide what python needs to talk to Ogre & CEGUI.
(08:09:39) dteviot: Sorry, all game logic and game state objects.
(08:09:50) dteviot: in python.
(08:09:58) Garo_: I suggested that also once
(08:10:06) dteviot: Performance, should not be an issue.
(08:10:22) Garo_: guyver thinks that it could be an issue and I didn't disagree him
(08:10:35) Garo_: but after I thought it, EVE does practically everything with python
(08:10:48) Garo_: only 3D engine, lowlevel asyncronous IO etc are done with c++
(08:10:50) dteviot: There's not a lot going on in the geoscape. Some bases, maybe a dozen craft moving, and update of various progress.
(08:11:54) dteviot: Besides, if Python IS faster to write than C++, we should still write in python, then migrate the slow parts to C++ if we find the need.
(08:12:20) Garo_: I whish guyver would be here now. we can't make such major dedicions without him
(08:12:26) Garo_: but I agree with you on that
(08:12:27) dteviot: Trying to develop in a mixture of C++ and Python is just making life more complicated than we need.
(08:12:38) Garo_: that's true
(08:12:53) dteviot: Performance optimisation rule number one. Don't optimise.
(08:13:04) Garo_:
(08:13:16) dteviot: Build the code as simply and clearly as possible
(08:13:34) dteviot: Then use the time you save to optimize at the end, when you know where it's needed.

[dteviot]

I thought I'd document the steps I go through to build Stackless (from clean) on VS 2005.

Get latest files from Subversion (SVN): http://svn.projectxe...ches/stackless/

Get pre-built dependancies from:
http://projectxenoci...ming/stackless/

Build Boost, as documented:
http://docs.projectx...StacklessBranch

1. Run devpack-binaries-vs80.exe.
2. Copy contents of resulting ...\dependencies\lib\ to \dependencies\lib
3. Copy contents of resulting ...\dependencies\lib\vs80\ to \dependencies\lib\vs80
(Where is the root directory you got SVN out to.)
(Note to maintainer, why are the files in two different places?)

4. Copy contents of resulting ...\xenocidegame\bin\*.* and \xenocidegame\bin_d\*.* to matching \xenocidegame\xxx

5. Copy zlib1.dll to \xenocidegame\bin and \xenocidegame\bin_d
(Note to maintainer, should really replace the zlib1.dll in devpack-binaries-vs80.exe, with the new one.)


6. Run devpack-headers-vs80.exe.
7. copy contents of resulting ...\dependencies\include to \dependencies\include

8. Run devpack-log4cxx.exe.
9. Copy resulting ...\dependencies\include\log4cxx directory to \dependencies\include
10. Copy contents (2 files) of resulting ...\dependencies\lib\vs80 to \dependencies\lib\vs80
11. Copy the log4cxx.dll files in ...\xenocidegame\bin_d and ...\xenocidegame\bin to matching \xenocidegame\bin??? directories

(Note to maintainer, can get rid of:
dependencies\lib\vs71 from package
xenocidegame\bin_d
xenocidegame\bin)

12. Unzip freetype211.zip.
13. Copy freetype221.lib and freetype221_D.lib to \dependencies\lib\vs80
14. Copy freetype directory and ft2build.h to \dependencies\include
(This will replace the freetype directory that is already there. - Which came from devpack-headers-vs80.exe
Something else for maintainer to fix.)

15. Unzip pcre-6.6.zip
16. Copy pcre.h to \dependencies\include
17. Copy pcre.lib to \dependencies\lib\vs80

18.Unzip physicsfs-pack.zip
19. Copy bin\physfs_d.dll to \xenocidegame\bin_d
20. Copy bin\physfs.dll to \xenocidegame\bin
21. Copy include\physfs.h to \dependencies\include
22. Copy files in lib to \dependencies\lib\vs80

As I haven't added the boost library to my default include and lib paths,
23. copy boost header directory to \dependencies\include
24. Copy the files boost_filesystem-vc80-mt-gd-1_33_1.lib and boost_stackless_d.lib to \dependencies\lib\vs80
25. Copy boost_filesystem-vc80-mt-gd-1_33_1.dll and boost_stackless_d.dll \xenocidegame\bin_d

(Note, I only build Debug versions of xenocide, if you want to build release versions, you will need to copy the matching
release build boost files.)

26. Open \projects\vs80\dependencies.sln and build the "_buld_all_deps" project
27. Open \projects\vs80\xenocide.sln and build the "_buld_all" and "_test_all" projects

To run in debugger:
1. Set Configuration Properties->Debugging->Working Directory to \xenocidegame\bin_d
2. Set Configuration Properties->Debugging->Command to Xeno.stackless\xenocidegame\bin_d\launcher.exe

Final notes (for maintenance)
1. physicsfs-pack.zip includes physfs, which is also in SVN. (Looks like one in physicsfs-pack.zip is newer. Should probably update SVN, and remove physicsfs-pack.zip)
2. Should remove the following directories from SVN:
\xenocidegame\bin.vs80
\xenocidegame\bin_d.vs80
\xenocidegame\tests.vs80
\dependencies\lib\vs71
3. Could we move the dependancy packages into SVN? (Esp. the headers)

[dteviot]

(23:07:51) guyver6: _dteviot: I've cleaned them up yesterday, check out http://projectxenoci...ng/dependencies
(23:08:02) guyver6: there's only one package of dependencies
(23:08:20) guyver6: and additionally a minimal distribution of DXSDK
(23:08:45) Garo_: _dteviot: nice step-by-step tutorial
(23:09:00) Garo_: hope that guyver6 didn't make all that obsoeltte in just one night :/
(23:09:23) ***guyver6 is known to do that nasty things ;P
(23:09:42) guyver6: but most of it is the dependencies troubles
(23:09:45) _dteviot: No matter. I'll get the latest version of the dependencies tomorrow and update the instructions. No problem.
(23:10:01) guyver6: so I thought I'll clean that up a bit

[dteviot]

OK, tried building using Guyver's new dependanies package.
http://projectxenoci...ng/dependencies
Steps are:

1. unpack devpack-vs80
2. Copy resulting contents of ...\dependencies\include to \dependencies\include
3. Copy resulting contents of ...\dependencies\lib\vs80 to \dependencies\lib\vs80
4. Copy resulting contents of ...\xenocidegame\bin to \xenocidegame\bin
5. Copy resulting contents of ...\xenocidegame\bin_d to \xenocidegame\bin_d
6. Copy resulting contents of ...\xenocidegame\_both to \xenocidegame\bin and ...\xenocidegame\_both to \xenocidegame\bin_d


7. Copy boost_filesystem-vc80-mt-gd-1_33_1.lib to \dependencies\lib\vs80

Problems with build:

------ Build started: Project: physfs, Configuration: Release Multithreaded DLL Win32 ------
Compiling...
zip.c
.\archivers\zip.c(24) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory
Build Time 0:00

------ Build started: Project: base, Configuration: Release Win32 ------
Compiling...
physfs_wrapper.cpp
..\..\..\xenocide\src\base\physfs_wrapper.cpp(176) : fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "base_pch.h"' to your source?
Build Time 0:00

Build log was saved at "file://n:\POC\Xeno.stackless\projects\vs80\launcher\output\Debug\obj\BuildLog.htm"
launcher - 0 error(s), 0 warning(s)

------ Build started: Project: game_test, Configuration: Release Win32 ------
Compiling...
xenocidegame_test.cpp
..\..\..\xenocide\src\game\tests\xenocidegame_test.cpp(30) : fatal error C1083: Cannot open include file: 'gameapplication.h': No such file or directory
Build Time 0:01
Build log was saved at "file://n:\POC\Xeno.stackless\projects\vs80\game\test\Release\obj\BuildLog.htm"
game_test - 1 error(s), 0 warning(s)

------ Build started: Project: game_test, Configuration: Debug Win32 ------
Compiling...
xenocidegame_test.cpp
..\..\..\xenocide\src\game\tests\xenocidegame_test.cpp(30) : fatal error C1083: Cannot open include file: 'gameapplication.h': No such file or directory
Build Time 0:01

[dteviot]

OK, as part of connecting up phsyfs to Xerces XML parser I've figured out the following:

1. Xenocide uses physfs (also known as Physicsfs) as a virtual filesystem.
2. phsyfs is a C library, so it's been wrapped in the C++ class in phsyfs_wrapper.cpp
3. phsyfs needs to be initialised with a set of real directories, which it uses as its root.
4. The class PathHelper encapsulates the directories that Xenocide uses.
5. The classes physfs_source and physfs_sink (in physfs_stream.h) will instanciate a phsyfs_wrapper with a PathHelper.

So:
1. To get files, easiest way is via the physfs_source and physfs_sink classes.
2. The path of all files should be done using PathHelper.

Hooking up XML parser:
Looks like what I need to do is:
1. Create a function fileToInputStream() that takes a path, then uses physfs_source to load the file into a MemBufferInputSource.
2. Wrap this function in a XMLEntitySolver
3. In DomReader ctor, set this as the XMLEntitySolver.
4. In DomReader::parse(), call fileToInputStream() to get input stream for Xerces parse() call.
5. Add various other bits from old XMLManager class.

Additional notes:
(10:03:16) guyver6: dteviot: ok, I've read your understandings, here's some bits of mine about physfs and why there's physfs_sink and _source and yet another physfs_wrapper
(10:05:19) guyver6: because boost.iostreams uses headers (templates and stuff), all calls to physfs had to be done within headers, next that would require everything that uses physfs_sink and _source to link against physfs
(10:05:38) guyver6: that's why I asked reist to create a wrapper, so only Base has to link to physfs
(10:06:57) guyver6: PathHelper class is there as a helper to determine a paths, but is intended to use only by launcher and IModule implementation to setup physfs
(10:07:26) guyver6: after physfs is set up, loading files with physfs_source will get the files directly from data directory
(10:08:28) guyver6: so you can do physfs_source("schema/items.xml"); and it should be resolved correctly by physfs to ../data/schema/items.xml
(10:09:36) guyver6: PathHelper is also usable to create/delete files/directories
(10:09:47) guyver6: and it does so by physfs
(10:10:03) guyver6: so all filesystem traffic is routed by physfs and that's how it should work
(10:10:52) guyver6: so you don't have to determine paths using PathHelper, only use paths relative to data directory

Edited by dteviot, 10 July 2006 - 04:34 PM.

[dteviot]

Well, I’ve been trying to get a Load/Save dialog working. (So you can take this as a set of instructions on how to create a dialog in Xenocode.)

Step 1, create a layout, and save to xenocidegame\data\ui\layouts.
Here’s a simple dialog (savegamedialog.layout) that just has a cancel button

<?xml version="1.0" ?>
<GUILayout>
	<Window Type="XenoLook/FrameWindow" Name="SaveGameDialog">
		<Property Name="UnifiedPosition" Value="{{0.05,0},{0.15,0}}" />
		<Property Name="UnifiedSize" Value="{{0.65,0},{0.70,0}}" />
		<Property Name="Text" Value="STR_BUY/SELL_(UNDER_CONTRUCTION)" />
		<Property Name="SizingEnabled" Value="False"/>
		<Property Name="RollUpEnabled" Value="False"/>
		<Property Name="AlwaysOnTop" Value="True"/>
		
	<Window Type="XenoLook/Button/Right" Name="SaveGameDialog/Cancel">
	  <Property Name="UnifiedPosition" Value="{{0.60,0},{0.92,0}}" />
	  <Property Name="UnifiedSize" Value="{{0.25,0},{0.07,0}}" />
	  <Property Name="Text" Value="STR_CANCEL" />
	</Window>

  </Window>
</GUILayout>

Step 2. create a python script to hold the dialog’s logic.
Put the script in xenocidegame\data\scripts\graphics\dialogs
This is pretty much a minimal script (savegamedialog.py) for the above dialog

import cegui
import stackless
from enum import *

from graphics.modaldialog import ModalDialog
from graphics import util,UISystem

savegamedlg_counter = 0

def doSaveGameDialog(ignore):
	import snake.pyos
	snake.pyos.spawn(SaveGameDialog, "saveGameDialog_tasklet")
	
def SaveGameDialog():

	''' The dialog that allows players to save and load the game
	'''
	global savegamedlg_counter

	class Handler:
		def __init__(self, channel):
			self.channel = channel

		# at moment, dialog is a stub and only close does anything
		def handleClose(self, args):
			self.channel.send(0)
		
	savegamedlg_counter += 1
	name = "savegamedlg" + str(savegamedlg_counter)

	dialog =  cegui.WindowManager.getSingleton().loadWindowLayout("layouts/savegamedialog.layout", name)

	# here's where we will set the dialog's title and button to Load or Save
	msgbox = ModalDialog(name, dialog)

	ch = stackless.channel()
	handler = Handler(ch)

	dialog.subscribeEvent(
		str(cegui.Framewindow.EventCloseClicked), handler.handleClose)
	dialog.getChild(name + "SaveGameDialog/Cancel").subscribeEvent(
				   str(cegui.PushButton.EventClicked), handler.handleClose)
	
	UISystem.resolveStrings(dialog.Name)
	msgbox.show()
	response = ch.receive()
	msgbox.hide()
	return response

Step 3.
The “Load” button is currently in layout file optionsdialog.layout, and is defined as:

<Window Type="XenoLook/Button/Right" Name="OptionsDialog/Load">
			<Property Name="UnifiedPosition" Value="{{0.08,0},{0.14,0}}" />
			<Property Name="UnifiedSize" Value="{{0.85,0},{0.08,0}}" />
			<Property Name="Text" Value="STR_LOAD_GAME" />
			<Event Name="Clicked" Function="graphics.dialogs.options.handle_load" />

So in theory I should just need to replace "graphics.dialogs.options.handle_load" with "graphics.dialogs.savegamedialog.doSaveGameDialog". Unfortunately, this doesn’t work. Trying it gives me the error

Traceback (most recent call last):
  File "<cegui script>", line 0, in ?
AttributeError: 'module' object has no attribute 'savegamedialog'

So obviously there’s something else I need to do.

Alternate solution was to find handle_load() in options.py, and give it the implementation

from graphics.dialogs.savegamedialog import doSaveGameDialog
	doSaveGameDialog()

Which works, as soon as I change doSaveGameDialog() to take 0 parameters.

Anyway, questions.
1. What am I missing in step 3?
2. Should we standardise on locations for files and naming for files? e.g. would it make sense to put all python dialogs scripts in “scripts\graphics\dialogs” and remove dialog from the file’s name? Would it make sense to do the same thing for the layouts?
3. Is it possible to “common up” the dialog code into a base class? Currently the MessageBox, the YesNoDialog and SaveGameDialog are very similar?

[reist]

1. Well, what you're missing in step 3 is that there's an import network reaching graphics.dialogs.options when you call it's handle_load function.
There's none going to graphics.dialogs.savegamedialog.
What you should do is import all modules you want in graphics/dialogs/__init__.py.
Then you will always have access

2. Standardising is a good idea. I'm all for it

3. No idea really. The YesNoDialog was a kind of prototype I made to experiment with stackless+GUI based on Garo ideas.
There's probably a way to do a dialog generator and then pass it only the meaningful code.

Edited by reist, 12 August 2006 - 09:31 AM.

[dteviot]

Memory leak detection in Windows.

The quick and dirty way to check for memory leaks is to use the code provided by Microsoft. Detailed instructions can be found on MSDN under the title “Memory Leak Detection Enabling”. The basic steps are:
1. Add these lines to /xenocide/src/launcher/launcer.cpp, just after the line #include “launcher_pch.h”

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

2. Then add _CrtDumpMemoryLeaks(); to same file here:

// We have finished with xenocide so we can kill the module
		shutdownModuleFunc(module);
		module = NULL;
		_CrtDumpMemoryLeaks();

Now compile debug build and run. At the end of the run it will dump a list of all the leaked blocks to the Windows output debug stream. You can record this using Sysinternal’s DebugView. However, it’s not very useful because it’s just a set of entries that look like this.

Detected memory leaks!
Dumping objects ->
{1462573} normal block at 0x08268D70, 400 bytes long.
 Data: <				> 00 00 01 80 FB FB FB FB 00 00 00 00 00 00 00 00 
{1462572} normal block at 0x08268AF0, 580 bytes long.
 Data: <   4	 ]	  > 00 00 02 34 FB FB FB FB F0 5D EA 02 98 A0 EA 02 
{1462570} normal block at 0x08268858, 600 bytes long.
 Data: <   H	(	J  > 00 00 02 48 FB FB FB FB 28 D9 03 08 00 4A E8 02 
{623878} normal block at 0x0821C028, 400 bytes long.
 Data: <		`Mr x   > 00 00 01 80 FB FB FB FB 60 4D 72 B0 78 F7 C4 02 
{598189} normal block at 0x0823D7D8, 400 bytes long.
 Data: <		`Mr x   > 00 00 01 80 FB FB FB FB 60 4D 72 B0 78 F7 C4 02

So it tells you how much you’re leaking, but that’s about it. (With some effort you can sometimes figure out where you’re leaking, by doing to test runs, where you do slightly different things, and then diff the leak dumps. But that’s hard work.)

In order to find out where the leak is really coming from, use Visual Leak Detector.
http://www.codeproje...eakdetector.asp

1. Download the source for the project from the above site.
2. Build the VLD project.
3. Copy the resulting files vld.lib, vldmt.lib and vldmtdll.lib to /dependencies/lib/vs80
4. Copy the VLD header files (vld.h and vldapi.h) to /dependencies/include
5. If you are running Windows 2000 or earlier, then copy dbghelp.dll to \xenocidegame\bin_d
6. Add “#include vld.h” to /xenocide/src/launcher/launcer.cpp, just after the line #include “launcher_pch.h”
7. Add the line “::LoadLibrary("xenocide_game_d.dll");” to launcher.cpp, just before the line “library.load();” (More on this in a moment.
8. Build the debug version of your project.

Now, when you finish running your code the VLD will (as with MS) dump the leaked block information to the Windows debugging stream. And it looks like this:

---------- Block 954 at 0x00D35870: 43 bytes ----------	
Call Stack:	
	 c:\build\xenocide\xeno\physfs\physfs.c (652): appendDirSep	
	 c:\build\xenocide\xeno\physfs\physfs.c (760): PHYSFS_init	
	 c:\build\xenocide\xeno\xenocide\src\base\pathhelper.cpp (261): Xenocide::PathHelper::setupPaths	
	 c:\build\xenocide\xeno\xenocide\src\launcher\launcher.cpp (94): main	
	 f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c (586): __tmainCRTStartup	
	 f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c (403): mainCRTStartup	
	 0x7C816D4F (File and line number not available): Error487	
 RegisterWaitForInputIdle	
   Data:	
	 43 3A 5C 42	75 69 6C 64	5C 58 65 6E	6F 63 69 64	 C:\Build \Xenocid	
	 65 5C 78 65	6E 6F 5C 78	65 6E 6F 63	69 64 65 67	 e\xeno\x enocideg	
	 61 6D 65 5C	62 69 6E 5F	64 5C 00					   ame\bin_ d\......

Note, the way the VLD works is each time a memory request is made, it takes a snapshot of the return addresses on the call stack, and adds this information to the memory block. Then at the end of the run it goes through each leaked block and figures out what code is in that memory location. The difficulty is that most of the xenocide code is dynamically loaded DLLs, that are unloaded during shutdown. So when VLD tries to resolve the memory locations, there is no longer anything there. Adding the ::LoadLibrary() call makes most of the libraries remain in memory. However it doesn’t keep all of them, so if you’ve got stuff that doesn’t resolve, try adding additional ::LoadLibrary() calls to keep them in memory as well.

A final note, as xenocide is written in both Python and C++, it’s possible for the Python to leak. There’s a nice little script at http://www.nightmare...mory-leaks.html for detecting these. To use it steps are:
(09:50:23) reist: just copy the refcounts.py file to data\scripts
(09:50:25) reist: open the console
(09:50:42) reist: write "from refcounts import *"
(09:50:51) reist: and run print_top_100() whenever you want
(09:50:59) reist: i run it immediately
(09:51:07) reist: to have something to compare to
(09:51:22) reist: and later i look in the log and just copy them in order of calls
(09:52:00) reist: and sort by 2nd key(class name), then vimdiff them...you probably have some other sort and compare programs

Although by the time you read this, refcounts.py will already be in SVN, so you won’t need to add it to data\scripts.

[dteviot]

How clicking on item in geoscape gets converted into an item

(05:33:26) reist: yup
(05:35:55) LarsW: just described the way globe clicks will be handled then
(05:38:53) LarsW: 1. someone (the select target dialog) registers with game
(05:39:15) LarsW: 2. someone clicks on the globe, earthscreen.py handles the click
(05:39:38) LarsW: 3. earthscreen.py forwards the click to the game module
(05:40:10) LarsW: 4. the gamemodules transforms the 2D coords to 3D and informs all registered handlers

[dteviot]

Research topic

(07:57:27) Drako^lM: re
(07:57:40) LarsW: i am not shure about the binding in the middle
(07:58:19) LarsW: The error is: Boost.Python.ArgumentError: Python argument types in
(07:58:19) LarsW: GlobeController.onGlobeClick(GlobeController, MouseEventArgs)
(07:58:19) LarsW: did not match C++ signature: onGlobeClick(class Xenocide::GlobeController {lvalue}, class CEGUI::MouseEventArgs {lvalue})
(07:58:47) reist: ah that
(07:59:09) reist: you can't bind a boost-exposed class to cegui
(07:59:15) reist: because cegui is exposed with swig
(07:59:28) reist: they're not compatible
(08:00:09) reist: you can pass the widget name to a C++ function, and let it do the binding
(08:00:40) reist: that's also why to translate a dialog, we give the translation function the dialog name
(08:00:54) LarsW: hmm ok

However, I found this, which might be worth further investigation:
http://mail.python.o...ust/005309.html

> The first is that the Boost and SWIG wrappings do not recognize that
> they are actually wrapping the _same_ underlying C++ class. Would it
> be possible to make a Boost-wrapped foo look sufficiently like a
> SWIG-wrapped foo, in order for the SWIG-wrapped bar.baz to accept it
> as an argument, and to know how to access the underlying C++ object

You've got to ask the SWIG guys about that part.

> (and vice versa)?

Yes, the vice versa one we can cover. You just need to register an
appropriate lvalue from-Python converter.

Hmmm.
http://wiki.python.o.../GettingStarted

If you need to get to the underlying Python/C API

If you do use Boost::Python, though, you can still use stuff from the Python/C API in your C++ code. You don't even need to import the Python.h header file. Just use the functions. For example, to clear an error in Python that you caught in C++, you could do this in the middle of an otherwise purely Boost::Python program:

PyErr_Clear();

In C++, the Python/C API represents Python objects by PyObject pointers. In Boost::Python, these are wrapped by instances of the boost::python::object class.

If you need the underlying PyObject of any boost::python::object, you can get it via the ptr() method of boost::python::object, which returns a PyObject*. You can then use it in Python/C API calls. For example, to test if a boost::python::object called boostObj has an attribute called "myAttributeName", you can do:

PyObject_HasAttrString(boostObj.ptr(), "myAttributeName");

(09:27:11) LarsW: i found an example that passes SWIGs to Pythons: http://mail.python.o...une/009114.html

Edited by dteviot, 18 October 2006 - 02:54 PM.

[dteviot]

How to hook up button presses in CEGUI to python code (and get output from a dialog)
This stuff needs to be added to the Wiki

(03:31:05) Necron: the do such a dialog
(03:31:29) Necron: i have to edit the options.py and call the "dialogname.py" on "eventclick"
(03:31:32) Necron: as far as i saw
(03:32:17) Necron: in this "dialogname.py" i will have a class for the dialog and there i have to create it. but you all use something thats called "dialogname_tasklet"
(03:32:23) Necron: but i cant found your tasklets
(03:32:32) Necron: where are the sources of them?
(03:32:43) Necron: where did you hide them
(03:33:06) reist: EventClick causes a call to a function in dialogname.py
(03:33:15) Necron: yes
(03:33:19) Necron: a doDialogName
(03:33:41) reist: that function tells python to start a tasklet on a specific function, called mostly SOMETHING_tasklet
(03:33:42) Necron: and there you always do a tasklet thing
(03:34:00) reist: that function is the tasklet
(03:34:13) reist: it can run the dialog and wait on it
(03:34:16) Necron: ah. i am silly now i see it
(03:34:28) Necron: noAudio is a function defined in the .py
(03:34:43) Necron: and you say do the noAudio_tasklet
(03:34:51) reist: yep
(03:34:52) Necron: which is the noAudio function
(03:35:01) Necron: and why dont you just call the function?
(03:35:55) reist: because it waits for the class to finish - that channel.receive() call
(03:36:21) reist: if you do it in the main context - the one that's CEGUI is in - you'll freeze the program
(03:36:27) reist: so python won't let you do that
(03:36:35) Necron: ok. i see

(06:40:56) reist: ModalDialog* modalDialog = new ModalDialog(name, dialog)
(06:41:17) reist: yes, show displays the dialog
(06:41:31) reist: the dialog is in the main context, while you're in a tasklet
(06:42:05) reist: the receive() function will be stuck until someone sends something over the channel
(06:42:10) reist: meaning - dialog closing
(06:42:30) reist: then you hide the dialog and it's destroy automatically with the end of the function
(06:42:36) reist: *destroyed
(06:42:57) Necron: and you dont do anything with response ... its just temp?
(06:43:23) reist: in this case yes
(06:43:33) Necron: ok
(06:43:46) reist: when it's a YesNoDialog, then you want to know the value
(06:43:56) reist: here it just means the user closed the dialog
(06:44:02) Necron: and you would send the value via snake?
(06:44:13) reist: why?
(06:44:37) Necron: because you do the value exchange with snake
(06:44:43) reist: no i don't
(06:44:53) Necron: you get the initial values via snake, dont you?
(06:44:55) reist: not with CEGUI
(06:45:02) reist: what initial values?
(06:45:42) Necron: the initial values of sfxVolume for example
(06:45:42) Necron: you get them via snake
(06:45:43) Necron: and you send the modified value back via snake
(06:45:52) reist: via boost.python
(06:46:22) Necron: but isnt snake the layer between c++ and boost.pythoN?
(06:46:51) reist: snake activates python and calls the class register functions that call boost.python
(06:47:17) reist: snake doesn't pass values
(06:49:00) reist: so, snake does it's registering - boost.python code registers properties to python
(06:49:37) reist: it's snake.prop because properties (that are in base) were registered in snake's scope
(06:50:10) reist: because base doesn't have python
(06:50:40) Necron: oh
(06:50:53) reist: i used properties to save them
(06:51:21) reist: if you go into your xenocide directory in the user directory
(06:51:43) reist: you'll see in the config directory a gamesettings.cfg
(06:51:59) reist: that file will have those exact variables in it
(06:52:17) Necron: ah
(06:52:18) reist: if you ran the game and quit it without crashing
(06:52:31) reist: after i added those properties
(06:52:47) Necron: the settings are stored and restored on next launch
(06:52:18) reist: if you ran the game and quit it without crashing
(06:52:31) reist: after i added those properties
(06:52:47) Necron: the settings are stored and restored on next launch
(06:52:52) reist: yep
(06:52:54) Necron: nice
(06:53:22) reist: if you want to see something where the value in the channel has a meaning
(06:53:32) reist: try the bottom of optionsdialog.py
(06:53:38) Necron: ok
(06:55:43) reist: channels are like using pipes in C (message passing that locks your thread if you're waiting for something, or sent something and waiting for it to be consumed)
(06:55:56) Necron: ok

[reist]

lvalue_from_pytype:
http://boost.org/lib...rom_pytype.html

Everyone is invited to figure this one out

[dteviot]

I've noted a number of people have downloaded and build Xenocide.
Which seems a bit of a fustrating exercise. It takes 3 or 4 hours to download and build all the pieces, and then when it runs, there's not much going on.
We should put up some sort of "progress" page that has screen shots showning what has been done (Currently really only two screens Geoscape and XNet, and a number of dialogs) and notes detailing what what happens.

Edited by dteviot, 26 November 2006 - 01:28 PM.

[dteviot]

Xenocide.XNA project report.
Ultra Top Secret.

Well, had a bit of a look at XNA.
The good news, here's screen shot. Took me 2 days to get a spinning earth globe working. Most of that time was figuring out how to build the mesh.
Screen shot attached.
I’ve also attached the project, if anyone’s interested.

Observations:
Bad News:
Documentation for XNA is pitiful. I mean, really, really, pitiful. Even worse than usual MS docs. There’s about 40 pages of “how to” examples and the source for a 3D Spacewar program. And that’s it. There’s lots of docs saying, “class X has members Y and Z”. But nothing showing how to actually USE the class.

Bad News:
GUI support is nonexistent. As in, there’s no controls (buttons, lists, etc.) In fact, it doesn’t even have font support!

Good News:
There is a CeGUI#, that runs on XNA, along with a number of other C#//.Net/Mono environments

Bad News:
CeGUI# still needs work.

Good News:
I’ve spoken to the CEGUI# team leader, and he’s offered me a place on the team.

Bad News:
I have no idea how I’d find the time to work on both Xenocide, Xenocide.XNA and CeGUI#.

Attached Files

•  globe.01.JPG   27.37K   83 downloads
•  TestBed.02.zip   89.6K   58 downloads

[Mad]

Sorry to invade your blog... but you made a slight mistake... Let me correct this for you:

Good News:
I’ve spoken to the CEGUI# team leader, and he’s offered me a place on the team.

Should've been:

Extremely bad News:
I’ve spoken to the CEGUI# team leader, and he’s offered me a place on the team.

Seriously: I hope you'll stay with us! We really need your help!

[dteviot]

Well, it's been a long time since I made a post here.
Mostly because I feel if I've got some time spare, it's better working on code than gossiping.
(Besides, I write weekly XNA progress updates elsewhere. Which brings up a point, would it be worth while posting them to a more public area than the programming area, to cut down on the "when will Xenocide be finished" posts?)

However, a couple of events have occured that I felt like talking about.
I showed the XNA prototype to the company's Cheif Technical Officer (my boss's boss's boss) and he was impressed. So much so that he's bought the following books for me under the company's training budget.
"Microsoft XNA Game Studio Creators Guide"
"Professional XNA Game Programming: For Xbox 360 and Windows"
"Programming an RTS Game with Direct3D"
"Introduction to 3D Game Programming with Direct X 9.0c: A Shader Approach (Wordware Game and Graphics Library"


And a final thought:

The hard part of a journey of 10,000 miles is not the first step.
It?s the step after you?ve been hiking for 100 miles and realise after all that effort, you?ve still got 99% of the journey to go.

[red knight]

Excelent Reflection

Greetings
Red Knight

[dteviot]

These look interesting.
http://www.gamasutra...rithms_for_.php
http://aigamedev.com/programming-tips

[dteviot]

Was reading an interesting article last night "How to breed a better Ogre".
The idea was an Ogre had a genetic code that determined things like:
Aggression vs Self Preservation
Strength vs Stamina
etc.

Now the idea was that after each "game" (think X-COM Battlescape mission) the system would find the Ogres (aliens) that killed the most knights (X-Corp soldiers) and "breed" them together.
So,the idea is that over multiple missions, the ogres got better and better at killing the player's knights.
It's not exactly making the AI smarter, but it DOES make the aliens tougher as the game goes on.

[Zombie]

Yep, that's how some of today's better chess programs work. They start out pretty stupid and easy to beat, but after running them for a long time the program builds up a log of moves which may lead to victory (or at least a draw). Depending how it was programmed in the first place, it might even pursue a different route when it senses it may have a draw. Interesting stuff.

- Zombie

[Mad]

Very interesting indeed! Might be interesting for UFOs as well.

[red knight]

There are several approaches to do that, one of those is the idea behind multidimensional optimization, genetic algorithms and even neural networks.
For simplicity suppose you have a target multidimensional function f(x1,x2, .... , xn) = y when y has a max then you have the optimum combination (unbeateable for us ) or the min (the aliens just walk in front of you without shooting). The idea is that the very same value can be counted for you too and you will get an y' so now if the difference between y' - y is too much then the AI will try to adapt using the relationships that he got from you. For instance if you have a heck of a soldier, then the AI may choose to send to you a heck of a soldier or a bunch of just overpowered aliens. So in short the issue is how do you define those x1, x2, ..., xn values.

x1 may be a measure between how many moves per turn.
x2 may be the relationship of how many hits you shoot and hit.
x3 may be the relative distance between your squad members based on clusters.

you can generate every xk with a function mk(z1, z2, ..., zn) = xk and so on... given an optimal set of relationships and caracteristics you can addapt to be near your target objetive. The good thing is that if you think you are near but gets slaughtered your new evaluation function will give you far away with your tweaks so the adaptation procedure starts over again (skipping local maxima where it sense you are getting better).

The one that plans to implement something like this, just give me a call and I can direct you directly to the source what you have to implement .

Greetings
Red Knight

[dteviot]

Starting point, for some interesting links to terrain manipulation:
http://forums.xna.co...read/26051.aspx

[dteviot]

Possible alternate solution to getting C# working on Linux:
http://axiomengine.s...x.php/Main_Page

[dteviot]

Maintaining list of jobs for recruits is a bit of a pain.
There's the thread in the workshop forum, a wiki page, and my personal todo list.
Problem with thread is it has all tasks and their state all mixed up. Would it be better to create a new forum under workshop, and create a separate thread for each task? Then should be a lot easier to find jobs and their state.

[Darkhomb]

Would it be better to create a new forum under workshop, and create a separate thread for each task? Then should be a lot easier to find jobs and their state.

I think it would be

[red knight]

The other ohing we can do is move everything to the Archives and start over on the Workshop. Your call there.

Greetings
Red Knight

[dteviot]

The other thing we can do is move everything to the Archives and start over on the Workshop. Your call there.

Greetings
Red Knight

I'd prefer to keep the existing workshop, and create a sub-forum for the "recruit tasks"

[kafros]

What about the "BUGS" bug-tracker?

[dteviot]

What about the "BUGS" bug-tracker?

Well, I use the Forum as my primary communication tool, so having the list there (here) seems like a good idea.
Of course, it may just be a case of hammer (forum), nail (tasklist).

[Zombie]

Post a list of what needs to be done and pin it in programming. As tasks are finished, cross them off with a strikethrough and continue to add tasks to the list as necessary. This way, stuff doesn't get lost in the shuffle.

- Zombie

[red knight]

Zombie has a point there

Greetings
Red Knight

[dteviot]

Post a list of what needs to be done and pin it in programming. As tasks are finished, cross them off with a strikethrough and continue to add tasks to the list as necessary. This way, stuff doesn't get lost in the shuffle.

- Zombie

Ah, that's how you do a strikethrough. If someone would like to update the assorted To Do forums accordingly, that would be appreciated.

Edited by dteviot, 29 September 2007 - 01:46 PM.
fixed.

[dteviot]

Was thinking about going to these guys (or maybe these http://www.protobuild.co.nz/) and getting a X-Com chess set made up.
Trying to figure out what do I use for the various pieces.
So far:

• an unarmoured soldier is the X-Com pawn.
• The cannon HWP would be the rook (castle)
• Flying suit would be knight
• BB launcher HWP the queen
• Skyranger is the king (loose it, and you loose the game)
• greys are alien pawns
• ethereal is the king

But I'm not sure what to use for the other pieces. Any ideas?

[dteviot]

Turns out the standard Model class in XNA doesn't support animations.
Possible solution,
I've seen a .md2 (Quake 2) model importer that does support models.
And there's a .md3 importer on CodePlex.
So, look at using md2/md3 for the aliens/humans.
Might even be able to steal the models from UFO:AI, as that's supposedly Quake2 based.