civil-devel Mailing List for Civil

> Btw, this must be one of the lowest content/signature ratios I've ever
> seen. :) But the page that quote comes from is absolutely hilarious.
> Gareth, still have the URL?

Purely accidental. Seems the original page is no more, and a quick 
google only turned up replies to it...

--
     "Light travels faster than sound. That's why some people
      appear bright until you hear them speak."
       -- Unknown
--

On Mon, 30 Dec 2002 ml...@at... wrote:

>Thinking about this some more... a rectangular or circular hex-center sub-
>region might not be all that bad, but it will add another batch of special 
>cases to map.py.  I'd still recommend some, um, selective ignorance (la-la-la-
>LA-I'M-NOT-LISTENING) of this problem until at least .8? - fix the existing LoS 
>before we make it more complex - and depending on the solution it might be a 
>1.2 or 2.0 thing or some such.

I think it should be fixed somehow before 1.0, or otherwise we'll need to
ban some terrains. We won't be able to handle those hexes properly, and it
will look a bit silly when you have your troops in a little forest and
Civil boneheadedly says they're in a field.

But, of course we can ignore it and pretend it's not there. Someone will
notice it sooner or later though. :)

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

On Mon, 30 Dec 2002, Korruptor wrote:

>> Could you please put up a short blurb on the homepage that we're still 
>> not
>> dead? I tried to do it, but I didn't want to mess with your formatting 
>> and
>> the page was write-protected too.
>
>Was on my TODO for this week, so I'll do it right away! :-)
>
>Cheers
>
>g
>
>--
>"The real operating system hiding under the newest version of the MacOS 
>X is called... Darwin! That's right, new Macs are based on Darwinism! 
>While they currently don't advertise this fact to consumers, it is well 
>known among the computer elite, who are mostly Atheists and Pagans. 
>Furthermore, the Darwin OS is released under an "Open Source" license, 
>which is just another name for Communism. They try to hide all of this 
>under a facade of shiny, "lickable" buttons, but the truth has finally 
>come out: Apple Computers promote Godless Darwinism and Communism. "
>     -- Richard Paley

Nice!

Btw, this must be one of the lowest content/signature ratios I've ever
seen. :) But the page that quote comes from is absolutely hilarious.
Gareth, still have the URL?


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

> Could you please put up a short blurb on the homepage that we're still 
> not
> dead? I tried to do it, but I didn't want to mess with your formatting 
> and
> the page was write-protected too.

Was on my TODO for this week, so I'll do it right away! :-)

Cheers

g

--
"The real operating system hiding under the newest version of the MacOS 
X is called... Darwin! That's right, new Macs are based on Darwinism! 
While they currently don't advertise this fact to consumers, it is well 
known among the computer elite, who are mostly Atheists and Pagans. 
Furthermore, the Darwin OS is released under an "Open Source" license, 
which is just another name for Communism. They try to hide all of this 
under a facade of shiny, "lickable" buttons, but the truth has finally 
come out: Apple Computers promote Godless Darwinism and Communism. "
     -- Richard Paley
--

Thinking about this some more... a rectangular or circular hex-center sub-
region might not be all that bad, but it will add another batch of special 
cases to map.py.  I'd still recommend some, um, selective ignorance (la-la-la-
LA-I'M-NOT-LISTENING) of this problem until at least .8? - fix the existing LoS 
before we make it more complex - and depending on the solution it might be a 
1.2 or 2.0 thing or some such.

- mikee

On Mon, 30 Dec 2002 ml...@at... wrote:

>Chakie writes:
>> On Mon, 30 Dec 2002, Marcus Alanen wrote:
>[...]
>> >yeah but we should have a "center point terrain type", i.e. each hex
>> >has seven terrain types.
>> 
>> Yup, I'll add one as soon as I get to it. The centerpoint will be the 7th
>> triangle in order to not mess up current indexes.
>
>Not quite sure I understand what this means.  Do you mean to add a central sub-
>region to each hex?  That would make a (further) mess of the what-triangle-is-
>this-point-in code, and the what-triangles-does-the-LoS-vector-cross code.  I 
>suppose one could add a square or circular region to the center of each hex 
>without it becoming a complete mess, but it'll add another mess of cases to 
>that already sticky code.  Probably managable, but I'd rather avoid it... 

