civil-devel Mailing List for Civil

Oops, something went wrong. Dumping brain contents: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "./civil.py", line 462, in ?
    main ()
  File "./civil.py", line 454, in main
    event_loop ()
  File "./event_loop.py", line 274, in event_loop
    newstate = scenario.current_state.handleEvent ( event )
  File "./state/calculate_action.py", line 67, in handleEvent
    scenario.engine.update ()
  File "./engine/engine.py", line 144, in update
    self.updateForStep ( step )
  File "./engine/engine.py", line 202, in updateForStep
    self.runExecutor ( unit, step )
  File "./engine/engine.py", line 299, in runExecutor
    actiondata = planexec.execute ( step )
  File "./engine/executor/skirmish_exec.py", line 112, in execute
    return self.setUnitMode ( self.unit, step, self.unit.getMode ().onDone () )
  File "./engine/executor/executor.py", line 90, in setUnitMode
    newmode = createMode ( modename )
  File "./mode/mode_factory.py", line 120, in createMode
    raise ValueError ( "mode '%s' is unknown to the factory" % mode )
ValueError: mode 'unlimberedartillery' is unknown to the factory
------------------------------


It always happens after several turns, when enemy units become visible 
(and I assume the enemy can see me, too).
Maybe the ai is trying to fire at me and can't.

Cristian

I have looked to the los_point calculation for "bluring" terrain (such 
as woods)

The points are "decreased" for any pixel on the line, regardless of 
"slope", so a unit in a plane forest will have a square field of view.

The real "length" of a pixel is pixlen = sqrt (mx**2 + my**2) (where 
mx,my are the "slopes" computed by my code)
pixlen can vary from 1 (horiz or vertical line) to 1.41 (diagonal)

Unfortunately, using the multiplycative approach ( los_points *= 0.2 for 
forest) requires an exp ( instead of having 100 original lospoints
we'll have only 100 ** (1/pixlen)  ; this actually includes 1 div, 1 
log, 1 mul and 1 exp :-)

***

Both operations should be done once for a line, so time is not so critical

But anyway

in our case,

sqrt (mx**2 + my**2) can then be approximated by ( 2 + mx + my ) / 3 
(within 6% error)
or by 0.57 + 0.43*(mx**2 + my**2) (within 1% error)


for avoiding the exp, we can replace all vision modifiers by their log 
(ie 0.4 -> -0.916), the maximum points also (100 -> 4.6 ),
which including corection becomes (4.6 / pixlen). Each iter the modifier 
is added to available points (note they are negative)

The checking condition points < 1 becomes points < 0

I notice that for woods ln(0.2)=-1.6 so the unit can see only 2 pixels; 
maybe we can see a little further
for rocks ln(0.8)=-0.22 so can see 20 pixels (seems ok to me)

Cristian

PS: I have shown the game to my professor. He likes it but I'm not sure 
if he likes me hacking the code instead of working ...

Hi

I have hacked the "quick los" I have proposed 2 weeks ago ( checking the 
points in a non incrementing order)
I'll attach the source

First I modified some computings (note that the current version divides 
dy/dx also dx can be 0)

The line is "walked" as parameter t ranges from 0 to iters, by the formulas:
x=x0 + mx*t
y=y0 + my*t
z=z0 + mz*t

Then your code follows, unmodified.

But instead of for t = 1 to iters I will choose t in another order, 
keeping in mind not to give the same values more times
(it slows down the code and it puzzles the los_points, as a terrain 
cannot "blur" vision 2 times :-)

A quick choice was to use some number theory.
given a prime (503 in my sample) one can find a generator (5) s.t.
t=5
while (t!=1){
   t=(t*5) % 503
    if (t>iters) continue;
   ...  do job with t
}
will execute the "job" once for each t form 1 to iters (if iters < 503, 
of course)

Improvement: for different distances we can use smaler primes, because 
it's a waste of time to "continue" a lot ...
At this moment I use only 2 primes, 503 and 307 (for iters < 300)

***
Timing results (computed for the first turn)
the original algoritm gives an average of 14 ms / unit (as reported by 
"new total").
the modified algorithm gives an average of 4 ms / unit.

Of course, the algorithm cannot do better when 2 units can see each 
other, but statistically this will happen when the 2 units are close
to each other, so the time will be short, anyway.

I timed the code w/ the loop disabled (returning "start" instead of 
doing iterations) and the result is 3ms. So the bottleneck is no longer 
"tracelos" :-)

Hoping to be helpful,

Cristian

PS: the "limit point" of the "los line" does not say any more where the 
vision stops but says where the loop stops :-)

please comment out the "old los" call in unit.py around line 506
please modify delay() to wait() in net/connection_poller... around line 70

On Thu, 30 Jan 2003, Jan Ekholm wrote:

>Stay tuned for more details and some shot screens.

