civil-devel Mailing List for Civil

Well, it seems to be on mine. When ever i dont have it
in the src folder, it tells me it cant find modules
that it has to load (ie. weapons, version etc.).

So you can take it out of CVS, but it doesnt work on
my PC, and im not sure if it will on others.

---
Sean Carroll

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com

<=1B$B;v6H<TL>=1B(B>=1B$B-k%(%/%7%9=1B(B<=1B$BAw?.<T=1B(B>=1B$B-k%(%/%7%9=
=1B(B<=1B$BAw?.<T!&;v6H<T=1B(BURL>=1B$B!!=1B(Bhttp://plaza15.mbn.or.jp/~1=
234/ =1B$B$3$N=1B(B=D2=B0=D9=1B$B$O9-9p$G$9!#G[?.ITMW$NJ}$O=1B(B mailstop=
@melcon-c.com  =1B$BKx$4O"Mm2<$5$$!#G[?.$rDd;_CW$7$^$9=1B(B(=1B$BI,$:G[?.=
Dd;_$9$k%"%I%l%9$G$4JV?.2<$5$$!K=1B(B

H=1B$B$J=3Dw$N;R5^A}Cf!*:#$,%A%c%s%9!*=1B(B
http://www.melcon-c.com
=1B$BB(%"%]B3=3DP!*=1B(B
http://www.melcon-c.com
=1B$B$^$:$OEPO?$7$F$M!*=1B(B
http://www.melcon-c.com

Sean,

Does the Windows client really need paths.py? I think it should happily
just print an error "paths not found" and continue. The file is really
there for systems that can use autoconf, as it is regenerated every now
and then by "configure" when it is copied from "paths.py.in" and slighlty
modified.

What error does the Windows client give you if the file is not present?

-- 

                  - "What're quantum mechanics?"
        - "I don't know. People who repair quantums, I suppose."
                                               -- Terry Pratchett, in Eric

On Sat, 28 Sep 2002, Sean Carroll wrote:

>Ok, well i was running Civil on Windows XP. Whenever i
>tried to start a game against the computer, it would
>quit. So, i followed the dump and found the problem.
>
>In the gui/setup_network.py, we had the platform_name
>set to 'windows' but in the supported platforms in
>setup_network.py it was shown as 'win'. They
>conlficted. So i changed the supported to 'windows'.
>Then, it said it couldnt find 'civil-ai'. So i added a
>path variable in properties.py called 'path_source'.
>Then for the 'path_ai_client' varible, i set it to
>'path_source + 'civil-ai.py'. 
>
>This seemed to work, and AI works fine on Windows. It
>also doesnt affect how Civil runs on linux. BUT, i
>cant commit to cvs because i dont have write access.

Ok, good job fixing that.

>Chakie, could you please give me write acces to the
>cvs repository please.

You should have write access. You do however make sure that you checked
out Civil from CVS *not* as anonymous. You must do it using your own name,
(sccarroll) otherwise you'll never be able to commit. Anonymous checkouts
are read-only.

--
             In the Beginning it was a nice day.
                           -- Terry Pratchett & Neil Gaiman, Good Omens
			   

Whenever it tries adding a terrain layer i get this
error:

Oops, something went wrong. Dumping brain contents: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Civil\src\civil.py", line 480, in ?
    main ()
  File "D:\Civil\src\civil.py", line 455, in main
    initAll ()
  File "D:\Civil\src\civil.py", line 448, in initAll
    initPlayfield ()
  File "D:\Civil\src\civil.py", line 191, in
initPlayfield
    scenario.playfield.addLayer ( TerrainLayer   (
name="terrain" ),    visible=1 )
  File "D:\Civil\src\playfield\terrain_layer.py", line
32, in __init__
    self.loadIcons ()
  File "D:\Civil\src\playfield\terrain_layer.py", line
272, in loadIcons
    icon = pygame.image.load ( names [iconid] )
error: Error reading the PNG file.
---------------------------------------------------------------------------

It looks like it has a problem finding the png file. I
cant figure it out. Any ideas?

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Ok, well i was running Civil on Windows XP. Whenever i
tried to start a game against the computer, it would
quit. So, i followed the dump and found the problem.

In the gui/setup_network.py, we had the platform_name
set to 'windows' but in the supported platforms in
setup_network.py it was shown as 'win'. They
conlficted. So i changed the supported to 'windows'.
Then, it said it couldnt find 'civil-ai'. So i added a
path variable in properties.py called 'path_source'.
Then for the 'path_ai_client' varible, i set it to
'path_source + 'civil-ai.py'. 

This seemed to work, and AI works fine on Windows. It
also doesnt affect how Civil runs on linux. BUT, i
cant commit to cvs because i dont have write access.

Chakie, could you please give me write acces to the
cvs repository please.

---
Sean Carroll

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

More on screen resolutions. In game when i was
checking AI, i tried to switch the playingfield
resolution. It gave me a weird error:

Oops, something went wrong. Dumping brain contents:
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "./civil.py", line 480, in ?
    main ()
  File "./civil.py", line 472, in main
    event_loop ()
  File "./event_loop.py", line 282, in event_loop
    updateDisplay ()
  File "./event_loop.py", line 65, in updateDisplay
    scenario.playfield.paint ()
  File "./playfield/playfield.py", line 145, in paint
    layer.paint ( self.offsetx, self.offsety,
dirtyrect )
  File "./playfield/dialog_layer.py", line 197, in
paint
    self.customPaint ()
  File "./playfield/set_resolution_layer.py", line
152, in customPaint
    self.gui_checked = self.checked
AttributeError: SetResolutionLayer instance has no
attribute 'checked'
---------------------------------------------------------------------------

has that ever happened to anyone else?

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

On 27 Sep 2002, Michael Earl wrote:

>On Thu, 2002-09-26 at 07:13, Sean Carroll wrote:
>> When i get home after school today, i will see if i cant get the AI to where if the target is not in Line of sight, that it 
>> moves torward that enemy until it is in line of sight...then it goes to attack.
>> 
>> BTW...fwd this to the dev list. i am at school and cant send emails through yahoo.
>
>Well, I just put something in, and it moves units now.  It doesn't
>attack units it runs into along the way, which is probably wrong - is
>there still a fire-at-will switch or am I using the wrong move mode?

It will fire at will only when stopped. It should probably use the "combat
policy" to see if the player wants the unit to fight or just proceed. But,
right now you see the designed behaviour.

>Also, it seems a bit slow to me unless I'm missing something about the
>interface.  I wonder if all the prints during LoS are actually slowing
>it down enough to notice?

It's slow during the action phase at least, and also by design. It will
wait one second before the next step.

>Bug(?): ordering infantry to "wait" from right-button-menu crashed game.

Yes, this is a small developer-related buglet. Civil is probably setup to
launch the AI from /usr/games/civil-ai, and not from the normal sandbox.
Check:

        src/gui/setup_network.py

and the method:

        def __startAIUnix (self, command, port):
            """Performs the AI starting on Linux/Unix."""
            # add a & to make it go in the background
            command = "./civil-ai.py --port=%d &" % port
 
It should the above version of 'command'. Otherwise it will try to
run the AI with the obsolete 0.81 code, and that won't work.

-- 

  That's right," he said. "We're philosophers. We think, therefore we am.
                                             -- Terry Pratchett, Small Gods

On 27 Sep 2002, Michael Earl wrote:

> Also, it seems a bit slow to me unless I'm missing something about the
> interface.  I wonder if all the prints during LoS are actually slowing
> it down enough to notice?

Hardly, but do go ahead and try it without them.

Notice that the video playback always waits at least a second between 
each step, so it certainly could be quicker. See ./src/state/action.py 
and search for "1000" (milliseconds)

-- 
Marcus Alanen                       * Software Construction Laboratory *
mar...@ab...   * http://www.tucs.fi/Research/labs/softcons.php *

On Thu, 2002-09-26 at 07:13, Sean Carroll wrote:
> When i get home after school today, i will see if i cant get the AI to where if the target is not in Line of sight, that it 
> moves torward that enemy until it is in line of sight...then it goes to attack.
> 
> BTW...fwd this to the dev list. i am at school and cant send emails through yahoo.

Well, I just put something in, and it moves units now.  It doesn't
attack units it runs into along the way, which is probably wrong - is
there still a fire-at-will switch or am I using the wrong move mode?
Also, it seems a bit slow to me unless I'm missing something about the
interface.  I wonder if all the prints during LoS are actually slowing
it down enough to notice?


Bug(?): ordering infantry to "wait" from right-button-menu crashed game.

Oops, something went wrong. Dumping brain contents: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "civil.py", line 480, in ?
    main ()
  File "civil.py", line 472, in main
    event_loop ()
  File "event_loop.py", line 274, in event_loop
    newstate = scenario.current_state.handleEvent ( event )
  File "state/state.py", line 218, in handleEvent
    return self.handleRightMousePressed ( event )
  File "state/state.py", line 424, in handleRightMousePressed
    return self.keymap [ (key, modifier) ] ()
  File "state/own_unit.py", line 299, in wait
    mode = createMode ( createMode ( unit.getMode ().onWait () ).onDone
() )
  File "mode/mode_factory.py", line 120, in createMode
    raise ValueError ( "mode '%s' is unknown to the factory" % mode )
ValueError: mode '' is unknown to the factory
---------------------------------------------------------------------------



- mikee

I added a brutally simple implementation of keyboard shortcuts to the
setup dialogs. It's now possible to bind any key (a K_x code) to the
widget. When the key is pressed a "left mouse release" event is triggered
for the widget. Works well for buttons, probably for checkboxes too. 

Check any of the dialogs to see how the Ok (and Start) buttons have been
bound to a shortcut. Maybe the shortcut should actually be a property of
the widget instead of a passed parameter when the widget is registered.

Anyway, just FYI.

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

On Wed, 25 Sep 2002, Korruptor wrote:

>> I noticed when i tried to start up Civil on my linux
>> box, that the default screen res for the build is
>> 1024X768. How can we change this to default to the
>> actual screen res?
>
>The default resolution for Civil is 1024x768 primarily as all front end 
>menus and dialog GFX are built for that size -- including button 
>placement, font-size, etc. etc.
>
>The initial decision was to fix Civil's dialogs to this resolution and 
>only allow for changes "in game" -- this is something I strongly agree 
>with, as it wasn't all that long ago that we were going to have Civil 
>fixed at 1024x768 for *everything*.

Yeah, at first it was 1024x768 and nothing else. Then when we got rid of
the old fixed size panel there were no real problems anymore with having a
dynamic size, so it was done.

I'm not advocating changing the setup dialogs to 800x600 (or 640x480 for
that matter), as they still use so much more stuff that is fixed to the
1024x768 size. I don't really want to sacrifice time to fix that, there
*are* more important things to do.

>I'm starting to think that it /may/ be worth investigating using 
>pygame.transform.scale on the surfaces in order to support changes in 
>res for the front end (for res > 1024x768) and this would be a partial 
>answer to your question.  Backdrops could be scaled up easily enough, 
>but they'll always look crap, so I'd really not like to go down that 
>route.

Scaling them could lead to pretty bad stuff, especially for text, but I
have no real evidence for that unless it's tested. We could enlarge the
fonts a bit, which would mean that they could more easily remain readable
after a scale. But all this is academic, imho.

>Jan has also suggested that the backdrops be centered instead of 
>scaled, which is quite a reasonable approach I think.

That was mostly for the end game dialog. That part could be fixed with
moderate effort.

>Personally, I don't see why people can't live with the front-end at 
>1024x768 and allow the in-game modes to be set.  It is after all, the 
>only realistic place where a change in resolution gives any discernible 
>advantage. And anyone that can't get 1024x768 is going to have a very 
>bumpy ride with a Python game. They must have one old machine... ;-)

This is certainly true. I haven't had a machine stuck with 800x600 since,
well, '93, I think. And that machine would have had a pretty hard time
running Civil. :) For laptops it's the same. Palmtops probably can't reach
the needed resolution, but I doubt they reach the needed CPU power either. 

>Anyway, if it's a personal itch, I guess it needs to be scratched, and 
>I can sympathise, but as I tend to run it fullscreen, changes in res 
>aren't much of an issue. Jan's suggestion is the only good one I've 
>heard, so I put my vote behind that approach if someone does decide to 
>support dynamic res as I'm *very* protective of the GFX on those 
>screens.... ;)

Personally I vote for: leave it.

I like the chance to set a different reoslution for the main game, as
there the players will spend 99% of the time. Most probably want a larger
window, or a window tailored to some custom wide screen resolution.

-- 
 The Emperor had all the qualifications for a corpse except, as it were, the
         most vital one.
                                       -- Terry Pratchett, Interesting Times

And I mean minimal, was just committed.

It seems to work for me.  This mess is meant mostly for subclassing and
infrastructure; it mostly orders everything to attack some random enemy
unit, and the engine won't even execute those orders unless that unit
happens to be in Line-of-Sight.

Still, it does seem to give the orders, so not bad for a one-night
hack-job.

It shouldn't have broken anything but I hadn't touched this code or
python in a while, so no guarantees.  By all means back it out, fix it,
or flame me if it's breaking stuff. :)

- mikee

 

On Wed, 2002-09-25 at 17:51, Sean Carroll wrote:
> Well, i guess this could be ok. At fullscreen i can
> still see a pretty good portion of the buttons. Just
> not all of what everything is saying. I dont really
> see it as a problem with development, just on people
> computers, if they are like mine, you cant go any
> higher than 800 x 600 screen res. Its not a bother to
> me as much, it just might be to someone who has never
> played Civil before.

Yeah, when I'm debugging stuff I usually run in an 800x600 window, too,
so it's a minor bother.

It's a non-issue fullscreen for me.  Maybe center/crop if they insist on
running windowed mode at ~=1024x768, and just force resolution to
1024x768 (if hardware supports?) for front-end/backdrops (use their
resolution for in-game GUI only) when in fullscreen mode?

- mikee

Well, i guess this could be ok. At fullscreen i can
still see a pretty good portion of the buttons. Just
not all of what everything is saying. I dont really
see it as a problem with development, just on people
computers, if they are like mine, you cant go any
higher than 800 x 600 screen res. Its not a bother to
me as much, it just might be to someone who has never
played Civil before.

That was just my reason for bringing it up thats all.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

> I noticed when i tried to start up Civil on my linux
> box, that the default screen res for the build is
> 1024X768. How can we change this to default to the
> actual screen res?

The default resolution for Civil is 1024x768 primarily as all front end 
menus and dialog GFX are built for that size -- including button 
placement, font-size, etc. etc.

The initial decision was to fix Civil's dialogs to this resolution and 
only allow for changes "in game" -- this is something I strongly agree 
with, as it wasn't all that long ago that we were going to have Civil 
fixed at 1024x768 for *everything*.

I'm starting to think that it /may/ be worth investigating using 
pygame.transform.scale on the surfaces in order to support changes in 
res for the front end (for res > 1024x768) and this would be a partial 
answer to your question.  Backdrops could be scaled up easily enough, 
but they'll always look crap, so I'd really not like to go down that 
route.

Jan has also suggested that the backdrops be centered instead of 
scaled, which is quite a reasonable approach I think.

However, the buttons are a minor issue. Given how damn sexy they look, 
I *really* won't be happy to scale those up/down, so that requires some 
changes to placement, and given the size, things get cramped pretty 
quickly if res goes down. Text could also do with being dynamic in that 
case, but for the very small benefits I've been of the opinion for a 
long time that this is a waste of effort.

Personally, I don't see why people can't live with the front-end at 
1024x768 and allow the in-game modes to be set.  It is after all, the 
only realistic place where a change in resolution gives any discernible 
advantage. And anyone that can't get 1024x768 is going to have a very 
bumpy ride with a Python game. They must have one old machine... ;-)

Anyway, if it's a personal itch, I guess it needs to be scratched, and 
I can sympathise, but as I tend to run it fullscreen, changes in res 
aren't much of an issue. Jan's suggestion is the only good one I've 
heard, so I put my vote behind that approach if someone does decide to 
support dynamic res as I'm *very* protective of the GFX on those 
screens.... ;)

Cheers

G



--
"Computer games don't affect kids; I mean if Pac-Man affected us as 
kids, we'd all be running around in darkened rooms, munching magic 
pills and listening to repetitive electronic music."
     -- Kristian Wilson, Nintendo Inc., 1989
--

I noticed when i tried to start up Civil on my linux
box, that the default screen res for the build is
1024X768. How can we change this to default to the
actual screen res?

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

On Wed, 25 Sep 2002, Marcus Alanen wrote:

>On Wed, 25 Sep 2002, Jan Ekholm wrote:
>
>> >BTW, are the regiments and other unit groups defined when the scenario
>> >is created or is this something the AI manages?
>> 
>> The units are found as two separate versions:
>> 
>> 	scenario.info.units
>> 
>> which is a flat dictionary indexed by the unit id, with mixed union/rebel
>> units.
>> 
>> 	scenario.info.brigades
>
>Let me add that if you need any helper functions
>(e.g., "i want a list of rebel units that are within X pixels
>of coordinate P" or whatever), don't hesitate to ask. I would like to 
>think that AI programming should not be concerned of how we present 
>data structures in civil, instead civil should provide easy access 
>functions to the AI so it can make good decisions.

True. So far we have quite few convenience functions, but that's mainly
because the "human client" often doesn't benefit too much from them. But
yeah, I'm with Marcus here, we should do it as simple as possible for the
AI (and the human client too, of course) to get wanted data. Time should
be spent on the logic, not doing routine stuff that can be abstracted away
somewhere.

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

On Wed, 25 Sep 2002, Jan Ekholm wrote:

> >BTW, are the regiments and other unit groups defined when the scenario
> >is created or is this something the AI manages?
> 
> The units are found as two separate versions:
> 
> 	scenario.info.units
> 
> which is a flat dictionary indexed by the unit id, with mixed union/rebel
> units.
> 
> 	scenario.info.brigades

Let me add that if you need any helper functions
(e.g., "i want a list of rebel units that are within X pixels
of coordinate P" or whatever), don't hesitate to ask. I would like to 
think that AI programming should not be concerned of how we present 
data structures in civil, instead civil should provide easy access 
functions to the AI so it can make good decisions.


Marcus

On Wed, 25 Sep 2002, John Eikenberry wrote:

>ml...@at... wrote:
>
>> Yeah,  it'll see the same stuff in the scenario as the 
>> rest of the engine, so as long as you have a pointer to 
>> that you're good.  Might want some kind of 'macro' or 
>> dynamic filter or something to make it simpler to ignore 
>> units that the AI can't actually see - I mean, you can 
>> just loop through them and check each one before acting 
>> on it, but that will be happening constantly and might 
>> get annoying.
>
>I wasn't going to worry about the AI not cheating at first. It is an
>eventual goal (makes things more interesting), but its easier to cheat
>at this point. So, at least for the influence map, I had just planned on
>using the info on all the units. Whether they can see them or not.

Yeah, better let it cheat and play a better game, than not cheat and do
*really* stupid things. Doing an AI client that doesn't cheat is actually
very hard, much harder than a cheating one. But this isn't news to anyone
here.
 
>> I was thinking it might be nice, especially if we're 
>> doing parallel development, to set up the AI(s?) as an 
>> object, when would then just have it's 'update' method 
>> called once per turn by the updateAI method in the main 
>> loop.   Keeps junk out of that main loop and segments 
>> things off.  
>
>I was thinking pretty much the same thing. We could probably go ahead
>and add the call along with some dummy code to handle it to CVS. Then we 

Ok, sounds good.

>> You could even have multiple AIs running at 
>> once, called with slightly different construction 
>> parameters:
>
>As far as the different AIs go, I plan on doing all that in the AI code.
>I was going to build up a heirarchical system where something like the
>general decides on the goals and assigns them to the commanders. The
>commander code then handles the details of assigning units to roles.
>
>Your approach is similar in that it'd have to have a decision making
>'general' to decide what the objectives are. It just breaks up the code
>by the objectives rather than a psuedo military hierarchy. Something like
>that will probably end up being the better design, but I think the
>hierarchical structure will be easier to deal with at first.
>
>BTW, are the regiments and other unit groups defined when the scenario
>is created or is this something the AI manages?

The units are found as two separate versions:

	scenario.info.units

which is a flat dictionary indexed by the unit id, with mixed union/rebel
units.

	scenario.info.brigades

which contains the brigades for each player, indexed first by REBEL or
UNION and then the brigade id. The brigades in turn contain the regiments,
which contain battallions or companies and battallions contain companies.
A full hierarchy, that *may* need to be expanded upwards to divisions.

The commanders for each organization is accessible too. See
src/organization.py for more info, or ask here. :)

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

ml...@at... wrote:

> Yeah,  it'll see the same stuff in the scenario as the 
> rest of the engine, so as long as you have a pointer to 
> that you're good.  Might want some kind of 'macro' or 
> dynamic filter or something to make it simpler to ignore 
> units that the AI can't actually see - I mean, you can 
> just loop through them and check each one before acting 
> on it, but that will be happening constantly and might 
> get annoying.

I wasn't going to worry about the AI not cheating at first. It is an
eventual goal (makes things more interesting), but its easier to cheat
at this point. So, at least for the influence map, I had just planned on
using the info on all the units. Whether they can see them or not.
 
> I was thinking it might be nice, especially if we're 
> doing parallel development, to set up the AI(s?) as an 
> object, when would then just have it's 'update' method 
> called once per turn by the updateAI method in the main 
> loop.   Keeps junk out of that main loop and segments 
> things off.  

I was thinking pretty much the same thing. We could probably go ahead
and add the call along with some dummy code to handle it to CVS. Then we 

> You could even have multiple AIs running at 
> once, called with slightly different construction 
> parameters:

As far as the different AIs go, I plan on doing all that in the AI code.
I was going to build up a heirarchical system where something like the
general decides on the goals and assigns them to the commanders. The
commander code then handles the details of assigning units to roles.

Your approach is similar in that it'd have to have a decision making
'general' to decide what the objectives are. It just breaks up the code
by the objectives rather than a psuedo military hierarchy. Something like
that will probably end up being the better design, but I think the
hierarchical structure will be easier to deal with at first.

BTW, are the regiments and other unit groups defined when the scenario
is created or is this something the AI manages?

> #1 is the 'take-objective' AI, told to take objective A 
> with units 1-10.
> 
> #2 is the 'attack' AI, told to kill vulnerable enemy 
> units with units 11-15
> 
> #3 is the 'scout' AI, told to look for the enemy.
> 
> etc, etc.  Perhaps #1, if successful, terminates and 
> hands its units over to a defense AI/behavior.  Maybe 
> the map itself would have hints for the initalization of 
> AI about roles for various forces.
> 
> 
> - mikee
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Civil-devel mailing list
> Civ...@li...
> https://lists.sourceforge.net/lists/listinfo/civil-devel

-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"Perfection (in design) is achieved not when there is nothing more to add,
 but rather when there is nothing more to take away."
                                        -- Antoine de Saint-Exupery

On Mon, 23 Sep 2002 ml...@at... wrote:

>> While I'm here maybe someone could help get me 
>started. In the ai event
>> loop do I just put a call in the updateAI to my code 
>to calculate the
>> plans for that turn and set them on the units? It 
>looks like keeping the
>> units state up to date (eg. its location) is handled 
>already. Does this
>> sound right?
>
>Yeah,  it'll see the same stuff in the scenario as the 
>rest of the engine, so as long as you have a pointer to 
>that you're good.  Might want some kind of 'macro' or 
>dynamic filter or something to make it simpler to ignore 
>units that the AI can't actually see - I mean, you can 
>just loop through them and check each one before acting 
>on it, but that will be happening constantly and might 
>get annoying.

Exactly. The AI client can if it will know everything and cheat (I'm not
too good at those fancy words), as it gets sent everything that happens
for any unit.

All the received data is applied automatically as it arrives, so there is
no "action phase" for the AI client. It's just a "calculate what to do"
and then a more or less long "wait and see what happened" part. 

The only parts the AI does have to take care of is in updateAI(), and the
only thing it is required to do is create plans for the units. How plans
are actually created (parameters etc) is quite simple.

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

On Mon, 23 Sep 2002 ml...@at... wrote:

>> This could be very useful in coding the AI.
>
>I don't think this ought to be terribly hard; isn't the 
>AI still communicating with the engine via TCP?

Yeah, it does. For the engine the AI player doesn't actually differ at all
from a human player. The AI gets sent the exact same data as a human
client would.

>You would need an omniscient-observer mode for the GUI, 
>though.  The Starcraft RTS doesn't do exactly that, but 
>it allows you to save a 'log file' of a battle and watch 
>the replay from an omniscient perspective, or any 
>player's, which is really neat.  I *think* we could do 
>something like this by just cc'ing the update stream 
>going over the network into a file as well?

I've been thinking of this too, and yes, I think it could be done. Just to
write the stream to a file is really simple, but for playback we'd need
some more code. Actually we could use take Action state (the one that now
plays back one turn), modify it a bit to load and instantiate stuff from
the data read from the file.

It could be done, and it could be sexy. :)

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

> This could be very useful in coding the AI.

I don't think this ought to be terribly hard; isn't the 
AI still communicating with the engine via TCP?

You would need an omniscient-observer mode for the GUI, 
though.  The Starcraft RTS doesn't do exactly that, but 
it allows you to save a 'log file' of a battle and watch 
the replay from an omniscient perspective, or any 
player's, which is really neat.  I *think* we could do 
something like this by just cc'ing the update stream 
going over the network into a file as well?



- mikee

> Oh, and how much work would it be to allow for AI vs AI fights. So that
> I could just hit the next turn button and watch the AIs go at it. This
> would be real handy for working on the AI. Seems like it could be
> as easy as putting the same call from updateAI into the players loop
> somewhere.

This would be very helpful if we could find a way to do this. Maybe if we put a button on the main part of the game asking ot play against a computer or human, asking if we wanted to play AI v AI just for dev purposes (take it off for release). Then somehow activate both AI's pitting them up against one another. This could be very useful in coding the AI.




---------------------------------
Do you Yahoo!?
Yahoo! News - Today's headlines