Hmm, ok.

There are a few hexes where we just can't represent the data without some
kind of "mid point". For example the hexes that only have a blob of trees
in the middle. There the triangles are *all* partially covered towards the
centre, but none is fully covered.

But I do understand the issues involved with breaking up the hexes into
something even less regular.

What to do, o, what to do?

-- 
  "You can't trample infidels when you're a tortoise. I mean, all you could
                  do is give them a meaningful look."
                                              -- Terry Pratchett, Small Gods

Chakie writes:
> On Mon, 30 Dec 2002, Marcus Alanen wrote:
[...]
> >yeah but we should have a "center point terrain type", i.e. each hex
> >has seven terrain types.
> 
> Yup, I'll add one as soon as I get to it. The centerpoint will be the 7th
> triangle in order to not mess up current indexes.

Not quite sure I understand what this means.  Do you mean to add a central sub-
region to each hex?  That would make a (further) mess of the what-triangle-is-
this-point-in code, and the what-triangles-does-the-LoS-vector-cross code.  I 
suppose one could add a square or circular region to the center of each hex 
without it becoming a complete mess, but it'll add another mess of cases to 
that already sticky code.  Probably managable, but I'd rather avoid it... 


- mikee

On Mon, 30 Dec 2002, Marcus Alanen wrote:

>On Mon, 30 Dec 2002 ml...@at... wrote:
>
>> I think just treating roads/streams/etc. as tris is the most reasonable thing 
>> without a lot more heavy work to the engine.
>> 
>> The problem is that this can't exactly handle rivers/roads that run through the 
>> center of a hex very well; the engine will treat them as being on one side or 
>> the other, or you can just call the whole hex that type.  I'm afraid the answer 
>> may just be 'don't do hexes like that then', but a lot of the road/river hexes 
>> are drawn that way.
>
>yeah but we should have a "center point terrain type", i.e. each hex
>has seven terrain types.

Yup, I'll add one as soon as I get to it. The centerpoint will be the 7th
triangle in order to not mess up current indexes.

-- 
  "You can't trample infidels when you're a tortoise. I mean, all you could
                  do is give them a meaningful look."
                                              -- Terry Pratchett, Small Gods

On Mon, 30 Dec 2002 ml...@at... wrote:

> I think just treating roads/streams/etc. as tris is the most reasonable thing 
> without a lot more heavy work to the engine.
> 
> The problem is that this can't exactly handle rivers/roads that run through the 
> center of a hex very well; the engine will treat them as being on one side or 
> the other, or you can just call the whole hex that type.  I'm afraid the answer 
> may just be 'don't do hexes like that then', but a lot of the road/river hexes 
> are drawn that way.

yeah but we should have a "center point terrain type", i.e. each hex
has seven terrain types.

I think just treating roads/streams/etc. as tris is the most reasonable thing 
without a lot more heavy work to the engine.

The problem is that this can't exactly handle rivers/roads that run through the 
center of a hex very well; the engine will treat them as being on one side or 
the other, or you can just call the whole hex that type.  I'm afraid the answer 
may just be 'don't do hexes like that then', but a lot of the road/river hexes 
are drawn that way.

- mikee

On Mon, 30 Dec 2002, Marcus Alanen wrote:

>On Mon, 30 Dec 2002, Jan Ekholm wrote:
>
>> I hate to admit, but I don't remember why I originally added
>> roads/rivers/fords as a separate column instead of doing it like this from
>> the beginning...
>
>I think this was my blabbering... (?) Probably my point was that
>there is no distinction between a road in the forest and a road on the 
>plains. If we even want to have such a distinction is debatable.