Now a line symbolizing the line of sight is drawn in the LOS debug map
when you check LOS for a unit. Show the LOS debug window, select a unit,
press "l" and click in the map somewhere and voila, a line is drawn in the
LOS debug window. Like magic. :)

The line is green as long as the unit sees, and red onwards from the point
where the unit does not see. That way it is possible to see exactly where
a unit's LOS ends and probably also why. Click in the LOS debug window to
switch between a terrain and a height view. Note that as long as you are
checking LOS you can't click in the LOS debug window, as the LOS checker
grabs the mouse presses.

Have fun. 

-- 
      Real children don't go hoppity-skip unless they are on drugs.
                          -- Susan Sto Helit, in Hogfather (Terry Pratchett)

Cristian Soviani wrote:

> I have turned the los off (so everybody sees everybody) to be able to 
> test the game.
> After 2 turns I get this error message:
> 
> AssignTargets.execute: 1st battery skirmish 2nd infantry
> ClearTargets.execute: 3rd battery can not skirmish: target destroyed
> 
> Oops, something went wrong. Dumping brain contents: 
> ---------------------------------------------------------------------------
> Traceback (most recent call last):
[snip]
> ValueError: mode 'unlimberedartillery' is unknown to the factory
> ---------------------------------------------------------------------------

Hi Cristian! You didn't tell which version of civil you are running. The 
latest release, 0.81, is quite a bit out of date, with LOS errors and 
these "mode xxx is unknown to the factory". They should more or less be 
gone by downloading from CVS.

> ***
> 
> Another error occurs when a unit tries to cross "impassable" terrain.
> I've hacked the sources a little (to make the movement only if the 
> terrain is passable), but I believe these changes should be done in an 
> organized manner,
> by somebody who really knows the program.

This is a flaw even in the CVS version, unfortunately. We are planning 
version 0.82 to be out quite soon, when we have made LOS better and 
faster, and fixed impassable terrains (river/sea).

> ***
> 
> I'm using:
> 
> Python 2.2 (#1, Apr 12 2002, 15:29:57) [GCC 2.96 20000731 (Red Hat Linux 
> 7.2 2.96-109)] on linux2
> 
> and
> 
> pygame-1.5.3.-1
> 
> There is a deadlock comm problem between th eserver and client; I had to 
> introduce a bogus "time.sleep(4)" in the updateAI() (before sendPlans())
> to make it work on my system. The code looks OK, I assume my system is 
> guilty. Please let me know if you have an idea why.

The python and pygame versions are OK. There probably is a communication 
deadlock there lurking somewhere, but it is very unlikely to show up, so 
this is a bit surprising. How fast is your computer? (MHz)

Thanks for the bug report!

Cheers,
Marcus

I have turned the los off (so everybody sees everybody) to be able to test the game.
After 2 turns I get this error message:

AssignTargets.execute: 1st battery skirmish 2nd infantry
ClearTargets.execute: 3rd battery can not skirmish: target destroyed

Oops, something went wrong. Dumping brain contents: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "./civil.py", line 458, in ?
    main ()
  File "./civil.py", line 450, in main
    event_loop ()
  File "./event_loop.py", line 274, in event_loop
    newstate = scenario.current_state.handleEvent ( event )
  File "./state/calculate_action.py", line 67, in handleEvent
    scenario.engine.update ()
  File "./engine/engine.py", line 147, in update
    self.executeAI ( step )
  File "./engine/engine.py", line 347, in executeAI
    actiondata = module.execute ( step )
  File "./engine/ai/clear_targets.py", line 62, in execute
    self.clearTarget ( unit, actiondata, step )
  File "./engine/ai/module.py", line 80, in clearTarget
    self.setMode ( unit, unit.getMode ().onDone (), actiondata, step )
  File "./engine/ai/module.py", line 65, in setMode
    unit.setMode ( createMode ( mode ) )
  File "./mode/mode_factory.py", line 120, in createMode
    raise ValueError ( "mode '%s' is unknown to the factory" % mode )
ValueError: mode 'unlimberedartillery' is unknown to the factory
---------------------------------------------------------------------------

***

Another error occurs when a unit tries to cross "impassable" terrain.
I've hacked the sources a little (to make the movement only if the terrain is passable), but I believe these changes should be done in an organized manner,
by somebody who really knows the program.

***

I'm using:

Python 2.2 (#1, Apr 12 2002, 15:29:57) 
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-109)] on linux2

and

pygame-1.5.3.-1

There is a deadlock comm problem between th eserver and client; I had to introduce a bogus "time.sleep(4)" in the updateAI() (before sendPlans())
to make it work on my system. The code looks OK, I assume my system is guilty. Please let me know if you have an idea why.


Cristian

On Tue, 21 Jan 2003, Korruptor wrote:

