Messages

Thanks for the quick responses! 

GSH, I was hoping you would offer some advice in particular.  You pretty much confirmed some of the things I suspected and was considering.  I was concerned that having dozens of threads running might be a performance issue, and didn't relish the idea of having to debug the them, especially since I'll be developing this on multi-core machines.  Ultimately I would like to work this into the MPI DLL and knew state synchronization would be a real bear.  Managed cooperative multitasking per your suggestion seems doable to me, and much more easily portable to MPI.  It's not far off from one of the alternatives I had in mind.  The main thing I'm worried about is trying to do too much during a single Execute.  Do you have any tips on how to avoid that and how to detect when you've gone overboard?

OvermindDL1, I appreciate the offer.  Learning something about how your Python scriptor works might help to solidify what I have in mind, whether I borrow some of your ideas or not.  I'll be happy to take a look at whatever instructive material you have.

During the Summer of 2007 I developed a bunch of new strategy maps for Battle Zone.  Most of them are intended for two players.  My sons and I have had a good time playing with them.  I would like to share them with the community. 

I don't have my own web site to offer the maps for download at this time.  May I have some suggestions from the BZ community for a good place to upload them so they will be easily available to anyone interested?

I am thinking about creating a new Instant Action DLL modification that will separate action control logic to individual units.  The intent is to make the units somewhat autonomous.  They will make their own decisions about what they do in any given situation.  I also expect to be able to set up a kind of self-organizing "swarm intelligence" to make the units work more cooperatively as a group by taking advantage of their individual decision-making.

To make this idea work well I am hoping to be able to take advantage of multi-threading.  In short a thread would be created for each unit as it is added that would persist until the unit is removed.  In effect, each unit would be "thinking" and responding to events on its own, and would be able to respond to requests and commands from other units.

I've searched the boards here for information related to multi-threaded capabilities in the BZ2 DLLs and not found anything so far to the point.  Can anyone tell me whether there are any impediments to implementing this idea, or if anyone has actually coded something like this for BZ2?

Natty has been and will continue to work on G66 2.1 when possible to make it work awesomely with BZ2 PB3.  I'll release it when it is working well and the CPU is whipping me on a regular basis. 

The current version of the G66 v2.0 Beta has been released for public review.  You can get it at Natty's Cabin, http://nattyscabin.bzuniverse.com/.  

G66 v2.0 is designed specifically for BZ2 1.3.  Work on the next build for G66 v2.0 is underway.  Notices will be posted as soon as it is released.