I think there could be some use of the distinction if we go down to really
gory details. But at that point the hexes are anyway too coarse, so I
think we can go ahead and do the change. It won't actually affect any
other code than the code that loads the hexes...

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

On Mon, 30 Dec 2002, Jan Ekholm wrote:

> I hate to admit, but I don't remember why I originally added
> roads/rivers/fords as a separate column instead of doing it like this from
> the beginning...

I think this was my blabbering... (?) Probably my point was that
there is no distinction between a road in the forest and a road on the 
plains. If we even want to have such a distinction is debatable.

Helo,

I've looking at the description file for terrains at:

	gfx/terrains/terrains.txt

It gives all needed data about all terrain types, such as the heights and
terrains in the triangles as well as the color for the minimap.

However, road, river and ford info has been separated in the file from the
terrain data. So an icon has been "100% woods with roads on triangle 1 and
4". I'd like to change that so that we can nuke the separate
road/river/ford column in the file and instead integrate it into the
terrain data. So the above hex would be "triangle 1 and 4 road and
triangles 2,3,5,6 woods". Would simplify things a bit.

I hate to admit, but I don't remember why I originally added
roads/rivers/fords as a separate column instead of doing it like this from
the beginning...

Comments?

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

Gareth,

Could you please put up a short blurb on the homepage that we're still not
dead? I tried to do it, but I didn't want to mess with your formatting and
the page was write-protected too.

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

On Sun, 29 Dec 2002 ml...@at... wrote:

> PS - yes, I do realize in 
> retrospect this borders on ludicrous overkill.  In my defense I will only say that it is a unique 
> feature, and that I was a math major.

Hi, I haven't yet read & digested everything you have said, although 
I think I understand the basic algo. Anyway, I feel it does _not_ 
border on overkill, we really do need the triangle granularity for 
something that is realistic enough. And mathmetical precision can 
provide that realism, so being a math major is cool :-)

I see two problems: there are some mistakes every now and then, but 
that can certainly be fixed. The real problem is speed.


I did a simple test whereby one guy walked so three enemy units could 
see him, and vice versa. Complete with all the other calcView 
calculations, the Line-Of-Sight for this _extremely small_ example 
took 1.6 seconds. Multiply this by a realistic factor of > 10 and we 
have a long delay for _each_ step in the action phase. 16 seconds * 60 
steps = too much.

( They were on a hill, otherwise no other 
stuff like forests etc., and I don't know if other units were nearby.
The point is, none of this matters because in real scenarios we will
have these kinds of calculations anyway. )



The current code perhaps calculates things twice, due to my 
mistakes/additions. Doesn't matter. Point is, we need to take a 
close look on how to cache calculations and avoid unnecessary 
calculations in the general case, code mistakes can always be fixed.

Almost half the time is used in the for loop in losValueFloat:
        for index in range(len(crossings)-2):
            A, B = crossings[index:index+2]
            ...

Anything that speeds this up is great, but doesn't solve the whole 
problem.



Misc todo stuff:

* Some algo mistake, since we get bogus LOS sometimes, try e.g.
  with the horrible graphical LOS displayer hack. No idea what the
  problem could be, tho.

* calcView() calculates twice:
            self.calcViewSingle (unit)
            unit.calcViewSingle (self)

* _All_ units should first be moved, then the LOS recalculations that 
  need to be done should be done. Thus, in move_act.py/MoveAct.execute(),
  calcView is called unnecessarily often.

* Check if the for loop could be optimized.

* Server should notify client "now unit A sees unit Z", since the
  server still has to calculate this and it's a waste to recalculate 
  the same stuff on the client sides as well.