>>
>> 	t-ghill-018-640
>> 	t-rdhill-019-644
>> 	t-rdhill-020-645
>> 	t-sang-hill-019-642
>> 	t-sang-hill-020-643
>> 	t-shill-018-641
>> 	t-whill-049-646
>> 	t-whill-050-647
>> 	t-whill-051-648
>> 	t-whill-052-649
>>
>> Suggestions?
>
>Delete those files from your repository and cvs update. Don't think 
>anyone's ever reported those files as causing problems before.

I've had no problems with them, and they are used as they are in a
scenario. Some PNG files still gives me warnings when loaded, but
apparently libpng on Linux just whines, it won't crash.

-- 
         Real stupidity beats artificial intelligence every time.
                                              -- Terry Pratchett, Hogfather

>
> 	t-ghill-018-640
> 	t-rdhill-019-644
> 	t-rdhill-020-645
> 	t-sang-hill-019-642
> 	t-sang-hill-020-643
> 	t-shill-018-641
> 	t-whill-049-646
> 	t-whill-050-647
> 	t-whill-051-648
> 	t-whill-052-649
>
> Suggestions?

Delete those files from your repository and cvs update. Don't think 
anyone's ever reported those files as causing problems before.

G

-- 
   "The first rule of holes: if you're in one, stop digging!"
       -- Unknown Confucius
--

Jan;

	The CVS version worked much better. I was able to get as far as loading
a scenario. Starting the scenario on the other hand crashed the s/w with the
following:

> libpng error: PNG file corrupted by ASCII conversion
> TerrainLayer.loadIcons: failed to load: 647, ../gfx/terrains/t-whill-050-647.png
> 
> Oops, something went wrong. Dumping brain contents:
> ---------------------------------------------------------------------------
> Traceback (most recent call last):
>   File "civil.py", line 458, in ?
>     main ()
>   File "civil.py", line 431, in main
>     initAll ()
>   File "civil.py", line 424, in initAll
>     initPlayfield ()
>   File "civil.py", line 192, in initPlayfield
>     scenario.playfield.addLayer ( TerrainLayer   ( name="terrain" ),    visible=1 )
>   File "playfield\terrain_layer.py", line 32, in __init__
>     self.loadIcons ()
>   File "playfield\terrain_layer.py", line 273, in loadIcons
>     icon = pygame.image.load ( names [iconid] )
> error: Error reading the PNG file.
> ---------------------------------------------------------------------------
> 

The specific terrain causing the problem depends on which scenario I try to start.
I checked the whole set with one of my graphics utilities and it identified the
following as "corrupted":

	t-ghill-018-640
	t-rdhill-019-644
	t-rdhill-020-645
	t-sang-hill-019-642
	t-sang-hill-020-643
	t-shill-018-641
	t-whill-049-646
	t-whill-050-647
	t-whill-051-648
	t-whill-052-649

Suggestions?

	Larry

On Mon, 20 Jan 2003, Lawrence J. Levin wrote:

>Gentlemen;
>
>I am trying to get Civil-0.81 running on my laptop (running Win 2k) but have 
>had some problems. Some I could fix myself, but now I seem to have hit a roadblock
>and need some assistance.

Please use the CVS version. It's much better and "lacks" a few bugs that
the packages have.

The __init__.py files are all there in the CVS version

>Once I added the init files, the program started ok. I accepted the default of 
>playing against the computer, then got asked for the port number. I accepted
>the default of 20000, after which the s/w crashes with the trace shown below.
>For the hell of it I tried a manual start of the civil_ai and it failed with
>the msg:
>
>	Error creating socket to 'localhost' on port 20000: Connection refused

The AI client wants to be started after a server has been started. If you
start them separately start Civil normally, and select "Play against
human, act server", click "Ok" until it waits for the other player to
connect and then start the AI client.

>Got any suggestions? The full trace is shown below. By the way, if it matters
>I am using python 2.2

I use the same.

As you use Windows the stack trace is beause of that. The task of starting
a process (the AI client in this case) is horribly broken for Windows
right now. It should work ok if you start the AI client separately. We are
working on fixing that, but as none of us really uses Windows too much
nobody has got around to do it.

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

Gentlemen;

I am trying to get Civil-0.81 running on my laptop (running Win 2k) but have 
had some problems. Some I could fix myself, but now I seem to have hit a roadblock
and need some assistance.

The first problem (which I fixed) was an inability to start the s/w due to
imports that failed. I figured out that some of the directories lacked
__init__.py files. These were:

		    editor\plugins
                    engine
                    engine\ai
                    gui
                    lounge
                    net
                    scenario_server
                    server
                    test
                    util

Once I added the init files, the program started ok. I accepted the default of 
playing against the computer, then got asked for the port number. I accepted
the default of 20000, after which the s/w crashes with the trace shown below.
For the hell of it I tried a manual start of the civil_ai and it failed with
the msg:

	Error creating socket to 'localhost' on port 20000: Connection refused