* None of the above really solves our problem. :(

I guess we'll have to move 0.82 "Yule Feast" to a future date...

And in order not to sound pessimistic: Happy New Year!

Marcus

We should probably spit out a warning message if some unit gets stuck
somehow with a calculated speed of 0.00. I don't understand how this 
happened, tho.

Merry Christmas.

Marcus

calculateMovementSpeed: base speed 10, modified speed 0.83:
calculateMovementDeltas: 353.130540 0.833333 0.734327 -0.393964
calculateMovementSpeed: base speed 10, modified speed 1.67:
calculateMovementDeltas: 99.800000 1.666667 1.666667 0.000000
calculateMovementSpeed: base speed 10, modified speed 1.67:
calculateMovementDeltas: 97.785058 1.666667 1.664048 -0.093390
calculateMovementSpeed: base speed 10, modified speed 0.00:

Oops, something went wrong. Dumping brain contents:
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "civil.py", line 486, in ?
    main ()
  File "civil.py", line 478, 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 142, in update
    self.updateForStep ( step )
  File "engine/engine.py", line 197, in updateForStep
    self.runExecutor ( unit, step )
  File "engine/engine.py", line 270, in runExecutor
    actiondata = planexec.execute ( step )
  File "engine/executor/move_exec.py", line 109, in execute
    return self.move (step)
  File "engine/executor/move_exec.py", line 122, in move
    self.movespeed )
  File "engine/executor/move_util.py", line 97, in 
calculateMovementDeltas
    turns_needed = distance / float(speed)
ZeroDivisionError: float division
---------------------------------------------------------------------------



-- 
Marcus

Ok,

I think I committed a working implementation of precalculated height. I
also added the <valid/> and <invalid/> tags, which are also used. The main
game refuses to use invalid scnearios.

I'll try to dive more into LOS ASAP thanks to Mike's excellent
description of how it works. Thanks Mike!

-- 
        Five exclamation marks, the sure sign of an insane mind.
                                              -- Terry Pratchett, Reaper Man

So, it suddenly occurs to me that this would be an appropriate time to explain just what the heck I 
think the LoS code I wrote is doing.  The theory and algorythm is as 
follows:

Theory/model:

The board is composed of triangles, each of which has a terrain 
type and an altitude/slope.  Each terrain type has a 'visibility stack'; this is essentially a 
list/function that tells how opaque it is at a given altitude.

I.E., all terrain types are 0% 
transparent at/below ground level.  Most types have some obscuration just above that to some 
height (due to ground cover, grasses, trees) and are 100% clear at higher altitudes.  Note that 
these values are for looking through an entire hex worth of that material, and thus have to be 
adjusted down for less distance.

The 'base visibility' between two (3D) points is inversely 
proportional to the square of the distance between them (the light/apparent size would drop off 
as the square of distance), less whatever (cumulative) attenuation is caused by terrain 
obscuration; if I look through two full hexes of 80% visibility, it reduces visibility to 
64%.

Why triangles and not hexes?  Three reasons:  1) Math is much easier with triangles.  2) 
Some hexes appear to be composed of multiple terrain types, and we can approximate more closely by 
subdividing into triangles.  3)  If we break into triangles, we can give each a constant slope and 
have the map be continuous.

Computation:

We take our two points, and assume the 
watcher/target to be 3M tall.  Consider the 3D line between them; this is the literal LoS.  Taking 
just the 2D (top-down) view of that line, we figure out all the triangle edges it crosses, in order.  
The line segments between consecutive pairs of these points each cross a single 
triangle.

Now, start with the base visibility (constant / distance ^2).  We then run through 
all the triangles we cross, figuring out how much they obscure the view.  Well, how much is 
that?

First, we figure out which triangle we're crossing; take the midpoint of the segment 
and it's in that triangle.  Using the 3D version of the LoS vector again, take the worst (most 
obscured) altitude for the segment, which will be the lowest, and (because the triangles are 
flat) will be at one of the two points where we enter/exit the triangle.  Compare that to ground 
level at that point to figure out the height above ground level, then look that up in the terrain 
visibility 'stack' for the terrain type in this triangle.