Got any suggestions? The full trace is shown below. By the way, if it matters
I am using python 2.2

	Larry


==================================================

G:\Gaming\SynBat\Civil\civil-0.81\src>python civil.py
running on: windows
creating personal directories for saved games and scenarios
  >>> creating directory: XXXXXXXXXXX/
  >>> creating directory: XXXXXXXXXXX/saved_games
  >>> creating directory: XXXXXXXXXXX/scenarios
personal directories created ok
checking your system...
 - pygame version is 1.5.5, works ok
 - detected pygame version later than 1.5. No rect workarounds needed...
initializing hardware accelerated mode.
audio: 8 sound channels available
audio: no audio CD found
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk

Oops, something went wrong. Dumping brain contents:
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "civil.py", line 480, in ?
    main ()
  File "civil.py", line 455, in main
    initAll ()
  File "civil.py", line 439, in initAll
    setup ()
  File "civil.py", line 295, in setup
    if SetupNetwork ( run_ai ).run () == ACCEPTED:
  File "gui\dialog.py", line 199, in run
    returncode = self.wm.handle ( event )
  File "gui\widget_manager.py", line 104, in handle
    return self.handleMouseReleased (event)
  File "gui\widget_manager.py", line 221, in handleMouseReleased
    status = w.handle ( widget.MOUSEBUTTONUP, event )
  File "gui\widget.py", line 163, in handle
    code = self.callbacks[type] ( self, event )
  File "gui\setup_network.py", line 147, in ok
    return self.initServerSocket ( port )
  File "gui\setup_network.py", line 181, in initServerSocket
    self.__startAI ( port )
  File "gui\setup_network.py", line 269, in __startAI
    method = supported [ properties.platform_name ]
KeyError: windows
---------------------------------------------------------------------------

On Sun, 19 Jan 2003, Jan Ekholm wrote:

> >Hi, I sold my computer to my brother, so I'm at the moment without one 
> >here at home. I'll try to fix my computer at work to run pygame et al
> >soonish. Oh, I'll get myself a new computer as well :)
> About time. :) Didn't you have something even more prehistoric than my
> p2-333?

Heh, actually it was a AMD K6-II at 500 MHz, so no small beast :)
...But if jack wants to play instead of only working, a faster 
computer is required.

Hi Cristian,

I see you're on the list, so I won't send a copy directly to you.

>*** 1. Idea for a quicker los:
>
>Assume I'm looking from (0,0) to (100,0).
>The program will check points 1,2, ..., 100, in this order.
>
>But the map isn't random, i.e. it's likely that adjacent points to have 
>related heights & terrain types.
>So it's quicker to check the points in an alternate order, let's say:
>50, 25, 75, 12, 37, 62, ....
>If there is a "mountain" between 60 and 70 (i.e. points between 60 and 
>70 will block the los), instead of computing 60 steps we'll have to 
>compute only 6.

I like this new idea. It uses some simple facts of normal terrain
topology. It could reduce the failing LOS tests from linear time to
logarithmic, and still keeping linear for "worst case", ie. when the LOS
test passes. The LOS code you've looked at is still very new and probably
even a bit buggy (at least my initial version), so every improvement is
very welcome.

The more I think about it, the better it sounds. I'll have to look into
it, unless you already have something working?

>I'm sure the los will be much quicker. If you wish, I can give you the 
>actual algorithm (very simple).
>
>
>*** 2. I notice current_distance and total_distance are kept squared to 
>avoid sqroot.
>Then:
>los_height=st_h + delta_h * current_dist / total_dist.
>Unfortunately this does not ok.
>Assume st_h=0, startx=0, endx=100  and delta_h=10. At x=50 los_h should 
>be 5 (of course).
>
>So total_distance=100*100=10000, current_distance=50*50=2500,
>and los_h = 0 + 10*2500/10000=2.5 (wrong).
>
>I suggest to be replaced by:
>if(update_x_every_it)
>los_h = st_h + deltah * (x-startx)/ dx
>else  los_h = st_h + deltah * (y-starty)/dy

Just to be sure, it would look like this?

    if update_x_every_iteration:
        x += add_to_x
        y = int ( m * x + b )

        los_height = start_height + delta_height * (x-startx) / dx

    else:
        y += add_to_y
        x = (y - b) / m

        los_height = start_height + delta_height * (y-starty) / dy


>current and total _distance are not longer needed.

Yes, true. All simplifications an more importanty bugfixes are always
good. :) Thanks a lot for the fix.

>I really love this game.

Thanks! Do you happen to have any "first test" reflections of stuff that
is weird, hard, buggy or ugly that you'd like to share?

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

On 19 Jan 2003, Michael Earl wrote:

>On Sun, 2003-01-19 at 11:03, Lawrence J. Levin wrote:
>> 1) Civil is written in python. We work mostly in C/C++ and Java and 
>> have no experience in Python (not because we think there is something wrong
>> with it but just because there is a limit to how many languages you can
>> learn). For a number of reasons, we want to stick to this. Hence one
>> question is how hard it is to link Java and Python. I have heard about
>> "Jython" but don't know anything other then it has something to do with
>> providing python-like capabilities in a Java context).
>
>The communication between the remote player and server is all XML over
>TCP, so I would image you'ld just write the AI in your language of
>choice but have to build a module to parse the civil-XML-data, which is
>not too bad.

Actually, the in-game data is even simpler than that. It's just simple
text lines that begin with a keyword, an optional space separated list of
parameters and finally an newline. The keyword could be "move",
"changemode" etc.

>Python is an interpreted language, and Jython is a python interpreter
>ported to Java.  Theoretically you could probably get civil to work in a
>JVM that way, but I believe some of the libraries we require are not
>available in that requirement.

Probably not SDL/Pygame?

>Alternately, I understand (but have not tried) that it is relatively
>easy to use C/C++ to build libraries for Python code and vice versa.
>
>> 2) The key issue will be the ability of the Synthetic Commander (call it the
>> "SynC" for short (which is a pun on CinC which stands for Commander in Chief))
>> to get the info it needs via your API. The SynC needs info about anything
>> relevant to tactics, including terrain, infrastructure (e.g. roads, bridges)
>> *presumed* location of both friendly and enemy forces, and their strengths.
>> The reason I say "presumed" is that I need to account for the "fog of war".
>> Not only does the commander not always know the location of the enemy but
>> sometimes he is in the dark about some of his subordinates (e.g., Lee 
>> wondering where the hell Stuart was at Gettysburg). The gods-eye view of
>> the board that most RTS games offer is a no-no if you want realistic
>> behavior by synthetic actors. This leads to the next question:
>
>We have some fog-of-war with respect to visibility of enemy units.  It
>currently doesn't handle terrain, and intelligence reports come back
>instantaneously, although orders are delayed.

Full terrain handling is on the TODO. It does handle it partially, eg for
movement.

Something that we should some day incorporate is some kind of way to let
a player knwo that a unit was seen in a certain location, but now it has
vanished. That could mean that the unit has hidden, moved slightly (but
still is almost there) or moved entirely away. Other games leave a
"marker" on the map to indicate that an enemy unit was spotted on that
location. The markers have a certain time to live, after which they are
removed, probably to simulate that the observation isn't accurate anymore.
It makes it easier for a human player to keep track of probable enemy
movements.
 
>> 3) is Civil 2-player or multiplayer? The only description I have is that
>> it is 2-player and that one of these players acts as the server. That makes
>> me wonder what prevents it from being multi-player. Can one person be
>> Lee, another Longstreet, another Pickett, etc.? I can do the basic work
>> I need to do in a 2-player context but eventually I need to get to an
>> environment with a chain of command with SynCs at every level from commanding
>> general down to company & platoon level.Note that I do not expect CIVIL to
>> provide the communcations channel the SynCs use to pass orders and reports
>> back and forth.
>
>This would require minor engine changes, but not huge ones, except
>insofar as it might require solving the intelligence delay problem
>mentioned above.

We have actually never even thought about such an idea, but I don't
actually think it would be such a big change. It would be pretty fun
though. Just make sure that a player is tied to one certain commander and
can't affect other troops.

>My impressions is that there's probably some engine work lacking for
>what you want, but it may be close enough, especially if you were
>willing to pitch in on some of it (python and all).

Actually I think going with Python wouldn't be a bad choice. A normal
programmer learns it in an hour, gets up to speed in a few hours and
grasps the syntax of 99% of all Civil code in a day (the algorithms aren'
t always that easy though). Keeping an external wrapper up-to-date is an
extra challenge.

-- 
               "Stercus, stercus, stercus, moriturus sum."
                                       -- Terry Pratchett, Interesting Times

On Sun, 2003-01-19 at 11:03, Lawrence J. Levin wrote:
> 1) Civil is written in python. We work mostly in C/C++ and Java and 
> have no experience in Python (not because we think there is something wrong
> with it but just because there is a limit to how many languages you can
> learn). For a number of reasons, we want to stick to this. Hence one
> question is how hard it is to link Java and Python. I have heard about
> "Jython" but don't know anything other then it has something to do with
> providing python-like capabilities in a Java context).

The communication between the remote player and server is all XML over
TCP, so I would image you'ld just write the AI in your language of
choice but have to build a module to parse the civil-XML-data, which is
not too bad.

Python is an interpreted language, and Jython is a python interpreter
ported to Java.  Theoretically you could probably get civil to work in a
JVM that way, but I believe some of the libraries we require are not
available in that requirement.

Alternately, I understand (but have not tried) that it is relatively
easy to use C/C++ to build libraries for Python code and vice versa.