Now, we have to adjust the 
visibility loss for the distance covered by that segment - this is a power thing, rather than 
linear, because of the way we multiply visibility together.  (For instance; if looking through a 
full hex-width of forest gives you 50% visibility, looking through half that gives you ~70%, 
because two half-hexes would be 70%*70% = 50%.)  Possibly clever things with logarythms might make 
all this power-fiddling into addition, but that makes my head hurt.

Anyhow, you now multiply 
the base visibility by all of the segments' visibility, and that's your result.  Ta-Da!  Being able 
to see further from hilltops, and not see through hills etc, should fall out automagically if the 
altitudes and terrain data are set up sensibly.


Note: this is from memory, not from the 
code.  If the code isn't doing quite this it may well be a bug...

- mikee

PS - yes, I do realize in 
retrospect this borders on ludicrous overkill.  In my defense I will only say that it is a unique 
feature, and that I was a math major.

>     * starting and ending points for the calculations (OK, done)
>     * a list of the hexes that the LOS 
traverses through 
>     * a list of the triangles in each hex that LOS traverses through

Well, 
the triangleCrossings method in map.py returns the list of all the places the LoS line 
enters/leaves a triangle, so you could calculate it from this with some mildly tedious work 
(might get tricky in odd cases where LoS actually hits the corner where three hexes meet).  
Actually, what you probably want is diagnostic output from that inner loop in 
map.losValueFloat; "midpoint" will have a value in each triangle crossed as it runs through that 
loop.

Right now the triangles are supposed to be initialized when the map loads to have slope 
(the code for this is there in calculateHexTris), but are actually inited as blank/flat in the 
__init__.  Ooh, I wonder if that's part of the problem?  Anyhow, I have code to actually use the 
calculateHexTris instead (it's a one-liner), but this added several minutes to the map load time, 
so I hadn't committed it.  If you're thinking about precalculating map height info, might go ahead 
and calculate those tris instead of just the hexes.  I had started to look at some of this, but was 
short on time - I think the existing LoS code is pretty good, might be overkill, is a bit flakey in some 
cases now and I'm not 100% sure why.

Am currently at the inlaws and don't have access to my Linux 
box and local code, sorry; am working from memory and the sourceforge web CVS here. :)  I should have 
some time mid-late January, but I'm moving in Feburary so heavy coding time will be pretty limited 
then.


Another useful diagnositic trick would be a terrain display mode that showed simple 
colored icons for terrain type (by tri?) and/or altitude.  Or maybe draw a spray of lines out from 
the selected point, running through some spectrum of colors as the LoS value drops?

- 
mikee

Uh,

I've been trying to grasp how LOS is being calculated right now, as it has
a few cases where it gives bogus values. To do that I'll add a playfield
layer (or use one of the existing ones) to visualize graphically how LOS
is being calculated. For that task I somehow would like to get the
following data:

    * starting and ending points for the calculations (OK, done)
    * a list of the hexes that the LOS traverses through 
    * a list of the triangles in each hex that LOS traverses through

With these I could draw the full LOS traversing mechanism and make it
easier to debug. The layer could paint the outlines of the affected hexes
and the affected triangles within those hexes.

I thought about integrating this into the existing "Check LOS" function,
so that we could simply check LOS from a unit to any point on the map. It
would then be a matter of doing a scenario with units in all interesting
(from a LOS point of view) locations to easily check and debug the LOS
calculations.

Another idea is to just allow the player to turn on some kind of LOS
debugging and be able to click on two locations in the map and see LOS
being calculated between those.

I've tried to get the info out from the code, and I think that the
triangles can be had directly. Hmm, then it should be possible to take the
triangles and take any arbitrary point inside them and get the hex they
belong to? Right?

Comments? After some serious thinking about LOS I do think we have a
pretty nice system already, but one which just does have a few issues that
we need to solve.

Once LOS works better I think we have a 0.82 ready to be released.

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

Hullo,

I had a small idea that would optionally speed up loading of scenarios a
little bit and thus make starting games a bit faster. Right now the
absolute height of a map is calculated when the scenario has been loaded
and is being set up, in ScenarioInfo.setupScenario(). Not a bad place to
do it, but what if the heights were precalculated and in the scenario
data? The editor already does the calculations before saving a scenario,
and it even warns that user if there are height errors. Couldn't we just
add a flag to the scenario info with that would indicate if the scenario
has been "validated" or if it is work in progress that is partially
incorrect?

Something like:

    <scenarioinfo>
      <name>Clash in the pass</name>
      <turns current="0" max="30"/>
      <location>Littletown</location>
      <date year="1863" month="6" day="18" hour="11" minute="30"/>
      <valid/>
      ...
    </scenarioinfo>

Change <valid/> to <invalid/> for an unfinished scenario. Civil would then
only try to load valid scenarios by adding a small check.

The actual height would be added to the <hexes> part of the scenario file:

    <hexes>
      <hex x="0" y="0" terrain="12" height="1"/>
      <hex x="0" y="1" terrain="340" height="1"/>
      <hex x="0" y="2" terrain="86" height="2"/>
      ...
    </hexes>

What do you think? This was just something I came to think about when
trying to grasp how LOS is calculated right now. 

Hmm, if we did this we only need the method Map.calculateAbsoluteHeights()
in the editor, so the editor could have an own class EditorMap that would
inherit the Map class and add editor specific code. Would reduce some code
from the Map class, as it is one of the larger classes already.

Comments?

Oh, btw, I hope you all had a really nice Christmas and got to eat
yourself stuffed and play with new toys. I'm personally running to the gym
almost every day now trying to fight the eternal Fat War (the Fat army
just got a few kg of reinforcements).

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

This is what I got after pressing the cd-eject button:

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 207, in handleEvent
    return self.handleLeftMousePressed ( event )
  File "state/state.py", line 319, in handleLeftMousePressed
    newstate, handled = layer.handleLeftMousePressed ( x, y )
  File "playfield/floating_window_layer.py", line 131, in handleLeftMousePressed
    handled = self.handleContentsClick ( x, y )
  File "playfield/audio_layer.py", line 151, in handleContentsClick
    self.callbacks [ buttonname ] ()
  File "playfield/audio_layer.py", line 312, in ejectCD
    scenario.audio.ejectCD ()
  File "audio_manager.py", line 410, in ejectCD
    self.cd.eject ()
error: CD drive not initialized
---------------------------------------------------------------------------

> Hey I installed pygame and python on XP. I installed 
> Civil-0.80-win32.exe to
> the default library. Did the home thing in control panel.  Document 
> states
> "To start the game on Windows or Mac OS X just doubleclick on the icon 
> that
> was installed along with the game. This will bring up the Civil 
> window."
>
> I see no icon to doubleclick??? Help. Also is there a version for XP 
> in 081...
> Thanks Curt.


Hi curt,

Apologies for the documentation, that was updated after the release of 
0.80 to reflect the plans for the win32 release from there on in. 
Unfortunately, I've not gotten around to updated the code to reflect 
the documentation, and 0.80 had to be rebuilt due to a bug I 
purposefully included to check that I was awake a few days later...

For now, try double clicking on the "civil.py" file in the /src folder. 
If that doesn't work, please email back and report the error. We'll try 
and help from there!

G

--
   "As soon as I find the right small group of girls, the seven
    or eight women who are right for me, my wandering days are
    OVER buddy! "
     -- Cat, Parallel Universe
--

Hey I installed pygame and python on XP. I installed Civil-0.80-win32.exe to 
the default library. Did the home thing in control panel.  Document states
"To start the game on Windows or Mac OS X just doubleclick on the icon that 
was installed along with the game. This will bring up the Civil window."

I see no icon to doubleclick??? Help. Also is there a version for XP in 081...
Thanks Curt.