> 2) The key issue will be the ability of the Synthetic Commander (call it the
> "SynC" for short (which is a pun on CinC which stands for Commander in Chief))
> to get the info it needs via your API. The SynC needs info about anything
> relevant to tactics, including terrain, infrastructure (e.g. roads, bridges)
> *presumed* location of both friendly and enemy forces, and their strengths.
> The reason I say "presumed" is that I need to account for the "fog of war".
> Not only does the commander not always know the location of the enemy but
> sometimes he is in the dark about some of his subordinates (e.g., Lee 
> wondering where the hell Stuart was at Gettysburg). The gods-eye view of
> the board that most RTS games offer is a no-no if you want realistic
> behavior by synthetic actors. This leads to the next question:

We have some fog-of-war with respect to visibility of enemy units.  It
currently doesn't handle terrain, and intelligence reports come back
instantaneously, although orders are delayed.
 
> 3) is Civil 2-player or multiplayer? The only description I have is that
> it is 2-player and that one of these players acts as the server. That makes
> me wonder what prevents it from being multi-player. Can one person be
> Lee, another Longstreet, another Pickett, etc.? I can do the basic work
> I need to do in a 2-player context but eventually I need to get to an
> environment with a chain of command with SynCs at every level from commanding
> general down to company & platoon level.Note that I do not expect CIVIL to
> provide the communcations channel the SynCs use to pass orders and reports
> back and forth.

This would require minor engine changes, but not huge ones, except
insofar as it might require solving the intelligence delay problem
mentioned above.



My impressions is that there's probably some engine work lacking for
what you want, but it may be close enough, especially if you were
willing to pitch in on some of it (python and all).

-Mike E.

Hi

*** 1. Idea for a quicker los:

Assume I'm looking from (0,0) to (100,0).
The program will check points 1,2, ..., 100, in this order.

But the map isn't random, i.e. it's likely that adjacent points to have 
related heights & terrain types.
So it's quicker to check the points in an alternate order, let's say:
50, 25, 75, 12, 37, 62, ....
If there is a "mountain" between 60 and 70 (i.e. points between 60 and 
70 will block the los), instead of computing 60 steps we'll have to 
compute only 6.

I'm sure the los will be much quicker. If you wish, I can give you the 
actual algorithm (very simple).


*** 2. I notice current_distance and total_distance are kept squared to 
avoid sqroot.
Then:
los_height=st_h + delta_h * current_dist / total_dist.
Unfortunately this does not ok.
Assume st_h=0, startx=0, endx=100  and delta_h=10. At x=50 los_h should 
be 5 (of course).

So total_distance=100*100=10000, current_distance=50*50=2500,
and los_h = 0 + 10*2500/10000=2.5 (wrong).

I suggest to be replaced by:
if(update_x_every_it)
los_h = st_h + deltah * (x-startx)/ dx
else  los_h = st_h + deltah * (y-starty)/dy

current and total _distance are not longer needed.


***

I really love this game.

Cristian

On Sun, 19 Jan 2003, Marcus Alanen wrote:

>Hi, I sold my computer to my brother, so I'm at the moment without one 
>here at home. I'll try to fix my computer at work to run pygame et al
>soonish. Oh, I'll get myself a new computer as well :)

About time. :) Didn't you have something even more prehistoric than my
p2-333?

-- 
           "Right, you bastards, you're... you're geography"
                                         -- Terry Pratchett, Guards! Guards!

Hi, I sold my computer to my brother, so I'm at the moment without one 
here at home. I'll try to fix my computer at work to run pygame et al
soonish. Oh, I'll get myself a new computer as well :)

Jan;

Glad you are interested. In response to some of your questions....

> May I ask if it is for military research or general behavior research?

The research is for the military. The issue is creating realistic behavior
in synthetic forces. An excellent overview of the problems and issues can
be found in "Modeling Human and Organizational Behavior: Applications to 
Military Simulations", by R. W Pew and A. S. Mavor. This is published by the
National Academy Press and the full text is available online at:

http://books.nap.edu/books/0309060966/html/index.html

Chapter 2 has an excellent introduction to the issues, including a scenario
based on platoon-level operations. The specific problem I want to focus
on is realistic behavior by commanders. For example, it would not address
the "fine grain" behavior that would lead to realistic visual images of
infantry company moving through a village or woods, stopping to shoot, or
take cover. It would, however, lead to realistic tactical behavior by
the platoon and company commanders as to where to position squads, when
to attack or retreat, etc. 

 One aspect of all this that is worth noting, especially in the context
of a game focused on historically accurate recreation (like CIVIL) is
the full meaning of the phrase "realistic tactical behavior". This
includes "realism" at 3 levels:

 1) something a sane and rational person would be expected to do
	under the same circumstances,
 2) something consistent with the doctrine, training, and tactics 
	of the force being simulated (e.g., Soviet-style armored
	tactics are not the same as US tactics), and
 3) something a specific individual would be expected to do
	under the same circumstances.

The last item deals with the issue of "behavior modifiers". Partially
the goal is to be able to have synthetic commanders that show some
variation in individual "personality" (e.g., aggressiveness, willingness
to inflict civilian casualties, etc.). The long-term goal is to be able
to model the personality of a specific opponent and then simulate
what they might do in a given situation. 

 IF (and that is a big IF) this works, you might be able to re-fight
Gettysburg with Grant in charge of the Union forces. For that matter,
why not pit Napoleon against Lee? 

I should point out a couple of things up-front. One is that this is 
*proposed* research and it may get turned down (I won't know for sure 
for several months). On the other hand, I am for now assuming it will
get funded and am trying to get some preliminary work out of the way
in terms of setting up a test environment. The second point is that this
is "research" and there is every possibility that it will fail to produce
useful code or algorithms. Hopefully of course it will get funded and will 
work. But ya never know till you try :)

 
> I think Civil could be a pretty good testbed for your application. Right
> not it focuses on the American Civil War, but once we reach a stable
> version 1.0 I'd like to adapt it to simulate the Napoleonic battles.
> That's mainly an issue of adapting the weapons, some strings and
> optionally some graphics as well as build the new scenarios.
> 

From my point of view, there is really no significant difference between
the two. Ultimately I have to address all types of conflicts and weapons
from small unit urban ops to major regional conflicts using chem-bio, 
space-based directed energy weapons, and info warfare. The ultimate
target environment is the Joint Synthetic Battlefield (JSB) and simulation
environments like MODSAF/OneSAF (see http://www.onesaf.org/onesaf.html).
For a variety of reasons, however, I want to start out using something
smaller, simpler, and easier to control and work with (e.g., CIVIL?).


> I'm interested in what you're doing and would like to do with Civil. I
> also think that for an AI client Civil has pretty good facilities to
> access all the needed internal info.
> 
> Good luck with your project and let us know what you decide on! If you
> have more questions don't hesitate to ask us.

OK, since you have taken the bait (so to speak) here are some of the 
issues and questions...

1) Civil is written in python. We work mostly in C/C++ and Java and 
have no experience in Python (not because we think there is something wrong
with it but just because there is a limit to how many languages you can
learn). For a number of reasons, we want to stick to this. Hence one
question is how hard it is to link Java and Python. I have heard about
"Jython" but don't know anything other then it has something to do with
providing python-like capabilities in a Java context).

2) The key issue will be the ability of the Synthetic Commander (call it the
"SynC" for short (which is a pun on CinC which stands for Commander in Chief))
to get the info it needs via your API. The SynC needs info about anything
relevant to tactics, including terrain, infrastructure (e.g. roads, bridges)
*presumed* location of both friendly and enemy forces, and their strengths.
The reason I say "presumed" is that I need to account for the "fog of war".
Not only does the commander not always know the location of the enemy but
sometimes he is in the dark about some of his subordinates (e.g., Lee 
wondering where the hell Stuart was at Gettysburg). The gods-eye view of
the board that most RTS games offer is a no-no if you want realistic
behavior by synthetic actors. This leads to the next question:

3) is Civil 2-player or multiplayer? The only description I have is that
it is 2-player and that one of these players acts as the server. That makes
me wonder what prevents it from being multi-player. Can one person be
Lee, another Longstreet, another Pickett, etc.? I can do the basic work
I need to do in a 2-player context but eventually I need to get to an
environment with a chain of command with SynCs at every level from commanding
general down to company & platoon level.Note that I do not expect CIVIL to
provide the communcations channel the SynCs use to pass orders and reports
back and forth.

Last is a mundane question: where can I get a copy of "python-xml"? The install
notes for Civil says it is needed but I can not find anything by that name
(do you mean "PyXML"?)

Thanks

	Larry

Ok, at least the AI client can load scenarios again. Well, it doesn't
really load them, it just gets the XML over the network and then parses
it.

I haven't tested saving games, but I expect it to be slightly broken.

--
  Shadwell hated all southerners and, by inference, was standing at the
  North Pole.
                           -- Terry Pratchett & Neil Gaiman, Good Omens

Hi Lawrence,

I'm not sure if you're on the mailing list, so I'll reply to you directly
too.

>I am looking around for a suitable test environment for a project I may
>be starting up soon and Civil strikes me as a possibility. The project
>deals with knowledge representation and the modelling of human behavior
>when making a decision. The targeted application is synthetic commanders
>for military simulations.

This actually sounds quite interesting, although a bit out of my league.
May I ask if it is for military research or general behavior research?

>I am looking for a suitable test environment and I have been focusing on
>pre-20th century land combat. Hence my interest in Civil. I have noticed
>that you already have an AI capability built in although it sounds like
>it is not very extensive at this time.  Would you folks be interested in
>coorperating in this area (assuming that (1) my R&D program gets funded,
>and (2) Civil turns out to be an appropriate testbed).

I think Civil could be a pretty good testbed for your application. Right
not it focuses on the American Civil War, but once we reach a stable
version 1.0 I'd like to adapt it to simulate the Napoleonic battles.
That's mainly an issue of adapting the weapons, some strings and
optionally some graphics as well as build the new scenarios.

Civil does have quite a lot of initial AI framework and utility code, but
so far nothing that really *does* anything. But doing a totally standalone
AI client is really easy, it would mean copying a few classes to get a
clean working environment that takes care of starting up, reading a
scenario from the server, reading/sending data etc.

I think I cansay for the whole team that we're interested. When it comes
to code details I'll help you out, but that's a later problem.

>If so, let me know and I can give you a better idea of what I am looking
>to do and you can tell me if the interfaces exist to support the
>proposed work.

I'm interested in what you're doing and would like to do with Civil. I
also think that for an AI client Civil has pretty good facilities to
access all the needed internal info.

Good luck with your project and let us know what you decide on! If you
have more questions don't hesitate to ask us.

Regards,
   Jan 'Chakie' Ekholm

-- 

             Gravity is a habit that is hard to shake off.
                                              -- Terry Pratchett, Small Gods

Greetings;

I am looking around for a suitable test environment for a project I may be starting up
soon and Civil strikes me as a possibility. The project deals with knowledge 
representation and the modelling of human behavior when making a decision. The targeted
application is synthetic commanders for military simulations.

I am looking for a suitable test environment and I have been focusing on pre-20th century
land combat. Hence my interest in Civil. I have noticed that you already have an AI 
capability built in although it sounds like it is not very extensive at this time. 
Would you folks be interested in coorperating in this area (assuming that (1) my R&D
program gets funded, and (2) Civil turns out to be an appropriate testbed).

If so, let me know and I can give you a better idea of what I am looking to do and
you can tell me if the interfaces exist to support the proposed work.

Thanks

	Larry Levin


-- 

Lawrence J Levin
Critical Architectures, LLC
Skillman NJ 08558
email: lj...@ec...
voice: (609) 333-9750

On Fri, 17 Jan 2003, Jan Ekholm wrote:

>
>Hola,
>
>I added some code to make the editor write the new scenario type, aka.
>.civil. This type contains in a zipped file the scenario data, the
>scenario info and (currently) a pickled version of the LOS data.
>
>I will run the scenarios we have through the editor, save them in the new
>format and then change the scenario loading to cope with the new format.
>Shouldn't be too hard, saving didn't take too long to implement.

Ok, scenarios are fixed. So far the new scenarios can't yet 
be loaded, as the ScenarioManager only finds the scenario info XML file
and parses it. The scenarios are now called:

	foo.civil

These files are normal zip file created with the module zipfile. Inside
these files are three files that are *always* called:

	info.xml
	scenario.xml
	los.pickle

No matter what the scenario itself is called the names inside the files
are always the same, and they are given without a directory. This makes
them pretty easy to parse and handle.

**** 1h later ****

Loading scenarios works fine now, but they can't yet be sent over to the
remote party, that'll need some extra fiddling. Pickle is also dead slow,
so i'll have to figure out something better. The loader also handles the
fact that there might not be a LOS map in the scenario. If so, it is jus
created. Why would that be needed then? Well, a client that connects to a
server will have no need for a LOS map, thus it doesn't get sent one. So,
when this client saves a game that saved game has not LOS data to save,
and thus no LOS map in the scenario. If at a later time this saved game is
continued the LOS map is instead created froms scratch. And if the LOS map
is never sent over the socket to a client we don't send any more data then
we did before. Nice, eh?

Will fix the sending tomorrow, it's just a matter of getting stuff from
a zip file instead of a gzip file. How hard can a little "g" be to get
rid of? :)

-- 
    - "Remember -- that which does not kill us can only make us stronger."
    - "And that which does kill us leaves us dead!"
                                           -- Terry Pratchett, Carpe Jugulum

Hola,

I added some code to make the editor write the new scenario type, aka.
.civil. This type contains in a zipped file the scenario data, the
scenario info and (currently) a pickled version of the LOS data.

I will run the scenarios we have through the editor, save them in the new
format and then change the scenario loading to cope with the new format.
Shouldn't be too hard, saving didn't take too long to implement.

Have a nice weekend, folks!

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

> Ah, a zip file would allow us to put many files into the scenario. Now 
> our
> scenarios are just one file that happens to be gzipped. Moving to zip
> would basically make the scenarios work like tar.gz -files.

Fair enough :)

G

-- 
     "I'd rather get screwed by Steve Jobs once in a while, than be
     raped by Bill Gates every day."
       -- Unknown Mac Abuser
--